How does Conway's Law interact with the decision to split a system into microservices, and under what organizational conditions does that split actually deliver the promised autonomy and scaling benefits versus just adding cost?

## The law and its mechanism Conway's Law, formulated by Melvin Conway in 1968, observes that any organization that designs a system will produce a design whose structure mirrors the organization's communication structure. The mechanism isn't mystical: - software interfaces require coordination to define and maintain - coordination is expensive across organizational boundaries (different managers, different priorities, different meeting cadences) and cheap within a tight-knit team that shares a standup and a chat channel Over many small decisions — "should I ask the other team to change their API, or just work around it in my own code" — engineers naturally route around expensive coordination, and the resulting software ends up structured the way the teams that built it were structured, whether or not anyone planned it that way. ## The same split, two very different results Applied to the microservices-versus-monolith decision, this law explains why the same technical split — say, a catalog service and an orders service, physically separated with their own deployment pipelines — produces completely different real-world outcomes depending on the team structure behind it. - If catalog and orders are each **owned end-to-end by a single small, stable team** that rarely needs anything from the other team beyond a documented API, Conway's Law predicts the services stay genuinely loosely coupled: each team optimizes its own service's internals freely, deploys on its own cadence, and the published API becomes a real, respected seam because that's the only channel of coordination available. - If instead the organization has **one shared backend team** writing code across both services, or the two service-owning teams are **in constant coordination** because their features are always coupled, Conway's Law predicts the software will reflect that shared, high-frequency communication structure regardless of the deployment diagram: the services will evolve in lockstep, their APIs will leak internal details because coordination is cheap, and you end up with exactly the distributed-monolith outcome — many deployables, one team's worth of actual coupling. ## The organizational condition This is why the organizational condition for microservices to deliver on autonomy and scaling isn't "we have microservices" but a specific **team topology**: small, stable, cross-functional teams — Team Topologies calls these **stream-aligned teams** — that each own a bounded, coherent piece of the business domain end-to-end, including on-call for it, and that interact with other teams through a small number of well-defined, infrequently-changing interfaces rather than constant ad hoc coordination. Supporting roles matter too: - a **platform team** providing shared deployment infrastructure so each stream-aligned team doesn't need deep expertise in Kubernetes or service meshes - **enabling teams** that temporarily help build a new capability without taking over ownership When that structure is in place, the technical split into services is mostly formalizing a boundary that already exists organizationally, which is a low-risk move; when it isn't in place, splitting the code without splitting the organization mainly adds network calls and deployment machinery on top of coordination costs that don't go away. ## The failure mode The failure mode this produces in practice is one of the most common reasons microservices initiatives underdeliver: an organization decides "we should do microservices" as a top-down technical initiative, draws service boundaries on an architecture diagram, but leaves the team structure untouched — the same handful of generalist engineers, or the same siloed functional teams, now work across a dozen services instead of one codebase. Every feature still requires the same cross-team coordination it always did, because the organization's communication structure didn't change, so per Conway's Law the software keeps behaving like a monolith — just a much more expensive one to operate, page for, and trace requests through. ## The inverse Conway maneuver The corrective move this insight leads to is the "inverse Conway maneuver": instead of treating team structure as fixed and hoping the architecture ends up decoupled anyway, deliberately restructure teams into the shape you want the architecture to eventually have, and let Conway's Law work in your favor — the software naturally tends toward the loosely coupled shape because that's now the path of least coordination cost. This is documented practice at organizations like Amazon (the "two-pizza team" structure preceding and enabling its service-oriented architecture) and is the central thesis of Matthew Skelton and Manuel Pais's Team Topologies: get the team boundaries and interaction modes right first, or at least concurrently, rather than assuming a diagram of service boxes will impose discipline on an unchanged organization. A principal-level answer to "should we do microservices" therefore has to include a team-topology answer, not just a technical one — the same decomposition can be the right call for one org and a costly mistake for another, purely as a function of how the teams around it are structured.