The Subtraction Framework

Most operational problems are not caused by something missing. They are caused by everything that was added once and never removed.

The correction is a single move. Invert the burden of proof. Nothing has to justify its removal. Everything has to justify its existence.

Five rules follow from that one inversion.

• Default is delete. Nothing stays because it is good. It stays only because removing it breaks a named need.

• The need must be named, not implied. "Best practice," "might be useful," "it is free," "everyone does it," and "we already paid for it" are not needs. If the need cannot be stated as a specific thing that breaks, it is not a need.

• One place per thing. One source of truth per fact, one channel per function, one owner per decision. A copy is a future contradiction.

• No speculative generality. No tool, process, abstraction, or capacity for something that does not exist today. A future need cannot be named today, so it automatically fails rule 2.

• Success means the next change is fast. Not that the thing is impressive. The measure of any system, document, or process is how cheaply it can be changed tomorrow.

The framework is uncomfortable to apply, and the discomfort is the point.

Rule 1 removes the most common argument in business: that something is working fine. Working fine is not a named need. Plenty of things work fine and cost more to maintain than they return.

Rule 2 is the one doing the actual work. Rule 1 is unenforceable without it, because "we need it" will be asserted for everything. A need is not a category, a preference, or a sunk cost. It is a specific thing that breaks on Monday if the item is gone, and someone has to say out loud what it is.

Rule 3 is the one most organizations violate hardest. The same number lives in a dashboard, a board deck, and somebody's spreadsheet. Nobody removed the other two, so every meeting opens with an argument over which copy is true.

Rule 4 is the one that saves the most money. Flexible platforms, optional modules, and configurable frameworks are almost always built for a need nobody has yet stated. That need cannot be named today, which means it fails rule 2 before any work begins.

Rule 5 changes what counts as a win. Impressive systems are usually expensive to change, and expensive to change is the definition of fragile. A plain system that can be reworked in an afternoon beats an elegant one that takes a quarter.

Adding is easy to defend, fund, and present. Removing is none of those things, which is exactly why it compounds.

The test of an operation is not what it can build. Most can build. The test is what it is willing to remove.