Paying programmers: are bonuses bad and what to do about it?

Marry Poppendieck talked today at Agile 2008 about compensation schemes, attacking the traditional model of bonuses and appraisals. Pointing out that a traditional bonus system undermines teamwork and implies that most people will not do their best without additional financial incentives, she suggested focusing on more immediate and non-financial motivation techniques.

Quoting Jeffrey Pfeiffer’s testimony to US Congress in 2007, Mary Poppendieck said that there is a lot of evidence that intrinsic motivation is much more effective than external factors such as financial bonuses, pointing out that external motivators can actually undermine intrinsic factors. Opensource projects, for example, work because people care about them and starting to pay some of the contributors will negatively affect the motivation of other contributors on the project.

Citing a research by Arie de Geus, author of The living company, Mary said that highly successful companies foster a culture which does not use financial compensation as a primary rewards motivator. The same research shows that those companies pay people above market rates to to reduce turnover and attract the best people, coupled with rewards that share organizational success, but money is not the primary reason why people work there. As an extreme case, Mary mentioned Tandem Computers, who according to her gave no salary information on job interviews. Their CEO was of the opinion that people who come for money will leave for money and did not want those people onboard.

Team payment does not work

Mary said that 80% compensation systems reward individual, not team performance and that
only 10-20% of appraisal systems include team performance, causing a lot of competition inside teams that discourage team behaviour. In software development, it is very hard to establish the effects of individual contributions and good teamwork is key to the project. Most individual compensation schemes, according to the presentation, absorb vast amounts of management time and resources and leave nobody happy, but team compensation strategies are not easy to implement. Mary presented results from HP’s experiments during the beginning of the nineties, when HP allowed 13 local organisations to experiment with team-incentive plans. All programs were discontinued by the 4th year, due to constant changes to the plans which were needed to distribute available money among the teams and a wide dissatisfaction with the plans by employees. On the end, all projects concluded with no relationship or negative relationship between actual incentives and performance. San Diego team pay for performance program started great, with everybody feeling very positive about the plan in the first six months and most teams outperforming their goals. However, that meant that a lot more money was given out than HP planned for, so the standards were adjusted in the next six months which met stiff resistance. High performance teams started excluding new members, managers felt that teams concentrated on money not jobs and the plan was discontinued because it caused way too much hassle.

Mary also gave a case study of a high performing team that was given a large bonus to distribute internally. Everyone agreed that individuals should get a part matching their contributions, bot no one could agree on individual contribution levels. After a heated discussion, team decided on an equal split which left everybody unhappy, and the same group of people never worked again well as a team.

Instead of financial incentives, companies should focus more on encouraging and training teams to provide internal intrinsic positive feedback and non-financial positive reinforcements, according to Mary.

Fair compensations are effective

Citing a research from Elliot Jacques, she said that the most effective financial compensation schemes are those that are felt fair in the organisation. Differences in salaries can exist between different levels that are perceived fair. In software, criteria that is generally accepted fair are the timespan of discretion (how long can you work without your boss looking over your shoulder) and job complexity. That kind of compensation schemes is, according to Mary, validated by many studies over several decades. An especially important idea was that the money should not be used a differentiator at the same level, and that if money moves rapidly in the market, everyone in the company should be moved up regularly, not generating a gap between new hires and older employees.

On the end, Mary gave some advice on effective incentives and compensation schemes:

  1. abandon the zero-sum game: eliminate competition for a bonus pool
  2. tell people directly what’s important and why. it is cheaper and easier than financial incentive systems signaling what is important
  3. base pay differentials on job complexity, avoid individual performance bonuses because they extinguish collaboration
  4. base collective rewards on broad measures — the larger the group that is measured, the more reliably performance can be accessed. Use profit sharing schemes instead of bonuses to tie people to the organisation goals.
  5. keep in mind the norm of reciprocity — if people feel that they are being treated generously, they will reciprocate it with increased discretionary effort.

read other news from the Agile 2008 conference

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Product Owner Survival Camp

Specification by Example Workshop

Conference talks and workshops

