Friends,

I know how many of you are northerners going into winter, but it’s finally my time to gloat: Summer’s coming, and I’m here for it.

The days are getting longer, and warmer, and there’s that buzz in the air as people get excited for that, and because the end of year is coming (Q4 is literally next week…).

This week, we’re exploring the humble salary range.

How to build one, and why you shouldn’t just build one, but a whole set of them to help you be a better business partner.

It was also an opportunity to share a tool I built a while that lets you build a set of salary mid-points based on a single number (😱). And although I’d hate to be that guy that’s like “look at this thing I vibe coded”, it got me thinking:

→ Do you, dear reader, want more of that kind of stuff? (survey time!)

But don’t stop there. Tell me what! Either comment in the survey, or hit reply and tell me.

What is a real pain point you had on comp, and I’ll build some solutions to share with you.

Enjoy this week’s edition ✌️

Matt

In case you’re new here (or just missed it) here’s the past three editions of the FNDN Series:

While HR got a chatbot duct-taped onto the same old systems and a pat on the back.

Shapes is the actual rebuild: an agentic HRIS with a secure core, live organisational data, and AI agents that handle the admin so you don't have to.

But it goes further than that - Shapes surfaces the stuff HR usually finds out too late:

The whole "wait, did we know this?" list BEFORE it becomes a resignation letter on your desk.

And when you need a specific use case for your business? Just describe it, vibe-code it, and watch a dashboard or workflow appear.

Now go make HR about people again.

Thank you for supporting our sponsors, who keep this publication free.

Know a startup Head of People looking for answers 🙋 why not forward this to them for some instant karma? ✨

When I start working with companies, many of them have been treating comp as a pain point they solve at the moment in time it presents.

As a small company, it’s manageable. But as you grow, and because of the importance of pay in the range of things People professionals do, these issues grow from dominating your work day, to eventually, your entire work week.

Requests like:

The temptation is to solve that singular pain point in the moment, but this mode of work leaves you reacting to the business.

One way in which companies can solve this is by thinking of their benchmarks as a system, instead of a one off solution for a given moment in time.

Stop me if you’ve heard this one before.

One of the scenarios above emerges, and you’re called into action to find a benchmark that solves the issue.

And whether you have a benchmark dataset or not, you’re likely doing one of the following:

Then, the problem is solved (hopefully), and we get on with our day.

The main issue is what happens after the problem is solved.

9 times out of 10, the benchmark gets discarded.

It’s a temporary solution for a problem we had in the moment.

It’s solving the issue now, when it could be used to also solve tomorrow's problem.

Especially because we know the problem will emerge again. 

And while we might think the benchmark works for that one role:

Not to mention, you’ve had one benchmark approved. What if — instead — all benchmarks were approved before you needed them?

Wouldn't we be able to move faster as a business?

Wouldn’t we help ourselves (and the business) on issues like pay equity?

The answer is yes.

A salary system prices the whole ladder at once. Here’s how to do it.

Using whatever your data source for salaries is, take the data for every level in the family together. 

Let’s use Software Engineering as an example. Pull the data for roles IC1 (Junior) to IC6 (Principal), even if today's hire is an IC3.

If you only have data for a couple of levels though, that’s ok, because we’re going to ‘generate’ the other levels.

Most benchmark datasets give you a set of raw data.

The challenge with that is it just reports what everyone is doing as an aggregate. It’s up to you to apply an overlay to it to make it right for your business.

Case in point: I’ve seen benchmark data that showed a Senior level role with a lower salary than a Mid-level role ☹

Often, raw data can look like this.

The jumps between them are highly inconsistent, and if used as is, issues emerge, such as:

Instead, we need to smooth the data to reflect a consistent salary progression.

There are two ways to shape the curve:

To help illustrate this, I’ve actually built a tool you can use.

Even if you have only two datapoints, by working out where the line passes through them in either an exponential or linear progression, we can determine what the whole set of salaries should look like at any level.

The curve gives you a mid-point for each level. Put a range either side of those mid-points (+/- 15% is common) so there's room for someone who's just stepped into the level and someone who's ready for the next one.

Now we have a set of salary ranges for a role at any level. 

If you need a benchmark to hire a Software Engineer, now you also have the benchmark to hire a Senior Software Engineer.

But it doesn’t stop there.

Once the curve exists, most new pay questions become a percentage you can apply to it.

Let’s revisit some of the questions we posed above.

You’ve got a set of salary ranges for Software Engineer, but you want to create a sub-family for Frontend Engineers.

Say your Frontend Engineers price slightly below the rest of engineering. In a system, you apply a modifier to that sub-family, maybe 8% below the the rest of Software Engineering, and the salary ranges for all Frontend Engineers are now built.

You want to hire a Software Engineer, but in a new country.

Say you're hiring your first IC3 engineer in a new market. The usual response is a fresh benchmark for one role in one country, which no-one looks at again. In a system, you apply a modifier to the whole curve. If that market sits 15% above yours (accounting for currency conversion), your mid-points can up, and every other level in that country moves with it.

Sure, while you don’t need to build out a whole salary framework in one go, taking just a little bit of time to turn your benchmark into something with longevity can earn you massive gains.

You’re approving something you can use repeatedly.

You’re ensuring consistent benchmarks no matter the role.

You’re able to adapt it to other problems that will emerge.

All of this aids in saving you time, allowing you to move faster, and improves pay equity, to name but a few things.

So the next time someone asks you for an ad hoc benchmark, think about how you can turn it into a system vs something you dispose of straight after.

If you enjoyed this post or know someone who may find it useful, please share it with them and encourage them to subscribe.

A roundup of the most interesting stuff from the week:

When you’re ready, here’s three ways I can help you:

1. Tools & resources
Resources and tools that give you what you need to build your own startup compensation practices.

2. Comp consulting
Building startup compensation practices that are clear, fair and competitive.

3. Startup People Summit
A 1-day annual event for People professionals in scaling companies. Creating the playbook for startup people practices. Grab recordings from past events, or subscribe to join the next summit.