How to research market salaries for tech roles
Numbers go stale but method does not: triangulate salary surveys, live job ads and candidate conversations into tech pay ranges you can defend.
On this page
Research tech salaries by triangulating three independent source types: published salary surveys, the ranges employers post in live job ads, and what candidates tell you in real conversations. Adjust the result for region, remote policy and equity, refresh it quarterly, and hand it to hiring managers as a range with a confidence level, never as a single number. Any specific figure is stale within a quarter or two; the method is the part worth learning.
Why a method beats a number table
Every salary table you have ever bookmarked was wrong within months of being published. Tech compensation moves quickly, surveys lag the market by their collection cycle, and the same title covers wildly different jobs: a senior engineer at a five-person startup and a senior engineer at a bank share four words and not much else. Quoting any single source means inheriting its sample, its lag and its bias without knowing what they are.
A method does not go stale. If you know which sources to combine, how to correct for their known distortions and how to express uncertainty honestly, you can produce a current, defensible range for any tech role in an afternoon, and update it in half an hour each quarter.
Which sources should you triangulate?
Four families, each flawed in a different direction, which is exactly why combining them works.
Published surveys. Vendor reports, government statistics and community-run datasets. Their strength is sample size and consistency; their weakness is lag and self-selection, since people paid unusually well or unusually badly are overrepresented in voluntary surveys. Use them to anchor the midpoint, never to set the edges.
Posted ranges in live job ads. Increasingly rich in Europe as pay transparency rules take hold and posting a range becomes the norm rather than the exception. Posted ranges are current and role-specific, but read them critically: companies advertise the band, candidates remember the top, and offers usually land lower.
Candidate conversations. The freshest signal you have. Ask every candidate about expectations, not salary history; asking history is restricted in a growing number of jurisdictions and is bad practice everywhere. Five conversations for the same role tell you more about this month’s market than any survey. The weakness is sample size, so treat conversations as a correction to the other sources, not a dataset.
Your own offer outcomes. Accepted, declined, and why. Two declines in a row citing compensation is the strongest possible evidence that your band is off, and it is evidence nobody outside your team has. If you do not track decline reasons yet, start; the pattern behind why candidates turn down offers usually shows up in your own pipeline before it shows up anywhere else.
| Source | Freshness | Main distortion | Use it for |
|---|---|---|---|
| Published surveys | Months behind | Self-selection, title mismatch | Anchoring the midpoint |
| Posted job-ad ranges | Live | Bands used as advertising | Direction, competitor positioning |
| Candidate conversations | Real time | Tiny sample | Correcting the other sources |
| Your offer outcomes | Real time | Only covers your roles | Ground truth at the edges |
How do you adjust for region, remote and equity?
Raw figures from any source describe their market, not yours. Three adjustments matter most for tech roles.
Region. The same title pays differently across metros and countries, and the gap is not a fixed percentage. Prefer sources local to your hiring market. When you must extrapolate, write the adjustment down so it is a documented assumption rather than a silent guess.
Remote. Decide whether you pay for the location or the role before you benchmark, not after. Location-based pay means the band follows the candidate’s labour market; role-based pay means one band regardless of geography. Either is defensible; switching between them per negotiation is how internal pay inconsistencies are born.
Equity and total compensation. Compare cash to cash. Equity-heavy offers from startups and bonus-heavy offers from corporates both look bigger than their salary line, but candidates discount paper value, and they are right to. Benchmark base salary first, then treat equity, bonus and benefits as separate lines with their own norms.
How do you turn the data into a defensible range?
For each role, level and region, write down three numbers and a date:
- Floor: below this, credible candidates stop engaging. Usually visible in candidate conversations first.
- Midpoint: where most successful offers land. Anchored by surveys, corrected by your own outcomes.
- Stretch: what it takes to win a contested candidate from a stronger brand. Posted ranges and lost offers tell you this.
Then attach a confidence level, which is the step most teams skip. High confidence: three or more independent sources agree, the data is fresh, and you have hired this role recently. Medium: two sources, some divergence, or a market you rarely hire in. Low: thin, conflicting or old evidence. Low confidence is not failure; it is the honest label for a first-of-its-kind role, and it warns everyone that the first offers are experiments.
How do you present ranges to hiring managers?
Bring the range, the confidence level and the source list to the intake meeting, in that order. A hiring manager can argue with a number; it is much harder to argue with four sources pointing the same way, and the conversation shifts from whether your figure is right to which trade-off to make.
When the budget sits below the floor, say so at intake, not after three failed offers. The options are the same every time: raise the budget, lower the seniority, or compete on something other than cash. The third one is a real strategy with rules of its own, covered in pitching a role with a lower salary. What does not work is hoping the market makes an exception. And if the manager’s expectations and the evidence refuse to meet, that is a different conversation, and a manageable one if you run it on data rather than opinion.
How often should you refresh, and what forces an early update?
Quarterly is the right default for roles you hire continuously: reread posted ranges for your benchmark roles, fold in the quarter’s candidate conversations and offer outcomes, and move the band only when two sources agree on the direction. Annual is too slow for tech, and weekly is theatre.
Three triggers justify an out-of-cycle update: two compensation-related declines on the same role, a visible jump in posted ranges among the companies you lose candidates to, and a step change in what candidates name as their expectation. Any one of these outranks the calendar.
Most of this method runs on data your team already generates, provided it gets captured instead of evaporating in inboxes: expectations noted on candidate records, decline reasons logged against offers, the history searchable when the quarterly pass comes around. That is an ATS job. In Recruitifly, the assistant Fly can search your talent pool and assemble pipeline reports on request, with every change proposed to you for approval before it happens, which keeps the benchmark pass a reading exercise rather than an archaeology dig. We are in private beta at the moment; if a tidier evidence trail for conversations like these sounds useful, talk to us.
Frequently asked questions
What are the best sources for tech salary data?
No single source is reliable on its own, so triangulate three families: published salary surveys for a stable baseline, posted ranges in live job ads for direction and competitor positioning, and real candidate conversations for what the market accepts right now. Your own offer outcomes, accepted and declined, are a fourth source most teams ignore. Where all of them roughly agree, you have a defensible range; where they diverge, you have flagged uncertainty worth investigating.
How often should tech salary benchmarks be refreshed?
Quarterly for roles you hire often, and before every new search for roles you touch rarely. Annual surveys lag the market by months, sometimes a year, and tech compensation moves faster than that, especially for in-demand specialisms. A light quarterly pass is enough: reread posted ranges for your benchmark roles, fold in recent candidate conversations and offer outcomes, and adjust the band only when at least two sources move in the same direction.
How do you adjust salary research for remote roles?
Decide on a pay philosophy first, because the data will not decide for you. Location-based pay anchors the range to where the candidate lives; role-based pay anchors it to the value of the work regardless of geography. Both are defensible, but mixing them ad hoc is not. Once the policy is set, adjust your researched range by the relevant labour market and write the adjustment down, so two recruiters benchmarking the same role reach the same band.
Why present salary ranges with confidence levels?
Because a bare number invites false precision and a fight you cannot win. A range with a stated confidence level tells the hiring manager three things at once: what the market looks like, how sure you are, and what would change the picture. High confidence means several independent sources agree on recent data. Low confidence means thin or conflicting evidence, which is itself useful information: it tells everyone the first offers will be experiments, not certainties.
Recruitifly Editorial
Editorial
Related reading
Adding LLM screening to your ATS without creating duplicate records
Layer LLM screening over your ATS without splitting your candidate data: one source of truth, stable ID sync, scores written back as fields, not copies.
Sourcing with adjacent job titles and skills
Searching one job title misses most of the market. A worked SRE example plus a repeatable method for mapping adjacent titles and skills for any role.
AI Act candidate disclosure: notice template
What to tell applicants when automated screening is used, under the EU AI Act and GDPR Articles 13, 14 and 22, plus a copy-paste disclosure notice template.
Want to see how this looks on your own data?
No hard promises. Just a straight conversation about exports, stages, and your current stack.
Contact us