There is a peculiar pride that lives in engineering teams — the pride of the fast. Story points closed, PRs merged, pipelines green. Efficiency metrics cascade down from dashboards into daily standups, shaping what gets praised and what gets ignored. On the surface, this looks like discipline. But somewhere along the way, the optimisation stopped being about outcomes and started being about the optimisation itself.
Efficiency is not inherently wrong. The problem is context collapse: when a tool designed for one environment gets wielded in another without anyone noticing the difference. And in software engineering, this happens constantly.
"We have become extraordinarily good at building the wrong thing faster."
The factory floor problem
Efficiency as a concept was born in manufacturing — Frederick Winslow Taylor timing workers with a stopwatch, squeezing waste from repetitive physical tasks. The logic holds there. A bolt tightened in two seconds is strictly better than one tightened in five, all else being equal.
Software engineering is not a factory floor. The act of writing code is not a repetitive physical task — it is a series of small, consequential decisions made under uncertainty. When you apply factory-floor metrics to this kind of cognitive work, you do not make the thinking faster. You make the thinking disappear. Engineers stop asking whether something should be built and start optimising for building it smoothly. Speed becomes the proxy for quality, and velocity becomes the goal rather than the vehicle.
- 68% of software features are rarely or never used after launch¹
- 4× the cost to fix a defect found in production vs. at design time
- 40% of engineering time is estimated to go to unplanned rework²
Three ways it plays out
The sprint trap. Two-week sprints were designed to force reflection — a short loop so you could course-correct quickly. In practice, many teams have turned sprints into a delivery conveyor belt. Stories flow in, tickets close, velocity is tracked, and the retrospective at the end is a fifteen-minute ritual before the next sprint begins. Nobody asks whether this sprint's stories were the right ones to build. Efficiency of execution; zero interrogation of direction.
The automation reflex. "Can we automate this?" has become the first response to almost any manual step in the engineering process. Sometimes the answer is absolutely yes. But an automated bad process is just a faster bad process. Test suites that test the wrong things at scale, pipelines that deploy flawed assumptions reliably, monitoring dashboards that efficiently track metrics nobody cares about — these are efficiency wins that create the illusion of rigour without the substance.
The ticket-as-truth problem. When a Jira ticket closes, something inside a team's collective psychology treats that as evidence of value delivered. The ticket described a feature. The feature was built. Therefore value was delivered. This logic only holds if the ticket described the right thing — and that is the assumption nobody checks because checking it does not show up on a velocity chart.
"A team running efficiently in the wrong direction arrives at the wrong place faster, with less energy to recover."
What should replace it
The answer is not to abandon efficiency. It is to restore its context. Efficiency is a multiplier — it amplifies whatever it is applied to. Apply it to purposeful work and you get a high-performing team. Apply it to purposeless activity and you get a well-run machine producing waste at scale.
The teams that get this right do something deceptively simple: they ask different questions before they ask efficiency questions. Not "how fast can we deliver this?" but "should we deliver this at all?" Not "what does our coverage percentage look like?" but "are we testing the things that actually break in production?" Not "is our pipeline green?" but "is what we're shipping moving the metric that matters?"
Engineers are not resources to be utilised. They are people whose best work requires space — space to think, to question, to occasionally slow down so that the ten things that follow can be done with clarity. A team that moves slowly because it is thinking well will, over a long enough horizon, outperform a team that moves fast because it has stopped thinking.
The most efficient thing you can do is build the right thing. Everything else is optimisation theatre.