Fair Pay: A Blueprint
As an engineering leader, one of the most important things I do is make sure that we pay people fairly for their work. The challenge, of course, is that pay is the result of a bunch of different variables, almost none of which are objective. How do we get to fair pay when there are so many opportunities for our own biases to slip in?
The answer is to design processes and systems to eliminate or counteract bias. This is usually easier said than done, but I’ve found a compensation model that I think helps.
Throw Away Your Salary Bands
I’m not kidding. Scrap them.
A salary band is a judgement call. It gives the appearance of fairness while still allowing a manager’s personal bias to slip in. The wider it is, the more influence your gut has.
What’s more, salary bands — especially narrow ones — encourage fake precision. Can you actually, fairly tell the difference between the work of someone making $100,000 a year and someone making $102,000 a year? Are you sure it’s not a $1,500 difference? Are you sure it’s not a $3,000 difference? How do you know?
The answer, for most people, is that you’re going by your gut. John is a better dev than Sally. You just know that he is. He’s been doing it longer. And, sure, Sally did really well on the last project she had, while John’s last project had some major issues… but that’s just one project!
The truth is that for most knowledge industry workers (software devs included), there isn’t an evaluative framework to support such small differences. So, any pay difference that small runs the risk of being nothing more than bias.
It works the other way, too: if Sally is obviously better John, you might feel like giving her $2k more than John is fair when she should be substantially higher.
Better: Salary Points
Instead, come up with a finite number of salaries that a member of your team can be paid. Then, make sure everyone knows what they are. Unless you have a lot of titles, it can be helpful to add a few points to each title. I’ve found three points to be a good number, as it’s usually easy to tell whether an engineer is closer to the previous title, the next one, or right in the middle.
Let’s take a look at an example, based on this hypothetical comp table:
Title | Salary Band |
Software Engineer 1 | $80k – $100k |
Software Engineer 2 | $100k – $120k |
Software Engineer 3 | $120k – $140k |
If you look at your actual salary data, the actual points may reveal themselves. You’ll probably have people clustered around a few different numbers in each title. These $20,000 spreads can become the following salary points:
Title | Low | Mid | High |
Software Eng. 1 | $80k | $86k | $92k |
Software Eng. 2 | $100k | $106k | $112k |
Software Eng. 3 | $120k | $130k | $140k |
With this setup, even if an engineer’s point isn’t immediately obvious, you can compare engineers a bit more easily. Is Sally more like the engineers at the middle or high point of her current title?
In this example, the SE3 splits are a little bigger because there’s nothing above SE3 for the engineer to progress into. The top-end position in this system is a little tricky. You can create another position for top-end SE3s to grow into, you can find other ways to recognize and compensate long-tenured SE3s, or you can exempt the top-end position entirely, assuming that there won’t be too many of those types of people. Until you’ve got a full compliment of titles ranging from Junior to Staff/Principal/Technical Fellow, adding titles is probably the right move, as it underscores the need for higher paid employees to bring more value to the org.
One caveat: salary points will not fix problems in your evaluative systems. If you don’t evaluate your team members fairly, this system won’t magically result in fair pay. It is still be better than biased evaluations plus salary bands, though. After all, it’s harder to under-level someone by $6k -$10k than it is to under-level them by $2k – $3k.
What are the Drawbacks?
One big drawback is that you’ve now lost the ability to negotiate with candidates. Your offer is your offer and that’s all your offer is going to be. I’ve found candidates to be receptive to the lack of negotiation when we’re transparent about our compensation model. We explain how compensation works and show them what point they’re being offered. Most developers will value the transparency and fairness more than a couple thousand dollars a year. But there is a bit of cognitive dissonance to overcome.1
The second downside is that it’s more work. In this system, there are no pro forma annual raises. Raises are either the result of performance increases or moving the points around. You will need to regularly decide if the points are still where you want them. If they’re not, you’ll need to give a bunch of people raises. Making exceptions ruins the system, so you have to be very conscious of the market and move your points proactively to stay competitive.2
Finally, this can be a scary change for your execs. To put this in practice, you’ll likely need to give a bunch of people raises all at once. Your CFO might not love the idea of payroll taking an unscheduled 3-5% bump. You can implement a system like this a little at a time, moving people onto the new points when they’re due for their raises, but this drags implementation out for a year or more and you can run into issues when you have different people on different compensation plans.
But there are some hidden benefits!
It’s important that your team is paid fairly. It’s just as important that they believe they’re paid fairly; being transparent about your salary points gives them peace of mind. They’ll know that they’re not missing out due to their lack of negotiating skill, gender, race, or their absence at company happy hours.
In addition, having discrete steps within a title can foster more open communication about performance and compensation. It’s usually easier to tell someone how to get from low SE1 to mid SE1 than it is to tell them how to get all the way to SE2. “What do I have to do to get to the next level?” is a bit easier than asking “How do I get a raise?”
This also makes your payroll a bit more predictable, which your execs will probably like.
Finally, distinguishing between performance raises and market adjustments benefits everyone. It makes raises more meaningful, and market adjustments let people know that you’re still trying to remain competitive.
In closing, remember that this isn’t a silver bullet! But you’ll find that a salary-point compensation plan removes one variable in your quest for fair pay. The bigger (and harder) problem is how you evaluate your team’s performance. But that’s a topic for another day.