How do I know what salary to offer a candidate for a new job position – fairly and equitably?

A new hire on the way – the team is ready to start recruiting for a much-needed job position.

But what salary should be offered for this new role?

It needs to be competitive with the wider market to attract top candidates to apply. It needs to be within the finance team’s payroll budget. It needs to fit into the structure of existing salaries within the organisation to ensure internal pay equity remains intact. It needs to be flexible enough to account for salary negotiations once a candidate has been chosen.

In short: there’s a lot to consider.

In this article we’ll cover:

1. How to decide the salary band for a new job position
2. How to determine the salary offer for the successful candidate within the range

How to determine the salary band for a new job position

In an ideal world, your level framework and salary bands structure will have been set up to include all the future job positions that will soon be introduced to the company’s structure, so that when it comes to hiring for that new role, the salary band already exists.

This ideal scenario is pretty commonplace when companies are in hypergrowth mode: you know you’re going to be hiring a substantial amount of new roles over the next year, so it’s vital both for the people team and the finance team to plan ahead for that.

But, the reality for most people teams is that it’s somewhat unlikely that those future job positions will already be in the structure and have a salary band ready and waiting.

It’s much more common to create a level framework (and therefore salary bands) based solely on the job positions that already exist in the company at the point in time the framework was created. Or, for very early-stage start ups, there may be no structure at all to those early hire compensation decisions, with the salary range determined on a case-by-case basis.

So, how do you get the salary band set up for this new job position – in a way that ensures a fair and competitive salary that won’t have you pulling your hair out at the next compensation review?

Step 1: Define the scope of the role

First, you need to make sure there’s clarity and alignment on the scope of this new job position.

What are the responsibilities of the role? Are there key skills and competencies that are required? What level of autonomy is expected? What level of business impact is the role expected to make? How does it sit alongside other roles that already exist in the same team and in the organisation as a whole?

These questions enable you to level the new job position against a level framework like Ravio’s:

In an ideal world, you’d be hiring at a specific level for a new role e.g. a P3 software engineer.

But, in reality, it’s often the case that there’s a more broad need, e.g. for a mid-level software engineer, and you’d be happy to hire a P3 or P4 depending on the candidates who apply.

Step 2: Research market salaries for the role

Once there’s clarity on the job position and the level it sits at, the next step is to look at the data.

That’s both internal data – looking at what existing employees in similar roles or teams are paid, and therefore what a fair salary might look like within your structure.

And external data – using salary benchmarking to identify what a typical salary for this job position is in companies like ours, and therefore what salary expectations candidates will have.

There are many tools and sources out there to help with this, but we’d always recommend working with a real-time salary benchmarking tool like Ravio’s to ensure that the data is as reliable and up-to-date as possible.

Let’s look at an example.

If your company is based in the UK and you know you want to hire a P3 software engineer, you would want to find out what a typical salary looks like for a P3 software engineer in the UK – and use that to set a range.

Using Ravio’s salary benchmarking tool, you’d find that the median salary for a P3 software engineer in the UK is £63,500.

Of course, the median salary is bang in the middle of what other companies are offering for the same job position and offering this salary means you are meeting the market. But, you might decide that your salaries should be above this (leading the market) to attract top tech talent in a competitive market. Or, you might decide your salaries should be below the median (lag the market) e.g. as a start up which has a strong equity offering for early hires but less cash to offer.

Depending on that, you’d decide on a target percentile (which may also be pre-decided as part of your overall compensation philosophy), and this would be the midpoint of your salary band for the new job position.

Step 3: Decide how wide the salary range should be

With your midpoint decided, you also need to decide the minimum and maximum salaries that you would offer for this new job position: the width of the salary band.

The width of the salary band is closely tied to career and pay progression – because you want the employee to be able to progress with incremental salary increases over time within their role and salary band.

A standard width for a salary range is around 15% either side of the midpoint.

That reflects a standard of around a 5-10% annual salary increase and 3-4 years to be promoted to the next level (bearing in mind that employees don’t typically start at the band minimum salary and end up at the band maximum salary – these reflect the absolute minimum and maximum before there's concern about an employee's pay).

So, if we’d decided that we wanted to stick with that median (50th percentile) P3 software engineer salary as our midpoint, and we went with a range of 15% either side of this, we’d end up with a salary range that looks like:

• Minimum – £53,975
• Midpoint – £63,500
• Maximum – £73,025

And there we have it!

Our final salary band for the new position at the P3 level is £53,975-£73,025.

And this would effectively fill the gap within your existing salary band structure.

For instance, if your salary bands are grouped by department, this would be added as a new salary band for the P3 level within your software engineering salary band group.

Although this gives us the overall salary band for the new job position, when it comes to putting the job live it’s typical to slightly narrow the range.

This is because ideally you don’t want a new employee whose starting salary is at the upper end of their salary band, as this leaves little room for pay progression within their role.

So, as an example, in this instance you might opt to set the salary range for the new hire as £55,000-£65,000.

How to determine the salary offer for the successful candidate within the range

So, you have a robust salary band in place for the new job position.

But, once you’ve gone through the hiring process and you have a successful candidate, how do you know what exact salary to offer them?

What you don’t want to do is pluck a number out of the air and see if it sticks.

If you’ve done the groundwork to put a robust structure in place to determine the salary range based on the job level, as we’ve outlined above, it’s much easier to make fair and equitable decisions within the confines of the salary range.

There are two main considerations when it comes to deciding the salary offer:

1. Where does the candidate sit within their level? This means evaluating their previous experience, competencies, level of autonomy etc against the criteria you’ve determined for their role at their level – for instance, if this role is a big step up for their career, they’re likely to be at the lower end of the salary band.
2. Where does the candidate sit against existing employees? Maintaining compensation fairness across the team is paramount – you don’t want to bring a new hire in on a salary that is way above or below existing employees performing work of similar value.

These two questions should be the main factors in determining where the candidate fits within the salary band you’ve created, and therefore their offer.

Having that structure in place also changes the quality of the conversation during negotiation with the candidate.

You might factor in some wiggle room for negotiation – for instance, you might have a starting offer which you take to the candidate, but also have a final offer in mind which is the maximum you could offer to this candidate.

Or, like Testgorilla, you might opt not to negotiate on pay. TestGorilla has a location-agnostic approach, anchoring all offers to their European-wide benchmarks regardless of candidate negotiation, and they avoid offer negotiation to maintain fair pay across the organisation.

When a candidate in London or Berlin comes back with expectations based on local rates, Senior People & Culture Partner Luis García de la Cruz checks those local benchmarks in Ravio to understand exactly where they stand.

"We've directly used market data to inform hiring conversations,' he explains. "Even though our decisions are anchored to our bands, we can see whether we're offering something way below the London market, or whether we're within an acceptable range."

The data doesn't change the offer, but it gives the conversation a defensible foundation.