How to run a fair pay review process

So you're an engineering manager for the first time, and you've got to figure out how to run a pay review process. This is easy to screw up and, if you do, you will make lots of people unhappy. I want to show you the simplest, most defensible, way to allocate pay rises to staff. I need a cool name, so I'm going to call it The STEVE Protocol.

I'd like to claim there's some very clever backronym here, but actually it was introduced to me by a guy named Steve. It's almost certainly not original, because it's actually common sense.

TL;DR

Simples.

The philosophy

To apply this approach, you need a few things in place. The first thing you need is a philosophy of compensation. Here it is: Your salary is compensation for your time. Your employer pays you to do work for them instead of growing mung beans, or playing Pokemon Go, or reading Baudelaire, or whatever else you kids get up to. That's why you get paid every month, it's a transaction where the employer buys your time and attention.

Your salary should be dictated by the market rate for your time. In a perfect world, your employer shouldn't pay you more than your time is worth, and you shouldn't accept less than your time is worth. Now this is up for some debate, because you might choose to work for less than market rate at a start up, or a registered charity or what have you.

Pay rises are to correct disparities between market rate and current compensation. Over time, you hire people, you promote people, and so disparities will inevitably creep in. Some people will be over paid, others will be underpaid. The purpose of pay rises is to correct these imbalances as best you can. Pay rises are not a reward, because your salary is not a reward: it is your fair price for your time.

With all of that said, let's talk about the pre-requisites, and set up a scenario.

Pre-requisites

There are two-and-a-half other things you need to have understood before you get started.

A Compensation Strategy

Your compensation strategy is the decisions you make with respect to equity and market rate. Here are some viable options:

• We pay market rate. No more, no less.
• We pay the lower end of market rate. We make up for it with equity.
• We pay below market rate. We make up for it with a sense of mission, and a fantastic learning culture.
• We pay over market rate, because the work here is boring.

None of these are wrong. I work for an early-stage startup, and our pay scales are market rate, but we're working on fixing climate change, and everybody is really friendly. Also, we have stock options, and a very well provisioned fridge. Those factors are enough to keep people happy, for the most part.

I know people who work in finance, and earn double what I do, but they're shuffling around money on behalf of hedge funds.

It doesn't matter what your strategy is, so long as you choose one, and you apply it consistently, and you are honest with your employees about the trade-offs you're making. This is unlikely to be a decision that an engineering manager has authority to take. You'll need to pester your boss and your boss's boss to get a simple message in writing.

A Set of Pay Bands

Okay, so once you know how you pay people (we pay average market rate, but we're super cool, and fighting to save the world), you can draw up a set of of pay bands. These should be relatively wide, so that there is room for people to get increases, but shouldn't overlap. For example, in London right now, you can probably find yourself

• A graduate engineer for £35,000-£40,000
• A junior engineer for £45,000-£60,000
• A mid-level engineer for £60,000-£75,000
• A senior engineer for £75,000-£90,000
• A principal engineer for £90,000-£110,000

And so those are a good starting point for pay bands. In practice, the exact numbers will depend on the stack you're using, your geographical location, and a host of other factors. It's worth engaging a recruitment consultancy to do this for you. Tell them what skills you're hiring for, and they will go and do the market research and tell you how much it will cost. Don't do what I just did and pull it out of thin air.

Word from Steve

I have totally given up on getting industry benchmarking salary data because it’s the average of different data sources. See The Pragmatic Engineer for an explanation. As soon as you start hiring you’re participating in the market and you’ll work out the bands from candidate expectations pretty quickly anyway.

Every engineer should know which band they're in, and whereabouts they fall. They should also know at least the lower-bound of the band above, so that they know what's waiting for them in the future. You might want to publish the whole pay structure, but be mindful that other parts of the organisation might pay significantly less, and it's not necessarily helpful.

A growth framework

The last pre-requisite is a growth framework that helps you correctly level your engineers. There are a whole bunch of these available to crib from at levels.fyi. At CarbonRe, we stole a bunch of material from Rent The Runway because we liked the playful, D&D character sheet approach.

Depending on the size of your organisation, your framework will be larger or smaller, don't fret. Right now, at CRe, we have four defined levels: junior engineer, engineer, senior engineer, and lead. That's more than enough. At the bad place it took us far too long to build a framework. Just pick something off the shelf and adjust as you go.

Once you've written something up, you'll need to spend time with each engineer to work out where they think they are on that ladder, and where you think they are so that you can get buy-in.

The procedure

Whew! That's a lot of stuff to do, and you should expect that to take you a few weeks: agree a compensation strategy with the higher-ups, get a benchmark for pay bands, and introduce a careers framework.

Now you're ready.

Meet our sample team. Our sample team are widget chuckers, and they are paid in W-bucks. We have five team members.

Their current pay is as follows

After talking to the recruitment consultants, we draw up the following pay bands.

And then we assess each employee against the careers framework. We decide the following:

We use that to derive the target salary for each employee. In other words, if we were starting again, how much should we pay these people as fair compensation for their time?

It turns out, to everybody's shock and horror, that we systematically underpay our female employees, and our earliest employees. Everybody is very embarassed.

Realistically, we're not going to cut Björn's pay, so we'll just have to live with him being overpaid and chalk it up to experience. If we want to correct all the other imbalances, it will cost us an extra 40 w-bucks. So you take that number, and you go talk to the CEO and say "please can I have 40 w-bucks extra budget to correct historical imbalances in our pay?" and he laughs at you.

"No," he says, "you can have 20 w-bucks extra for next year".

So what do we do now? We divide the target by the available increase.

We want to hand out 40 w-bucks of pay rise, but we only have 20, so we simply halve the allocation.

The consequences

So in our worked example, Amara got a huge uplift, while Celeste got a modest bump. Our two overpaid employees got nothing. In practice, you might need to fudge a little to avoid people running away, but in theory what we've done is use the available funds to close the biggest gaps.

To work around the cliff-edge effect here, you might want to phase this in over time. For example, if your company has had a policy of flat 5% rises for a few cycles, try using the disparity data to modify the existing policy rather than replacing it. You might want to set a policy for the first couple of rounds that nobody gets a greater than 10% increase, and nobody gets zero.

Regardless, as you iterate this process, people's actual salary will converge toward their fair compensation.

As a nice side-effect, it's now easy to explain to any given engineer why they did, or did not, get a pay rise:

• You were earning W$80.
• Your target salary is W$85.
• I only have budget for 50% of the gap, ergo
• You now earn W$82

All this requires is a bit of set up, and the willingness to honestly evaluate your employees against the careers framework.