--- title: "Rushed work costs more, but never the people who ordered it" description: "Why organisations keep choosing speed over understanding, even after being burned: the people who order rushed work rarely pay for the cleanup." dek: "Almost everyone who has worked in a large organisation has watched a rushed project collapse and cost more to repair than it would have cost to do properly. The habit survives anyway. The reason is structural rather than personal." published_at: "2026-08-05T05:02:49.531Z" updated_at: "2026-08-05T05:02:49.531Z" tags: - "Business" - "Labour" source_url: "https://graybeard.ing/the-religion-of-speed/" source_domain: "graybeard.ing" canonical: "https://hex37.com/rushed-work-costs-more-but-not-those-who-ordered-it" --- Most people who have spent a few years inside a large organisation can describe the same sequence from memory. A deadline is set before anyone is quite sure what is being built. The work goes out on time, or close enough to claim it did. Then it breaks — not spectacularly, usually, but persistently, in ways that consume the following year. Someone writes up what went wrong. Everyone agrees the schedule was unrealistic and that next time the team will be given room to think. Next time, the team is not given room to think. The interesting question is not whether rushing is a bad idea. Almost everyone who has lived through the aftermath already believes it is. The question is why direct, repeated, expensive experience of the consequences changes so little about what happens next. An essay published in late May under the title [The Religion of Speed](https://graybeard.ing/the-religion-of-speed/) makes the case that this is not an accident of any one workplace but a settled belief system — that at some point moving fast stopped being a practical calculation about a particular piece of work and became a moral position about the person doing it. Move quickly and you are ambitious. Ask for time to understand the problem and you are frightened, negative, or standing in the way. ## Motion is much easier to feel than progress Start with the thing that is confusingly obvious once said out loud: being busy and getting somewhere are different states, and only one of them is pleasant to be in from moment to moment. A day spent in back-to-back meetings, answering messages, closing tasks and pushing something out the door produces a continuous stream of small, legible satisfactions. A day spent working out what the thing actually needs to do, who depends on it, and which assumption everyone is quietly hoping is true produces nothing you can point at by evening. That asymmetry is doing enormous work. The reward for moving fast is immediate and felt by the person moving. The cost of not understanding the work is deferred — it shows up in six months, or eighteen, and it does not arrive labelled as a consequence of anything in particular. Human beings are poor at weighing those two things against each other even when the trade is explained to them. In an environment where the fast option also reads as the serious, committed, professional one, there is no contest at all. ## The bill arrives at somebody else's desk If that were the whole story, it would still be a story about individual weakness, and it would be fixable by telling people to be more disciplined. It is not the whole story, and telling people to be more disciplined has never worked. The second thing going on is that the people who decide to rush are, as a rule, not the people who live with what rushing produces. The executive who fixes the date moves on to the next initiative. The manager who accepts vague requirements rather than force an awkward conversation is promoted. The maintenance falls to whoever is holding the system two years later, frequently someone who was not in the room and cannot reconstruct what was decided or why. Economists call this shape moral hazard — an arrangement in which the person taking a risk is insulated from the loss if it goes badly, so they take more risk than they otherwise would. It is not a description of bad character. It is a description of a wiring fault. The fault is reinforced by what organisations can see. Speed is countable: dates hit, releases pushed, tickets closed, headcount added. Fragility is not counted, because until the moment it fails it does not exist as a number anywhere. Performance reviews follow the countable thing. Employees are assessed on what they shipped, not on the rework they avoided or the maintenance burden they declined to create — which means that for the individual making the call, choosing speed is not merely tempting. It is correct. They are optimising accurately for the thing they will be judged on. ## Half-decisions quietly become load-bearing What accumulates in the meantime is not a single flaw but a residue. Requirements nobody pinned down. Decisions passed along the chain in the hope that someone further down would resolve them. Dependencies on systems nobody examined. In software this residue has a name — [technical debt](https://en.wikipedia.org/wiki/Technical_debt), the compounding future cost of a shortcut taken now — but the same thing forms in operations, hiring, logistics and customer service, wherever activity gets mistaken for accomplishment. The residue hardens. A workaround improvised to get past a launch becomes the way a process is done, then becomes something the business genuinely depends on, and by then removing it is a project of its own. Nobody chose any of this. It is the sum of a few thousand small preferences for motion over comprehension, each individually defensible. ## And then the crisis is blamed on the market Eventually the accumulated fragility does what accumulated fragility does. Something fails badly enough that it cannot be absorbed: an outage, a missed commitment, a customer who leaves without explaining why, a team that burns out and disperses. Here is the step that closes the loop. The failure is almost never attributed to the rushing that produced it. It is attributed outward — to competition, to a demanding customer, to a market moving faster than expected, to a team that was always too small and a budget that was always too tight. Sometimes those explanations are true. But the internal bookkeeping quietly relabels everything: the original rushed build is remembered as fast, the cleanup as unexpected, the rework as iteration, the confusion as alignment, the wholly preventable failure as learning. Once the emergency is understood as something imposed from outside, the only sane response to it is to move faster. Fix faster, ship faster, hire faster, replace faster. The disease is prescribed as the cure, and the cycle starts again with more conviction than before. This is why the lesson never lands. The organisation is not failing to learn because it is stupid. It is failing to learn because the structure has severed the signal: the people in a position to choose comprehension over motion do not receive the information that would make comprehension look worth choosing, and the people who do receive it are not in a position to choose anything. ## Slowing down is not the same as moving slowly The most common objection to any of this is that the alternative is sluggishness — endless deliberation, another meeting, a competitor eating your lunch while you draw diagrams. That objection misreads what is being proposed. Slowing down, in this argument, does not mean lowering the overall pace. It means declining to skip the specific part where the work becomes legible: what are we trying to produce, who depends on it, what breaks if this assumption is wrong, what do we already know, where has this been tried before. Those questions feel slow because they cannot be performed. You cannot posture your way through them or convert them into a presentation. But they are what makes genuine speed possible — the kind that happens when the problem is understood, the constraints are known and the decisions are clean enough that execution proceeds without being relitigated every fortnight. Work done that way still ships. It usually ships sooner, because it is not being rebuilt. None of this is an argument against the vocabulary that has grown up around fast delivery — [agile](https://en.wikipedia.org/wiki/Agile_software_development) methods, or shipping a [minimum viable product](https://en.wikipedia.org/wiki/Minimum_viable_product) to get real feedback early. It is an argument about what that vocabulary is now frequently used to avoid. Which leaves the harder question unanswered. The diagnosis explains why an organisation stays locked in; it does not explain what would unlock one. If the cycle persists because those who benefit from rushing are structurally separated from those who pay for it, then exhortation cannot fix it — no amount of insisting that people think more carefully changes who receives the bill. Something in the wiring would have to change. What that something is remains, for now, genuinely open.