Simple and complex are not two categories. They are two words covering four distinct operations: simplification, reduction, manufactured complexity, and natural complexity. Two of the four are counterfeits sold as virtues, and two are real conditions that most organisations refuse to name. The cost of the confusion is not intellectual. It is paid in capabilities that vanish quietly and in invoices that buy volume instead of judgment.
Two words carry four different operations
The vocabulary is the failure point. When an executive says “simplify this”, four different things can come back, and the language offers no way to tell them apart before the money is spent.
Simplification removes what is in the way and keeps what mattered. Reduction removes until the thing stops doing its job, and borrows the word simplification to describe the damage. Manufactured complexity adds weight that no requirement asked for, because weight reads as rigour and rigour justifies a price. Natural complexity is the part that was already hard before anyone touched it, and stays hard after every tool has been bought.
Four operations. Two words. Every organisation I have looked at owns a rich vocabulary for cost and almost none for this.
Reduction destroys substance and calls itself simplification
Reduction is always presented from the side of what remains. That is its signature and it is reliable.
A vendor demonstrates a workflow that used to take fifteen steps and now takes three. The three steps are real. What left the building is not discussed, because the person demonstrating does not know your business well enough to know what left. The export your accountant relied on, the record of who changed what, the ability to correct an entry after a close: none of those appear in a demonstration, because a demonstration shows capability, never absence.
The interesting part is that reduction is rarely dishonest. Nobody in the room lies. The failure is structural: no one at the table holds the mandate to name what disappears. Sales does not, because it sells what exists. The operational team does not, because it was not invited. The executive does not, because from that seat the missing capability has no visible shape.
John Gall, writing in 1975 in General Systemantics and again in the 1977 edition, made the observation that systems tend to fail in ways their designers did not anticipate, and that a system’s behaviour cannot be deduced from its specification. Reduction is that failure with a marketing layer on top. The specification says fewer steps. The behaviour says a capability is gone and someone will discover it on a bad day.
Manufactured complexity is a pricing strategy, not an engineering outcome
Manufactured complexity grows when you ask for a price and never when you ask for a result. That asymmetry is the whole tell.
A framing exercise runs six weeks before the first decision that changes anything. Three governance bodies exist where one would do. Forty slides carry six slides of content. None of this is incompetence, and reading it as incompetence is the mistake that keeps executives from acting on it. The volume is the product. The heaviness is what makes the invoice defensible, both to the buyer and to the buyer’s board.
The internal version is quieter and more durable. A team over-designs: three layers of abstraction for a requirement that has one shape, an architecture split into fourteen services for a product with three hundred users. Reading this as laziness is also wrong. It is insurance. Work that nobody else can understand cannot be handed to anybody else, which means the person holding it cannot be moved, questioned cheaply, or replaced. Manufactured complexity is a career strategy long before it is an architecture.
Larry Tesler’s law of conservation of complexity, formulated around 1984, says that the irreducible complexity of an application cannot be deleted, only moved between the user, the application developer, and the platform developer. Manufactured complexity is the inverse operation and it deserves its own name: complexity that was not there, created and then relocated onto the buyer, who now pays to carry it.
Natural complexity is irreducible and only yields to atomisation
Natural complexity does not respond to slogans, tools, or reorganisations, and pretending otherwise is more expensive than admitting it.
Thirty years of pricing rules, seven of which come from contracts nobody can reopen. Three enterprise systems that arrived with three acquisitions. A regulatory constraint that moves twice a year. None of that is a defect. It is the shape of the business, written down in software. Frederick Brooks named this in 1986 in No Silver Bullet, separating the difficulties inherent to the problem from the difficulties introduced by our tools, and arguing that the second category had already been largely harvested. Forty years later the accidental layer has been harvested several times over, and the essential layer is exactly where it was.
The only honest treatment is decomposition. Herbert Simon described in 1962, in The Architecture of Complexity, why this works: complex systems that survive tend to be near-decomposable, meaning interactions inside a subsystem are much stronger than interactions between subsystems. That property is what makes a hard system understandable at all. It is also what makes a hard problem tractable: break it into unit problems, each with an owner, a definition of done, and a date, and you get twelve small things you can stop individually instead of one large thing you can only abandon.
This is the test that separates real complexity from the manufactured kind, and it requires no technical skill to run. Ask for the decomposition. Real complexity accepts being cut into pieces, and some of those pieces will be ugly, and two or three will have no clean solution. Manufactured complexity resists, because it needs to stay whole to stay impressive. The refusal is the information.
Simplification is the rarest of the four because it requires knowing what things are for
Simplification costs more upfront than reduction and looks worse in a meeting, which is why it is the least practised of the four operations.
The removal is trivial. Knowing what can be removed is not. Most of what looks useless is used: by one person, once a quarter, for something nobody wrote down. Documentation does not help, because documentation describes intent and the question is about usage. The only reliable method is observation: who opens this, at what point in the month, and what do they do with the output.
An honest simplification produces a sentence its author is willing to sign before acting: here is what you lose, here is who it hurts, here is why we are doing it anyway. Reduction sold as simplification never writes that sentence. It does not need to lie. It only needs to leave the subject closed.
Case: the capability that had no name
What follows is a composite. The details are changed and no single organisation is being described. The mechanism is untouched, because the mechanism is the point, and I have watched it run more than once.
A distribution business, around a hundred and eighty people, four sites, roughly forty years old. Eleven tools in the operational stack, several of them older than half the staff. A consolidation programme is launched with a slogan that nobody could reasonably argue with: one system, one version of the truth. The business case is sound. The eleven tools genuinely cost more than they should, the reconciliation work between them genuinely consumed people, and the executive committee genuinely wanted the simplification. Every intention in this story is good. That is what makes it useful.
The old order-management system had grown a path over roughly fourteen years, added one patch at a time, that handled a specific situation: partial delivery with substitution and repricing. When a reference was short, the system would propose an equivalent from a different range, reprice the line according to a matrix of customer-specific rules, split the order, and keep the commitment date on the part that could ship. It was ugly. It had been built by three different people, none of whom were still there. It touched perhaps six per cent of order lines.
Those six per cent carried a disproportionate share of the margin, for a reason that never appeared in any document: they were how the business kept its largest customers supplied during shortages, which was how it kept those customers at all. Sales knew this in the way people know weather. Nobody had written it down, and more importantly, nobody had a name for it. No catalogue listed it as a feature. No process map carried it as a line. It was a behaviour of a system, understood by usage.
The requirements workshops for the new platform ran for nine weeks and were well conducted. Every documented process was mapped. Every named feature was assessed, scored, and either retained or dropped with a rationale. The substitution path was never assessed, because it was never named. It appeared in the workshop notes once, as “handles some special cases”, and moved to a backlog category that nobody revisited. The new platform handled partial delivery, which sounded close enough to anyone reading the summary. It did not handle substitution with repricing, and the vendor was never asked whether it could, because nobody in the room knew there was a question.
Go-live was declared a success, and by the criterion in the programme charter it was one: eleven tools became one, on schedule, within budget, with training completed. The criterion measured the transition, not the business.
The six per cent became manual within three weeks. First a spreadsheet maintained by one person in customer service, who reconstructed the substitution matrix from memory and from old order confirmations. Then a shared mailbox, because one person could not hold it. Then two people, then a third during quarter ends. Response time on shortage substitution went from same-day, handled by software, to two to four days, handled by humans with incomplete rules. Errors appeared: wrong equivalents proposed, prices applied from the wrong matrix, credit notes issued to fix them.
Fourteen months after go-live, someone finally counted. The manual handling of a capability the new system did not have was consuming more salary than the licence and maintenance cost of the tool it had replaced. That number was uncomfortable but it was not the real loss. The real loss was that the business had stopped being the supplier who solved shortages faster than its competitors, which had been its actual differentiator for two decades, and nobody had decided to stop being that. It had simply not survived a requirements workshop.
The post-mortem, when it happened, blamed the vendor selection, then the workshops, then change management. All three are wrong. The vendor sold what it had. The workshops did exactly what workshops do, which is assess named things. Change management managed the change that was described to it.
The failure was lexical. A capability with no name cannot be defended, because defending it requires someone to say the words out loud in a room where decisions are made, and there were no words. The programme did not make a bad trade-off between simplicity and capability. It never knew a trade-off was on the table, which is the difference between simplification and reduction, and the difference is entirely in whether anyone said what was being given up.
What a competent intervention looks like here is unglamorous. Before a consolidation programme opens its first workshop, someone spends three weeks not in documentation but in usage: which screens are opened, by whom, at what point in the month, and what happens to the output. Anything with no detectable usage across a full business cycle is a candidate for removal. Anything used rarely and by few people is exactly where the value hides, and gets named before it gets assessed. That work is slow, it produces no slide anyone enjoys presenting, and it is the difference between a programme that simplifies and a programme that reduces.
Organisations confuse the four because their vocabulary has only two words
The confusion comes from missing names, not from missing intelligence, and names are cheap to fix.
An executive team can distinguish gross margin from contribution margin without a finance degree, because someone once insisted the two words be used correctly and the distinction was enforced in meetings. No equivalent discipline exists for simplicity. Two counterfeits and two real conditions share two words, and the words are used interchangeably by vendors, by consultants, by internal teams, and by the executives buying from all three.
The consequence is predictable. Reduction gets approved because it is described as simplification and simplification is agreed to be good. Manufactured complexity gets approved because it is described as rigour and rigour is agreed to be responsible. Natural complexity gets refused, because admitting a problem is genuinely hard reads as an excuse, and the person who says it is asked to come back with a simpler plan. Real simplification gets refused too, because it costs three weeks of observation before anyone sees a result.
The two counterfeits are bought. The two real things are declined. That is what a missing vocabulary does.
The cost of the confusion is paid twice
Every organisation that cannot name the four operations pays once for the counterfeit and once again for the repair.
The first payment is visible on the invoice: a tool that dropped a capability, a framing exercise that produced volume, an architecture that needs two full-time people to stay upright. The second payment is invisible on any ledger: the manual workaround that grows a headcount at a time, the differentiator that was never decided away, the internal knowledge that walks out with the person who was holding the spreadsheet.
The second payment is always larger, and it is never attributed to the decision that caused it, because eighteen months have passed and the decision was declared a success at the time.
Naming the four is an executive skill, not a technical one
None of this requires an executive to understand a system. It requires an executive to hold four labels and insist that people use them.
Ask what you can no longer do after the change, and require the answer in writing. Ask for the decomposition, and watch whether it is refused. Ask for the short version, and watch whether the subject survives being short. Ask who uses the thing you are about to remove, and accept that the honest answer takes three weeks to obtain.
Four questions, four labels. The technical work belongs to someone else. The naming belongs to the person who signs, and it cannot be delegated to the party being paid.
Sources
- Frederick P. Brooks Jr., No Silver Bullet: Essence and Accident in Software Engineering, 1986. https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf
- Larry Tesler, Law of Conservation of Complexity, c. 1984. https://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html
- Herbert A. Simon, The Architecture of Complexity, 1962. https://faculty.sites.iastate.edu/tesfatsi/archive/tesfatsi/ArchitectureOfComplexity.HSimon1962.pdf
- John Gall, Systemantics: How Systems Work and Especially How They Fail, 1977 (first edition 1975 as General Systemantics). https://archive.org/details/systemanticshows00gall
- Laws of UX, Tesler’s Law. https://lawsofux.com/teslers-law/
FAQ
What are the four operations hiding behind the words 'simple' and 'complex'?
Simplification (removes what’s in the way, keeps what matters), reduction (removes until the thing stops doing its job, but borrows the word simplification), manufactured complexity (adds weight no requirement asked for, because weight reads as rigour and justifies a price), and natural complexity (the part that was already hard before anyone touched it, and stays hard after every tool has been bought). Two words, four operations — and most organisations only have vocabulary for two of them.
How can you tell natural complexity apart from manufactured complexity?
Ask for the decomposition. Real, natural complexity accepts being cut into pieces — Herbert Simon’s near-decomposability — and some of those pieces will be ugly with no clean solution. Manufactured complexity resists being broken down, because it needs to stay whole to stay impressive. The refusal to decompose is itself the information you need.
