Think twice before creating a bonus system


Before opening the Pandora Box, read this or regret.

What should you do when your team is underperforming or misaligned with your company’s strategy? One solution you might think of is implementing an employee bonus system, after all humans reward desired behaviors for centuries, either with sugar cubes, toys, or bonus paychecks. Be advised that you’re playing with fire. One misguided step and you might reduce to ashes your authority, your teamwork environment, and your products’ quality.


horse race

Since “you can only manage what you measure”, first you need to define how you’ll evaluate your employees. Simple, objective and consensual metrics will be the foundations of your bonus system. Evaluators and appraisees should understand how each metric score is calculated — that means that in the event of the evaluator being replaced by another person, the new evaluator reaches the same scoring. After several drafts and meetings, you finally reach a conclusion of how and which metrics will evaluate employees.

The point is, no matter what you measure, humans (not just programmers) get very good at optimizing to meet exactly that thing. Joel Spolsky

For a moment now, recall the days when you were at school. Imagine that a teacher gives out in advance the questions of next week’s exam. Will you study everything or just the best answers to those specific questions? Now back to the present. Will your employees waste time and energy doing things that do not contribute to a better evaluation? Time for things like tests, teamwork, innovation, documentation?

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead is to check in lots of buggy code and fix it, rather than getting it right in the first place. When you try to correct this by penalizing bugs, they’ll hide them. You can’t win. Joel Spolsky

Those who work for the metrics will get ahead of those who work for the people and keep spending time on unmeasured things. And when the latter group figures that out, they’ll eventually join the former. At this point you either give up on metrics or add up all the missing metrics describing every employee’s responsability. So much for your simple scoring system…


This short (true) story illustrates most bonus systems. During the kickoff meeting, everyone agrees to share a bonus among each team member according to their contribution to the project. After the project is completed, the team meets again to determine how much each member will receive. Some argue that their contribution was higher or more important than the others, some disagree, and the rest just wants to get over it. In order to end two hours of intense discussion, everyone gets the same percentage, and no one wants to work with the backstabing, arrogant, greedy colleagues. As a manager, you paid extra money to destroy a previously healthy team.

The whole point of employing someone is that you pay them a fair salary and they do the best work they can. If your workforce is not giving 100%, then you probably have bigger problems that can’t be solved by waving bonuses around. Simon Harris

Decades of research have confirmed, again and again, that bonus systems rarely have a positive effect on people’s performance when they perform intellectual work. Bonuses do work on repetitive no-brainer tasks, but when it comes to creative and knowledge work they do more harm than good:

  1. Individual rewards disrupt collaboration. They also stimulate competition and individualism, destroying relationships between colleagues and their managers.
  2. Reality is too complex to measure with simple metrics. Those metrics ignore the soft side of great performance, including teamwork and collaboration.
  3. Bonuses represent an additional distraction and pressure, disrupting creative thinking and increasing employees’ stress’ levels. This causes them to play safe and prefer easy tasks, since innovation requires the opposite: taking risks, doing complex tasks, and probably missing the bonus.

In the words of Dan Pink, “all you can do to motivate knowledge workers is to give them interesting work and autonomy.”

Is there hope?


By now you should be thankful for finding this article before implementing that bonus system you kept thinking about. With so many pitfalls, should you give up the idea of such system?

There are no best practices. Only good practices in context. Agile

The secret is learning from experts and their latest researches, from other companies’ experiences and their mistakes, and finally adapting all this knowledge to your company’s context. Your success depends on the kind of people you manage and the relationship you have with them. You’ll have to tweak your system a few times before everyone is happy with it.

There are some advices you can follow when creating your own system:

  • Explain clearly what’s missing. Don’t make your employees guess from your actions.
  • Avoid individual performance bonuses. They murder collaboration.
  • Measure team performance. Peer pressure will do the work for you.
  • Track your Karma. Justice and generosity nurtures motivation; afterhours destroy it.
  • Share profits instead of bonuses. That way you tie people to organisational goals.
  • [Option A]: Set a fixed % of the bonus for every employee, thus removing competition and preserving relationships.
  • [Option B]: Set a dynamic bonus based on job complexity, thus rewarding those who tackle hard projects.

If you really want to go the metrics way, this site suggests interesting metrics for software-based companies to measure Productivity, Engagement, Quality, Code Base knowledge, Adherence to guidelines, Skill learning, and Responsibility. I’ll list my favorite of each category, in the same order:

  • Does the developer get a reasonable amount of work done in a given period of time?
  • Is the developer dedicated to company success?
  • Does the developer thoroughly test code and believe it to be correct before checking it in?
  • Does the developer take responsibility for his/her team’s code base, improving it at every opportunity?
  • Does developer’s code routinely meet coding standards?
  • Is the developer constantly learning and improving his/her skills?
  • Does the developer take pride in their code, ensuring it is clean, tested, easy to read, and easy to maintain?