What you'll learn
- Compensation benchmarking is not salary research — it is a repeatable methodology
- The four primary data sources and what each is actually useful for
- Job matching to market data is where most benchmarking programs fail
- Building pay bands: the P25-P50-P75 structure and when each reference point applies
- When to pay above median and when median is right
- Compression is a structural problem that market-rate hiring creates and ignores
Most companies believe they benchmark compensation. What they actually do is look at what they paid the last person in the role, add a percentage increase, cross-reference one salary aggregator, and make an offer. That is not benchmarking. Benchmarking is a structured methodology for matching your specific jobs to market data, determining where in the market distribution you want to pay, building bands that account for internal equity and performance differentiation, and updating that data on a schedule that tracks actual market movement rather than your HR team's bandwidth. The gap between those two descriptions is the gap between a company that loses a software engineer offer to a competitor paying $30,000 more and a company that extends offers confidently because it knows exactly where its compensation sits relative to the market it is competing in. In 2026, that gap is consequential: a median US software engineer earns $150,000 to $175,000 in base salary depending on geography and company type, but the range from P25 to P75 spans roughly $130,000 to $210,000 — a $80,000 band in which companies with poor benchmarking methodology are making arbitrary decisions. For non-technical roles, the stakes are lower but the methodology failures are equally common. This guide covers what compensation benchmarking actually is, the four data sources worth using, how to match jobs correctly to market data, how to build and maintain pay bands, when to pay above median and when to target median, how to manage the compression problems that arise when you hire at P75 and your incumbent employees are at P50, and how to know when your benchmarks have gone stale.
Compensation benchmarking is not salary research — it is a repeatable methodology
Quick answer
The distinction matters because one is an ad hoc activity and the other is an organizational capability. Salary research means looking up what the market pays for a job title when you are about to make an offer or when a candidate asks. Compensation benchmarking means establishing a structured process for matching jobs to market data, selecting reference points in the market distribution, building internal salary ranges around those reference points, and refreshing those ranges on a defined cadence. Companies that do salary research make defensible individual offers but lack the infrastructure to maintain internal equity, manage compression, or forecast compensation expense accurately. Companies that have a benchmarking methodology do all of those things as a byproduct.
The four components of a compensation benchmarking program are: job architecture (defining the job levels and career paths that determine which market data applies to each role), market data sourcing (selecting and maintaining subscriptions to the data sources that match your industry, geography, and labor market), job matching methodology (the process of mapping your internal jobs to specific survey job codes, not just titles), and range construction (translating market reference points into internal pay bands with a defined structure and update cadence). Most HR teams have some version of job architecture and some access to market data. The gaps are almost always in job matching and range construction — the two components that determine whether the market data you are paying for is actually being applied correctly.
A compensation benchmarking program does not need to be expensive to be functional. The minimum viable version — job architecture with defined levels, one or two market data subscriptions matched at the job-code level, P25/P50/P75 bands per level, annual refresh cycle — can be built and maintained by one experienced compensation analyst. The expensive version — multi-source blended benchmarks, quarterly refresh cycles, executive compensation overlays, geographic differentials by metro, and real-time market monitoring — adds precision that most sub-2,000 employee companies cannot justify. The risk is not spending too little on the program; it is running no program at all and making offers based on intuition while your talent competitors are working with validated market data.
The four primary data sources and what each is actually useful for
Quick answer
Radford (now Aon Radford, part of the McLagan and Radford merger) is the dominant survey for technology and life sciences compensation. It covers approximately 1,500 jobs across 7,000-plus participating companies globally, with strong representation of US-based tech employers from series B startups through large-cap public companies. Radford data is job-code matched, meaning you are comparing to a defined scope description rather than a job title — which is the correct methodology. The survey publishes semiannually (March and October), costs $5,000 to $25,000 annually depending on participation and access tier, and is most useful for engineering, product, data, and technical leadership roles. If you are hiring more than 20 software engineers per year and are not using Radford, you are almost certainly working with less accurate market data than your competitors.
Mercer is the counterpart to Radford for corporate functions, finance, operations, HR, legal, and general management roles. Mercer's Total Remuneration Survey covers similar scope across non-technical roles and is the benchmark standard for HR, finance, and operations compensation at companies above 500 employees. Levels.fyi is the most relevant data source for consumer internet and enterprise software engineers specifically — it is crowd-sourced rather than survey-based, which means it captures current market rates faster than semi-annual survey cycles but with less statistical rigor. Levels.fyi is most useful as a real-time directional check on whether your survey data has drifted from actual offer activity, not as a primary benchmark source for building bands. Industry-specific surveys — CompData for healthcare, Culpepper for pharma and biotech, SHRM Compensation Data Center for broad industry benchmarks — fill the gaps for roles and sectors where Radford and Mercer coverage is thin.
The practical data sourcing decision for most mid-market companies is: Radford for technical roles, Mercer for corporate functions, Levels.fyi as a directional check on engineering, and one industry-specific survey if you operate in a sector with distinct compensation norms. This covers 90-plus percent of benchmarking needs for companies with 200 to 5,000 employees. The mistake is substituting free tools — Glassdoor, LinkedIn Salary, Payscale, Salary.com — for paid survey data. These sources aggregate self-reported salaries from individuals who may be misrepresenting titles, omitting equity, or reporting total compensation incorrectly. They are useful for understanding candidate expectations and market narratives, not for setting internal pay policy. Glassdoor data for a specific role can be off by 20 to 30 percent relative to validated survey data at the same company size and geography because of how sample bias affects self-reported compensation aggregations.
Compensation benchmarking requires job-scope matching against validated survey codes — not title matching against aggregator averages — and a maintained job catalog with documented match decisions that makes annual refreshes a mechanical update rather than a months-long re-scoping exercise.
Job matching to market data is where most benchmarking programs fail
Quick answer
Title matching — taking your internal job title and finding the closest match in a salary database by name — is the most common benchmarking error and produces consistently unreliable results. Job titles do not have standard meanings across companies. A 'Senior Software Engineer' at a 50-person startup is often performing work that a large-cap tech company would classify as Staff Engineer. A 'Director of Marketing' at a 200-person company owns a scope that a 5,000-person company distributes across three separate Director-level roles. When you match by title, you are often comparing different jobs — and the resulting market data either over- or under-states what your actual job should pay.
Correct job matching uses scope-based criteria: the survey job code that best matches the actual decision authority, team size, revenue responsibility, geographic scope, and technical complexity of your role, regardless of what the internal title says. Radford and Mercer provide detailed job code descriptions — typically 200 to 400 words per code — that define the scope characteristics at each level. The matching process involves reading those descriptions, comparing them against your actual job scope, and selecting the code whose description most closely matches what the role actually does and is accountable for. For roles with hybrid scope — a Head of Marketing at a seed-stage startup who owns both demand gen and brand, both of which are separate Director-level jobs at a large company — the convention is to match to the primary scope (the function that consumes 60-plus percent of the role's work) and supplement with secondary benchmarks for total compensation context.
The operational discipline that makes job matching work at scale is a maintained job catalog with documented match decisions. Every role in the organization has an internal job code, a survey code match, the rationale for that match, and the date of the last match review. This sounds bureaucratic but it is the mechanism that prevents individual recruiters from re-matching the same role to different survey codes for different offers — which produces inconsistent offer levels for the same job and creates internal equity problems. It also makes the annual benchmark refresh tractable: you are updating market data for existing match decisions rather than re-matching every role from scratch. A company that maintains a job catalog with documented matches can run an annual refresh in two to three weeks. A company that does not can spend months re-matching and still end up with inconsistent results.
Building pay bands: the P25-P50-P75 structure and when each reference point applies
Quick answer
A pay band has three reference points drawn from the market distribution: P25 (25th percentile — 75 percent of the market pays more), P50 (median — half the market pays more, half pays less), and P75 (75th percentile — 25 percent of the market pays more). These three points define the range: P25 is typically the band minimum, P50 is the midpoint, and P75 is the band maximum. In 2026, for a mid-level software engineer in a major US tech market (San Francisco, New York, Seattle, Austin), these reference points are approximately: P25 $130,000, P50 $155,000, P75 $185,000 in base salary. For the same role in a secondary market (Denver, Atlanta, Nashville), discount those figures by 10 to 15 percent. For a senior software engineer, the P50 base moves to approximately $175,000 to $195,000 in primary markets.
Where you set your hiring target within that band is a strategic decision based on your market position, retention risk for the role, and the supply-demand dynamics of the specific talent pool. P50 targeting is the baseline: it is defensible, equitable, and consistent with being a market-rate employer. P75 targeting is appropriate when you are competing for talent in a supply-constrained pool (senior machine learning engineers, specialized security roles, certain clinical leadership positions), when you have identified that competitors for this talent are consistently paying above median, or when the role has a disproportionate revenue or cost impact that justifies a higher compensation investment. P25 targeting makes sense only when you offer non-cash compensation components — equity upside, mission, development opportunity, flexibility — that candidates in this role demonstrably value more than incremental base. Startups can sometimes hire at P25 base with P75 total compensation because of equity value, but only for candidates who are sophisticated enough to value that equity correctly.
Band construction for a four-level job ladder (L1 through L4, or Associate through Principal) requires that bands at adjacent levels overlap by no more than 30 to 40 percent to preserve promotional upside while allowing high performers at lower levels to earn more than low performers at higher levels. A band that has zero overlap between levels forces everyone into a box: the outstanding L2 performer cannot be compensated at L3-equivalent pay without a title change, and the underperforming L3 hire must be paid at L3 minimum even if their contribution is at L2 level. Overlapping bands solve this by allowing compensation decisions to reflect performance within the band rather than forcing premature promotions or suppressing pay for strong performers waiting on headcount approval.
Related reading
When to pay above median and when median is right
Quick answer
The decision to pay above P50 should be driven by three factors: supply constraint in the talent pool, revenue or cost criticality of the role, and competitive intelligence about what your direct hiring competitors are paying. Supply-constrained roles are those where qualified candidate supply is materially below demand — in 2026, this includes AI/ML engineers, staff-level security engineers, certain clinical informatics roles, and senior growth marketing operators in specific verticals. For these roles, P50 targeting means losing offers because candidates with multiple options will take the P75 offer from a competitor. The correct benchmark for supply-constrained roles is not P50 of the full market but P50 of the market you actually compete in for that talent — which is often skewed above the general market.
Revenue and cost criticality creates a different argument for above-median pay. A role that is directly responsible for $10 million in annual revenue impact — a top enterprise sales rep, a senior product manager running your highest-traffic feature — has a compensation economics equation that is distinct from a support function role. A 15 percent above-market premium on a $200,000 base costs $30,000 per year. If that premium is the difference between retaining a $10 million revenue contributor and losing them to a competitor, the ROI is not difficult to calculate. Compensation philosophy that applies a single market position (P50 for everyone) to roles with dramatically different economic leverage is leaving money on the table.
Median targeting is appropriate for roles where supply is adequate, competency is more learnable than innate, and the marginal difference between a P50 and P75 candidate is small relative to the premium. Most operational, administrative, and entry-to-mid-level individual contributor roles fall into this category. Hiring at P50 and investing in development, clear career ladders, and a strong culture of internal promotion is a compensation strategy that outperforms indiscriminate above-median hiring for these roles — because the retention driver for employees in learnable, developable roles is opportunity and recognition more than incremental base salary. Overpaying operationally for roles in this category creates budget constraints that prevent you from paying appropriately for the critical few roles where above-median compensation actually wins the hire.
Compression is a structural outcome of hiring at current market rates while incumbent employees receive 3 to 4 percent annual merit increases in a market appreciating 5 to 6 percent per year; addressing it requires a dedicated market adjustment budget separate from merit, funded at 1 to 2 percent of payroll annually.
Compression is a structural problem that market-rate hiring creates and ignores
Quick answer
Compression is what happens when market rates increase faster than your existing employees' salaries. You hired a senior engineer in 2023 at $155,000, which was P50 at the time. In 2026, P50 for the same role is $175,000. Your new hire is coming in at $175,000. Your 2023 hire — who now has three years of company-specific knowledge, institutional context, and demonstrable performance history — is being paid $20,000 less than the person they are about to onboard. That is a compression problem, and it is invisible to you until one of three things happens: the existing employee discovers the disparity (which takes about six months after the new hire starts), they start interviewing (which typically happens within a year of discovering the disparity), or their manager comes to you asking why your best engineer just gave notice.
The structural cause of compression is the mismatch between compensation adjustment cycles (annual merit increases averaging 3 to 4 percent) and market rate appreciation in high-demand talent pools (which ran 6 to 12 percent annually for software engineering roles from 2020 to 2024, and stabilized at 4 to 6 percent in 2025 and 2026). The math is straightforward: a 4 percent annual merit budget compounds to 12 percent over three years. If market rates have grown 15 percent over the same period, your existing employees are now 3 to 5 percent below market even after full merit increases — and that gap widens every time you hire a new employee at current market rates.
Managing compression requires a separate budget line from merit increases — a market adjustment pool funded at 1 to 2 percent of payroll annually for most companies — and a commitment to proactive market reviews rather than reactive spot adjustments when employees threaten to leave. The process is: run the benchmark comparison for each job level annually, identify employees whose current pay falls below P25 of the current market for their job code and level, and bring them to at least P25 as a baseline. This is not optional for retention: a 2024 SHRM study found that employees who discovered their compensation was more than 10 percent below market peers had a 68 percent twelve-month attrition rate, compared to 23 percent for employees at or above market. The cost of the market adjustment is almost always less than the cost of recruiting, onboarding, and ramping a replacement.
When to re-benchmark: annually is the minimum, not the aspiration
Quick answer
Compensation benchmarks go stale faster than most HR teams assume. Radford and Mercer publish new data twice per year; the delta between a March 2025 survey and a March 2026 survey for software engineering roles ran approximately 4.5 percent base salary increase at the median. A company that uses the same benchmarks for 18 months is making offers based on data that is 4 to 7 percent below current market before accounting for any geographic or role-specific variance. In tight hiring markets, that gap is the difference between a successful offer and a candidate who takes a higher offer elsewhere.
Trigger-based re-benchmarking supplements the annual refresh for roles where market dynamics are moving faster than the calendar. Three triggers warrant an off-cycle benchmark review: a run of two or more declined offers where candidates cited compensation as the reason; an unusual spike in voluntary attrition from a specific job level or function over a 90-day period; and credible intelligence that a direct competitor has moved their compensation structure above your current bands. None of these triggers should wait for the annual review cycle. The cost of an off-cycle benchmark is two to four hours of analyst time. The cost of continuing to make below-market offers while the problem compounds is six to twelve months of degraded offer close rates and elevated attrition.
The long-term discipline that makes re-benchmarking functional is maintaining the job catalog with match decisions so that refreshing the data is a mechanical exercise rather than a re-scoping project. A company with a documented job catalog can update all benchmarks within a week of new survey data release. A company without one spends weeks re-debating job scope and match decisions before getting to the data. The annual benchmark refresh should be calendared in Q1 — when Radford March data is released — with a structured review process: pull new survey data, apply to existing job matches, compute the delta from prior-year bands, model the market adjustment cost, and bring a recommendation to leadership with specific band updates and an estimated adjustment budget. That process, run annually and documented, is the operational foundation of a compensation program that keeps you competitive without requiring constant reactive corrections.
Frequently asked questions
Common questions about talent acquisition and how InCruiter helps teams solve them.
InCruiter Editorial Team
AI Hiring Research · Interview Intelligence · Enterprise Talent Strategy
The InCruiter editorial team covers AI-driven hiring, interview intelligence, and modern talent acquisition strategy. Our guides draw on platform data from 2,000+ hiring teams, conversations with talent leaders, and published research in industrial-organizational psychology.
