Adding a control element to any system may seem like an easy path, even a necessary one. Redundancy reassures the stakeholders and the auditors, and it might become a sales pitch for the customers. Removing such elements is, on the other hand, more challenging; it’s an effort that requires accountability and traceability. It’s a signed decision, and your name is on it. A recent example of that second path arrives from an unlikely direction.

The engine that got emptier

Side-by-side photographs of the successive versions of SpaceX’s Raptor engine were met with astonishment when first published a few years ago. It was immediately evident that the same engine reached a more streamlined, distilled form. Many of the previously visible elements had vanished. Pipelines gone, plumbing and sensors moved, protective shrouds eliminated or integrated into the body of the engine itself. Three pictures, and what people saw was absence.

Credit: SpaceX

This result is precisely what happens when clever people iterate quickly and efficiently. This is true enough, but it skips something: The achievement per se was not addition but, rather, subtraction. And subtraction is the harder of the two.

The removal of a part or a subsystem requires that its function is thoroughly known and understood. It means knowing what the old part was doing all along: every condition it covered, every failure mode, every interaction and allocation. You can’t safely delete what you don’t fully understand. Which leads to an interesting diagnostic point: A system that has become simpler over time is usually a system that is now better understood.

On the other side of this spectrum, could a system that has only ever accumulated parts, functions, and lines of code be a system that nobody took the effort and accountability to understand well enough to prune? It’s not a rhetorical question.

Scar tissue

When something goes wrong, the body builds scar tissue to patch things up. It’s an efficient response, but the applied substance is denser and less elastic than what was there before. Also, it doesn’t revert. When scar tissue gets excessively accumulated, for example, a joint eventually stops moving properly—not through any single damage, but through the sum of successful repairs.

Organizations may similarly stiffen and, in their case, the scarring is documented. Pick an old procedure or operative instruction, one that has been in place for many years, and read it end to end, applying an analytical approach. Verifications that duplicate themselves from one page to the other, a tolerance check introduced after an accident seven years ago, a sign-off whose only function today is to record and justify its own existence. They all live here, and none of them is anyone’s fault; they’re merely the output of a mechanism that more often than we would like to admit runs in one direction only. It adds elements. The approach is also very common: Something goes wrong, analyses and investigations are performed, a corrective action is agreed upon and formalized. That very corrective action is most likely an addition: a new check, a new indicator, a new form to be filled, a new approval workflow, and new lines in the procedure.

The system has now grown by another one.

Over time, these practices will produce documents that can contradict themselves. They could generate procedures so intricate that they simply can’t be run in the time allotted, causing a growing gap between the process as written and the process as performed. Everyone on the floor knows about these discrepancies and begins adjusting their work accordingly, building hidden factories that are difficult to dismantle once they have set in. The mechanism is familiar enough, but what gets examined less often is why it only ever shapes in one direction.

Addition is anonymous; subtraction is signed

Perhaps this accumulation isn’t a documentation problem but a question of who carries the risk. The logic is simple and can easily sprout in the minds of middle and top managers: Add a control that turns out to be unnecessary, and nothing happens to you. No incident, no audit, no analysis. It’s the organization that pays an invisible cost. Piling up control elements has a cost—real, tangible—in the form of working hours, attention, effects on lead time and lean operations, and, ultimately, erosion of the document’s own credibility. This cost is diffuse, delayed, spread over large functional parts of the organization and, frankly, hardly ever attributable to anyone. It’s quite unusual, aside from heavily regulated or very advanced industries, for anybody to be disciplined for adding a check.

Remove a control, and the payoff inverts completely. If nothing happens, no credit is given. If something bad does happen, though, the removal is in the change log with your name right against it. Nothing happening is the status quo, while a mishap requires someone to be held accountable, to be looked at. William Samuelson and Richard Zeckhauser in their article “Status Quo Bias in Decision-Making” described this type of bias in 1988 when they showed that people have a disproportionate tendency to prefer to leave things as they are when facing a decision—weighting the existing condition more than its actual effects would justify.

