Conway's Law as a Tool

Overview

The previous topic observed that structure prices designs. Conway’s Law is the mechanism, and it converts an observation into something predictive.

Stated once, from Conway’s 1968 paper: organisations produce designs whose structure mirrors their communication structure. Not their org chart — their communication structure, which is usually similar and occasionally very different.

Why it holds

Not mysticism. A module boundary is a coordination boundary, and coordination has a price that varies by distance.

Two engineers on the same team settle an interface in a conversation at a desk. Two engineers in different departments settle it in a document, a meeting, a follow-up, and sometimes a quarter. The second interface will be coarser, more conservative, and more stable — because changing it is expensive.

So interfaces ossify where conversations are expensive, and stay fluid where conversations are cheap. Over time the system’s seams migrate to wherever the organisation’s seams already are. Nobody decides this; it is the accumulated result of every small choice to take the path of least coordination.

graph TD
  A["Team boundary"] --> B["Expensive<br/>conversation"]
  B --> C["Coarse, stable<br/>interface"]
  C --> D["A seam in<br/>the architecture"]
  E["Same team"] --> F["Cheap<br/>conversation"]
  F --> G["Fluid, fine-grained<br/>coupling"]
  G --> H["No seam —<br/>things merge"]

  classDef org fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef conv fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef arch fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class A,E org
  class B,F conv
  class C,D,G,H arch

The mechanism in both directions. Seams appear where conversations are costly; components merge where they are free. The architecture is a fossil record of the communication structure.

Three uses, in descending order of availability

As a prediction. Given the communication structure, you can forecast the architecture that will emerge regardless of what the design document says. This is the use that is always available and most undervalued. It tells you which of your intended boundaries will hold and which will erode.

As a diagnosis. An architecture that does not match the organisation is in one of two states: new, and about to drift; or maintained against pressure at a cost somebody is paying. Find who is paying — it is usually one conscientious person doing unrewarded coordination, and when they leave, the boundary goes.

As a lever — the Inverse Conway Maneuver. Change the team structure to get the architecture you want. It genuinely works, and you almost certainly cannot do it. Reorganising teams is an executive act, and Module 1 drew the line that this guide teaches you to influence the organisation rather than own it.

What is actually available to you

Being honest about the third use matters, because advice you cannot act on is worse than none. With no authority over team composition, three moves remain:

Propose boundaries that match existing team boundaries. Your design’s seams will survive if they sit where the organisation’s seams already are. This is the single highest-value application of the law for someone without a mandate.

Name the mismatch and its coordination cost. When a design needs a boundary the organisation lacks, say so in those terms: this requires one team to own both sides, and without that it will drift back together within a year. That is a prediction, which makes it checkable, which makes it credible.

Be ready for the window. Reorganisations are when the maneuver becomes available, and they are announced with little notice and executed quickly. An architect who already has a view on what team boundaries would serve the architecture gets asked. One who needs a month to form a view does not. Keep that view written down and current — it costs an hour a quarter and it is the cheapest option value in this module.

Team Topologies — Matthew Skelton and Manuel Pais’s book of that name — is worth naming here as vocabulary: team types (stream-aligned, platform, enabling, complicated-subsystem) and defined interaction modes. Its value for you is less the taxonomy than having shared language for the conversation above — proposing a boundary is easier when both parties have a word for the kind of team you mean.

The limit of the law

Two honest caveats.

It is a tendency, not a mechanism with a timescale. A boundary can hold for years against organisational pressure if someone is maintaining it deliberately.

And it describes communication structure, which is not always the chart. Two teams who talk constantly behave as one team for Conway purposes, whatever the reporting lines say. Which is why the detection work in topic five — who actually talks to whom, who gets consulted — is the input to this analysis rather than a separate concern.

Predicting the drift

Two years of strangler migration has produced about twenty Go services. Conway’s Law predicts their boundaries follow whichever teams extracted them rather than the domain’s natural seams — and nobody should expect those to coincide.

That is a prediction you can check in week one, and it is a good opening question for Ivan Petrov: why is this service shaped like this? If the answer is “because that team took that slice”, the estate’s boundaries are organisational fossils, and any future consolidation argument has to account for them.

The prediction that matters for the current design. Module 3 chose two services — a retrieval path and an action path — because their non-functional requirements differ sharply. Conway’s Law says: if one team owns both, they will merge. Not through a decision, but through a hundred small conveniences, each individually reasonable, over about a year.

So the Module 3 decision has an organisational precondition nobody wrote down. Either the two paths get two owners, or the boundary needs a deliberate guardian — a named person whose job includes noticing the erosion, plus a recorded decision explaining why the seam exists so a future engineer finds a reason rather than an inconvenience. That is Module 9’s ADR practice earning its place for an organisational reason rather than a documentation one.

And the honest limit. With 140 engineers fully consumed by the migration and no spare capacity, asking for two teams to own two new services is not a request Tomas Beck can grant. So the realistic answer is one owner plus a recorded rationale plus a review date — and an explicit acknowledgement that the architecture will drift toward one service unless something changes.

Writing that prediction down now is worth more than winning the argument, because in a year it is either evidence of foresight or a documented decision to accept the drift.

Feeds the workbook

The rubric requires Conway’s Law applied to the specific team structure — not stated as a general principle. Name the boundaries you expect to drift, the ones you expect to hold, and the organisational precondition each of your Module 3 decisions quietly assumes.

→ Structure and its mechanism are visible. The next factor is not on any chart and decides what the structure permits. — Reading culture from meetings