Assigning tasks your developers will want to do

Getting developers to emotionally invest in tasks is the fastest way to improve motivation and performance.

Not every development task is easy, smooth or glamorous, and when the work itself is not it's own reward we have to think carefully about getting the developer to emotionally invest in the outcome.

So how do you help a developer emotionally invest in their work? How do you format and assign tasks the developers will actually want to do?

Here are the principles I try to apply when assigning work:

Ask for volunteers

Start by giving developers the chance to select their own tasks, or at least express an interest. This can be as simple as putting the list of upcoming tasks on a wall so people can see what's coming next and put their names against anything they would like to be part of.

Don't confuse contribution with commitment

When a developer makes a comment or contribution to a task, it doesn't always mean they want to be the one fixing it. Don't fall into the mistake of punishing ideas and bug reports with the work of implementing or fixing them. You need to know when feedback on the problem comes without any interest in being part of the solution.

Strike while the iron is hot

If a developer does show interest in being part of a task/feature/or bug, think about moving it up the priority tree and giving it them now rather than later. Take advantage of their interest or annoyance while it's fresh, as both are emotional motivations that end in positive satisfaction when they can do something about it.

Lighten the load

Stress can hinder development. Too many design decisions or too many solution options can make it hard to know what to do next. Use the buddy system on difficult tasks, assign a mentor or "back up brain" for complex tasks so developers have someone else to talk to about it, to bounce ideas off and so on. It reduced stress for the developer and gives the mentor lots of additional engagement for little additional responsibility.

Targets of opportunity

Small tasks can seem like a lot of work for a minimal benefit. Take the time to look for targets of opportunity when assigning work. If you have a task that addresses a particular feature or library, look for other bugs or features that will be in the same code, or can be solved the same way. These other tasks may not be as important but hitting two bugs with one update makes for a better sense of productivity.

Ask for advice

Your developers probably know the product better than anyone, so why not ask them for input on tasks? I've lost count of the times when instead of fixing something that was broken I changed the system so that it was no longer needed. Developers are in the best position to make suggestions on how to solve or avoid tasks altogether so take the time to ask what they think and actively listen to their answers. Even if they don't have anything to offer they will feel better for being in the loop.

Invite recognition

When your product designers, testers or support guys let people know about a bug fix or feature, get them to CC the developer responsible. This reminds developers of the reason for the work and puts a human face on the people who benefit.

These approaches all address the reasons why developers like or dislike tasks. Material rewards are fine but why have a person working for the bonus or working for the prize, when what you want is a person working for the fix, for the solution, for the next release and the happy user.