Part I — Discovering Organizational Flow · Chapter 4 · 3 min read · First Public Draft

Living systems

We Stopped Building Machines

We learned to treat systems as living things, one deployment at a time, and went on treating the organizations around them as machinery.

Anyone who built software in 2001 will recognize the vocabulary.

Change requests. Change boards. Release windows. A maintenance budget kept carefully separate from a development budget, because one of them was for building the thing and the other was for keeping a finished thing running. A specification signed off before anyone wrote a line, on the reasonable theory that you would want to know what you were getting.

None of that was stupid. It was a coherent way of working, and it followed from one belief that everybody held and nobody examined: that a system is a thing you build, finish, and then look after.

That vocabulary is nearly gone now, and it went quietly. Nobody held a meeting to retire it. There was no memo announcing that the change board was over. The work simply stopped matching the words, and the words fell away — first in a few teams, then in most, until a graduate could join and never hear the phrase “release window” at all.

What replaced it took about fifteen years and arrived without ceremony. Continuous delivery. Teams that own a thing rather than hand it over. The quiet disappearance of “done” as a meaningful state. We stopped talking about finished systems because we stopped having any.

I lived through that shift from inside it, and the interesting part is how little of it felt like a decision. Almost nobody set out to adopt a philosophy. People just kept running into the same wall — the specification was wrong by the time it was signed, the handover lost something expensive, the finished system needed changing in month two — and worked around it, one deployment at a time, until the workarounds became the way things were done.

We learned, in other words, to treat our systems as living things. By instinct. Without ever writing down what a living thing actually is.

And then we carried on treating the organizations around them exactly as before.

The same people who would laugh at a two-year specification for a system will approve a two-year transformation programme with a completion date. The same organization that abandoned the change board still routes decisions to a monthly forum.

You can hold both beliefs for years without noticing, because they never meet in the same conversation. One is how you build. The other is how you are managed.

They do meet in the friction between them, constantly. A team that can deploy in an hour, waiting three weeks for a decision. A capability that evolves continuously, funded in annual chunks against a fixed scope.

If one thing is designed for continuous evolution and the other for completion, that mismatch is not an unfortunate side effect. It is where the friction comes from.

Which is the good news, oddly. We have already done this once, on the harder half, without a programme or a mandate — a lot of people working around the same wall until the workarounds became the way things were done. There is no reason the other half should be beyond us.