What is Conway's Law, and why does it matter when a company splits a monolith into microservices?

## The mechanism Conway's Law comes from a 1968 paper by computer scientist Melvin Conway, which observed that 'organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.' The mechanism is not mystical: software has to be split into modules, and **each module boundary is a place where two pieces of code must agree on an interface**. Formalizing an interface (a REST contract, an event schema, a function signature) is **expensive** — it requires explicit negotiation, versioning discipline, and documentation. People take that expensive step at the edges of frequent, informal communication: - **Within a team**, changes get negotiated in a stand-up or a Slack thread and code can stay tangled without anyone noticing, because the humans compensate for the mess with conversation. - **Across a team boundary**, that informal compensation doesn't happen at the same bandwidth, so the code is forced into a cleaner, more contractual shape. The upshot: the seams in your software will appear wherever the seams in your organization's communication are, whether you planned it that way or not. ## What it does to a microservices migration Why this matters for microservices specifically: a microservices migration is usually sold as a purely technical exercise — 'split the monolith along bounded contexts' — but bounded contexts drawn on paper only stay stable if a team's day-to-day ownership matches them. If Team A and Team B jointly own the 'Orders' service, every change to `Orders` requires cross-team coordination: - PR reviews from both sides - a shared deploy calendar - negotiation over the data model Over months, that friction produces exactly the symptoms microservices were supposed to eliminate: - synchronous cross-service calls that ought to have stayed in-process - a shared schema nobody wants to migrate because it breaks the other team - features that ship slower than they did in the monolith In other words, Conway's Law explains why 'we split the code into 20 services but our team structure didn't change' migrations routinely produce a **distributed monolith**: tightly coupled deployment and change patterns, just now with network calls between the pieces instead of function calls. ## The trade-off The trade-off is between architectural ambition and organizational cost. | Boundaries follow… | What that buys, and what it costs | |---|---| | the 'textbook-correct' domain model | Drawing service boundaries there is cheap on a whiteboard but expensive in practice if it requires teams to reorganize, retrain, or take on new operational responsibilities — see the **'inverse Conway maneuver'**, the deliberate practice of restructuring teams first so the architecture Conway's Law produces is the one you want. | | the existing team structure | Conversely, drawing service boundaries there is organizationally cheap but can bake in whatever team boundaries already exist for historical, not domain, reasons — you get services that map to reporting lines rather than to actual business capabilities, which is its own long-term liability. | ## Failure modes in production Failure modes show up concretely in production. 1. **The shared-ownership service**, the most common: two teams both have write access to one service's repo, both deploy it, and neither treats it as fully theirs on-call. Incidents in that service get slow triage ('is this our bug or theirs?'), and the codebase accumulates competing conventions because there's no single team enforcing consistency. 2. **Chatty cross-service calls**, a second failure mode, recreate a monolith's function-call latency profile over the network: because two teams working on nominally 'separate' services actually talk constantly, their services end up needing synchronous, fine-grained calls to satisfy that tight collaboration, producing cascading latency and availability coupling. 3. **The 'org chart service'**, a third: a service exists because a team exists, not because the business domain calls for a boundary there, and it gets awkwardly stitched into workflows that cross domains. ## The lesson in practice A concrete illustration: Amazon's shift to what became known as **'two-pizza teams'** (small, autonomous teams each owning a service end-to-end, publicized around the mid-2000s) is frequently cited as a deliberate application of Conway's Law — restructure the organization into small, loosely coupled teams first, and the resulting software architecture (what became the AWS service ecosystem) naturally inherited that loose coupling. The lesson generalizes: if you want a target architecture, the fastest lever is often not a better architecture diagram, but changing who talks to whom, how often, and across which boundaries.