How does one create an enthusiastic development team? [closed]

Question

If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development?

No gimmicks, but a genuine move to create an environment where people want to work in software, not just because the company is a good company to work for overall.

Answer 1

In my opinion, the absolute, #1, most essential thing that motivates developers to be enhusiastic about their work is a sense of ownership over their product. All the team-building excercises, reading groups, etc. are good but ultimately ineffective if the developers don't have a sense of ownership.

Here's a quick, off the cuff list of things that are important, in my mind, to ensuring this is the case:

• Developers have a real and honest stake in the future design of the system. There will always be requirements that come from outside the development team, but developers should be represented when those requirements are discovered and be able to give real input into the future state of what you're working on.
• Developer championed requirements or changes to your solution should be given a voice. A balance needs to be found, certainly, but all too many companies don't have proper mechanisms to allow pure development-focused requests to get through. These could be product enhancements, building up unit tests or simple refactorings, but they are essential to the quality of your product and for giving developers a stake in your project.
• Developers should have contact with users. A development staff that's treated like the guys in the basement who churn out code are never going to have a very enthusastic approach to the product or developing their own skills.
• Embrace new technologies, even if it's only for a PoC or prototype of what the technologies can do. No developer in the world has ever been excited about churning out boilerplate code, and they never will be.
• Let development teams own their process. Development methodolgies decreed from on-high will without fail demotivate the development team, who now need to deal with the added burden of planning meetings and waterfall development. Require that a process exist, but until there's a problem, keep your hands off the specifics.
• "Just the way things work" is NEVER an excuse for a broken process. If developers have a legitimate concern with a process they need to follow, they need a honest chance to argue against it. As a manager, one of the worst things you can say is "That's the way the VP / Executive / CEO / God wants it, so we need to follow it". You need to champion your developers concerns, or failing that, allow them direct interaction with the person in question. If you as a manager are viewed as a sockpuppet for the executive, good luck ever motivating a developer again.

Answer 2

Shield your developers from all the politics to the best of your ability. Let them what they do best, develop software. Nothing kills a productive team like having to squabble in inner-office politics.

This well-known conversation says it best:

Peter Gibbons: Bob, I have eight different bosses right now.

Bob Slydell: I beg your pardon?

Peter Gibbons: Eight bosses.

Bob Slydell: Eight?

Peter Gibbons: Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled, that and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.