The simple version
A $50,000-a-year engineer who solves the wrong problems slowly costs more than a $300,000-a-year engineer who solves the right problems fast. The difference is not skill in isolation. It is the relationship between salary and value produced.
Why salaries feel like costs but aren’t
Every CFO understands payroll. It shows up as a line item, it recurs monthly, and it is easy to track. What doesn’t show up anywhere on a balance sheet is the cost of slow velocity, the cost of a wrong architectural decision that takes two years to untangle, or the cost of shipping a feature six months late because nobody on the team understood the system well enough to build it cleanly the first time.
This is the core accounting error that makes cheap engineering feel rational. You are comparing a number you can measure against costs you largely cannot.
The McKinsey Global Institute has studied productivity variation across knowledge workers for years and found that top performers in complex roles (software engineering qualifies) produce output that is not 20% or 50% better than average, but several times better. In engineering specifically, research published by academics including Lutz Prechelt has found order-of-magnitude variation in how long different programmers take to complete the same task. Not 10% variation. Ten-times variation.
If that finding is directionally correct, the $300K engineer is not six times more expensive than the $50K engineer. The $300K engineer might be six times cheaper per unit of working software produced.
What the multiplier actually looks like
The salary comparison is only the beginning. Consider what a software engineer actually costs a company beyond base pay: employer payroll taxes, benefits (health insurance alone runs $15,000 or more per employee per year at many companies), equipment, software licenses, management overhead, office or remote-work stipends, and recruiting cost (often 15-25% of first-year salary). A $50K engineer might cost $75K to $85K all-in. A $300K engineer in a total-compensation package might cost $350K to $380K.
That’s roughly a 4.5x difference in total cost. Now apply the productivity multiplier.
If the senior engineer produces code that is 4x faster to ship, 3x less likely to introduce critical bugs, and makes three junior engineers around them meaningfully more effective through code review and mentorship, the arithmetic stops favoring the cheaper hire very quickly.
Bugs are a useful place to apply actual numbers. Capers Jones, who spent decades studying software project economics, estimated that the cost to fix a defect rises by roughly a factor of 10 at each stage of the development process. A bug caught during development might cost an hour of work. The same bug caught in production might cost days of incident response, customer support escalation, and engineering time, plus whatever revenue was lost while a feature was broken. An engineer who writes code with a materially lower defect rate is saving money that never appears in a comparison of salary lines.
The wrong question most hiring managers ask
The question most engineering managers ask when hiring is: “Can this person do the job?” The question that actually drives value is: “How much leverage does this person create relative to what they cost?”
Leverage is the operative concept. A senior engineer who can architect a system that three junior engineers then build correctly is generating leverage. A senior engineer who makes a bad architectural call early, forcing the team to rewrite six months later, is destroying leverage, regardless of their own individual coding speed.
This is why your first hire is a thesis statement about what you believe. Early engineering hires set patterns, make foundational decisions, and establish the technical culture that every subsequent hire inherits. Optimizing that hire for salary cost rather than value multiplier is one of the more expensive mistakes a startup can make.
It is also why the $300K engineer at a large company is often underpaid relative to value produced. If that engineer’s architectural work enables a product to scale to 10 million users without a rewrite, the value created likely runs into tens of millions of dollars. Against that number, $300K is not expensive. It is cheap.
Why companies keep making this mistake anyway
The problem is not ignorance. Most engineering leaders understand this intuitively. The problem is organizational incentives.
A VP of Engineering who hires three $50K engineers instead of one $300K engineer has a headcount story to tell, three people whose work is individually accountable, and a budget that looks controlled. If those three engineers produce less value, the shortfall is diffuse and hard to attribute. It shows up as slow velocity, rising technical debt, and eventual rewrites, none of which trace cleanly back to the original hiring decision made two years prior.
By contrast, the manager who hires one expensive engineer and that hire doesn’t work out has made a visible, attributable, costly mistake. The asymmetry of accountability pushes toward cheaper hires even when the math doesn’t support them.
There is also a genuine skill problem: evaluating whether a candidate will produce 4x the output of an average engineer is hard. Comparing salary numbers is easy. When measurement is difficult, people optimize for what they can measure.
What the data suggests you should actually do
The implication is not “always hire the most expensive engineer you can find.” High salary does not guarantee high output, and there are plenty of expensive engineers who produce mediocre results. The implication is that salary should be a weak input to hiring decisions, not a primary filter.
The stronger filters are demonstrated output history, technical judgment (the ability to make good decisions under uncertainty, not just execute known solutions), and the capacity to write code that other engineers can actually work with. Those qualities correlate imperfectly with salary, which means the right hire at $180K might outperform the wrong hire at $300K.
What the data clearly argues against is using a salary ceiling as the primary screening criterion and assuming you have saved money when someone accepts a lower offer. You have deferred the cost. You have not eliminated it.
