Show me your team boundaries and I'll draw your architecture.
Melvin Conway's 1967 observation was that any system's structure mirrors the communication structure of the organisation that built it. Sixty years of software has mostly served to confirm it — and to embarrass every leadership team that tried to mandate an architecture without touching the org chart.
Commit before you look.
A company has four teams: front-end, back-end, DBAs and QA. Leadership mandates a move to microservices, with each service owned end to end by an autonomous team. Eighteen months and a lot of money later, what do they most likely have?
Move the people. Watch the architecture follow.
Twelve engineers, four disciplines, up to four teams. Assign them however you like on the left; the right-hand panel is not something you draw — it is derived, cell by cell, from who owns what. A team that owns one band produces a layer. A team that owns the whole stack produces a service.
Turn this on when the operations team ships a platform other teams use on demand, rather than a queue other teams file tickets into. It is the same box on the org chart and a completely different number of handoffs.
How the model works. A user-visible change needs all four
disciplines. If the team it lands on owns all four, it is a single-team change; otherwise every
missing discipline is a handoff, and each handoff adds a queue — modelled here at 2.5 days.
Coordination links are n(n−1)/2 across non-empty teams. Cognitive load is the average
breadth of stack a team has to hold, which is the real price of the vertical answer.
Read the symptom, name the org.
Conway's Law is most useful backwards: as a diagnostic. Each of these is a complaint you could hear in a real architecture review. For each one, decide what it is actually telling you.
Called: 0 of 4 · Correct: 0
The org chart is a design tool, not a constraint you inherit.
Most people meet Conway's Law as a piece of fatalism — "the architecture will look like the org, so don't bother". The useful reading is the opposite one. If team shape determines system shape, then team shape is a lever, and it is one leadership already knows how to pull.
| Mandate the architecture | Inverse Conway manoeuvre | |
|---|---|---|
| What you change | The diagram, and the technology. | The team boundaries — first. |
| What resists | Every existing communication path. | The reorg itself. Once. Loudly. |
| Typical outcome | Services that still ship together. | Boundaries that fall out almost by themselves. |
| Time to feel it | 18 months, then a post-mortem. | A quarter, in lead time. |
| The honest cost | Sunk migration, unchanged flow. | Cognitive load per team goes up. Really. |
| Test of success | "Are they separate services?" | "Can one team ship a change alone?" |
The test of a boundary is independent deployability
Not the repository layout, not the number of services, not whether it has its own container. If two "independent" services share a database, every schema change is still a four-way conversation and you have one system wearing two shirts — with the operational cost of distribution and the coupling of a monolith. Ask "can this team ship on Tuesday without asking anyone?" and let the answer overrule the diagram.
The honest cost: cognitive load
Vertical teams are not free. A stream-aligned team owns screen to schema to on-call rota, which is a great deal of stack for eight people to hold in their heads, and the failure mode is real — burnout, shallow expertise, six teams each solving deployment slightly differently. That is what a platform team is for: it lowers the load without reintroducing the handoff, but only if it ships a self-service platform rather than a ticket queue. Toggle "Ops is self-service" in the mirror above and watch that one distinction move the lead time.
Why this is the last step of the delivery path
A layer-siloed org cannot produce a thin vertical slice, because no single team owns a journey end to end. It cannot really do short-lived branches either, because work waits in another team's queue whatever your branching policy says. Every technique in this path is downstream of this one — which is why teams that adopt the practices without changing the shape conclude, reasonably enough, that the practices do not work.
The law, doing its work quietly.
Nobody in any of these stories decided to build the system they ended up with. They decided who reported to whom.
The four-team copy change
Changing one label on one screen needs a front-end ticket, an API ticket to expose the new field, a DBA ticket for the column, and a QA pass — each waiting its turn in a different team's sprint. Elapsed time: six weeks. Actual work: about forty minutes.
Reorganise, then migrate
A payments group reorganises into product-aligned squads — each owning a customer journey end to end — before starting the microservices work. The service boundaries then fall out of the team boundaries almost without argument, because the expensive conversations about who owns what already happened, in the org design.
The shared database
Two teams own two "independent" services that write to the same tables. They still coordinate every migration, still deploy in a fixed order, and still break each other. They have paid the full operational price of distribution and received none of the autonomy.
The compiler team's compiler
Conway's original example, and still the cleanest: four groups assigned to build a compiler produced a four-pass compiler. Not because four passes was right, but because four groups was the shape available. The same reflex names your services after your teams today.
Architecture is a shadow of the org chart.
Which means the highest-leverage architecture decision most leaders make is one they do not think of as an architecture decision at all: who sits with whom, who owns what, and who has to ask permission. Redrawing those lines is slow, political and unglamorous, and it moves things no technology choice can — which is exactly the kind of work we do alongside leadership teams.
Talk to us about coachingYou cannot mandate around the org chart
An architecture that contradicts the communication structure loses. Layer-shaped teams ship layer-shaped software, whatever the target diagram says.
Run the law in reverse
If team shape determines system shape, team shape is the lever. Design the teams for the architecture you want, and let the boundaries follow.
Count handoffs, not services
Handoffs per user-visible change is the honest measure of a boundary. A platform removes them; a ticket queue with a nicer name does not.