Part II · Chapter 3 · Risk, without the score · lesson 9
The treatment nobody picks, and the one case where it is right
10 min
Builds on Four things you can do, and only one of them is work
Part II · Chapter 3 · Risk, without the score · lesson 9
10 min
Builds on Four things you can do, and only one of them is work
Four things an organisation did last year, each of them written into the register as a treatment. One of them is avoidance and three of them are not.
Predict
The test is whether the thing can still happen.
If it can, and you have made it rarer or smaller, that is reduction. There is a control, it has an owner, it produces evidence, and it costs hours every period for as long as the organisation exists.
If it cannot — because the field is gone, the endpoint is gone, the data is no longer held, the market is no longer served — that is avoidance. There is nothing to own and nothing to evidence, because absence does not produce artefacts.
Which gives avoidance two properties nothing else in the treatment list has. It carries no recurring cost, and it cannot drift. A control stops happening when its owner changes teams. A deleted field does not quietly undelete itself.
Every other treatment is a standing commitment. Build a control and you have bought a small permanent obligation: somebody performs it, somebody notices when they stop, and every period it owes an artefact to whoever asks. That is the real price of reduce, and it is paid in the second year and the fifth as well as the first.
Avoidance is paid once. The field is deleted on a Tuesday and the row is over. Nothing appears in next year's evidence request, because the honest answer to show me this control running is that there is no control; the thing it would have protected is not there.
The drift property matters just as much and is even less discussed. A quarterly review that depends on one person remembering stops when that person moves teams, and it stops silently. Removal has no owner to lose.
It has exactly one failure mode, and it is worth naming because it is common: somebody adds the thing back. A customer asks for free-text notes, a developer re-adds the field, and nobody connects the pull request to a row in a register they have never read. That is not a risk question. It is a change-control question, and it is the one place where an avoided risk needs anything at all from you afterwards.
Because the activity is somebody's revenue, or somebody's roadmap, or somebody's promise to a customer who is on the call.
A register that proposes avoidance without naming whose revenue it is proposing to remove is not a serious document, and it will be read as one. The honest form of the suggestion includes the cost: we would stop offering bulk export, which two customers use, worth this much, and here is what we would tell them.
Three cases where it is genuinely the right answer, and they have a shape in common — the activity has almost no users and a large blast radius.
A field you hold and nobody reads. Date of birth on a form that exists because the template had it. The leak risk is real and the usage is zero.
A feature with two users and an outsized reach. The bulk-export endpoint that returns every record in one call, built for a migration in 2023 and never removed.
A data category you entered without deciding to. Free-text health notes, a field that collects children's ages, a country whose rules nobody has read. Nobody chose these; they arrived, and avoidance is how you leave.
Check