The Tao of Platform Architecture

When the platform loses its Tao, teams rely on goodness. When goodness fails, they rely on governance

Nov 11, 2025

(Continues on from the short story “The Protocol River”)

A Tale of Two Architectures: Shared or Enforced

A platform team introduces a shared build system. They don’t mandate its use. They just make it fast, simple, and observable. Within months, nearly every team adopts it. The few that don’t soon realise they’re the ones breaking pipelines and missing releases. No decree was issued. The Tao was written in the feedback loops.

An organisation mandates a central CI/CD tool. Adoption is enforced by policy. Developers grumble, automate around it, or clone its internals for side projects. Productivity drops, resentment rises, and compliance dashboards glow green while creativity goes dark. The Tao is gone; only law remains.

There’s a passage from Lao Tzu that drifts back to me every time I see a platform team in trouble:

“Losing the way of life, men rely on goodness.
Losing goodness, they rely on laws.”

It’s one of those lines that lingers. It describes every failed technology platform I’ve ever known.

When the Tao — the way that works — is lost, people reach for moral exhortation.

“We just need a better culture.” “If everyone did the right thing, this would run smoothly.”

But goodness without alignment is just effort against friction. When that fails, the laws arrive: governance boards, policy templates, ticket queues. Suddenly, a thing that was meant to accelerate creation becomes a gatekeeping bureaucracy. The Tao has evaporated, and what’s left are rules to simulate it.

Tim O’Reilly once connected this wisdom to the history of open source. He noticed that the early Free Software Foundation started from a moral argument: source code must be free. They encoded this morality in the GNU Public License, a kind of software scripture. Meanwhile, the BSD and X Window projects relied more on trust and recognition — “goodness,” in Lao Tzu’s phrase. But what truly made open source thrive was neither law nor goodness. It was architecture.

Unix, the Web, and the Internet itself all embodied what O’Reilly called an architecture of participation — small pieces, loosely joined, bound by clear communication protocols. Anyone could contribute something new as long as they respected the interfaces. The architecture itself invited cooperation. It created a market of possibility, not a maze of permissions.

That’s the Tao in platform engineering.

When your platform’s architecture naturally leads teams toward healthy, self-reinforcing behaviour, you don’t need slogans about culture or commandments about compliance. The system itself teaches the right behaviour through feedback and flow.

Bad platforms, like bad societies, mistake control for alignment. They rely on process documents, approval gates, and top-down enforcement because the underlying architecture doesn’t produce coherence on its own. The monolith masquerades as order, but what it really breeds is dependence — every change becomes an act of negotiation.

A good platform, by contrast, behaves like a protocol. It makes participation effortless and deviation costly. It encodes the right patterns into the grain of the wood, so that anyone working with it naturally carves along the grain, not against it.

The Tao of platform engineering, then, is this:

Don’t enforce what you can encode. Don’t encode what you can embody.

Build a system whose structure makes the desired outcome the path of least resistance. Let the Tao flow through the interfaces. Let feedback teach more than policy ever could.

When you find that your teams have started relying on moral pleas — “we just need more understanding,” “please just listen” — the Tao is already slipping away. When you find yourself adding gates and forms and audits to restore order, it’s gone.

The work of the platform engineer is to surface that Tao — to find the architecture that makes participation inevitable, cooperation natural, and governance almost invisible.

A platform without the Tao must be ruled. A platform with the Tao rules itself

There are, broadly speaking, two kinds of platforms: those that flow and those that explain.

The former hum quietly, self-regulating like good plumbing — water finds its level, errors correct themselves, and nobody quite remembers who designed it. The latter are endlessly described in internal wikis, their workings illuminated by org charts, governance frameworks, and motivational posters about “synergy.” In these, nothing flows; everything is justified.

History suggests that civilisations, like software, rarely collapse because of their lack of ambition. They collapse because someone — well-meaning, soberly dressed, and armed with a whiteboard — decides that flow requires management. The Tao slips quietly out the back while the committees convene. By the time anyone notices, the platform has become self-aware only of its own paperwork.

Some Practices to Consider

Design architectures that reward good behaviour naturally.
Prefer communication protocols to governance processes.
Let feedback loops replace enforcement loops.
Build APIs that invite participation, not petitions.
Treat developer experience as moral architecture.

Some things to avoid

Substituting culture campaigns for structural change.
Mistaking compliance for coherence.
Over-governing due to architectural misalignment.
Treating golden paths as mandates instead of invitations.

A platform is not a temple to be guarded. It is a riverbed — shaped just enough to let the current flow where it must. When the water runs smoothly, goodness arises by itself, laws become unnecessary, and teams rediscover what O’Reilly called the architecture of participation.

The Tao is not written in documentation or policy. It’s encoded in the shape of your system and revealed only when you stop forcing it to behave.

A Software Enchiridion

Discussion about this post

Ready for more?