Merit Based Pay

Conventional wisdom tells us to take the top performers and reward them highly. The theory goes that if they aren't recognised and rewarded, they will soon leave to better opportunities elsewhere. Even if they don't leave, they will soon be demotivated and put in an effort comparable to the weaker performers. After all, the reward is going to be the same!

Conventional wisdom is wrong.

Do not reward the better programmers any more than the weaker programmers.

By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.

The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:

• Annual salary or merit reviews
• Management by objectives (MBO)
• Praise of certain workers for extraordinary accomplishment
• Awards, prizes, bonuses tied to performance
• Performance measurement in almost any form

If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.

Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.

In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.

One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?

Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.

The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.

Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.

Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.

Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.

No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.

This post is a part of the selected archive.