Preventing the Next One

Preventing the Next One is the chapter the business asks for first and funds last. The signals that preceded this delivery were present, readable and unread, and the reason they went unread is almost never that the team lacked the knowledge to interpret them.

Key takeaways

• The four early signals are a rising deployment rework rate, a tightening hotspot concentration, estimate spread widening while averages hold, and a why column nobody can fill. All four are visible months before anyone uses the word rescue.
• Estimate variance predicts trouble earlier than estimate accuracy does, because a team can hold its averages by absorbing overruns quietly long after its forecasting has stopped working.
• Prevention fails on incentives rather than on knowledge. A control only survives if it produces a number that somebody outside engineering already reads for their own reasons.
• The cheapest durable control is a standing review of the same three metrics with a named owner, because the mechanism that failed here was attention rather than capability.
• Some deliveries should be allowed to fail. A prevention practice that never recommends stopping is not a control, it is a ritual.

Read this beside Chapter 1, whose five conditions this chapter tries to catch before they harden, and Chapter 11, which handed the measurements to a named owner. This is the last chapter, and it deliberately ends inside the reader's own organisation rather than in the one that was rescued.

Look back at the delivery you were called into. Somewhere between nine and eighteen months before anyone said the word rescue, the data said it was coming, and somebody looked at that data every week without seeing it.

That is the uncomfortable claim in this chapter. Not that the signals were missing. That they were read and did not produce an action.

The four signals, and how much warning each gives

Each of these is measurable with what a normal team already has.

The first is deployment rework rate, in DORA's current definition: deployments that were unplanned and happened because of a production incident. It rises before availability degrades, because a team absorbs the first months of instability with unscheduled effort rather than with visible outages. It is the earliest of the four that appears in a dashboard.

The second is hotspot concentration. Tornhill and Borg's method across 39 production codebases ranks files by change frequency crossed with size, and the useful signal on an established codebase is not the ranking itself but its movement. Healthy systems spread change around as features arrive in different areas. A system heading for trouble concentrates: the same few files carry a larger share of all commits every quarter, because they are the only places anyone still knows how to change.

The third is estimate spread. Teams and their managers watch accuracy, meaning whether the average estimate is roughly right. Variance moves first. When the same team's two-day tasks start finishing anywhere between one and nine days while the mean holds, forecasting has already failed and nobody has noticed, which is the mechanism behind the long maximum cycle times that study measured in low quality code.

The fourth is not a metric. It is the first time a senior engineer cannot answer why something is the way it is, about a part of the system that is still changing. Naur's test is exact: a program's death becomes visible when demands for modification cannot be intelligently answered. On any real timeline that moment arrives long before the delivery stalls, and it usually gets recorded as an individual's knowledge gap rather than as a property of the system.

Why prevention fails, and it is not ignorance

Every organisation that has been through a rescue writes down lessons. Most of them are correct. Few of them change anything, and the reason is structural.

Prevention has diffuse benefits and concentrated costs. The cost lands on this quarter, on named people, in the form of work that produces no feature. The benefit lands on a future quarter, on people who may be different, in the form of a problem that does not occur. No individual in that arrangement is rewarded for the trade, and the person who insists on it is visibly slower than the person who does not.

Martin Fowler's argument from May 2019 is the strongest counter available, and it is worth having precisely because it is economic rather than moral: internal quality pays back in weeks, not years, and there is almost no runway on which trading it for speed is rational. That reframes prevention from a virtue into an arithmetic error being made repeatedly by people who are optimising correctly for what they are measured on.

Which is why the controls that work all share one property. They produce a number that somebody outside engineering already reads for their own reasons, and the number makes the trade visible while it is being made rather than after.

The controls worth keeping, ranked by what survives

Most prevention advice is a list of practices. The useful question is which of them survive eighteen months of delivery pressure without a champion.

A standing weekly review of three numbers survives, if the audience includes someone with budget authority. Deployment rework rate, change fail rate, and the hotspot concentration trend. Fifteen minutes, no slides, the same three charts each time, and one sentence per number saying whether it moved and why.

A decision record habit survives, because it costs almost nothing per decision and each record is written by the person who most wants to be understood later. Chapter 11 covers the mechanics; the prevention value is that a decision with a written rationale is one that can be revisited without an argument about what was intended.

A rule that every incident produces either an owned action or an explicit decision to accept the risk survives, provided the accepted risks are listed somewhere visible. An accepted-risk list is one of the few artifacts that makes an organisation's tolerance legible to itself.

Two things routinely fail. Coding standards enforced by review culture rather than by tooling last until the first crunch. And any quality initiative whose reporting line is inside the team being measured lasts until that team is behind schedule, which is also the moment it becomes necessary.

