The software industry has spent decades rewarding the wrong thing. Commit counts, story points, lines shipped — these metrics feel objective, so companies use them. The result is a persistent mismatch between what engineers are paid to do and what actually creates value.
The highest-compensated engineers at the best-paying companies, the staff engineers and principal engineers and distinguished engineers at places like Google, Stripe, and Meta, write surprisingly little code. Their leverage comes from somewhere else entirely. Understanding where is not a philosophical question. It’s an economic one.
The decision is worth more than the implementation
Software has an unusual property: a single architectural decision made at the start of a project can determine costs and constraints for years. Choose the wrong data model and every feature that touches that table becomes harder. Choose the wrong abstraction and you pay interest on that debt indefinitely.
The engineer who prevents a bad decision from being made in the first place creates more value than the team that would eventually have to undo it. This is measurable. Knight Capital lost $440 million in 45 minutes in 2012 because of accumulated technical debt in a trading system, much of it traceable to decisions made years earlier that nobody had revisited. The code ran fine. The decision behind it was catastrophic.
Senior engineers who spend their time in design reviews, architecture discussions, and early-stage product conversations are doing exactly the work that prevents those outcomes. The output is not code. It is constraint: a narrowed set of paths that the engineering team behind them will walk without falling off a cliff.
Multiplier effects compound faster than individual output
A very fast individual engineer might produce three or four times the output of an average one. A principal engineer who raises the quality of decisions across five teams produces leverage that compounds differently. Their influence shows up in other people’s code, in systems they never touch directly, in problems that don’t get built in the first place.
This is not a soft argument. Amazon’s internal structure of senior technical leaders, the principal and distinguished engineers who sit across multiple teams rather than owning one, reflects a deliberate bet that concentrated judgment multiplied across many efforts is worth more than the same person writing code full-time. It is why their compensation scales the way it does.
The same logic explains why a short conversation with the right person can be worth weeks of implementation work. Pair a junior engineer with someone who has seen the failure mode they’re heading toward and the value of that conversation is almost impossible to overstate.
Knowing what not to build is the rarest skill
Product decisions are engineering decisions, even when they don’t look like it. An engineer who can tell a product manager “this feature will take three weeks and will be used by two percent of customers” is performing a form of resource allocation that has immediate financial consequences. An engineer who can say “we don’t need to build this at all because the existing system handles it if you configure it differently” is doing something more valuable still.
The engineers who earn the most are often the ones who understand the system well enough to find those shortcuts, the places where a small, precise intervention produces a large result, or where the right answer is to not write a line. Why deleting code makes software more reliable is a principle most senior engineers understand viscerally. Deletion requires confidence. Confidence requires deep familiarity with what the code actually does and why.
That familiarity is the expensive part. It cannot be rushed. It is why experience commands a premium even when it does not produce proportionally more output.
The counterargument
The obvious objection is that this framework conveniently flatters senior engineers who have stopped coding and want to call it wisdom. There is something to this. Organizations do promote people into influence roles who have simply aged into seniority, and those people often produce very little, in code or in judgment.
The distinction matters. The argument here is not that writing less code is inherently valuable. It is that the specific activities that tend to replace code at high levels of seniority, system design, decision review, cross-team coordination on hard tradeoffs, tend to have higher leverage when done well. Done badly, they are expensive overhead. The salary differential is justified by the leverage, not by the title or the tenure.
Companies that cannot tell the difference between those two things end up with expensive engineering organizations that move slowly. The engineers at the top are not producing leverage. They are consuming it.
Output is not value
The software industry’s instinct to measure productivity in units of code is understandable and mostly wrong. Code is a liability as much as an asset. More of it means more to maintain, more to debug, more surface area for failures. The engineer who writes less but chooses better is doing the harder thing.
Paying for that judgment, rather than for volume, is not irrational generosity. It is accurate pricing. The companies that figure this out early tend to build more reliable systems with smaller teams. The ones that don’t keep wondering why their fastest coders aren’t solving their biggest problems.
