The salary number on an offer letter is the least important variable in engineering economics. Most companies never learn this until the damage is done.
Companies make expensive hiring mistakes not because they misjudge character or work ethic, but because they mistake the cost of a person for the cost of the work that person produces. These are different quantities, and conflating them leads to decisions that look fiscally responsible and turn out to be financially catastrophic.
The Arithmetic Everyone Gets Wrong
When a hiring manager rejects a candidate because they’re asking for $400,000 in total compensation, the implicit assumption is that this candidate is twice as expensive as one asking for $200,000. But cost isn’t compensation. Cost is compensation plus the value of everything that doesn’t get built, plus the value of what gets built wrong, plus the carrying cost of maintaining bad decisions over time.
Software organizations tend to track input costs (salaries, benefits, infrastructure) with great precision and output value (features shipped, technical debt avoided, architectures that scale) with almost none. This asymmetry is what makes cheap engineers feel like savings and expensive engineers feel like luxuries. It’s an accounting illusion.
The engineer earning $400K who ships a feature in two weeks that would have taken a $200K engineer eight weeks isn’t twice as expensive. They’re a fraction of the cost. The ratio that matters is value produced per dollar spent, and that ratio almost never correlates with compensation in the way hiring managers assume it does.
What Senior Engineers Actually Do
The confusion gets worse when you look at what high-compensation engineers actually spend their time on, because it often doesn’t look like productivity.
A principal engineer reviewing a system design for an hour and recommending a different approach isn’t visibly building anything. A staff engineer who pushes back on a product requirement because it will create unmanageable complexity six months from now isn’t adding to the sprint velocity. An architect who insists on a particular data model because they’ve seen three other companies regret the alternative isn’t delivering tickets.
All three are doing work whose value is almost entirely in what it prevents. The costs they’re avoiding are real, but they’re invisible on a spreadsheet because they never appear as line items. You can’t put a number next to “rewrite we didn’t have to do” or “outage that didn’t happen.”
This is partly why the notification you dismiss in two seconds took an engineer six months to build. The work that shapes a system from the inside, the work that prevents the expensive failures, is systematically harder to see than the work that produces visible output.
The Carrying Cost of a Bad Architecture
Here’s where the numbers get genuinely alarming. A bad architectural decision made in year one of a product doesn’t cost the same thing in year three as it did when it was made. It compounds.
Every developer who works in a system built on a compromised foundation spends some percentage of their time working around it. A team of ten engineers each losing 15 percent of their productivity to accumulated technical debt is mathematically equivalent to losing one and a half engineers entirely, but the cost doesn’t show up as a headcount line. It shows up as slower velocity, higher defect rates, and longer onboarding times for new hires. These are recoverable problems. The version that isn’t recoverable is when the debt is so severe that the system can’t scale and requires a full rewrite, a project that tends to take two to three times as long as estimated and frequently fails outright.
The senior engineer who costs $400K and prevents that architecture from being built in the first place has delivered value that dwarfs their compensation many times over. The junior hire who built the cheaper-looking system and left two years later is the expensive one. The company just doesn’t have a way to see it on a balance sheet.
Hiring to Save Money Is a Specific Kind of Trap
There’s a version of this mistake that’s particularly common in growth-stage companies: the decision to fill a senior role with a mid-level hire because the senior candidate’s compensation demands feel aggressive. The reasoning is almost always some variation of “we can grow someone into the role.”
Sometimes this works. More often, it doesn’t. Growing someone into a role takes time, mentorship, and a relatively forgiving environment for mistakes. Growth-stage companies usually have none of these in abundance. The result is a mid-level engineer operating above their current ceiling, making decisions they aren’t equipped to make, in a high-stakes environment that punishes learning.
The company ends up spending 18 months and a significant salary before acknowledging the hire isn’t working, then spending another six months finding and onboarding a replacement. The total cost, including the rework required to address decisions made during that period, often exceeds what they would have paid the original candidate. The “savings” were a loan taken out at a very high interest rate.
The Multiplier Effect Runs in Both Directions
Senior engineers produce leverage in ways that are well-understood but underweighted. A well-designed system is faster and safer to build on. Good documentation, clear interfaces, and thoughtful abstractions multiply the productivity of everyone who works in the codebase afterward.
What’s less appreciated is that a poorly-designed system imposes a tax on everyone who touches it. It’s not neutral. The drag compounds over time, and it’s particularly severe for new team members who don’t have the context to understand why things are the way they are.
This multiplier effect applies to hiring decisions themselves. Companies that develop a reputation for technical excellence attract engineers who want to work on hard problems in well-run environments. Companies with a reputation for accumulated debt and firefighting attract engineers who either don’t know better or have limited alternatives. Compensation signals quality, but culture signals it louder. And culture, in engineering organizations, is largely a function of the decisions made by the most senior technical people in the building.
What the Best Companies Have Figured Out
The organizations that consistently build effective engineering teams don’t think about compensation as a cost to minimize. They think about it as a signal to optimize. Paying at or above market rate for senior talent communicates that the company understands what it’s buying. It sets expectations for quality. It tends to produce teams where the senior engineers are genuinely senior rather than mid-level engineers with senior titles.
Amazon’s bar-raiser hiring process, whatever its flaws, reflects an understanding that every hire affects the quality of subsequent hires. The explicit goal is that each new team member should raise the average quality of the team, not just meet it. This is a more sophisticated frame than “does this person’s salary fit our budget.”
Stripe built and maintained a reputation as an exceptional engineering organization for years, which meant they attracted candidates who wanted to work at Stripe specifically, giving them more selection power than raw compensation alone would suggest. The investment in engineering culture paid compounding dividends in hiring.
As we’ve noted before on this site, this principle isn’t new, but companies keep rediscovering it the hard way.
What This Means
If you’re making engineering hiring decisions, the relevant questions are: What does it cost when this work takes twice as long? What does it cost when the wrong decision gets made and we carry it for two years? What does it cost to rebuild this when the architecture fails to scale? If the honest answers to those questions are large numbers, you’re in the business of buying expensive insurance when you hire senior engineers, and the premium is almost always worth it.
The salary on the offer letter is the price of admission. The real cost is what happens next.
