A startup I know spent eight months and somewhere north of $600,000 trying to fix a database architecture that a senior engineer, on their first week, identified as fundamentally broken. The engineer who built the original system had seemed like a bargain at the time. He was not.
This is the story that plays out constantly in tech, and the industry still hasn’t internalized it. We talk about engineering compensation in terms of salary lines on a budget spreadsheet. We should be talking about it the way we talk about leverage.
The Math Nobody Wants to Do
When a company hires an engineer at $800,000 total compensation (a real number at senior levels in San Francisco, New York, and increasingly remotely), the instinct is to compare that to a $200,000 engineer and ask what makes the expensive one four times better. That framing is wrong.
The question isn’t whether someone is four times more productive in raw output. The question is what problems they prevent. A great senior engineer doesn’t write four times more code. They write less code, choose better abstractions, kill projects that would have consumed a year of engineering time, and ask the question nobody else thought to ask before the architecture got locked in. Their value is largely negative space: the disasters that didn’t happen.
One way to see this clearly is through hiring failure rates. Bad engineering hires don’t just underperform, they create drag on everyone around them, introduce technical debt that compounds, and often require expensive remediation work after they leave. The cost of a bad hire is routinely estimated at two to three times their annual salary once you account for recruiting, onboarding, lost productivity, and cleanup. At that rate, cycling through even two mediocre engineers at $200,000 each gets you close to the cost of one exceptional one, with substantially worse outcomes.
What You’re Actually Paying For
The leverage point for elite engineers isn’t their ability to execute tasks. It’s their judgment.
Judgment means knowing which technical bets will age well. It means recognizing, before the team has written a line of code, that the distributed system everyone is excited about will require a dedicated infrastructure team to operate and will become a liability the moment the company’s headcount stops growing. It means being the person in the room who has seen the movie before.
This is particularly acute at architectural decision points. The choices made in the first year of a system’s life tend to compound. Good early decisions make every subsequent engineer more productive. Bad ones become the thing everyone works around, forever. Entire companies have been slowed by early architectural choices that felt fine at the time and became load-bearing walls nobody could remove. The diff that ships is often not the diff that solves the problem, and the engineer who understands that distinction saves enormous amounts of time over the long run.
There’s also a signal effect. Senior engineers attract other senior engineers. The best engineers in the market are often taking calls with their friends before they take calls with recruiters. One strong hire at the top of a team can compress your recruiting funnel in ways that a comp band spreadsheet will never capture.
The Dilution Problem
Here’s where many companies get it backwards. They recognize that elite engineers are valuable, so they hire one or two and then staff the rest of the team with cheaper alternatives to “balance the budget.” The result is that your expensive engineers spend a significant fraction of their time reviewing others’ work, fixing mistakes, and managing complexity they didn’t create.
This is a version of the same mistake organizations make with meetings and communication overhead. The cost doesn’t disappear because you spread it around differently. You’ve just moved it somewhere harder to see.
The alternative is to hire a smaller, more expensive team and give them fewer competing priorities. This is uncomfortable because it feels like you’re getting less for more. But a team of five elite engineers with clear focus consistently outperforms a team of fifteen mid-tier engineers carrying a sprawling backlog. The math works out, but it requires the kind of institutional confidence that is genuinely rare.
Why Cheap Engineers Are an Expensive Strategy
The companies that optimize relentlessly for low engineering costs tend to end up with high infrastructure costs, high remediation costs, and slow iteration cycles. What looks like savings on the salary line shows up as losses elsewhere, just in categories that are harder to attribute.
This is part of why gross margin is often a better predictor of survival than revenue growth. A company with sloppy engineering and low gross margins is paying for its talent decisions in places that don’t show up on the recruiting budget.
There’s also a strategic dimension. The engineer who costs $800,000 is almost certainly being courted by competitors. Losing them isn’t just losing a headcount, it’s potentially losing institutional knowledge that took years to accumulate, and handing a competitor a person who knows exactly how your systems work.
How to Know If You’re Getting the Value
The hardest part of this argument is that elite engineering judgment is genuinely difficult to measure in real time. You can count commits and code reviews. You can’t easily count the project that didn’t happen because someone raised an objection in week one.
The proxy metrics worth tracking are things like: how often do projects get abandoned mid-build due to architectural problems? How much engineering time goes to maintenance versus new capability? How frequently do systems fail in ways that required significant remediation? These are symptoms of the underlying judgment quality of the people who designed the systems.
If those numbers are bad, hiring cheaper engineers to fix them will make them worse. If they’re good, it’s worth asking honestly whether the team you have built is actually responsible for that, or whether you’ve been lucky.
The $800,000 engineer isn’t for every company at every stage. But the instinct to dismiss the number without pricing out the alternative is how companies end up rebuilding the same infrastructure three times, and wondering why they can never seem to ship.
