Software Development

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.


Ben Evans is a consultant, an IT pro, occasional CTO, system architect, JavaScript Jedi, and blogger. Ben has run his own business, been a program manager at Microsoft, a tech director for a London design agency, a contractor on the BBC iPlayer proje...


Well, tick tick tick, all correct. :) Just check my reply to Timothy for some comments about it… feel free to add your own comments if you want as I'm not infallible myself and could make a mistake or forget to mention something :)


Situation is difficult when there is a big team and handling them is quite a challenge. Often organization look out for tools that could help reach out to the destination. And similarly in our organization too we depends on the cloud based task management software from Replicon ( ) which is a hassle free tool and is all featured with the user friendly and calendar based interface which makes it an intuitive tool to work with.

Tony Hopkinson
Tony Hopkinson

It's easy to get ownership, just stop taking it back, when expediency rears it's ugly head.


Whatever happened to hard-earned money? Why are developers paid such higher than average salaries for their contribution to business development? Product owners need to take ownership of their products and expect hired developers nothing but the best at what doing what they were hired to do, which is suppose to be what they love most, and that is to work as a unit to reach the common goal of quality and timely delivery of software. The title of this post describes weak management and not strong leadership.


Creativity and passion can greatly influence both the speed at which a piece is completed, as well as the quality of the final product. You want cogs in a wheel? Why would you force me to do something another developer was just dying to do? Or was at a better point in their development to learn more from a task? No one is suggesting there aren't times when things just need to get done, but a project generally consists of many small projects, so why not assign them in a way that will inspire the best outcome for everyone involved when possible?

Editor's Picks