Two teams report to the same manager and share one backlog. One sits in Sydney and one in Lisbon with about 60 minutes of working overlap a day. What shape does the interface between their two components take over the next year?

What the mechanism actually is

Conway's Law is usually quoted against the org chart, and the org chart here says these teams are one unit: same manager, same backlog. The mechanism is communication bandwidth, not reporting lines. Sixty minutes of overlap a day is roughly 250 hours a year of possible synchronous conversation, shared across planning, incidents, reviews and every other topic. A fine-grained interface needs a decision per field, and each decision that needs a conversation waits up to a day.

Teams respond rationally: they converge on interfaces they can change without asking. That means coarse operations, their own copy of the data they need, asynchronous messages instead of calls that must be debugged live, and eventually a job that reconciles the two copies.

What happens month by month

Months 1 to 2: a shared schema is agreed in the overlap window and written down. Months 3 to 5: the first urgent change waits 18 hours, so someone adds a field on their own side instead. Months 6 to 8: there are two representations of the same entity, and a nightly export keeps them close. Months 9 to 12: three coarse endpoints, a reconciliation job that someone owns, and a diagram that still shows the schema agreed in month 2.

None of this is a failure. It is the interface the available bandwidth can sustain. The failure is getting it by accident, because then the duplication is undocumented and the reconciliation job has no owner.

Why the other options fail

• The fine-grained synchronous API with a shared schema is what the diagram will say and what the code will not do. It requires more joint decisions per month than 60 minutes a day supports, and the first production incident that straddles the boundary at 02:00 Lisbon time ends it. This option is wrong on timing, not on taste: at four hours of overlap it is the right answer.
• One team absorbing the other's component happens when one team has slack and the component is small. Here neither team can review the other's work inside its own day, so absorption produces a component nobody can change safely. It is right when the component is being retired.
• A shared database both teams write to looks like it removes coordination and creates the one form of coupling with no upper bound: every schema migration now needs agreement inside the same 60 minutes, and a bad index decision is felt by both. This is the option teams genuinely pick under deadline pressure, which is why it belongs on the list.

What to do about it

Choose the seam deliberately rather than discovering it in month nine. Pick the boundary where duplication is safe, name the owner of the reconciliation, and put a contract test in both pipelines so the coarse interface cannot drift silently. If the component must stay fine-grained, the fix is organisational: move it so one team owns both sides, and accept the staffing cost of that.

When this is the wrong prediction

If the two components change on very different clocks - one monthly, one twice a year - the interface stays fine-grained because it is almost never renegotiated. Low bandwidth only shapes an interface that is under constant pressure to change.