The most expensive engineer at most companies is not the staff engineer pulling down $400,000 in total compensation at a large tech firm. It is the $120,000 mid-level hire who takes eight months to ramp up, owns a critical system nobody else understands, writes code that requires three engineers to maintain, and leaves after 18 months for a competitor.
Companies do engineering compensation math the same way they do meeting math: they look at the sticker price and call it the cost. Both calculations are wrong in the same direction.
The Denominator Problem
Salary divided by nothing is still just salary. The actual unit of engineering value is output per dollar, and output is the variable almost nobody measures well.
Consider what a truly exceptional engineer actually does differently. They make architectural decisions that prevent entire categories of future work. They review code in ways that raise the skill floor of everyone around them. They scope problems correctly the first time, which means they don’t build the wrong thing and rebuild it. They write systems that other engineers can understand and modify without asking questions. Each of these contributions compounds. The architectural decision that prevents six months of future rework doesn’t show up on any productivity dashboard, but it is worth more than the salary differential between that engineer and a cheaper hire who would have made the wrong call.
This is the denominator problem. When you optimize on salary, you’re dividing output by the one variable you actually control, and ignoring the variable that matters most.
What Senior Engineers Actually Cost
The fully-loaded cost of an engineer is not their salary. It includes recruiting fees (typically 15 to 25 percent of first-year salary for external hires), onboarding time, the senior engineering hours spent on code review and mentorship, the opportunity cost of projects delayed while someone ramps, and the debugging hours spent cleaning up mistakes made during the learning curve.
For a $120,000 hire who takes six months to reach full productivity, requires two hours per week of senior engineering attention for the first year, and churns at 18 months, the effective cost per productive month is substantially higher than the salary number suggests. If you run that math honestly, the delta between that hire and a significantly more expensive senior engineer who is productive from month one and stays for four years often closes entirely, sometimes inverts.
Amazon, Google, and Meta did not build compensation structures that pay some engineers three to five times more than others out of generosity. They did it because internal data showed that their top engineers shipped disproportionate value. The research on this is old and consistent: across knowledge work, performance distributions are not normal. They are power-law shaped. The best performers do not produce 20 percent more than average performers. They produce multiples more.
The Hidden Tax of the Wrong Hire
A mediocre hire at a fast-growing company is not neutral. They impose costs that are genuinely hard to see in the moment.
The most insidious is the codebase tax. Code written by an engineer who does not fully understand the system they’re working in tends to accumulate technical debt faster than code written by someone who does. That debt is not abstract. It slows down every engineer who touches those files afterward. It creates the kind of subtle, hard-to-reproduce bugs that consume engineering days with no visible output. It makes systems more fragile in ways that compound over time.
Then there is the coordination tax. Engineers who are not operating at the level the role requires generate more questions, require more review cycles, and pull senior engineers into synchronous discussions that interrupt deep work. The context-switching cost of those interruptions falls entirely on your most valuable people.
Finally, there is the morale tax. Strong engineers are acutely sensitive to the quality of the people around them. They notice when code review is perfunctory, when architectural discussions stay shallow, when the bar for shipping is low. Over time, they find environments where the bar is higher. The worst outcome of a string of underqualified hires is not the direct cost of those engineers. It is the departure of the engineers who refuse to work in a codebase those hires created.
Why Companies Keep Getting This Wrong
The short answer is that budget structures punish salary line items and ignore everything else.
A hiring manager who brings in a $180,000 engineer instead of the $120,000 candidate will be asked to justify the difference. Nobody will ask them to justify the six months of senior engineering time spent correcting the cheaper hire’s architectural decisions, because that cost never appears as a discrete line item. It is diffused across dozens of tickets, code reviews, and Slack threads that look, to any accounting system, like normal work.
This is a measurement problem, and it is structural. The costs that are easy to see are the ones that get optimized. The costs that are hard to see keep compounding in the background.
Some companies have started treating engineering productivity more rigorously, using deployment frequency, change failure rate, and time-to-restore as proxies for team effectiveness rather than relying purely on headcount and salary metrics. These are imperfect measures, but they are better than salary alone because they at least attempt to capture the denominator.
The Leverage Question
There is a version of this argument that goes too far. Not every role requires a $400,000 engineer, and not every company can afford to find out which ones do. Startups with 18 months of runway face real constraints that Google does not. Cost matters when you are conserving capital.
But even constrained companies face a version of the same trade-off, and the insight holds at every level. The question is not whether to pay more for talent. The question is whether you are thinking clearly about what talent actually costs and what it actually produces.
The engineer who touches the fewest things and ships the most value is usually the one who has thought hardest about what not to build. That judgment is the expensive part. You cannot buy it with a lower salary and a longer job description.
The companies that have figured this out tend to have smaller engineering teams than you’d expect given their output. They are not understaffed. They are correctly staffed, with people whose fully-loaded cost, measured honestly against their actual contribution, is lower than the headcount-optimized alternative they didn’t build.
What This Means
The practical implication is not “pay everyone more.” It is that the financial model most companies use for engineering headcount decisions is systematically wrong, in a predictable direction, and correcting it changes which hires look like bargains.
Before approving a hire at any salary, the honest questions are: How long until this person is productive? What does onboarding actually cost in senior engineering time? What is the realistic tenure, and does that change the math? What happens to the codebase if this person makes decisions at the ceiling of their current ability?
If you run those numbers, the sticker price is almost never the most important number. Sometimes a $400,000 engineer is a bargain. Sometimes a $120,000 engineer is the most expensive decision you make this year. Knowing which is which requires measuring the right thing.
