The Costly Confusion
The highway can be built. The accidents require something else.
There is a difference between designing a highway system and designing fewer accidents.
The highway system is designable. You can specify it, model it, hand it to engineers, and what emerges will closely resemble what you drew. You can point to the blueprint and say: that is what we are building. The materials are known, the steps are known, the outcome is knowable. This is a complicated problem — hard, expensive, requiring enormous coordination — but ultimately solvable through planning.
Fewer accidents is something else entirely. Accidents happen at the intersection of driver behavior, road condition, weather, fatigue, enforcement, signage, vehicle design, the particular stress someone was under that morning, and a hundred other variables that are never all in view at the same time. You can change the speed limit. You can redesign an interchange. You can add a guardrail. Each of these influences the system. None of them controls it. The moment you start treating “fewer accidents” like a highway — as if you can blueprint your way to it — you have already misunderstood the problem.
This distinction, between the highway and the accidents, is what Complexity Design is about.
We use the word “complex” to mean difficult or elaborate. In complexity science, it means something more specific: a system whose behavior cannot be predicted or designed from its parts. Traffic is complex. A conversation is complex. A team is complex. A city is complex. These systems have emergent properties — behaviors that arise from the interaction of elements that nobody authored and nobody fully controls.
A car engine is not complex in this sense. It is complicated. So is a computer program, an org chart, a project plan. Complicated things can be difficult to understand, but they yield to analysis. You can take them apart, understand each piece, and predict how they will behave. Complexity resists this. The interesting behavior is precisely what you can’t get to by taking the thing apart.
The confusion between complicated and complex isn’t just a semantic problem. It causes real damage. Organizations hire consultants to solve complex problems with complicated tools — frameworks, matrices, process diagrams — and then wonder why nothing changes. Managers write detailed plans for situations that will require constant improvisation the moment they begin. Designers prototype solutions to problems that are actually ecosystems, and ship things that solve the wrong layer.
One of the axioms I teach is:
Plans are always complicated, execution is always complex.
Think about any project you have been part of. The plan, at the moment it was written, existed in a controlled space. It assumed a stable environment, predictable people, and information that would stay accurate. Then execution began, and the plan met the world. Someone left. A dependency shifted. A stakeholder changed their mind. A user behaved in a way that wasn’t in the brief. This is not a failure of planning. It is the nature of complex systems. The world does not hold still for your blueprint.