Two teams own two deployables: a reader-facing API and a mobile backend-for-frontend that calls it. They are merged into one team of nine with one backlog and one standup. What happens to the interface between those two services over the next two quarters, and what would you do about it now?

What Conway's claim actually predicts

Conway's 1968 Datamation paper says organisations "are constrained to produce designs which are copies of the communication structures of these organizations". The operative words are communication structures, not org chart. The interface between these two services was as clean as it was because changing both sides at once required a conversation across a team boundary, and that conversation had a cost. The merge sets that cost to zero.

Quarter by quarter

• Weeks 1 to 6. Nothing visible. The seam holds because habit holds.
• Weeks 6 to 14. The first shortcut: the BFF reads a field the API returns but never documented, because the person who added the field is sitting there and confirmed it is safe. No review catches it, because the reviewer is on the same team.
• Weeks 14 to 26. Shared types. One repository, one release, one pull request touching both sides. Then the BFF reaches past the API to the API's database for one query that was awkward over HTTP.
• End state. Two deployables that must be released together, coupled through a shared schema, with a network hop and a serialisation cost between them. That is strictly worse than either a single service or two independent ones — the operational cost of distribution with none of the independence it was supposed to buy.

Where it amplifies

Deployment is where it becomes visible. A change now needs both artifacts in a fixed order, so rollback needs the reverse order, and the first incident where one rolls back and the other does not is the moment somebody says "why are these two things separate at all?". By then the cheap answer — merge them — has been made expensive by the shared schema.

What stops it, and it is not discipline

Two honest options, and the choice should be made deliberately in the first month.

1. Accept the merge and collapse the deployables. Delete the network hop, keep the module boundary in-process, and enforce it with a build-time dependency rule so the boundary survives without anyone remembering it. This is usually right: the boundary was organisational and the organisation is gone.
2. Keep the seam and give it a mechanism. A published contract with consumer-driven verification in CI, a rule that fails the build on a shared type, and no database credential granted across the seam. Choose this only if there is a reason the boundary must outlive the current org shape — a different scaling profile, a different compliance scope, a planned re-split.

The general rule

Any architectural boundary whose only enforcement is that two groups of people find each other inconvenient will not survive a reorganisation. Every boundary you intend to keep needs an enforcement that a merged team still trips over: a contract test, a dependency rule, a separate credential, a separate pipeline.

When this is the wrong worry

If the two services are being merged precisely because the split was wrong, erosion is the desired outcome and fighting it wastes a quarter. The distinguishing question is whether the two sides have ever been released independently in the last year. If they have not, the boundary was already decorative, and the reorganisation is just making that legible.