Salary is the wrong unit of measurement for engineering talent. It’s what you pay, not what something costs. These are different numbers, and conflating them is how companies end up with large, expensive teams that move slowly and a nagging sense that something is structurally wrong.
The senior engineer earning $300,000 at a Bay Area company and the mid-level engineer earning $80,000 elsewhere are not separated by a factor of 3.75 in value. In most real-world cases, the gap runs in the opposite direction.
What You’re Actually Buying
When a company hires an engineer, it purchases a stream of decisions, not a stream of code. The code is almost incidental. What actually determines output is the quality of the choices made before, during, and after the code is written: which problem to solve, how to decompose it, which abstractions to reach for, when to say no.
A senior engineer with deep experience doesn’t just write better code. She identifies which features don’t need to be built, which architectural decisions will become load-bearing walls in two years, and which bugs are symptoms of a deeper problem rather than isolated incidents. That kind of judgment, the kind that doesn’t show up in lines of code or tickets closed, is what actually scales a product.
An engineer without that judgment isn’t cheaper. She’s expensive in a different currency: the currency of rework, accumulated technical debt, decisions that seemed reasonable and later became catastrophic, and the management time required to compensate for gaps in experience.
The Hidden Multipliers
Think through what a single poor architectural decision costs. A team at a growth-stage company chooses a data model that works at their current scale and breaks at the next one. Migrating away from it, once the product is in production with real users, takes months. During that migration, the team is shipping fewer features. The product falls behind a competitor. The company raises its next round at a lower valuation or doesn’t raise at all.
That’s not a hypothetical cascade. It’s a pattern that repeats across the industry with enough regularity that experienced engineering leaders treat architecture reviews as existential risk management.
Now price it. If the migration takes three engineers six months, and each engineer carries fully-loaded costs of around $150,000 annually, you’ve spent roughly $225,000 in labor alone, before accounting for opportunity cost. A more experienced hire at the start, earning perhaps $100,000 more per year, might have caught the problem before it was a problem. The math isn’t complicated.
The same logic applies to debugging, code review, and onboarding. Senior engineers tend to write code that junior engineers can read. This matters because code is read far more often than it’s written. Legible, well-structured code reduces the time every future engineer spends understanding what’s happening, which compounds across every feature built on top of it.
The Coordination Tax
There’s another cost that rarely appears in headcount spreadsheets: the cost of managing less experienced engineers.
Junior and mid-level engineers require more direction, more review cycles, more course-correction. Providing that costs something, and the thing it costs is the time of whoever is doing the managing. In many companies, that person is a senior engineer or engineering manager whose own output decreases proportionally. You’re not just paying for the junior engineer. You’re paying a fraction of every more senior person who has to support her.
This is why team size and team output have a complicated relationship. Adding engineers below a certain experience threshold can actually slow a team down, at least initially, because the coordination overhead outweighs the additional throughput. Fred Brooks documented this dynamic in “The Mythical Man-Month” in 1975. Companies keep rediscovering it as though it were new.
A smaller team of high-caliber engineers often outperforms a larger team of adequate ones. Stripe is a company that has operated this way deliberately. Amazon’s two-pizza team rule reflects similar thinking. The constraint isn’t manpower. It’s coordination.
When the Cheaper Engineer Actually Is Cheaper
This argument has limits. A $300,000 engineer solving a problem that doesn’t require her skills is expensive in a different way: she’s bored, underutilized, and probably interviewing elsewhere within eighteen months. Talent allocation matters as much as talent acquisition.
For certain categories of well-defined, repeatable engineering work, the cost calculus genuinely does favor less senior (and less expensive) engineers. If the task is implementing a spec that’s been thoroughly designed, working on a mature codebase with strong conventions, or contributing to a domain where the decisions are already made, experience has diminishing returns.
The problem is that most companies use this exception to justify a general hiring strategy. They optimize for junior and mid-level headcount because the salaries look manageable, then wonder why progress is slow and technical debt is accumulating. The well-defined, spec-driven work turns out to be less common than expected. Most of engineering, when you look honestly at it, requires exactly the judgment that experience provides.
Rethinking the Spreadsheet
The way most companies evaluate engineering costs is a spreadsheet problem masquerading as a strategy problem. If your unit of measurement is salary dollars per engineer, you will optimize for salary dollars per engineer, and you will get exactly what that optimization produces: lower salaries, more headcount, and slower progress.
The more useful frame is output per dollar of total engineering investment, including the hidden costs of rework, coordination, management overhead, and missed architectural decisions. Measured that way, the distribution of talent that looks expensive on paper frequently looks like a bargain in practice.
This isn’t an argument for paying everyone maximum market rate. It’s an argument for being honest about what you’re actually paying and what you’re actually getting. Salary is a visible number. Cost is what you calculate when you’re willing to look harder.
