Conway's law as a design tool

Conway's law gets quoted as an observation.

It's far more useful as an instrument.

The observation: organisations produce systems that mirror their own communication structure.

Melvin Conway wrote that in 1967 and it has survived every technology shift since, because it was never really about software.

A boundary between two groups of people who don't talk much becomes a boundary in whatever they build. And the interface between them ends up as clean, or as ugly, as their working relationship.

The instrument.

If that's going to happen anyway, pick the org that produces the architecture you want.

Usually called the inverse Conway manoeuvre. Clumsy name for a genuinely powerful move.

Reading the architecture backwards

Start with the diagnostic.

It's free, and it tells you things nobody will say to your face.

Take your current architecture. Work out which org chart would have produced it.

Not the current one.

The one that existed when each piece was built.

You'll find fossils.

A service doing two unrelated things, because in 2022 both were owned by one person.

A weirdly specific API between two systems, which exists because those teams' leads didn't get on and the interface was a negotiated settlement.

Three different ways of doing the same job, one per team, left over from a period when there was no shared platform.

None of it is visible from the code alone, and all of it explains why certain changes are expensive today.

When a small feature requires touching four services, the reason is usually that the domain boundary and the team boundary disagree. And the disagreement is historical.

The useful output is a short list.

The places where your current architecture reflects a company you no longer are. Those are the seams worth revisiting, and they're a far better input to structural change than anybody's opinion about which team is difficult.

Drawing it forward

The forward version is two steps, and the order matters.

First, decide what you want to be able to change independently.

That's the real design question, and it's about rate of change rather than about technology. Which parts need to move weekly. Which move quarterly. Which are effectively frozen.

Things that change at different rates, for different reasons, want to be different things.

Then draw team boundaries on those lines.

So the teams that need to move fast can do it without asking anybody.

Do it the other way round, deciding the teams and then hoping for the architecture, and you get the default outcome: the architecture follows the teams.

It's going to follow them anyway. The only question is whether you picked the teams with that in mind.

The practical test for a proposed structure.

For each team, name the last three pieces of work they'd have done, and count how many other teams they'd have needed.

Regularly more than one?

Then the structure produces exactly what you have now, with new names on it.

Interfaces between teams are interfaces between systems

The corollary people underuse.

You can't have a clean API between two teams who need a meeting to change anything. And you can't have a messy one between two teams who never talk.

Which means interface design and working relationship are the same problem.

Want a stable contract between two systems?

Put the teams at arm's length on purpose. A versioned API. A written contract. No shared database, and no informal channel where changes get agreed and then implemented afterwards.

Distance produces formality. Formality is what makes an interface stable.

If two teams need to iterate together constantly, stop pretending there's an interface.

Merge them.

Or accept that the boundary is a fiction, and stop paying for its ceremony.

The failure mode is the middle.

Two teams with a shared database and a strong personal relationship, shipping changes that depend on each other, with an interface that exists on a diagram and nowhere else.

It works beautifully right up until one of the two leads leaves. Then it fails all at once, in a way that surprises everybody.

When to accept the mismatch

Not every mismatch is worth fixing.

A leader who has just discovered this framing will want to fix all of them.

Accept it when the system is stable.

A component changing twice a year can be owned awkwardly by a team whose main focus is elsewhere. Coordination cost: two conversations annually.

Restructuring around it costs a quarter.

Accept it when the mismatch sits in something you intend to delete.

Reorganising people around a system with eighteen months left is an expensive way to make a legacy system feel loved, and everybody involved knows it.

Accept it, at least for now, when the alternative structure breaks something more important.

Boundaries have to satisfy several constraints at once.

Architecture, yes. But also who can mentor whom. Where the domain knowledge actually sits. Which people will quit if you separate them.

Conway's law is a strong input. Not the only one.

Treat it as a total theory of org design and you produce structures that are elegant on a diagram and miserable to work inside.

The version to refuse: keeping a mismatch because moving it would be politically awkward for one specific person.

That's the one still sitting there in two years. Usually the most expensive on the list.

Where it shows up at each size

Below twenty engineers, Conway's law is barely operative, because everyone talks to everyone and the communication graph is complete. The architecture reflects individual preferences instead, which is its own problem.

Between twenty and sixty, it turns on hard. Team boundaries become real, the informal channels stop reaching everybody, and whatever structure exists at this point gets encoded in systems that will outlive it by years. This is the highest-leverage window for deliberate design and most companies spend it reacting.

Past a hundred, you're mostly living with decisions made in the previous phase, and the manoeuvre becomes slower and more expensive but not less useful. At that size the more valuable move is often the smaller one: not a reorg, but a deliberate decision about which team owns a specific seam, made with the architecture in mind rather than the headcount.