A few years ago, a mid-stage startup I know well hired four engineers at roughly $80K each rather than one senior engineer who wanted $320K. The logic seemed airtight: same budget, four times the headcount, four times the output. Eighteen months later, they had rewritten the same authentication system three times, accumulated enough technical debt to slow every new feature by a factor of three, and were six months behind a competitor who had shipped a nearly identical product with two engineers. They eventually paid a staff-level contractor $180K for three months to untangle the mess. The math on “cheap” had stopped working around month four.
This is not an isolated story. It is, in my experience, closer to the default outcome when engineering hiring decisions are made primarily on salary line items.
The Cost of an Engineer Is Not Their Salary
Every engineer who joins a team generates costs that never appear on their offer letter. There’s onboarding time, which for a junior engineer can consume three to six months of a senior engineer’s attention before they reach independent productivity. There’s review overhead: the junior engineer writes code that someone more experienced has to read, question, and often rewrite. There’s the debugging cost when something goes wrong in production and the person who wrote it doesn’t have the pattern-matching to diagnose it quickly. And there’s the compounding cost of architectural decisions made by someone who hasn’t seen what happens when those decisions meet scale.
None of this shows up in a budget spreadsheet. But it’s real money, paid in senior engineer time, delayed releases, and customer-facing bugs.
The $400K engineer, by contrast, often generates a very different cost profile. They write less code, but the code they write tends to be right the first time. They spot the problem in a design review before it becomes a production incident. They make the architectural call that doesn’t need to be revisited in eighteen months. As I’ve argued before, the engineer who writes less code is often worth more precisely because they understand which code shouldn’t be written at all.
Multipliers Are Real, and They Compound
The best engineers don’t just do their own work better. They make the people around them better. A staff engineer who reviews code doesn’t just catch bugs; they teach the people whose code they’re reviewing to write differently. A principal engineer who sits in on a product spec can prevent three months of wasted work in a thirty-minute conversation. These effects compound across a team over time.
The research on this is consistent if not perfectly precise. Studies of software development productivity have repeatedly found that the variance between engineers is enormous, not the 2x or 3x most managers assume, but potentially an order of magnitude across the full distribution. When you hire four engineers near the bottom of that distribution instead of one near the top, you don’t get equivalent output. You often get worse output, because the coordination overhead of four people working on the same codebase is itself a cost.
This is why the best engineering organizations you’ll find, the ones consistently shipping high-quality products, tend to be surprisingly small. Stripe for much of its history maintained an engineering team that seemed undersized for what it was building. So did early GitHub. The pattern isn’t coincidence.
Where This Thinking Goes Wrong
There’s a version of this argument that gets weaponized in ways I want to push back on. “Hire fewer, better engineers” can become a justification for a homogeneous team of people from the same three universities who all think identically. That’s not what I’m advocating. Diversity of background and experience has real value in engineering, and some of the most important technical insight I’ve seen come from engineers earlier in their careers who were willing to question assumptions the senior people had stopped questioning.
The point isn’t that junior engineers are bad hires. It’s that the decision to hire them should account for the full cost, including the mentorship infrastructure required to make them productive. A junior engineer with a great senior mentor in a well-structured team can be an excellent investment. Four junior engineers with no clear technical leadership, hired because the CFO wanted to “optimize” the engineering budget, is usually a disaster.
The other place this breaks down is in genuinely repetitive, well-scoped work. If you have a large volume of clearly defined tasks that don’t require much judgment, the cost calculus shifts. But most early and mid-stage companies don’t have that problem. They have ambiguity, moving targets, and systems that need to be built right the first time because there won’t be time to rebuild them.
How to Actually Think About Engineering Cost
The mental model I’d suggest: stop thinking about engineering salaries and start thinking about engineering output per dollar over an eighteen-month horizon. That timeframe matters because it’s long enough for the compounding effects to show up, short enough to be relevant for most planning cycles.
For any significant hire, ask what happens if this person is the wrong call. With a $400K engineer, the downside is real but bounded. With four $80K engineers who turn out to be mediocre, the downside includes coordination costs, technical debt, the senior engineer time spent managing them, and the opportunity cost of the things that didn’t get built while they were building the wrong things slowly.
Also worth considering: the $400K engineer is often more likely to tell you when something is a bad idea. Junior engineers, especially in environments that don’t actively protect dissent, tend to build what they’re told. Senior engineers tend to push back. That pushback has economic value that is genuinely hard to put a number on, but any engineering manager who has been saved from a bad architectural decision by a senior engineer who was willing to say “this won’t work” knows exactly what it’s worth.
The budget spreadsheet will always make the cheaper hire look safer. In software, it almost never is.