Read the culture as a leading indicator

DORA's capability guidance on generative organisational culture names Westrum's six behaviours: high cooperation, messengers are trained, risks are shared, bridging is encouraged, failure leads to inquiry, and novelty is implemented. Their finding is that a high-trust generative culture predicts software delivery and organisational performance.

Used as prevention, the useful question is narrower than the model. How long does bad news take to travel upward, and what happens to the person who carries it. That single question predicts more about the next eighteen months than any architecture review, because every one of the four signals above requires somebody to say something unwelcome early.

There is a practical version for a founder who does not want a culture programme. Ask the two most junior engineers, separately, what they would fix if they could. Then watch what happens to the answers. A system where those answers reach a decision maker and produce a visible response is a system where the four signals will be reported. One where they do not is a system where they will not be, whatever the dashboards say.

Some projects should be allowed to fail

A prevention practice that only ever recommends continuing is not a control.

Flyvbjerg and Budzier's measurement across 1,471 IT projects, published in March 2013, found a mean cost overrun of 27% with one project in six overrunning cost by 200% and schedule by almost 70%. Distributions with tails like that contain projects whose correct treatment is cancellation, and an organisation that never cancels anything is not avoiding those projects. It is funding them to completion at the tail's price.

So the last control is a stopping rule, written before the project starts. Name the conditions under which this delivery would be stopped rather than rescued: a market that moved, a dependency that will not arrive, a cost that has crossed the value it was justified by. Then review those conditions on the same cadence as the three numbers.

The value of writing it in advance is that the conditions are set by people who are not yet emotionally committed. Six months in, the same people will be defending decisions they made, which is a different and worse position to reason from.

The signals apply to the rescue itself

There is a use for the four signals that is easy to miss, and it is the one that keeps a rescue honest.

Point them at your own engagement. Deployment rework rate should be falling by week eight, hotspot concentration should be loosening as change spreads back out across the codebase, and estimate spread should be narrowing as the perimeter closes. If those three are flat at week eight, the repair is not working, and the correct response is to say so before the sponsor notices rather than after.

The fourth signal applies too. Count the cells still blank in the why column. If that number has stopped falling while people who could close cells are still employed, the interviews stopped happening, usually because delivery pressure displaced them quietly. That is a schedule problem with an expiry date attached, and it is the one failure in this book that cannot be recovered later.

What this book asked you to do, and in what order

The order was the argument. Name which kind of broken this is before proposing anything. Establish four facts from records in the first week. Rebuild the theory by reading history before state and asking people why rather than how, while they are still reachable. Decide between repairing, wrapping, replacing, rewriting and archiving, per component, in a time-boxed assessment. Stabilise, measured rather than declared. Build a test net around the paths that carry money and obligations. Renegotiate the schedule with priced options rather than explanations. Work with the people who built it as the source they are. Sequence the repairs in small batches so delivery never stops. Restore the release path until it is boring. Hand ownership back as demonstrated capabilities. Then leave, having written down what is unfinished.

None of that requires unusual talent. It requires doing the diagnosis before the prescription, which is difficult for a specific reason: the prescription is what you are being paid for, and the diagnosis looks from the outside like a month of not starting.

Chapter summary

Every rescue was legible before it was called one, in four signals that a normal team already has the data for: deployment rework rate rising while availability still looks fine, hotspot concentration tightening quarter on quarter as change collapses into the few files anyone still understands, estimate spread widening while averages hold, and the first unanswerable why about a part of the system that is still changing, which is Naur's test for a dead theory. Prevention then fails on incentives rather than on knowledge, because its costs are concentrated on this quarter and its benefits are diffuse, which makes Fowler's economic argument the right one to deploy: internal quality pays back in weeks and there is almost no runway for the trade. The controls that survive delivery pressure are the ones producing a number an outsider already reads, being a standing fifteen-minute review of three metrics with budget authority present, a decision record habit, and a rule that every incident yields an owned action or a listed accepted risk. Culture is the leading indicator underneath all of them, and the narrow diagnostic is how fast bad news travels upward and what happens to the person carrying it. Finally, a stopping rule written before the work begins, because a distribution with a tail like the one Flyvbjerg and Budzier measured contains projects that should be cancelled rather than rescued, and only people who are not yet committed can set that condition honestly.

That is the book. The order it argues for is the whole of its advice: diagnose, then stabilise, then decide, then repair, then hand back. If you take one thing from it, take the discipline of naming which kind of broken you are looking at before proposing what to do about it, because every expensive mistake in this book descends from skipping that step.