The Simple Version
An engineer who ships features quickly but creates hidden problems costs more than one who ships slowly but cleanly. The difference shows up in your balance sheet, just six months later than you’d expect.
Why Speed Looks Like Performance
Engineering output is hard to measure, so companies measure what’s easy: pull requests merged, tickets closed, features shipped per sprint. Speed is visible. The fast engineer looks productive in every standup. Managers can point to them during reviews. They feel like momentum.
The slow engineer is harder to defend. They ask questions before writing code. They push back on requirements. They spend Tuesday afternoon thinking about a problem they won’t touch until Thursday. On a velocity chart, they look like a bottleneck.
This is a measurement problem masquerading as a performance problem.
What Fast Shipping Actually Costs
There’s a concept in software called technical debt: shortcuts taken today that create extra work tomorrow. It’s useful but slightly too abstract. The real cost of fast, undisciplined shipping is more concrete.
Consider what happens when a feature is built quickly without considering edge cases. QA misses something. It ships. Six months later, a customer hits the edge case. A bug is filed. An engineer, not necessarily the original one, has to reconstruct the mental model of code they’ve never seen. They fix one thing and break another. A second engineer reviews it. A third deploys it. What started as two days of “fast” work now costs eight days of slower, more expensive, more senior work.
This is before accounting for the customer who churned, the support tickets, or the engineering manager’s time spent triaging.
Research on software maintenance consistently finds that fixing a bug after deployment costs significantly more than catching it during design or code review, sometimes by an order of magnitude. The ratio varies by context, but the direction never does.
The fast engineer didn’t save time. They borrowed it, at a high interest rate, from their future colleagues.
The Hidden Output of the Slow Engineer
The engineer who moves carefully is producing output you can’t see in a sprint report.
They’re writing code that the next person can actually read. (The average piece of code is read ten times more than it’s written. Clarity is leverage.) They’re catching design problems in review before they calcify. They’re asking “what happens when this fails” before the system is in production. They’re having the ten-minute conversation with a product manager that prevents three weeks of building the wrong thing.
None of this shows up in a velocity metric. All of it shows up in team output over time.
This is related to a dynamic high-output teams understand about “done”: shipping isn’t the finish line. A feature that works, that doesn’t require three follow-up patches, that the next engineer can extend without reading a archaeology report, is worth more than a feature that technically shipped on Friday.
Why Companies Keep Getting This Wrong
Two reasons. The first is time horizon. The costs of fast, sloppy engineering show up months later, often after the engineer who created them has moved to a different team or a different company. The person who benefits from careful engineering is rarely the one who could have rewarded it.
The second is that careful engineers are often less visible in the ways that get people promoted. They prevent fires rather than fight them. In most organizations, the engineer who heroically debugs a production crisis at 2am gets more recognition than the one whose thorough code review prevented the crisis from ever happening. The incentive structure actively selects against the behavior you want.
This isn’t a new insight, but it’s worth stating plainly: if your engineering culture rewards speed above everything else, you’re running a system that punishes the people protecting you.
How to Tell the Difference
Not every slow engineer is careful. Some are slow because they’re disorganized, or stuck, or conflict-averse in ways that keep them from making decisions. Speed isn’t the variable. Judgment is.
The engineer worth paying more for has a specific profile. They can explain why they made a design choice, not just what they did. Their code reviews are substantive, not rubber stamps. When something goes wrong in a system they built, the bugs are at the edges, in genuinely hard cases, not in the predictable paths that should have been caught upfront. And when they push back on a timeline or a requirement, they’re usually right.
The question to ask in a code review or a postmortem isn’t “how fast did they ship” but “how much of this did they anticipate.” Future-proofing is impractical and over-engineering is a real failure mode, but there’s a middle ground that experienced engineers occupy: they solve today’s problem in a way that doesn’t make tomorrow’s problem worse.
As the true cost of a cheap engineer shows up over time, so does the true value of a careful one. The balance sheet eventually catches up to what the sprint board never captured.
Pay for judgment. Speed is trainable. Judgment is what you’re actually buying.
