Building salary bands: a practical framework for growing companies
You hired your first 20 employees based on gut feel, market conversations, and whatever it took to close the candidate. That worked. At 60 people — with a VP of Finance asking why two engineers doing the same job earn $30K apart, and a recruiter asking what the "range" is for a role you're about to post — gut feel stops working.
Salary bands are the structure that replaces gut feel with a defensible, scalable system. Done well, they let you pay fairly, hire predictably, and have honest conversations with employees about where they sit and how they move. Done poorly, they create bureaucracy without clarity. This guide walks through how to build them right.
Why bands matter more as you scale
At a handful of employees, you can hold the entire compensation picture in your head. You know what everyone earns, you know the justification for each number, and you can spot anomalies instantly.
As headcount grows, that mental model breaks down. You get:
- Pay compression — senior hires made during a hot market earn more than long-tenured employees at the same level.
- Inconsistent offers — two recruiters make different offers for identical roles depending on candidate negotiation skill.
- Equity perception problems — employees compare notes (they always do) and lose confidence in the system.
- Manager helplessness — a manager wants to reward a top performer but has no framework for what "a raise" actually means.
Salary bands solve all of these by creating a shared, documented structure that separates the question of what the market pays from the question of where within the range a specific person sits.
Step 1: Define your job architecture first
You can't build bands until you know what you're building bands for. Before touching any market data, you need a job architecture — a structured set of levels and role families that describes the shape of your organisation.
A basic job architecture has two dimensions:
Role families group jobs that require similar skills and compete in overlapping talent markets. Engineering, Product, Design, Sales, Customer Success, Finance, and People are typical families for a tech company. You don't need a separate family for every team — the test is: would a person move between these roles without retraining? If not, they're different families.
Levels represent increasing scope, complexity, and impact within a family. A common engineering progression looks like: Associate → Engineer → Senior Engineer → Staff Engineer → Principal Engineer. Each level has a clear description of what "good" looks like at that level — not just years of experience, but the problems you're expected to solve independently, the decisions you're trusted to make, and the multiplier effect you have on others.
Getting levels right is harder than it sounds. The most common mistake is creating too many levels early, leading to spurious distinctions and endless leveling debates. At under 200 people, four to five levels per family is usually enough. You can always add levels later when the organisation genuinely has that structure.
Document each level with a one-paragraph definition and three to five concrete examples of what that level owns or decides. These descriptions become your leveling rubric for hiring, promotions, and compensation reviews.
Step 2: Set a compensation philosophy
A compensation philosophy is one sentence that tells your whole organisation (and every manager making pay decisions) what you're trying to do. For example:
- "We target the 50th percentile of our industry peer group globally."
- "We pay at the 65th percentile of the tech market in our primary hiring locations."
- "We benchmark to the 75th percentile for technical roles and the 50th for operational roles."
The percentile you choose is a strategic decision, not a math problem. It depends on what else you're offering — equity, growth, mission, flexibility — and on how you expect to compete for talent. A cash-lean startup with meaningful equity can defensibly sit at P40–P50. A late-stage company with limited upside equity should probably be at P60 or above to compensate.
One important nuance: many companies set different target percentiles for different role families. Roles where talent is scarce and competition is global (senior engineering, specialised data science) often warrant a higher target than roles where the candidate pool is deeper. That's legitimate, as long as you're explicit about it and consistent within a family.
Step 3: Pull market data for each level
With your architecture defined and your philosophy set, you need market data to anchor each band. For every level in every family, you need a market midpoint — the salary at your target percentile for that combination.
Sources matter here. A single salary survey is a single data point, and surveys have well-known lag problems: they're typically fielded annually and published 6–12 months later, meaning you can be benchmarking against data that's 18 months old. In a year where the market moved, that's a meaningful error.
EvenBetter is designed exactly for this step. You paste the full job description for each level, and the tool triangulates across multiple AI models and live market feeds — job postings, salary surveys, open-web data, and its own dataset — to return a signal-strength-rated range anchored to the current market. The methodology is transparent: you can see which sources are weighted and how the signal-strength rating is derived. That transparency matters when you're presenting bands to a CFO who asks where the numbers came from.
Work through each level systematically. For a four-level engineering family, you might end up with midpoints that look like: Associate $85K, Engineer $110K, Senior $145K, Staff $180K. Those are illustrative — your numbers depend entirely on your market, your geography, and the roles themselves.
Step 4: Build the band around each midpoint
A midpoint tells you where the middle of the band sits. You still need to define the minimum and maximum — the edges that bound new hires and experienced performers respectively.
Range spread is the percentage difference between the minimum and maximum of a band, calculated as (max − min) / min. Typical spreads:
- Junior / associate levels: 30–40% spread. Less room because the role has less scope variation and employees typically move to the next level relatively quickly.
- Mid-level roles: 40–50% spread. Enough room to reflect 2–3 years of growth within the level before a promotion is warranted.
- Senior / specialist roles: 50–70% spread. These roles have wide variation in experience and impact. A senior engineer can legitimately stay at that level for many years with genuine contribution growth.
A common rule of thumb is to set the minimum at roughly P25 of market and the maximum at roughly P75, with your target percentile as the midpoint. That framing gives you a defensible story: the minimum is not below what the market pays for someone starting in the role, and the maximum isn't beyond what the market recognises for a top performer at that level.
Band overlap between adjacent levels is intentional. You want the maximum of Level N to exceed the minimum of Level N+1. An overlap of 15–25% is typical. This means a long-tenured strong performer at Level N can earn more than a new entrant at Level N+1 — which is accurate and honest. Without overlap, the only way for high performers to get meaningful pay increases is promotion, which drives unhealthy promotion pressure.
Step 5: Apply geographic differentials
If your company hires in multiple locations, you need a position on geographic differentiation. Three common approaches:
Location-adjusted bands — a single national or global structure, with a cost-of-market (not cost-of-living) multiplier applied by location tier. For example, a San Francisco hire might be at 110% of the midpoint while a Denver hire is at 90%. This is the most defensible approach because it anchors to what talent actually costs in each market.
National bands — one set of numbers that applies everywhere, set at a level that works for your highest-cost hiring location. This is administratively simple but expensive: you're overpaying in lower-cost markets. At small scale with distributed hiring, this is often acceptable.
Local bands — entirely separate band structures per country or region. This is the most accurate but the most operationally complex. Usually only warranted once you have substantial headcount in multiple distinct markets.
Whatever approach you take, document it explicitly. The worst outcome is a system where geographic decisions are made ad hoc by recruiters, which leads back to the inconsistency bands were meant to prevent.
Step 6: Keep bands fresh
Bands decay. The market moves, your organisation grows, and bands that were accurate 18 months ago may now be structuring pay decisions against stale data.
Build a cadence for band reviews. Annual is the minimum; semi-annual is better in high-volatility markets or if you're growing quickly. The review doesn't need to be a full rebuild every time — what you're looking for is whether your midpoints still match the live market, and whether your level definitions still describe how work actually gets done in the organisation.
Each review should trigger a compa-ratio audit — checking where your current employees sit relative to the updated bands. People who have drifted below the band minimum need to be addressed (they're at risk of leaving, and it's unfair). People above the band maximum are an anomaly to investigate: either the band is set incorrectly, the person is misleveled, or there's a legacy exception that needs to be managed.
EvenBetter makes the market-refresh step fast. Rather than waiting for survey cycle updates, you can re-benchmark specific roles against the live market at any point. The signal-strength ratings tell you whether the market has moved significantly enough to warrant a band adjustment. That keeps your system accurate between formal review cycles without creating constant churn.
The system, not the spreadsheet
The point of salary bands is not the spreadsheet. It's the clarity they create: every manager knows what they can offer; every recruiter knows what range to share; every employee knows where they sit and what moving up the band means in practice.
That clarity is only as good as the data underpinning it. Build on market data you trust, document your philosophy explicitly, and build a refresh cadence before you need it. The companies that do this right don't just pay more accurately — they have better conversations about pay, which is often worth as much as the money itself.
Ready to benchmark your salary?
Paste a job description. Get a market salary range with full sources breakdown.
Run your own benchmarkRelated articles
What is salary benchmarking? A complete guide for employers
What salary benchmarking is, how it works, and how employers use it to set fair, market-accurate pay — a practical guide for HR, finance and TA teams.
How to set a salary range for a job offer using market data
How to set a defensible salary range for a job offer using live market data — covering role scoping, percentiles, budget, and internal equity.
Salary benchmarking for HR: building fair, defensible pay
How HR teams use salary benchmarking to build fair, defensible, market-aligned pay — and answer 'why am I paid this?' with data, not guesswork.
