Coordination Bandwidth

Two teams report to the same manager and share one backlog. One sits in Sydney, one in Lisbon, and their days overlap by about 60 minutes. A year later their components talk through three coarse endpoints, each side holds its own copy of the shared entity, and a nightly job reconciles the copies.

Nothing went wrong. Conway's Law tracks the bandwidth available for joint decisions, not the reporting line, and 60 minutes a day is roughly 250 hours a year shared across planning, incidents and reviews. A fine-grained interface needs a decision per field, and a decision that needs a conversation waits up to a day, so teams converge on interfaces they can change without asking.

Why it matters

Coordination bandwidth explains why two organisations with identical structures produce different architectures, and it is the one input to Conway's Law measurable this week: overlap hours, standing joint meetings, a shared rotation, and cross-team review turnaround.

Used deliberately it converts an architecture argument into a staffing question. A fine-grained jointly evolved boundary requires bandwidth the organisation must buy, through overlapping hours, a shared rotation, or one team owning both sides. If it will not buy that, the coarse interface is coming regardless of the design document, and the only choice left is whether it is designed or discovered.

Implementation patterns

• Measure overlap before drawing the boundary: daily overlap hours, cross-team review turnaround, and the age of the oldest open cross-team request.
• Match interface granularity to bandwidth. Under about two hours of overlap, design for coarse asynchronous operations and an owned data copy. Above four hours, a jointly evolved schema is sustainable.
• Name the reconciliation owner at design time, because duplicated data arrives whether or not anyone planned it, and an unowned job is how divergence survives for years.
• Contract tests in both pipelines, so a coarse interface cannot drift without a build failing in the team that broke it.
• Buy bandwidth when it is cheaper than moving a boundary: two hours of overlap bought by shifting one team's start time usually costs less than relocating ownership.

Industry example

Melvin Conway's 1968 article "How Do Committees Invent?" stated the law in terms of communication structure rather than hierarchy, which is the whole of this entry: the org chart is a proxy for communication, and a poor one across time zones.

The clearest ongoing demonstration is open-source, where maintainers are distributed and communication is asynchronous by default. Surviving interfaces there are coarse, versioned and explicitly documented, and the integration points that need tacit knowledge are the ones that repeatedly break. Projects with a high-bandwidth core and a low-bandwidth contributor base land on the split this metric predicts: a coupled core evolved by people who talk daily, and a stable plugin API for everyone else.

Failure scenarios

• The diagram that lost. A fine-grained API is agreed in month two, the first urgent change waits 18 hours in month four, and a field is added on one side alone. By month nine there are two entity shapes and no document says so.
• The shared database shortcut. Faced with slow coordination, two teams write to the same tables, so every migration needs agreement inside the same 60 minutes.
• The 02:00 incident. A fault straddling the boundary needs both teams awake, and the sleeping team owns the failing component.

Trade-offs

Buying bandwidth costs money and goodwill: shifted hours, a shared rotation, or a hiring decision constrained by time zone. Accepting low bandwidth costs duplication and reconciliation, and buys genuine independence, which is why distributed teams often ship local changes faster while being slower on anything crossing the boundary.

If the interface is renegotiated monthly, buy bandwidth or move the boundary. If it is renegotiated yearly, low bandwidth costs almost nothing.

When not to use it

Do not use this metric to justify a boundary the domain does not support. Splitting an invariant because two teams cannot talk produces a correctness problem rather than a coordination one: some things must change together, and no interface design makes a shared invariant safe to split. Move the whole invariant into one team's ownership and pay the staffing cost. The metric predicts which interface you will get, not which ones are legitimate.

Interview question

Q: You are asked to split a component between a team in Europe and a team in Australia with an hour of daily overlap. The design calls for a shared schema both teams evolve. What do you tell the sponsor?

What a strong answer covers: predicting the coarse asynchronous interface with duplicated data as the one-year outcome and why that is rational rather than sloppy; offering two priced options (buy overlap hours or move ownership of the seam); naming the reconciliation owner and the contract tests if the split proceeds; and identifying any invariant that must not be split at all.

Quick check

Quiz: Two teams share a manager and a backlog but overlap by 60 minutes a day. What interface will they have in a year? Answer: coarse and asynchronous with duplicated data and a reconciliation job, because fine-grained interfaces need more joint decisions than the overlap supports.

Flashcard: Which measurement predicts interface granularity better than the org chart? Hours of daily overlap plus cross-team review turnaround: low bandwidth produces coarse interfaces and duplicated data whatever the reporting structure says.