If there were infinite time in the day and infinite budget, developing software would be a lot simpler. You just spend as much time as you want writing code until the thing is done. Wouldn’t that be nice?

Of course, we all know that’s not the case.

There’s only so much time and there’s only so much budget. And if you use too much of either, you have to have one of those shi*ty conversations with a manager who has no idea what it takes to write software in the first place.

This is the root problem that drives many of the difficult parts of software development.

Trying to balance time, resources, and effort–to make things work, but without spending too much time on them. And from that, we see that many teams are looking for ways to help–or inspire–their software developers to be more efficient or more productive.

Conventional wisdom, of course, says that if you want to motivate people, you just have to give them the right incentive.

Give people stuff and they’ll perform better.

It might be surprising to learn that there is actually some research that backs this up. Even when it comes to problem-solving and creative exercises, the right incentives can lead to better performance.

One recent study analyzed the performance of participants trying to solve escape room puzzles. Researchers studied more than 900 groups and over 4,000 total participants. Some groups were offered a cash incentive for completing the escape room in under 45 minutes, other groups weren’t.

The results were pretty clear: Money talks.

Teams not offered an incentive only completed in under 45 minutes about 10% of the time. But, those who were offered a reward for faster competition beat the 45-minute mark in more than 25% of cases.

While escape rooms aren’t quite the same as refactoring a codebase, it’s actually pretty similar, intellectually, to software development. In order to solve the puzzles, participants need to deploy critical thinking, teamwork, and pattern recognition.

So what we can learn from this study is that, under the right circumstances, offering an incentive may be a way to drive more performance from the team.

Where Incentives Come Into Play

How and when you should deploy incentives depends a lot on the type of activity in question and your desired outcome.

There are four types of work or tasks that we perform:

• Routine manual tasks (e.g. sorting or repetitive assembly)
• Routine analytical and interactive tasks (e.g. repetitive customer service)
• Non-routine manual tasks (e.g. truck driving)
• Non-routine analytical and interpersonal tasks (e.g. forming and testing hypotheses)

Just like escape rooms, most of the work related to building software would fall squarely in category 4–“non-routine analytical tasks.”

In routine and manual tasks, there’s generally a clear link between incentive and output. It just makes sense. People work quicker and more diligently when they’re properly motivated to do so.In other words, it’s a job that requires problem solving abilities and critical thinking skills. And the answers are not predetermined; nor is the work routine in nature.

But, when it comes to non-routine and analytical tasks, most people assume there isn’t the same kind of link. The science says otherwise.

Nevertheless, it’s important to remember that although incentives can drive performance under the right conditions, they aren’t a sure bet in all scenarios.

We need to consider the context of the incentives and when and how they are deployed.

How Not to Use Incentives for Software Teams

While you can offer incentives that help to drive performance, it’s not a fool-proof plan.

Any amount of objective reasoning will point out the obvious flaws in using strictly a carrot-dangling approach to driving performance from software teams.

Not Everything Can Be Incentivized

For starters, there may not be a way for someone who is working on a problem-solving task to speed up or improve their own performance. It’s possible that they are already working at the limits of their abilities and no incentive will ever be able to push them to solve the problem faster.

Sometimes, you just don’t have the right answer. And someone offering you $20 won’t help the solution pop into your head on its own.

In this case, offering incentives can seem like an unfair or arbitrary mechanism. As a developer, I would be pissed if you gave out rewards based on something that seems entirely out of my control.

Incentives Can Kill Creativity

Secondly, incentives fall down when you are trying to get people to apply creativity or look for new and unexplored ways of thinking.

Again, this is clear if you consider the circumstances. If you reward me for coming for finding a solution more quickly, then I am likely to accept the first solution that comes to mind. I’m not going to explore other possibilities–which may be more ideal–and risk the reward that’s being offered.

Studies have found a negative correlation between incentive and creativity or insight.

This tells us that incentives should only be used in a closed context; where there is a definitive solution that meets the requirements and there is no adverse effect for choosing an inferior solution.

In other words, expect that incentives will drive developers to find a “quick and dirty” way to solve the problem–make sure that won’t create more issues later on.

Incentives Need to Make Sense

If we look at the original experiment, there are some variables that are not fully explored.

For instance, the teams that were offered incentives for completing the puzzle in under 45 minutes then had a frame of reference for how long it should take them. This, no doubt, triggered an anchoring effect, priming them to expect the task to take that long.

When it comes to software teams, this means that the frame of reference used within the incentive structure could influence the actual performance. If you offer developers a bonus for completing their tasks in 6 hours, then they expect that the task should take about 6 hours. But, if you offer it for anything under 12 hours, it changes the expectation.

So, when using incentives, the threshold shouldn’t be arbitrary.

If developers have an empirical sense of how long a task might take, they’re better able to gauge their own progress and have a frame of reference for what is realistic. On the other hand, if estimates are just a handwave and a best guess, there’s nothing tangible that makes it a realistic or even reasonable assumption.

Timetracking and historical data can ground estimates, goals, and incentives in the real world.

Incentives Are Not a Long-Term Solution

There’s another important thing to know about incentives.

The science in the original study doesn’t really touch on this topic because the incentives were just for completing one-time tasks.

But, incentives can’t go on forever.

Eventually, what was once an incentive just becomes table stakes. As soon as the team doesn’t earn that incentive, they feel like they’re being robbed–punished–rather than simply not receiving a reward.

The team comes to rely on the incentive. Or, worse, they figure out specific levers to pull just for the sake of triggering an “incentive”, at which point it’s no longer really an incentive so much as a ransom payment.

Another potential risk is the concept of moral licensing. If you offer someone an incentive for meeting a certain goal or deadline, they may feel justified in not accomplishing it and simply losing out on the bonus. So, if your incentive plan is tied to an actual project deadline, it could easily backfire.

This tells us one thing clearly. Incentives should be used with care and precision.

Don’t walk around offering fat bonuses to anyone who completes their iteration tasks in 3 days. You’ll warp the motivation structure and drive unwanted behavior.

So, How Should You Use Incentives for Software Teams?

While there are many pitfalls associated with offering incentives for software teams, there is some potential upside.

As with most mechanisms, it all depends on how you use them.

How you should use incentives:

• Deploy incentives in special cases where they can’t be easily gamed or manipulated
• Offer incentives for problems with a clear set of solutions and acceptance criteria
• Use incentives to drive performance in ways other than speed/efficiency
• Tie incentives to real-world outcomes and anchor them to achievable goals

There’s no perfect playbook for how incentives should be deployed in every situation. But with the right parameters and careful use, they can be an effective tool for managing and driving performance for software teams.

The keys are caution and care.

Incentives can easily drive unwanted or unexpected behavior. So, managers should be diligent about considering how their offers might be perceived or ripple across the team.

Don’t just dangle a carrot and expect miracles.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.