8 thoughts on “Paying programmers: are bonuses bad and what to do about it?

  1. This is just my view..

    While laying out compensation schemes for a team (or Individual), some technical expectations should be defined like expected test code coverage, expected coding standards, code complexity, design standards etc etc.

    Sometimes developers have this tendency to skip writing test cases to make it to deadline


    skip test cases / not follow coding standards / not make proper design decisions / skip documentation in-order to impress the business by delivering more and quick (This will hurt the project in long run).

    Business is always happy as long as their requirements are delivered before deadline but they do not realize if code does not follow standards it would get harder to make enhancements.

  2. Bharat,
    A good team will use peer-pressure to influence the individuals to meet the coding expectations/follow the standards.
    Tying the compensation to the complexity of the work is fine, but you can’t tie it to a particular metric, because developers will always find ways to “game” it and it will become useless and actually hurt the project: everybody will pick the easiest parts so they can look good in terms of test cases, standards, and complexity…

  3. Pingback: Curious Cat Management Improvement Blog » Individual Bonuses Are Bad Management

  4. As a programmer, I would not work harder than I normally would for bonuses. I do my job on the time frame I specify to the quality required for the project. My free time is worth more in independent contracts than it is in bonus money anyway. If my boss were to offer me a bonus, I would be resentful, as the article stated. I would not appreciate the insinuation that me killing myself over a small paycheck increase is worth it to the company, that I’m not giving 100% of what I’m paid as-is, or that I am like a donkey with a carrot dangled in front of it. Pay me well and I will do what I feel I am paid to do. Pay me more, I work more. Simple as that. This would make me feel like I’m being paid *less* if I do not get the bonus, NOT *more* if I get the bonus. All in all, bad idea for programmers or anyone with an ounce of dignity and self respect.

  5. Bharat,

    I’d love to work for you. I bet I could pump out twice as many tests as any other employee. I’d be rich.

    Or I’d point at your design decisions (which you chose one design out of an infinite number of possible solutions) then offer a better one thus reducing your pay and increasing mine. But better yet, I’d offer a slightly better solution first, then 6 months later offer another slightly better solution. This would ensure my bonus never dropped.


  6. I have to admit I never would’ve thought group based incentives would have turned out so poorly. But when you describe it, it makes complete sense. You get what you’re paying for, but it isn’t exactly what you want.

    Like you say, there’s a big dis-incentive for the team to bring on new people. More money to share, but more importantly they have to brought up to speed very quick. I can see it really creating tightly nit groups (cliques) that work well together and don’t want to change since they know they can outperform.

    And the moving target can be very de-motivating. Groups will definitely perform at different levels. And different projects with different expectations will quickly change the effort to reward ratio, bringing on resentment, etc.

    Again, very thoughtful. I wouldn’t have thought, but then I’ve also never experienced this type of pay incentive. I don’t think I want to either ;)

  7. I never saw bonuses as a motivational factor. For example I worked at a company where there was a bonus on a sliding scale, more effort more bonus money. The problem was the max value was $5000, now suppose you worked on average an extra 5 hours a week for the year. If you hit the max bonus level then you would make $20hr for that overtime, less than half what I would have normally made. Not much of an incentive.

    I also worked at a company where the “senior” engineers got to work from home, got the latest and greatest equipment, got sent to conferences, etc. This lit a fire under everyone, junior engineers had a solid goal to work towards, and the senior engineers were motivated to maintain the high standards that got them their. Of course what helped was an overall feeling of comradery, senior engineers enjoyed their position and would also take pride in helping and mentoring the junior engineers.

  8. I approve that for very short term the bonuses work fine. But on long term they will pervert people.

    I work in a company were the bonuses are widely used and from mu point of view the system failed.

    Let me give you some examples :

    - One collegue (does some kind of data entry job) got a bonus proportional to the turnover she generates. Since there is no way for the management to hire new people and the development of this service is now blocked.

    - The salesmen also bonuses, of course. They may drop good deals because they have no bonuses on them.

    - The development team has no bonuses but works hard on projects that will be sold by the salesmen who will get bonuses. So finally the development guys are less and less motivated. From a point a view development+sales=one team, so there are bonuses but not correctly distributed.

    In the end a lot of energy is focused on this bonuses and the people are still not satisfied.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>