Divide et Impera ■ Episode 02
“Give teams autonomy.”
A perfectly reasonable sentence. Nobody could possibly object. Autonomy implies trust. Trust implies competence. Competence implies better software. The logic is elegant, self-reinforcing, and wrong in precisely the way that elegant logic tends to be wrong: by omitting everything that happens after the slide deck.
What happens after the slide deck is four teams, four frameworks, four deployment pipelines, four security postures, and a system architecture that resembles fourteenth-century Europe.
The Map
Here is what “autonomous teams” looks like in practice. Not in the conference talk. In the codebase.
Team A chose React, Scrum, GitHub Actions, and environment variables. Team B chose Vue, Kanban, GitLab CI, and Consul. Team C chose Svelte, bash scripts, and (one does wish this were an exaggeration) secrets committed to git. Team D chose Angular, Jenkins, and a spreadsheet on a shared drive.
Each team made a locally rational decision. Each team selected the tools they knew best, the process they found most comfortable, the deployment strategy they could maintain. Locally, every choice was defensible. Globally, the result is four kingdoms with incompatible infrastructure, no shared tooling, and a security posture that ranges from “adequate” to “career-limiting.”
The system diagram does not resemble a modern software platform. It resembles a map of fourteenth-century Europe: fragmented, contested, and held together primarily by the shared delusion that everyone is on the same side.
The Cross-Team Feature
The real cost of balkanisation does not appear until someone requests a feature that touches more than one kingdom.
Week one: learning the other team’s codebase. Not the language, everyone speaks JavaScript, or at least a dialect of it. The framework. The idioms. The state management pattern. The directory structure. The build tooling. The things nobody documented because “it’s obvious if you work here.”
Week two: understanding the other team’s pipeline. Not how CI/CD works in theory. How this particular CI/CD works. The Groovy script that Team D’s senior wrote in 2019 and nobody has touched since. The GitLab runner that Team B configured with a specific Docker image that only exists on one registry. The bash script that Team C runs manually because “we just ship.”
Week three: negotiating the API contract. Not designing it. Negotiating it. Because Team A expects REST with JSON:API, Team B expects GraphQL, Team C expects “whatever works,” and Team D expects a meeting to discuss the meeting where they will discuss the API.
Week four: discovering that a decision made in 2019, by someone who has since left the company, blocks the integration entirely. Nobody knows why the decision was made. The architecture decision record does not exist, because architecture decision records require the kind of cross-team discipline that “autonomous teams” was specifically designed to eliminate.
The feature ships in month three. The estimate was two weeks.
Conway’s Revenge
In 1967, Melvin Conway observed something that has been politely ignored by management consultants for the better part of six decades: organisations design systems that mirror their own communication structure. Not sometimes. Always. Not as a tendency. As a law.
If four teams do not talk to each other, the system will have four components that do not talk to each other. If the teams use different tools, the system will use different tools. If the teams have different security practices, the system will have different security postures. Conway did not frame this as a risk. He framed it as an inevitability. The architecture is the org chart, whether you planned it that way or not.
“Give teams autonomy” sounds like freedom. What it produces, absent shared technical governance, is fragmentation with a motivational poster.
The Dependency Paradox
The pitch was independence. The result is a new, more intricate web of dependencies.
The “autonomous” teams now depend on a platform team to maintain four different CI/CD pipelines. They depend on a DevOps team to provision four different deployment targets. They depend on an architecture board to adjudicate API disputes. They depend on an integration team to make the four kingdoms speak to one another. They depend on a security team to audit four different approaches to credential management, one of which involves a shared drive.
The monolith had one dependency graph. It was legible, if occasionally ugly. The “autonomous” organisation has a mesh of dependencies so dense that mapping it requires a dedicated consultant and a whiteboard the size of a small country.
We traded one dependency for a hundred. And we called it independence.
The Numbers
The average enterprise runs over 200 microservices. The average developer understands three to four of them. Integration bugs, failures at the boundaries between services, between teams, between kingdoms, account for 40 to 60 per cent of production incidents.
Read those numbers again. A developer understands roughly 1.5 per cent of the system they are ostensibly responsible for. The majority of production failures occur in the 98.5 per cent they do not understand. This is not a knowledge management problem. It is a structural inevitability of fragmentation at scale.
Matthew Skelton and Manuel Pais articulate this rather precisely in Team Topologies: team boundaries must align with architectural boundaries, and both must be designed together. Autonomy without alignment is not empowerment. It is entropy with a headcount.
The Vocabulary Trick, Again
As with Agile before it, the vocabulary is doing most of the heavy lifting. “Autonomy” sounds like trust. In practice, it means “nobody is responsible for the whole.” “Ownership” sounds like accountability. In practice, it means “my service, my rules, your problem when they interact.” “Empowerment” sounds like agency. In practice, it means “we have no platform, no standards, and no shared understanding of what ‘production-ready’ means.”
The words remain. The meaning inverts. One begins to notice a pattern.
What Alignment Looks Like
The alternative is not the abolition of autonomy. It is autonomy within constraints. A shared deployment pipeline. A shared secret management strategy. A shared understanding of what constitutes a production-ready service. Agreed API contracts. Architecture decision records that outlast the individuals who made the decisions.
This is not radical. It is, in fact, how every functioning federation in history has worked: local governance, shared infrastructure, agreed protocols at the boundaries. The cantons are autonomous. The railway gauge is standard.
The question is not whether teams should have autonomy. Of course they should. The question is whether autonomy means “choose your own framework, pipeline, deployment strategy, and security posture” or whether it means “decide how to solve the problem, within a system that allows the solutions to compose.”
One of these produces a platform. The other produces a map of fourteenth-century Europe.
The Punchline
“Give teams autonomy” was never wrong. It was incomplete. Autonomy without alignment is fragmentation. Fragmentation without governance is balkanisation. And balkanisation, as the Balkans themselves could attest, does not tend to end with everyone agreeing on the API contract.
Four teams. Four frameworks. Four pipelines. Four security postures. One company. Zero shared infrastructure.
They called it autonomy. Conway called it inevitable.