Destructive bonuses

Many if not most of software development companies employ some kind of the bonus plan for their developers. Developers or teams get a set of targets to reach and depending on the target fulfillment the bonus is paid. The idea of compensating the extraordinary performance and success is a good one. Unfortunately there two major problems with the bonus plans:

Expected bonus is not a reward

As Joel Spolsky puts it “They [bonus plans]’ve become like tips in restaurants: everyone expects one, so they can no longer be used well to award performance”. Most of the good managers I’ve heard of try to plan the bonus targets so that their subordinates would get about the same amount of money whatever happens.At the time when there is a reasonable lack of programmers everywhere, it is just too dangerous to have an employee that expected the bonus, but didn’t get it. The received bonus feels like something expected, while the one that was not received feels like a punishment and most of bosses wouldn’t like their employees to feel punished.


Whatever is the bonus target it effectively forces the person to optimize towards the concrete target. That’s not bad idea on its own. Unfortunately, there are so many aspects of software development, that it is too difficult to define a set of meaningful metrics to optimize for. Programmers are clever people and whenever there is a request to optimize towards a certain goal, it is usually possible to game the metrics and actually make things worse (since the problem is not removed, but rather hidden). For example, if the bonus target was to reduce the number of critical bugs per month, one of the ways for reaching the target would be to reject the bug reports as long as possible, to move them to another slightly-related departments, to claim that these are “features”, etc. As a result, the system would look better (since less bugs are in the bug system), but would actually become worse (since less bugs are actually acknowledged and fixed).

Salary raises

There is so much potential harm in the bonus plans, that frankly, I fail to understand why so many companies keep using the bonus plans. The only reason I could see is if the bonus is seen by the top management as the method for implicitly cutting salaries, whenever the company results are not too good. To me the potential employee disappointment feels like too big price for such a method. If the company is doing really bad, cutting the bonuses out won’t probably be enough, and if the company is doing just a bit bad, the disappointed programmers is the last thing needed for getting out of trouble.

Do you find your bonus plan motivating useful? Would you trade your bonus for the almost equivalent salary raise?

4 thoughts on “Destructive bonuses”

  1. Nice to find your new blog, Artem 🙂

    …but to the topic. I remember reading somewhere (I think this is a well-known fact in behavioral sciences or something) that people and animals improve their behavior to the wanted direction the most, when the reward or “negative reinforcement” is unpredictable.

    I just looked up a quote from a great reference book that I found last year “The Universal Principles of Design”, page 144: “An optimal behavior modification plan typically includes predictable reinforcement early in training and less predictable reiforcement later in the training”

    So, regarding the issue, you are spot on.

    1. I was not sure that you are interested in agile methods, Tommi. Otherwise I would have sent you a link long time ago 🙂

      If you have a bonus plan, do you yourself consider it useful, useless or demotivating? Would you personally trade it for a bit smaller salary raise?

  2. In one company a team was promised to be promoted by a small bonus in the next month for their hard work. After the promise, the management hired several undergraduates and put them on the project in question. So, obviously the new guys had no idea of the system under development, their learning took time and the main developers had to mentor them and lose valuable time.

    The month arrived and the bonus was postponed to next month. And then to the next and to the next, over and over again and then the management saw that the new implementations (that were made after the initial disappointment for not getting the bonus and already in another development cycle) took more time than the developers had declared and then the main developers were told to forget the bonus. The usual salary was already much below the average and then – no bonus too!

    Consequence: the company’s reputation falled like a rock from a cliff edge, and many employees started to leave.

Leave a Reply

Your email address will not be published. Required fields are marked *