How do team structure and Conway's Law affect which architectural style is workable, and what is the 'inverse Conway maneuver'?

### Conway's Law Melvin Conway, 1967: *"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."* It is an empirical observation, not a rule anyone enforces. The mechanism is mundane: an interface between two components is also an interface between the people who build them. Where people talk constantly — same team, same standup — they produce fine-grained, tightly coupled, easily changed interfaces. Where communication is slow and formal — different departments, different time zones — they produce coarse, stable, defensively designed interfaces, because renegotiating is expensive. ### Why this constrains style selection If the intended architecture does not line up with the organisation, the organisation usually wins: - **Microservices owned by one team.** You get network calls, versioning and separate pipelines, but no independent release benefit, because the same people coordinate all the changes anyway. Cost without payoff. - **Many autonomous teams in one deployable.** Release contention: every team waits for the slowest, a rollback for one team's bug reverts everyone's work, and shared code becomes contested. - **Teams split by technical layer** (a front-end team, a back-end team, a database team). Every user-facing feature needs three teams and hand-offs, so lead time is dominated by queueing, and the architecture drifts toward layered coupling with no clear domain ownership. ### The inverse Conway maneuver Rather than fighting the law, use it: change the team structure to the shape you want the system to have, and let the architecture follow. The vocabulary from *Team Topologies* (Skelton and Pais) is useful: - **Stream-aligned team** — owns a continuous flow of work for one business domain or user segment, end to end. - **Platform team** — provides self-service internal capabilities (pipelines, runtime, observability) so stream-aligned teams do not each rebuild them. - **Enabling team** — temporarily coaches others in a capability such as test automation, then leaves. - **Complicated-subsystem team** — owns a part requiring deep specialist knowledge, such as a pricing engine or a video codec. And three interaction modes: **collaboration** (high-bandwidth, temporary, good for discovery, expensive), **X-as-a-service** (consume a stable interface, low coordination), and **facilitating** (one team helps another improve). ### Cognitive load as the sizing constraint The practical limit on how much a team can own is cognitive load, not headcount. A team owning twelve services it barely understands has poor availability and slow change. This is why platform investment usually has to precede a move to microservices: without paved-road pipelines, tracing and runbooks, the extrinsic load of operating services crowds out domain work. If you cannot fund the platform, the service-per-team style is not actually available to you, regardless of its technical merits. ### Caveats The maneuver is not a licence for constant reorganisation — reorganisations are expensive and destroy tacit knowledge, so use them for durable structure, not fashion. Conway's Law also does not say the organisation chart is the *only* force; a strong platform and clear contracts can dampen it. Distributed or outsourced teams push toward coarse, asynchronous, contract-first interfaces whether or not that was the intent — so plan those boundaries deliberately. Finally, record the topology assumption in the ADR: when the team count doubles or a reorganisation lands, that is a legitimate trigger to revisit the architectural style.