Agile Compensation

The subject of determining compensation for developers on Agile teams comes up from time to time on the mailing lists. I’m no HR specialist, and I don’t have any easy answers to this question. It seems certainly true that some people will have provided more value than others and should therefore be given more reward. It is also certainly true that if the reward system is geared only toward individual achievement, then teamwork will suffer. Beware the law of unintended consequences.

There’s a whole class of arguments, however, that can be discarded rather easily. Those are the arguments that suggest the work should be arranged in a manner that makes personnel evaluation easy. This is pure BS! Surely a company doesn’t undertake a software development project for the sake of evaluating their employees. No, the purpose of the project is to gain the business advantage of having the working software at the end of the project.

This means that any argument suggesting pair programming is bad because you don’t know which of the pair did the better work, or that collective code ownership is deficient because you can’t judge the developers by the quality of their output, is inherently flawed. First figure out how best to develop the software, then how, in that context, how to compensate the developers.

What’s a good compensation system? It may be easier and less “numerically objective” to develop one than you think. I’m always suspicious of schemes that try to reduce the reward system to a numerical algorithm without any subjective judgment. Sure, that makes it easier, but not better. I’ve always thought that the concept of paying on a share basis, like whalers were and some fishermen still are, has a certain charm. In such a system, the shares were not equal, but the survivors of the voyage shared on a percentage basis in the profit generated. It is left as an exercise to the student how such a scheme can best be adapted to your software development project.

When developing or modifying your compensation scheme, you would do well to consider David Maister’s list of criteria for a good compensation system. It provides a good starting point without some of the a priori biases I’ve seen in some other suggestions.

6 Replies to “Agile Compensation”

  1. Perhaps – and just perhaps – the compensation system primarily being a reward system contributes to the problem?

    I’m not even convinced that “more money” is the best reward you can give, anyway – far from…

  2. Ilja, I agree that money is a lousy reward mechanism. But not getting money when others around you are, is terribly de-motivating. I’ve seen too many situations where sales and marketing get rewards for good times, but engineering doesn’t.

    Yves, while David Maister’s list is undoubtedly built with individual contributors at the forefront, I don’t think it’s anti-team. In fact, his second point is “It encourages working for the good of the whole.”

    One thing about David’s list is that it considers the needs of the organization, too. I like that. After all, that’s generally the point of view of those creating compensation systems.

    Your list is a good elaboration of “working for the good of the whole.”

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.