When Gitlab’s salary calculator page went private a few months ago, I had a fearful peer reach out asking what to do now that their “salary data was no longer available.” Puzzling, as they didn’t work for Gitlab. Further puzzling, as they are a part of a company of a size where using Gitlab’s salary calculator seemed like a precarious choice.
Since starting my role at Whereby I have been asked a variation of this question a few times; do we “use Buffer’s calculator?” or “do the same as Gitlab?” It’s a peculiar question to me, because it implies that a compensation framework can be copy and pasted from another misc. remote company.
Copying another company’s calculations (for anything), and then using them to inform your own decisions, is broadly regarded as a bad idea. The reasons why it’s a bad idea lie largely in my first post in this series: different commercial and strategic aims, different buyer personas, and different life-time-value strategies for your teams.
So, it follows that this next part of “how to build a compensation framework” is largely focussed on building something which is bespoke and fit for your purposes, but — crucially — something which offers you what Gitlab and Buffer have created for themselves: consistency. A dear friend sent me this wonderful blog post, which I think covers a lot of ground I will try to avoid duplicating, but the list of “good and bad” systems really speaks to me.
You need to build a replicable system. To graciously steal some of my favourite points from Erik Bernhardsson:
- A bad system pays people on an arbitrary scale, where salary history is the primary factor, and determines offers to new hires mostly based on their other offers.
- A bad system give raises to people who are already paid more than you would pay to hire them today.
- A bad system makes people frustrated because they don’t understand why some people make more others.
We want to build a good, replicable system.
You should already (if you read my first post) understand both your organisational design principles and where you need to compete for that talent. This means you have the kindling for rules on which you can base this system so it is fit for purpose.
🖐 The five most commonly used (and practical) logic steps in your system are as follows:
ASK: What kinds of companies are you competing against (size, industry)?
- This is not where you are competing for business, but where you are competing for talent.
- I advise you, generally, to be a bit ambitious here. If you are currently running at $10m ARR, it might be worth competing against companies at $50m in order to give your framework more longevity and a higher competitive edge.
ASK: How competitive do you need to be?
- Do you want to be paying at the 75th percentile, or 25th?
Roles & Levels
ASK: How is your team structured in terms of functions, years experience and/or seniority?
- This is why I had, earlier, suggested to build your levelling framework first if you can afford to.
- This doesn’t mean you need a full progression framework yet, you simply need to know the comparable levels across your team so you are able to give your comp framework something to grip onto.
ASK: Where (geographically) are you competing?
- Are you going to be recruiting across-border?
- Are you competing with remote companies, or local companies?
- Do you believe factoring in cost-of living will benefit you financially (for example, off-shoring part of your team to lower-cost-of-living geographies)
- Are you in a city with high-salaries?
ASK: Where (team, level, skills) do you need to be most competitive?
- If you need to be more competitive in engineering (for example) you may want to have an additional “rule” or set of rules for their structure.
- Consider if your organisational design principles require you to invest most within certain levels.
- Are there special skills or backgrounds you are willing to create discretionary adjustments or considerations for?
There are many ways to ice a cake, but the way I find which works the best, and which is most common, is creating a calculation from the questions above. Use each of the headings above as a logic step you must run through in order to make consistent compensation decisions.
The final product can be either a dynamic calculation (due to complex considerations, like cost of living and multiple geographies — a good example of this is the way Buffer’s comp calculator works), a simple set of bands (if you are recruiting into one city, for example), or something somewhere in the middle.
Before we build a compensation calculator, let’s quickly break one down…
Step 1: Data set
From memory, Buffer uses Radford as their data set, and bases all compensation out of San Francisco.
Step 2: Data subset
It is not clear which percentile they use in Radford’s data, but let’s presume Buffer is aiming to be highly-competitive, and operates at the 75th percentile, and looks at data for all companies operating above $10m ARR.
Step 3: Roles & Levels
Buffer has created a list of every type of role they offer in their team, and includes level at the “role” dropdown. They appear to have at least 4 levels, which you can see in “Content Marketer 3” up to C-suite.
These levels seem to be baked into the base data, rather than layered on top. Compare them with how levels work on PostHog’s compensation calculator.
Step 4: Geography
Finally, Buffer offers you a San Francisco salary, which you run through a simple cost of living calculator, based on your residential city’s COL index.
It’s a solid, pretty basic, and easy to understand set of rules which every single role can be simply passed through to offer a consistent outcome. I am sure there are some additional, behind the scenes, considerations — such as situations where someone has unique skills which are within Buffer’s interest to acquire.
Let’s talk through building your own, and what it may look like. First, you need to make some base level decisions:
- Which data set will we use? Radford is expensive but highly regarded, ERI is comprehensive but perhaps a little old-school. You can even build your own data-set by patching a selection of Agency Salary reports. I talk more about these options at the end of this post.
- Do we want to create a calculator, a list of rules, or a strict list of bands? If you are a company with a fairly structured organisational design, plenty of clarity and role data, a strict list of bands may work very well for you. However, if you are a team which has more dynamism in your recruitment, talent, and organisational design, a calculator or list of rules may work best and pairs very well with using a pre-purchased data-set.
Step 1: Geography
Broadly, you have three choices:
- You can start with one geography from which you base all salary decisions, and then overlay with cost of living adjustment(again, Buffer does this). The reason you may do this is to gain the competitive financial edge of employing remotely, and seeing your talent primarily as smaller businesses in those regions.
- Alternatively, you can select a list of geographies which you align regions to. For example — everyone in APAC is paid a Sydney salary, and everyone in Europe is paid as if they were in London. The reason you may take this path is if you are a remote company competing heavily against other remote companies in the region.
- If you would like the most geographic flexibility, and you have elected to purchase a large data set, it may be an option that you simply look up the market rates of each city in which you recruit into. This is the most short-sighted solution and (if you are growing) will likely cause you administrative pain later on as local economies change and you must constantly calibrate your team.
Step 2: Team
This is perhaps the most controversial element of the calculation, which many companies avoid “saying out loud”.
This is where you identify the team someone is joining (product, engineering, operations) and decide whether or not that makes a difference to compensation calculation. Do you pay your engineers at the 75th percentile and everyone else at 50th?
I have a lot of thoughts about why doing this publicly, and letting your team be aware of the reasons behind this decision, is the kindest thing you can do, but I may leave them for another blog post.
Step 3: Level
A compensation framework requires some understanding of the levels in your team, even if rudimentary. It is important these aren’t strongly tied to years experience in your team, but rather some kind of progression framework (even if you haven’t made this yet, try to think about levels as the contribution/productivity of the roles, rather than their CV).
This is also where you do the previous step, but this time considering level. Do you pay your Heads-of and above at 60th percentile and your graduates at 90th?
Also — within your data set, it’s crucial to decide if you levels overlap, or if there a hard line? Both arguments have valid points, and you need to take a stance.
Step 4: Additional Education
Some data sets offer an additional adjustment according to education. This is not something the majority should be doing. I would suggest, however, you consider this if you require a certain professional qualification (for example, PQ Solicitors).You can also replace education with any niche experience you require for certain roles.
Do you automatically add an additional 20% for those with a completed PhD? Do you consider up to an additional 5% for those with an MBA?
Step 5: Banding and/or discretion
Finally, you need to make a decision if there is a hard band where you do not negotiate, or if you have some kind of discretionary range above whatever the data set gives you.
This is perhaps a little difficult to understand without an example. Say your salary calculation for a Sydney-based (step 1) developer (step 2) at a mid-weight level (step 3) with an MBA (step 4) gives you a salary outcome of $75,000 (or even $75,000 — $85,000 if you are using bands). Great, but we all know it’s rarely that simple. Like I’ve said previously, compensation is a market-force, and just because your data set has given you this number does not mean every candidate is going to fit perfectly (and happily) into that box.
In this final step it is crucial (for DEI purposes, as well as establishing fairness and transparency for your team) that you have some grasp on the rules of play when it comes to negotiations outside of your salary framework. Do you go above $85,000 if asked? Why or why not? It is your responsibility to know the answer to this before the circumstance arises, and to have documented rules of engagement.
Without this final step fully nailed down, every decision you make outside of your salary framework degrades the integrity of the work you have done.
The final result
This should give you a list of rules, a spreadsheet, a calculator, or some combination of all of these things.
You should now be able to assess your entire team against these rules and see if your work is aligned with the salary decisions your company has made in the past.
If they are — great! You did a good job and got a handle on this before it became an issue.
If they aren’t — it is not a disaster. You now need to decide if you want to bring your entire team up to match these decisions gradually (lowering your percentiles for a year until you’ve reached some revenue goals, for example), whether you want to bite the bullet and make big changes, or whether you need to seriously reconsider your original presumptions (hmm, maybe we aren’t competing with Deepmind after all).
Select, or create, a data-set?
I get this question often; should you purchase or develop a data set to base your work on? This is up to you and what size you are, as well as how many resources you have. Ultimately, salary sets are pretty self-fulfilling. You buy the data to assess your team and then you feed the data back into the set, perpetuating the validity of the information. If you are out in the market looking at a range of salary surveys it’s an art as much as it is a science and you will almost always be able to find a set with considerable differences to your final work.
Benefits of purchase: It is easy, the information is often pretty broad and complex, and a purchased salary set naturally attracts higher-trust from your team.
Benefits of create: Presuming you are honest with yourself and don’t fudge the numbers, creating your own data set allows you to be more flexible and skeptical, and it also allows you to be pretty specific (looking at SaaS and not just “tech” for example).
Publishing your outcomes
Look, I’m going to tell you that you should be transparent with this. If you don’t think that’s the right thing to do, there is a whole other blog post I need to write to address that. The market is demanding this information and it’s plainly the right thing to do if you’re being honest with your colleagues and want to treat them like adults.
People will scrutinise this work. Do a good enough job that you can welcome the scrutiny. It’s their livelihood at stake and they deserve to understand how you came to the number on their payslip. Don’t forget the power dynamic between you and a single team member is astronomical, and if you do a good job publishing your compensation framework has an overwhelmingly positive effect on overall culture and clarity.
What we do at Whereby (coming next…)
If you‘re keen to see what we do at Whereby, keep an eye out for the final instalment of this little series…
I am a person and I like to think I am good enough to do it professionally. So that’s what I do. I’m a hands-on Chief People Officer. I find my joy in diverse, kind, and world-changing companies of excellent people, which is why I am at Whereby, where our mission is to give people freedom to live and work where they thrive. (How fantastic is that?)