Method note
Delete, separate, or structure
The standard advice on complexity is to delete it. That is right more often than people admit — and it is one of three moves, not the only one.
Simplification programmes almost always reduce to a single instrument: find what is not earning its place, and remove it. In a business selling to consumers that is close to sufficient, because a part has no value except through the product it sits in. Nothing in the bill of materials is attached to a relationship.
Industrial businesses are not built that way. You have a few hundred named accounts, and a low-margin product is very often the reason a high-margin account calls you first. Delete it on its own numbers and the loss shows up two lines away, in a P&L nobody connects back to the decision. The product looked like the problem. It was holding something up.
Coupling is what the single-instrument approach cannot see, and in industrial business-to-business it is most of what makes complexity hard to remove.
GT Solar
I ran an eighty-twenty across the product range — the ITW method, a customer and product matrix rather than a ranked list of product margins. The A products serving A customers were obvious. So was the tail that served nobody. The quadrant that mattered was the B products attached to A customers.
I moved the twenty into a different building.
They kept shipping. The main line got clean flow and a footprint sized to the eighty. Nothing was dropped that a customer we cared about depended on. That is not a softer version of deleting — it produces the same information without the destructive test.
The rule
- Uncoupled and unprofitable — delete it.
- Unprofitable but attached to a profitable relationship — separate it, re-cost it, set a date to look again.
- Genuinely load-bearing — build the structure that carries it.
Most simplification programmes fail because they only own the first move.
The honest limits
Delete is right more often than people expect — a line nobody has ordered in two years, an approval step whose approver has never once said no. If it is uncoupled, delete it and do not hold a workshop about it. Separating is not a way of avoiding the argument. It is what you do when the argument has two right answers.
And separation fails two ways. It duplicates overhead, so it only pays when the flow improvement on the core exceeds the cost of the second site. And without a review date it becomes permanent tolerance — you have not simplified anything, you have moved the mess somewhere it stopped being visible and are paying rent on it.
Why the high-volume playbook does not transfer
Deleting to see what breaks is an empirical search: you find out what was load-bearing by breaking it. That is a cheap experiment at thousands of units a week and an expensive one at a dozen machines a year against contracts carrying liquidated damages. And questioning a requirement assumes the requirement belongs to someone in your building — a great many of mine are named CE marking, UL, ISO 17025, or an EPC’s bid documents. You can question those. You cannot delete them.
Boeing built the 787 to specification without a controlled interface definition, and the overrun ran to billions. On the 737 MAX an interface parameter was changed and the consequences were managed in software rather than requalified. People died. Both are steps that looked deletable and were load-bearing. Deleting is not the error. Skipping the test against the interface is.
What you build around what survives
Whatever is left after the sort still has to be carried, and that is the part I do. A skeleton rather than scaffolding — internal, load-bearing, and administrable by managers with normal amounts of authority. A named decision, a named approver, a threshold, and a date to look again.
A method that only works while one person with absolute authority is in the room is not a method. It is a personality.
Right Tack Operational Consulting 