Adding freely and never removing may be seen as a rational, human response. Is it self-preservation? Stress-coping adjustments? It’s probably neither. What if it were a correct calculation about an asymmetric risk made by people who have come to understand their organization well enough to see the risk of being called accountable for risks they can’t really control as unacceptable?

Again, all this has a cost. Control an0d alerting systems have a degradation factor, and if every incident adds a threshold, a flag, or an alarm, after a certain density is reached the operators stop noticing them—because paying proper attention to them is simply incompatible with the actual performing of the work. In scenarios like this, the alerting system has become a source of risk of its own rather than a way to control it. The irony is that all this grew, step by step, out of safety improvements.

You can build a dangerous system on nothing but very reasonable responses to real events.

Two types of subtraction

Saying that organizations never remove anything was a poetic stretch that served the argument. In fact, they do remove something every now and then. But what if they do it the wrong way, for the wrong reasons, and from the wrong direction?

Subtraction may be driven by knowledge, starting from a deep understanding of the system at hand. Decisions are made considering the system as a whole, tracing subsystems and components back to their function. Demonstrating that a control element now guards against a condition that no longer exists or that’s now covered by another safeguard requires full ownership and responsibility. This is precisely what happened to the Raptor engine.

Another form of subtraction is driven by cost, and it starts from a specific target: a value, a percentage that must be chopped off. You remove steps or parts because they are expensive—when their critical value isn’t fully understood by certain areas of management, or the knowledge behind the purpose of those elements isn’t consulted. In smaller organizations, it may all very well reduce to a matter of opinion by a powerful stakeholder.

Here’s the difficulty: Both types of subtraction, from the operator’s perspective, look identical. They both arrive packed and wrapped as an updated instruction or procedure. The operator’s viewpoint may sometimes be narrower in scope and extent than that of the decision makers. An operator has no way to discern between subtraction by cost or by knowledge but, in their mind, every subtraction inherits the credibility of every cost-reduction, budget-optimization approach that came before it, regardless of whether such reputation is deserved.

The test

We could synthesize the whole problem into a single, Swiss-army-knife question for addressing improvement by subtraction: Can the person removing this system, part, control, or step clearly describe what that element was doing and the rationale behind its existence? Can this person state why this element is no longer needed?

It’s not “Can the savings be justified?” or, “Has this element ever caught anything?” It’s more about the failure it was designed to prevent, and the traceability to where and upon what that failure is now addressed.

If the answer to our test question is yes, then we may be dealing with real systems and organizational knowledge. If the answer is a cost figure, for example, or the unsupported strategic desire of a manager, then it’s erosion scraping the very essence of continuous improvement. No Raptor engine was ever built on that kind of discipline.

The challenge of this question, or drawback as some may see it, is that it can’t be automated or simply passed by a program that doesn’t understand the process or system in question deeply. It can’t be delegated to consultants or reviewers. Only someone who has done the work, who has contributed to the design and analysis, or has walked the shop floor and asked the people who do about it, can answer it.

What we can’t remove

This is the paradox we face: Systems that only add become bloated, fragile, and eventually unusable—yet those who build them are never blamed for the accumulation. True continuous improvement demands not just the wisdom to know what to add, but the courage to remove. It requires leaders who accept ownership of both gains and losses, who trust their teams enough to prune the deadwood without fearing blame when something is missing. Until we build cultures where subtraction is celebrated as skillfully as addition, our quality systems will continue to grow—not because they must, but because it’s safer to do nothing at all.

There’s a subtle signal in forms that multiply. We build systems on the principle of more and call it safety. We’ve forgotten that subtraction is also a form of knowing. It could be how our brain works: In 2021, Gabrielle Adams and colleagues proposed a paper in which, through a series of experiments involving LEGO structures and symmetry tasks, they describe how people tend to default overwhelmingly to adding components when removing would have worked as well or even better. It’s cognitive accessibility—additive ideas arriving quickly and cheaply while subtractive ones require more effort to generate at all.

The risk in plain sight: systems growing around us like structures we didn’t build but must inhabit, walking through rooms filled with alarms no one listens to anymore.