Motivation for a development team?

Question

In two and half months I have successfully brought a team from the brink of doom to being a successful development team. The project is a using new .net technologies (MVC, EF), has new tools, and the team members have a large say in how a feature will be created, designed and implemented.

What I want to do for the team is to keep this momentum going. I think the motivation is good and the project is interesting enough that it won't bore someone just yet, but I know that as time goes on, doing the same thing over and over lowers the interest level.

What as a team lead can I do to make sure that we keep up this high level of motivation we have right now?

Answer 1

Read Drive: The Surprising Truth About What Motivates Us

It contains some good insights into how to motivate and which pitfalls to avoid. It's really easy to mess up and kill motivation by offering external rewards ("I worked my ass off and got a movie ticket, gee thanks") so don't do anything hasty.

That being said a somewhat difficult but fun motivational tool to implement would be to make development gameful. Build a leveling ("Level 4 programmer, Level 10 tester") and badge ("You just earned the bugslayer badge!") system. Team-members get experience points for fixing bugs, meeting milestones, shipping etc.

To start things off you can give them 1 experience point retroactively for each day they've worked in the company and like 100 points for each project they've completed and then level them up accordingly. Level on a curve so that it's easier to level up in the beginning but requires more points as you reach higher levels. Make leveling fun and put some kind of ceremony around it or at least send out an email to everyone in the team when someone levels so that they get some recognition (good for pride). Only offer experience points for things that truly matter or the whole system will only seem dilbertian and stupid ("What mineral are you? Lint...").

Tying levels to monetary rewards is tricky and requires serious thoughts so that they do not backfire. You should be paying them well anyways and monetary rewards aren't that effective. Better to let them "unlock" different perks as they level up, starting with small ones like upgrading their "gear" (monitor, computer etc) to really good ones at higher levels (have a day off every week to work on personal projects/ Personal washing service) and really really good ones as they reach like level 60 (1-year long sabbatical to do whatever the heck they want) so they have something to aim for.

The perks should be above the baseline of what you currently offer, and don't lower that baseline just so that they can level up to it. Ie if everyone at your company gets dual-monitors 24" than you have to offer a perk above that ("dual 30" monitors!").

Also, come up with fun badges for different stuff, both on a team and individual level.

Make sure to promote co-operation rather than competion. Ie, "how many bugs can we fix together" rather than "who can fix the most bugs". Might not work on all kinds of people (like stodgy 60 year old COBOL programmers) but I bet many would enjoy it

Reality is broken is another really interesting book on this topic.

"Achievement unlocked: Shipped!"

PS. If anyone implements this, be sure to leave a comment (or link to a blog entry) on how it works out so we all can learn from your success and mistakes :) DS.

Answer 2

Sounds like you are doing the right thing, just keep doing it.

A couple of things (which your team may already be doing, but they are worth mentioning nevertheless):

• Conduct regular retrospective meetings after each iteration to discuss what went well (and should be continued), what went wrong (and why), what to improve (and how). Then act upon the findings to continuously improve the development process. One of the major motivation breakers is the feeling that one has no power over his/her (work) life - so give them the power to change / eliminate whatever they are unhappy with (within the project at least :-).
• Make sure the team gets to succeed together often enough - the more the better. This is a major factor in team cohesion. If regular development projects don't provide enough challenge, you can focus on improving the development process itself (e.g. by increasing your Joel Test score), or introduce external stimuli, like pet projects to learn interesting new technologies.

See also this related thread.

Answer 3

Motivation is tough to create, in some tasks it is organic and in others it is more of a struggle. Heck, I would be highly motivated to start a new project with MVC and utilizing EF (EF being probably one of the few things Microsoft has gotten RIGHT in recent years).

Other things like writing tech specs, and testing can be more of a bore and it is hard to stay motivated.

A good example of creating motivation is the stack exchange sites. Reputation points and badges, meaningless data constructs are sought after and this creates motivation from intelligent posters who otherwise wouldn't waste their time on these sites. We seek them anyway because it can become a competitive game to see who gets the best score.

Try setting up a point system in your sprints. Whatever estimates for your user stories are, use those units of completed user stories towards their point total, and then also keep a par score for comparison of original estimate to actual effort. If you got the task done in less effort then you are under par, if you are behind schedule you are over par.

This will help turn friendly competition into motivation.

Answer 4

Start tackling ways to do things better. As a team, look at your slowest or most painful processes, or investigate industry options for doing things better and as a team, agree on a next step that would improve the product and/or the life of the people developing it.

--OR-- look at your architecture and your feature wish list and tackle one of those features that is likely to require a major new piece of architecture or a fairly significant change to what you have. Change is good. :)

I think people like challenges, and what challenges programmers is either building things that are hard to make, or making the way you make stuff better.

Answer 5

I think you should try conducting 'code retreat', 'code jam' or 'Hack day' sessions where you ask them to work on a new language/tool which they have been thinking of working for sometime. The teams should be told to build some tool in those languages by end of day. They may come up with 'reusable assets' this way.

No judgements at end of day but a good experience for them to take a look at what others worked on and how they approached it. A great tech learning experience. Company benefits from reusable assets.

Also try 'group study' ideas.

All the above, I think will bring up tech vitality in teams and keep them motivated.

Answer 6

Different things melt different snow flakes. As a manager, try and build a strong rapport with the team, you will automatically realize what moves a person. Then work with them to help them achieve that (more money/name/levels/recognition...), this is the biggest thing a manager can do. These are the kind of managers who I still remember and want to work with.