In 2014, Stripe was making a decision that would have looked reckless to most finance departments. The payments company was paying engineers at rates that, fully loaded with equity, benefits, and overhead, cleared $400,000 to $600,000 per year per person. Meanwhile, a perfectly capable software engineer could be hired in the same market for a quarter of that. The instinct for most companies would be to staff up with the cheaper option and ship more code with more people.
Stripe did the opposite. It kept its engineering team deliberately small and paid for talent at the top of the market. By 2016, it had fewer than 200 engineers supporting a product used by hundreds of thousands of businesses. The bet worked, and understanding why requires thinking about engineering costs differently than most companies do.
The Setup: What a Salary Is Not
The mistake companies make is treating engineering compensation as the unit of cost. It isn’t. The actual unit of cost is output, and the relationship between compensation and output is not linear. It isn’t even close.
Studies on programmer productivity going back to the 1960s, including Sackman’s original 1968 research at System Development Corporation, have consistently found order-of-magnitude variation in output between developers working on the same task. A factor of 10x difference in productivity between the top and bottom quartile is not unusual. More recent research has generally confirmed that finding, though the exact ratio varies by task type.
If you accept even a modest version of that premise, say 4x or 5x variation rather than 10x, the arithmetic changes completely. A $500,000 engineer who produces five times the output of a $120,000 engineer costs one-tenth as much per unit of useful work. You are not paying a premium. You are getting a discount.
But productivity comparisons undersell the case, because elite engineers don’t just work faster. They solve different problems.
What Happened: The Architecture Decision Nobody Counted
In the mid-2000s, Amazon was struggling with the architectural complexity of its monolithic codebase. The system had become nearly impossible to change safely. Jeff Bezos famously issued a mandate requiring all teams to expose their functionality through service interfaces and communicate only through those interfaces, laying the groundwork for what became AWS.
The engineers who designed those interfaces weren’t just writing more code per day than their peers. They were making structural decisions that would compound in value over years. A poorly designed API, chosen because the available talent couldn’t see far enough ahead, would have cost Amazon hundreds of millions in rework, lost velocity, and competitive delay. The cost of that architecture decision wasn’t on anyone’s headcount spreadsheet.
This is the category most compensation analyses miss entirely: decisions that are invisible when made but enormous in retrospect. A senior engineer who designs a system that scales gracefully from 10,000 to 10 million users saves the company a full rewrite. That rewrite, if it ever happens, typically costs more than the engineer’s entire career compensation.
The inverse is equally true. A mid-level engineer who introduces a subtle concurrency bug into a financial system doesn’t show up as a cost at hiring time. The cost materializes months later, in debugging hours, in customer trust, in regulatory scrutiny. The causal chain between the original hiring decision and the downstream expense is long enough that most organizations never close the loop.
Why It Matters: The Coordination Tax
There is a second mechanism that makes cheap, abundant engineering talent more expensive than it appears: coordination overhead.
Fred Brooks established in “The Mythical Man-Month” that adding engineers to a late project makes it later. The reason is that communication costs scale with the square of team size. Two engineers need one communication channel. Five need ten. Fifteen need over a hundred. Every additional person added to solve a problem also adds friction to every other person already working on it.
A small team of elite engineers sidesteps much of this. They need less supervision, produce fewer bugs that others must diagnose, write code that is easier to read and extend, and make architectural decisions that reduce future complexity rather than adding to it. The coordination tax on a team of eight exceptional engineers is a fraction of what it would be on a team of twenty-five adequate ones producing similar output.
This is the logic that animated Stripe’s staffing philosophy, and it’s visible in other places. WhatsApp had 55 engineers when Facebook acquired it for $19 billion, serving 450 million users. Instagram had 13 employees at acquisition. Neither company achieved that ratio by hiring cheap and staffing up. They achieved it by being extremely selective and paying accordingly.
What We Can Learn: The Numbers Companies Don’t Track
The reason most companies get this wrong is a measurement problem. Salaries appear on a line in a spreadsheet. The cost of a bad architectural decision does not. The cost of three months of slower shipping while a mediocre team debugs a problem an expert would have avoided does not. The cost of a rewrite does not, at least not in a way that traces back to the original hiring decision.
This is a version of the problem that shows up across tech economics: the costs that are easy to see drive decisions, while the costs that are hard to see drive outcomes. A company that hires two $120,000 engineers instead of one $240,000 engineer has saved money on paper. Whether it has saved money in practice depends entirely on the gap in output between those engineers, which nobody measured at hiring time and which finance will never attribute to a staffing choice made eighteen months ago.
The companies that get this right do a few specific things differently. They treat headcount as a liability, not an asset, which means each hire needs to clear a high bar rather than simply being available and affordable. They invest heavily in hiring process, not because it’s a nice thing to do, but because the expected value of getting a hire right at the senior level is enormous. And they resist the pressure to staff up quickly when a project falls behind, recognizing that the cure is often worse than the disease.
None of this means every company should pay $500,000 for engineers. The logic only holds if you can actually identify and attract the engineers who justify it, and if your work is complex enough that individual judgment and skill matter at the margin. For straightforward, well-specified engineering work, the productivity premium for elite talent shrinks and the arithmetic shifts.
But for the kind of technical work where architecture matters, where the problem isn’t fully specified, where the decisions made today will constrain or enable decisions made in three years, the expensive engineer is frequently the rational economic choice. The budget line that looks like a premium is often, on closer inspection, the discount.
The companies that understand this don’t think they’re paying more for talent. They think everyone else is paying more for work.
