The Math Most Hiring Managers Never Do
Companies optimize for the number on the offer letter. It is an understandable instinct. Salaries are concrete, recurring, and show up clearly on a budget. The costs of a weak hire are diffuse, delayed, and easy to attribute to something else entirely.
But the salary line is almost never where the real money goes.
A study by the National Bureau of Economic Research found that the productivity gap between software engineers is not small. Top performers do not produce 10 or 20 percent more output than average performers. The gap is closer to 10x across measurable dimensions like code output, defect rates, and task completion speed. If that ratio holds even partially, the arithmetic becomes uncomfortable for anyone who has been optimizing for salary minimization.
A team of five engineers at $80,000 each costs $400,000 a year in salaries. A team of two engineers at $300,000 each costs $600,000. At first glance, the cheaper team wins. But if the two-person team produces equivalent output with fewer coordination costs, fewer defects to fix, and faster decisions, the calculus inverts.
What a Slow Engineer Actually Costs
The most visible cost of a weak hire is their direct output: features that take twice as long, bugs that make it to production, architecture decisions that need to be reversed six months later. Those are real, but they are the smaller part of the bill.
The larger cost is what they do to everyone around them. A struggling engineer consumes disproportionate time from senior colleagues who review their code, answer their questions, and quietly redo their work. Engineering managers at companies including Google and Meta have described a consistent pattern: one underperforming engineer can reduce the effective output of three or four teammates by 20 to 30 percent through coordination drag alone. The focus recovery cost of a single interruption compounds this problem. Every “quick question” is not a five-minute cost. It is closer to a 30-minute cost when you account for the context switch on both ends.
Then there is the systemic damage. A weak engineer does not just deliver less. They often build technical debt that outlasts their tenure. A rushed or poorly considered implementation does not stay contained. It becomes the foundation that future engineers build on, work around, or spend months untangling. The cost of a bad database schema choice, made in year one by an engineer who did not understand the product’s growth trajectory, can run into millions of dollars in migration work years later.
Why Companies Keep Buying the Cheaper Option
The mismatch persists because costs are not measured symmetrically. Finance teams can point to the exact dollar difference between a $300K offer and an $80K offer. Nobody tracks the engineering hours lost to code review on weak commits, the delayed product launches attributable to rework cycles, or the hidden cost of a senior engineer spending 40 percent of their time as an informal help desk.
There is also a risk asymmetry in how hiring decisions are evaluated. A manager who approves a $300K hire that does not work out will face scrutiny. A manager who approves five $80K hires that collectively underperform will find the failure distributed across enough variables that personal accountability diffuses. The incentive structure rewards the appearance of fiscal prudence over actual cost-effectiveness.
Startups feel this pressure most acutely. Early-stage companies face genuine capital constraints that make a $220,000 salary gap feel existential. The reasoning is defensible when runway is measured in months. It becomes less defensible when it calculates out to a 12-month timeline to build something a smaller, stronger team could ship in four.
The Multiplier Effect Goes in Both Directions
The same logic that makes a great engineer cheap at $300K makes an excellent engineer at $120K an extraordinary hire. Salary correlates with talent in software engineering, but loosely enough that the market creates real arbitrage opportunities, particularly in geographic markets outside major tech hubs or in candidates early in their careers whose potential has not yet been priced in.
What companies should be measuring is output per dollar spent, not salary in isolation. That requires actually tracking engineering productivity, which most organizations do a poor job of doing rigorously. Metrics like cycle time, defect rates, code review turnaround, and incident frequency give at least a partial picture. None of them is perfect, but collectively they provide a more honest picture of what a hire actually costs than the number in the compensation package.
The best engineering leaders treat hiring as a leverage decision, not a headcount decision. Jeff Dean, Google Fellow and the architect behind many of the company’s core infrastructure systems, is frequently cited internally as an example of a single engineer whose contributions enabled work that would have required hundreds of lesser engineers to replicate. That is an extreme case, but the principle scales down through every level of an organization.
What This Means for Hiring Decisions
The practical implication is not that every company should immediately start paying top-of-market salaries across the board. Compensation structures involve tradeoffs across retention, equity, culture, and budget that do not reduce to a single variable.
The implication is narrower: when a company is deciding between hiring one expensive engineer and two cheaper ones, the default assumption that two is better than one is usually wrong. The coordination cost between two people is not zero. The management overhead is not zero. The probability that both are strong performers is lower than the probability that one carefully selected person is.
Companies that consistently underpay for engineering talent tend to end up in a self-reinforcing cycle. They build slower, accumulate more technical debt, require more headcount to maintain the same systems, and find it harder to attract strong engineers who have options. The savings at the hiring stage show up as compounding costs in the operating budget.
The $300K engineer is not always the right answer. But treating salary as the primary unit of cost in an engineering organization is a category error that ends up being very expensive.
