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.

3 thoughts on “Creating Agile HR, Part 6: the Agile Compensation System”

  1. Is there any details to set up the compensation system more agile? I couldn’t find out specific method to develop

    1. The real question is this: What do you want to change and when? Where do you want transparency? What people-based interactions do you want as opposed to some interaction with a system?

      For pay parity, the quick “details” as I see them:

      1. Create career ladders for some number of levels. I prefer no more than 5 levels for technical team members. People need to know the criteria for each level.
      2. Decide if you will pay exactly the same amount for each level or have some leeway. I’m leaning to the same amount and that means people might get a cost of living increase each year, plus whatever increase the level gets. Yes, that means that unless a person moves to the next level, they don’t get a big raise for independent work.

      “Agile” applied to HR makes sense to me if we talk about:

      • Creating a transparent system of recognition and rewards
      • Encouraging team-based compensation in some way. At least, not creating a zero-sum game.
      • Corporate OKRs instead of individual MBOs

      I’m not sure what your question is. Please try me again.

  2. Pingback: Applying Scrum to Content Creation Project: Reasons and Concerns - TiTrias

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: