Creating Agile HR, Part 6: the Agile Compensation System

I wrote about career ladders in Creating Agile HR, Part 5: Performance Management, the Career Ladder. Once you have a career ladder, it's easy for everyone to understand the criteria for a given level.

That means you can use an “agile” approach to manage compensation.

Compensation is part of career management. Career management includes:

• Recognition (what we say about people)
• Rewards (raises and bonuses)
• Promotions (how we help people move—if they choose—to a different level of job)
• Education and training so people are ready for the next thing at their job.

I just read How we pay people at Basecamp and they use their ladder. Here's a quote:

Everyone in the same role at the same level is paid the same. Equal work, equal pay.

Well, of course!!

He didn't say how often people receive feedback. However, everyone receives their raise yearly. And, since they don't do bonuses (which make little sense for almost anyone in a collaborative team), it's easy to decide if someone is ready for the next level and/or what to pay them.

Basecamp made hiring and reviews transparent.  No, it's not fully transparent as I can't tell if everyone knows what everyone else makes for salary, but the process is transparent. And, since they adjust (company-wide, not geographically) what each level person makes every year, it's fair.

Making compensation transparent and fair gets you most of the way to a compensation system that can be agile.

How often do you need the compensation system to change?

• The process of compensation? Unless you change how you assess people, you don't need to do small, safe-to-fail experiments. So the process of compensation changes slowly. That shows everyone the process is fair.
• What is the compensation for each level? Yearly, because the salary surveys are yearly. And, to verify parity when you hire people. You might not change the compensation at a given level, but you certainly assess it and the incoming person's salary to maintain parity.
• What do people earn? This is the tricky part. If you hire according to a career ladder and you have competitive salaries (as Basecamp does), and you pay people at the top of the salary curve, you only need to address what people earn once a year. If you, like a client I had, hired the lowest possible skilled people, you might have to assess salaries more often. Even the “lowest” skilled people get raises.

Here are common compensation problems when you are transitioning to agile:

• The compensation bands are quite large and overlap a lot. That leads to an easy way to bias for higher compensation for developers and lower for testers (and women). Add in less-than-useful parts of the career ladder such as a degree or certification, and you've got a double whammy against people who may be competent but don't have pieces of paper. You could be a level 2 and make as much as a level 4. If you did, you wouldn't get a pay increase, ever. Worse, you could have the title or level of a level 4 and only make the median for a level 2. (That often happened with testers and with women.) Why? Because it depended on your previous salary and how good a negotiator you were.
• The company uses bonuses for part of a technical person's (not a team's) compensation. I don't see how anyone working below a VP level can affect their bonus. To me, bonuses smack of “We're too cheap to pay you what you should receive, so we'll defer part of your salary to your bonus.”
• The entire compensation is based on individual work, not collaborative work.

An organization can manage the career ladder and bands with a reasonable process, such as Basecamp's approach. The real issues for me are bonuses and individual compensation.

Agile approaches are based on collaboration. If you want collaboration, make it easy for people to do the right thing. Individual compensation and bonuses make it too easy to do the wrong thing.

Do I think an entire team should be paid the same amount? No. We don't all contribute the same way. I do believe in career ladders where people are paid the median (or something like that) and then they receive more individual compensation based on how they contribute to the team. Note, their contribution to the team, not their individual contributions.

In addition, the team might share in any extra compensation, as a team. If the team decides to split the extra equally, terrific. If the team decides otherwise, terrific. (I wrote Possibilities for Managing Individual and Team Compensation about this very problem.)

Remember, agile approaches create a cultural change. Culture is what we can discuss, how we treat each other and what we reward. Compensation is absolutely part of the reward structure!

Agile compensation isn't about iterating every two weeks on anything. Agile compensation does mean that we take a collaborative approach on how we compensate people and that we iterate on what we pay when it makes sense, so we can instill the spirit of collaboration.

Now, how do we know when a person is ready for more responsibilities and possibly a promotion? With feedback. Frequent feedback and possibly coaching. This post is long enough. The next post is about feedback and coaching.