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.