A Fresh Look at Compensation – Pt. I

Principles of a Compensation System

I feel like it’s time to tag up again on the subject of compensation for developers. Compensation comes up as a topic when people are transitioning to scrum, and for a good reason. People are compensated as individuals, but in scrum we begin to understand the role of the team and we find that like in so many areas, scrum makes the problems inherent in many compensation systems much more visible. Because of the risk of pitting individuals against the team under the guise of assigning goals or distributing rewards we have to be more careful than ever with compensation and its handmaiden, performance appraisal, in a scrum environment.

At the same time, we have to take commercial reality into account. Soon after I joined my current company as CTO, we lost a very promising young engineer. He was poached by a company who offered him a 60% raise. 60%. Did this loss hurt us? Yes. Is it likely that free lunches, the chance to learn and grow and control his professional life, flex time, and perhaps the opportunity to work on a team of respected colleagues doing scrum would have made him immune to the poaching? Nope. Possibly resistant, but not immune. I learned a couple of things from that experience. One is that compensation does matter on an individual basis. Very few companies have gotten to that place that Daniel Pink mentions, where “compensation is taken off the table as an issue.” Another was…oh…hmmm…I guess I only learned one thing from that incident. Compensation, individual compensation, matters.

Many coaches are against differential rewards to individuals within the context of an Agile team, but after a year of running a development organization I have come to recognize the desirability and the need to reward peoples’ varying levels of contribution. All of these new perspectives have changed my overall thoughts on compensation systems. I recently saw a list of “Criteria for a Good Compensation System” (from 2008) by a guy named David Maister. I didn’t agree with most of it, but I liked the idea of having a list of principles for designing a compensation system. Thank you, David, for the idea of having the list. Here’s my list:

  • Overall, we want to reward team results and individual contribution so we must find a way that those two things don’t conflict.
  • Rewarding people for their contributions is healthy and fair as long as the determination of relative contribution levels is transparent and reasonable.
  • A compensation system shouldn’t get in the way of the actual work. (It is dumb to arrange the work or the organization in order to make evaluating people easy.)
  • Paying people enough so that money is removed as a concern is a lovely concept that is rarely achievable in practice. Assume that money matters to people a lot.
  • Compensation is a retention tool. In a world of limited resources (money) you must use what you have to safeguard the people who are hardest to replace.
  • Some people just plain do more or better or quicker or smarter than others and they deserve better compensation, even within the structure of a team.
  • It takes a team to build something non-trivial. A compensation system should support and reward the team, or at least not conflict with it.
  • In a self-organizing team, it is the team that knows best the truth about who contributes what. Managers, stakeholders, and other outsiders can also contribute toward the complete picture.
  • We will not forget about intrinsic motivation. We will allow people Autonomy, Mastery, and Purpose. (But we won’t pretend that the money doesn’t matter.)
  • A compensation system is about compensation, which is about rewarding relative job performance, contribution to the company, and the creation of value. It’s not about motivation or self-development or communication between managers and employees or anything else.

Using those principles, we ought to be able to design a compensation system that will work for us in our  commercial Agile environment. We will also try to use these principles to try to generate strategies for Scrum Masters and managers who are trying to carve out an Agile enclave in a non-Agile environment. More to come…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s