The simple version
A $300K engineer who ships clean, maintainable systems in three months is less expensive than a $90K engineer who takes eighteen months and leaves behind code nobody else can read. Salary is a cost. Output is a return. Confusing the two is one of the most expensive mistakes a company can make.
Why salary feels like the whole story
Payroll is visible. It shows up on a spreadsheet, gets reviewed in board meetings, and makes CFOs uncomfortable in predictable ways. The costs of slow delivery, technical debt, and bad architectural decisions don’t appear on the same line. They don’t appear on any single line. They’re distributed across delayed product launches, engineer-hours spent firefighting legacy systems, and customers who quietly churn because features never arrive.
This accounting illusion is why so many companies default to hiring for salary minimization rather than output maximization. The cheaper hire feels responsible. It looks disciplined. It often isn’t.
The math most hiring managers skip
Consider what it actually costs to build a feature. There’s the engineering time, obviously. But there’s also the cost of every other engineer who has to work around incomplete or poorly designed systems. There’s the product manager’s time spent managing delays. There’s the opportunity cost of not shipping, which is real even if it’s hard to measure.
A senior engineer who moves quickly and makes sound architectural decisions compresses all of those costs. A slower or less experienced one multiplies them. The difference in total project cost between the two isn’t the gap in their salaries. It’s often a multiple of it.
There’s a useful concept here called the multiplier effect. Top-performing engineers don’t just do their own work faster. They make the engineers around them more effective by writing better documentation, designing cleaner interfaces, and identifying problems before they become expensive. Research on software team productivity has consistently found that the output gap between high and low performers isn’t 10 or 20 percent. It’s several times over.
This is related to why the engineer who writes less code is often worth more. The value isn’t in keystrokes. It’s in judgment.
The hidden cost that compounds
Technical debt is where the math gets brutal. Every shortcut a less experienced engineer takes to ship faster becomes future work that someone else has to do. Systems that weren’t designed to scale don’t scale gracefully. Code that wasn’t written to be read isn’t read, it’s rewritten, expensively, later.
The cruel irony is that technical debt tends to slow down future hiring. New engineers spend weeks or months just understanding existing systems before they can contribute. Every hour spent navigating a poorly documented codebase is an hour not spent building. If you hired cheap to save money, you often end up paying for it twice: once in the original hire’s lower output, and again in the drag that output creates on everyone who follows.
Startups feel this more acutely than large companies because they can’t absorb the drag. A Series A company with twelve engineers can’t afford to have three of them perpetually untangling what the first two built in a hurry.
The counterargument worth taking seriously
None of this means every expensive engineer is worth it. Some are expensive for bad reasons: geography, pedigree, negotiating leverage. A Stanford CS graduate with a FAANG pedigree and weak product instincts is not automatically worth three times a thoughtful mid-level engineer from a no-name school.
The real variable isn’t salary. It’s the ratio of output to cost. A $300K engineer who produces ten times the value of a $90K engineer is a bargain. A $300K engineer who produces twice the value isn’t, unless you need specific expertise that’s genuinely scarce.
The mistake isn’t hiring expensive engineers. It’s hiring any engineer without a clear model of what you expect them to produce and how you’ll know if they’re producing it. Salary is easy to track. Output requires you to know what you’re measuring.
What this means in practice
The companies that get this right tend to share a few habits. They hire fewer engineers overall, paying more for each one and expecting more in return. They’re explicit about what good output looks like before someone joins. And they treat every architectural decision as a long-term financial commitment, not just a technical one, because that’s what it is.
The companies that get it wrong hire for headcount because headcount feels like progress. More engineers must mean more output. It usually doesn’t. It often means more coordination overhead, more code to maintain, and more surface area for things to go wrong.
The paradox is that the best engineering organizations are often smaller than you’d expect, staffed with people whose compensation would make a cautious CFO wince. They’re also, typically, faster and cheaper to operate than organizations twice their size built on salary minimization.
Your payroll reflects what you paid. Your product reflects what you got. The goal is to make those two numbers relate to each other honestly.
