A founder I know spent eight months hiring three mid-level engineers at competitive but not outrageous salaries. By month nine, two had left, one was managing the technical debt the other two created, and the product was exactly where it had been before. The burn was real. The output was not.
Here is the uncomfortable math that most hiring conversations avoid: salary is almost never the dominant variable in engineering cost. The dominant variable is output per dollar over time. And when you measure it that way, the expensive engineer almost always wins.
The fully-loaded cost of mediocrity
When a company budgets for an engineer at $120K, they are not budgeting for an engineer. They are budgeting for a salary. The real number includes recruiting fees (typically 15-25% of first-year salary if you use an agency), onboarding time, the senior engineer whose productivity drops while they mentor the new hire, the bugs shipped to production, and the architectural decisions made without enough experience to know they were decisions at all.
None of that shows up in the headcount spreadsheet. It shows up six months later as a rewrite, a postmortem, or an all-hands about why the roadmap slipped again.
A strong senior engineer hired at $300K or more does less of all of that. They ramp faster, they ask better questions during onboarding, they tend not to create the categories of problems that require other people to stop working to fix. The expensive hire is often, paradoxically, lower risk.
Multiplier effects compound quickly
The real argument for paying for talent is not about the individual. It is about what one strong engineer does to everyone around them.
Code review quality is contagious. An engineer who writes clear, well-reasoned pull request feedback raises the average of the people they review. An engineer who approves things to keep the queue moving does the opposite. Architectural judgment works the same way. One decision made correctly early, by someone who has seen the failure mode before, can save months of work that never needs to happen.
This is why the 10x engineer framing is usually applied badly. The number is not really about individual throughput. It is about whether someone makes the team better or quietly makes it worse while shipping tickets on time.
Retention economics are brutal
The median tenure in software engineering jobs in the United States sits around two years at many tech companies. For a $120K hire, losing someone after 18 months means you paid recruiting, onboarding, ramp-up time, and knowledge loss costs that dwarf whatever you saved on base salary.
Strong engineers, hired well and treated like adults, tend to stay longer. Not because they have fewer options (they have more) but because they are more likely to be working on problems that are actually interesting, with people they actually respect. Retention is a quality-of-hire problem before it is a culture or compensation problem.
The churn math is simple: two engineers at $120K who leave in 18 months cost more than one engineer at $240K who stays for four years. And the one who stays for four years knows where the bodies are buried.
Seniority compresses team size
More engineers means more coordination overhead. This is not a controversial point, it is just one that companies consistently ignore when they are in growth mode and feel like more headcount equals more speed. It does not. Past some small threshold, it often means the opposite.
A smaller team of more expensive engineers moves faster than a larger team of cheaper ones, because the communication overhead scales with team size and the output scales with individual quality. Fred Brooks documented this in 1975 and the industry has been rediscovering it every few years since.
If you can do the same work with four people instead of eight, you have also cut your meeting load in half, your alignment problems in half, and your bus factor problems in half.
The counterargument
The obvious objection is that not every company can afford $600K engineers, and that is true. A pre-seed startup with $1.5M in the bank cannot make that bet without doing the math very carefully.
But the argument here is not that every company should pay top of market for every role. It is that companies consistently underestimate the total cost of cheap hires and overestimate the total cost of expensive ones. The comparison is almost always made on salary alone, which is like comparing two cars on sticker price without knowing that one needs an engine rebuild every six months.
There is also a real risk to overpaying for the wrong senior engineer. Seniority and effectiveness are not the same thing, and a disengaged $300K engineer who coasts is its own category of expensive. This is a hiring quality problem, not an argument against paying well.
What this actually means
Hire fewer engineers than you think you need. Pay them more than feels comfortable. Measure what they actually produce over time, not what they cost per month. The companies that have figured this out are not doing anything exotic. They are just running the math all the way through instead of stopping at the salary line.
The $600K engineer is not always cheaper. But they are cheaper far more often than anyone’s hiring spreadsheet suggests.
