Everyone wants the developers who are working on their product and service, to like what they are doing. Certainly if they are not happy they should go and find something that will make them happy and interested in what they are doing. But also if they do show enthusiasm by making suggestions of how changes and improvements can be made, you as the product owner will want to recognize that enthusiasm.
Last year I wrote several suggestions for product and engineering owners on how to get their teams to be more proactive - http://blog.softjourn.com/2010/09/
The enthusiasm issue falls along the same line. First of all when thinking about enthusiasm, think about what you believe constitutes showing enthusiasm. Often times product owners think that enthusiasm is shown by working a lot of hours. Sure, sometimes that will be necessary, there are deadlines, or issues that come up at the last minute. But really does working overtime, all of the time, show enthusiasm? Or is the person just finding it difficult to get going on what they are supposed to be working on, therefore it is taking them longer? It really depends on what they are accomplishing.
A better way your developers may be showing enthusiasm is by their suggestions. They are digging in to your system, learning it inside and out, and then they hit upon some ideas to make improvements, and they want to show you what they mean. So they work on their nights and weekends and come up with examples of how to technically improve the system; to make a system easier to maintain, or to make it more scalable, for example. They work nights and weekends to show what could be done, how long it would take and what would be the benefits. Then when they make their final presentation their enthusiasm is met with, not with enthusiasm in return, but rather a “not developed here” attitude, or “that is not your job” attitude. Of course their ideas may not fit the long term goal of the application, especially if it was not clear to them what the long term goal is. But maybe at least part of it will work, or maybe you can make suggestions as to how they can change it so it will fit the long term goals for the application. But to outright kill ideas that your people have spent time on (whether they are in-house, or a distributed team, or an outsourced team) will kill long term enthusiasm which will hamper the development of new ideas in the future. Think about that the next time you think your team is not showing enough enthusiasm. Have they in the past and you weren’t receptive to it. If so, you may have to work harder to get that enthusiasm back.
