Conway’s Law Explained: Why Team Structure Shapes Software Architecture (and How It Breaks Microservices)

Systems rarely collapse from bad code alone. More often, they suffer a slow bleed of coordination costs because the architecture quietly mirrors the team structure that built it — and nobody noticed until the incidents piled up. If you have ever looked at a distributed system and thought "this feels suspiciously like our org chart," you have already encountered Conway's Law. You just didn't have a name for it yet.

What Is Conway's Law?

Conway's Law is an observation about software design made by computer scientist Melvin Conway in 1967. Writing in a paper titled How Do Committees Invent?, Conway argued that the communication structure of an organisation will inevitably be reflected in the architecture of the systems that organisation produces.

The core statement is simple:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway, 1967

Conway was not writing a prescription. He was making an observation — one that has proven durable enough that Fred Brooks referenced it in The Mythical Man-Month and that decades later it remains one of the most quietly powerful forces in software architecture.

In simple terms: Conway's Law means that the way teams communicate inside an organisation will shape the structure of the software they build. Conway's Law explained in software architecture circles is often reduced to this: team structure and system design are not separate concerns — they are the same concern.

For example, if four teams each own a different part of a system, the final architecture will often resemble four separate components — even if a different structure would have been technically simpler. The architecture did not emerge from first principles. It emerged from the organisation.

What Conway's Law Actually Means in Practice

Strip away the philosophy and Conway's Law comes down to a few mechanical realities.

Communication paths become design boundaries. When two teams need to collaborate on a shared component, the boundary of that component tends to form along the boundary of their communication. If they talk frequently and closely, the boundary stays fluid. If they rarely speak, the interface between their components hardens — and often becomes a source of friction.

Team ownership becomes service ownership. In a microservices context, the services that emerge tend to map directly to the teams that own them. This is not always intentional. It happens because teams build what they understand, and what they understand best is the domain they live in every day.

Coordination cost becomes coupling. Every time a team has to ask another team to change something, coordinate a deployment, or agree on a contract, that is coordination cost. Systems optimise away from that cost over time. Boundaries form where coordination is expensive. The result is that services end up tightly coupled in ways that were never designed — they were negotiated.

Consider a simple example: three teams building a checkout system. One team owns the cart, one owns payments, one owns order management. Left to their own devices, they will produce three services with APIs shaped by their internal models and their inter-team conversations. The interfaces will reflect not the ideal domain model but the realities of who talked to whom, when, and about what.

Why Conway's Law Exists

Understanding why Conway's Law holds requires understanding something about how humans work in organisations.

People optimise for communication, not architecture. When an engineer makes a design decision, they are not operating from a platonic ideal of clean architecture. They are operating from the information available to them — which comes primarily from the people they talk to. A backend engineer on the payments team knows the payments domain deeply. They know less about the order management domain. Their design decisions will reflect that asymmetry.

Systems evolve along paths of least resistance. Architecture is not purely a product of intent. It is also a product of evolution. Decisions accumulate. Each small decision follows the path of least social and organisational friction. Over time, those accumulated decisions trace a path that mirrors the organisation that made them.

Architecture is often a byproduct, not a plan. Most organisations do not design their systems. They grow them. The architecture that exists at any given moment is the sediment of thousands of small decisions made by people working within the constraints of their team, their communication channels, and their understanding of the broader system.

Conway's Law is not a rule you can break by trying harder. It is a constraint imposed by the cost of coordination. You cannot design your way around the fundamental reality that people build systems shaped by the conversations they are able to have.

How Conway's Law Affects Microservices Architecture

Microservices were supposed to solve the monolith problem. In many organisations, they replaced it with a different one.

The "one team per service" model works — when it holds. The reason microservices succeed in mature organisations is that they align service boundaries with team boundaries. A team owns a service end to end. They deploy it, operate it, evolve it. The service boundary is also the team boundary. Conway's Law is satisfied by design.

Shared ownership creates distributed monoliths. The moment more than one team owns a service — or more commonly, when the services are divided wrong and teams have to coordinate across them constantly — the system reverts to monolith behaviour. Deployments require coordination. Changes require negotiation. The system is nominally distributed but behaviourally coupled. This is the distributed monolith: microservices in name, monolith in practice.

Cross-team dependencies produce API instability. When a service owned by Team A needs to be changed to satisfy a requirement from Team B, you have a coordination event. If that coordination is expensive — because the teams are in different time zones, have different priorities, or simply do not communicate well — the API between them becomes a site of chronic friction. APIs designed under this pressure tend to be overly broad, poorly versioned, and resistant to change because change is too costly.

The failure modes are consistent:

Tightly coupled services that cannot be deployed independently. Slow deployments because a release in one service requires coordination with three others. Constant overhead as engineers spend significant portions of their time not writing code but coordinating changes across team boundaries.

These are not technical failures. They are organisational ones, and no amount of refactoring fixes them without addressing the underlying team structure.

The Inverse Conway Maneuver

If Conway's Law says your system will mirror your organisation, the Inverse Conway Maneuver says: design your organisation to mirror the system you want to build.

The idea was popularised by Jonny LeRoy and Matt Simons and captured in the Team Topologies framework by Matthew Skelton and Manuel Pais. The insight is straightforward: rather than accepting the architecture that your current org structure will produce, deliberately shape your org structure to produce the architecture you want.

In practice this means a few things.

If you want independently deployable services, you need independently operating teams. Each team should own its service fully — from development through deployment and operation. No shared ownership. No cross-team coordination required for routine releases.

If you want platform capabilities to be reused across services, you need a dedicated platform team whose entire mandate is building and maintaining that platform. The platform team reduces the coordination cost for everyone else by abstracting the complexity away.

If you want clear domain boundaries, you need teams that map to those domains. You cannot have a clean payments domain boundary when the payments team also owns part of the user identity service.

The Inverse Conway Maneuver is not magic. It requires genuine organisational change, and organisational change is hard. But it is the only lever that reliably produces durable architectural improvement.

Where Conway's Law Breaks (or Seems To)

Conway's Law is not absolute. There are situations where it appears not to hold — and understanding them is important.

Strong architecture can temporarily override org structure. A technically exceptional architect or a small, cohesive founding team can build systems whose boundaries do not reflect the organisation that will later maintain them. This happens most commonly in early-stage products built by a handful of people with strong shared understanding.

Platform teams can abstract coupling. A well-designed internal platform can reduce the coordination cost between teams enough that Conway's Law's effects are dampened. If Team A and Team B both use the same deployment platform, the same observability tooling, and the same service mesh, their direct coordination cost decreases. The coupling exists — it is just mediated by the platform.

Early-stage startups frequently violate Conway's Law. A team of five people building a product that will later be maintained by fifty will often produce architecture that does not map to any obvious team structure. This is fine — and expected. Small teams with high communication bandwidth can sustain architectures that larger organisations cannot.

But here is what consistently happens: over time, systems drift back toward team structure. The startup grows. Teams form. Responsibilities get divided. And the architecture bends, gradually but reliably, toward the communication structure of the new organisation. What looked like an exception to Conway's Law was a temporary reprieve, not an escape.

Conway's Law and System Failures

The most painful manifestation of Conway's Law is not in architecture diagrams. It is in production incidents.

Microservices that behave like monoliths are the most common symptom. Conway's Law predicts that if teams cannot deploy independently, the system won't either. You have twenty services but they all deploy together because their release cadences are coupled. You have clear service boundaries on paper but in practice a change in one service requires coordinated changes in four others. The architecture looks distributed; the behaviour is centralised — exactly as the org chart dictates.

Unclear ownership causes production incidents to fester. Conway's Law shows that when communication around a service is ambiguous, accountability becomes ambiguous too. When a service is nominally owned by one team but depended on heavily by three others, the question of who responds to an incident becomes a negotiation. Time is lost in coordination at exactly the moment when time is most valuable. This is not a people problem. It is a structural one — the structure failed to assign a single communication owner.

Retry storms caused by cross-team misalignment are a subtler failure. Conway's Law explains that each team optimises for its own local communication patterns, not global system health. Team A's service adds aggressive retries to handle intermittent failures from Team B's service. Team B's service, now receiving a storm of retries, degrades further. Team A adds more retries. The cascade accelerates. Neither team designed this. They each made locally rational decisions within their limited view of the system — a view shaped by their position in the org structure.

These failures share a common root: the system was designed by people whose communication boundaries did not match the system boundaries they were trying to create.

Relationship to Domain-Driven Design, Team Topologies, and Microservices

Conway's Law does not exist in isolation. It is deeply connected to several other foundational ideas in software architecture.

Domain-Driven Design addresses Conway's Law from the other direction. Eric Evans's concept of bounded contexts defines explicit boundaries around domains — and the practical effect of good DDD is that it gives you a principled basis for aligning team boundaries with domain boundaries. If your teams own the same things your bounded contexts own, Conway's Law works in your favour rather than against you.

Team Topologies by Matthew Skelton and Manuel Pais is perhaps the most direct engagement with Conway's Law in the literature. The book proposes four fundamental team types — stream-aligned, platform, enabling, and complicated-subsystem — and three interaction modes (collaboration, X-as-a-service, and facilitation), specifically to help organisations design their team structures to produce the architectures they want. Where Conway's Law merely observes that structure follows communication, Team Topologies gives you a playbook for deliberately shaping that communication. It argues that by limiting team cognitive load, defining explicit interaction modes between teams, and treating platform teams as a way to reduce cross-team coordination costs, you can invert Conway's Law from a constraint you suffer into a tool you wield. In short: Conway's Law tells you what will happen; Team Topologies tells you what to do about it.

Microservices architecture as a discipline cannot be separated from Conway's Law. The microservices movement is, in significant part, an organisational pattern as much as a technical one. The idea that services should be independently deployable only makes practical sense if the teams that own them are also independent. You cannot have one without the other.

Understanding Conway's Law makes you a better reader of all three of these bodies of work, because it surfaces the underlying human constraint that all of them are responding to.

Practical Implications: What Engineers and Architects Should Actually Do

Theory is useful. Here is what applying Conway's Law in software architecture actually looks like in practice.

Align service boundaries with team boundaries. Before you draw a service boundary, ask: which team will own this service? If the answer is "two teams, jointly," that is a warning sign. Shared ownership diffuses accountability and increases coordination cost. Services should have single, clear owners.

Avoid shared ownership of critical services. The most dangerous services in any microservices architecture are the ones that sit at the centre of the dependency graph and are owned by nobody clearly — or everybody ambiguously. These become maintenance burdens, deployment bottlenecks, and incident magnets. Assign clear ownership or split the service until ownership is unambiguous.

Design APIs to reduce cross-team coordination. Every API between services owned by different teams is a cross-organisational interface. It should be stable, well-versioned, and as narrow as possible. Treat it with the same care you would treat a public API — because in organisational terms, it is one.

Treat org design as part of system design. This is the hardest shift for most engineers. We are trained to think of architecture as a technical concern and organisation as someone else's problem. Conway's Law says these are not separable. The conversation about service boundaries and the conversation about team structure are the same conversation. Architects who understand this have significantly more leverage than those who do not.

Audit your existing system for Conway's Law effects. Draw your current system's service dependency map. Then draw your current org chart. The resemblance is rarely accidental. Understanding which service boundaries reflect intentional domain design and which reflect historical team structure is the first step toward improving either.

Is Conway's Law Still Relevant?

More than ever. The relationship between team structure and system design has only grown more consequential as systems have grown more distributed.

When software was built in monoliths, Conway's Law operated slowly. The entire system was owned by one team, or a small number of closely integrated teams. The law's effects were real but contained.

Microservices increased its importance dramatically. When a system is composed of dozens or hundreds of independently deployed services, each owned by a different team, the communication structure of the organisation is encoded not in a single codebase but in the network of APIs between services. The architectural surface area for Conway's Law to operate on is vastly larger.

Distributed systems amplify communication costs in every direction — across teams, across time zones, across organisational boundaries. Every amplification of communication cost is also an amplification of Conway's Law's effects.

The organisations that navigate this well are not the ones that ignore Conway's Law. They are the ones that take it seriously and design their teams as deliberately as they design their systems.

Conclusion

Software architecture is often treated as a technical problem. Conway's Law reminds us that it is, at its core, a human one.

The services you build will reflect the conversations you were able to have. The boundaries you draw will follow the paths of least organisational resistance. The failures you experience will often trace back not to bad code but to misaligned team structures that were never quite right for the system they were asked to produce.

If you understand Conway's Law, you understand that fixing the architecture sometimes means fixing the organisation.

FAQ

What is Conway's Law in simple terms?

Conway's Law says that the software systems an organisation produces will tend to mirror that organisation's communication structure. If three separate teams build one system, the system will likely end up with three parts that reflect the boundaries between those teams — regardless of whether that is the best technical design.

What is the Inverse Conway Maneuver?

The Inverse Conway Maneuver is the deliberate use of organisational design to shape software architecture. Rather than accepting whatever architecture emerges from your current team structure, you reorganise your teams to match the architecture you want to build. If you want two independent services, you create two independent teams and let Conway's Law work in your favour.

Does Conway's Law always apply?

Not without exception. Strong engineering leadership, small cohesive teams, and well-designed platform abstractions can all reduce its effects. But over time and at scale, the tendency for systems to drift toward their organisational structure is robust and well-documented. Exceptions tend to be temporary.

How does Conway's Law affect microservices?

Microservices amplify Conway's Law because the architecture is explicit about its boundaries in a way a monolith is not. Each service boundary is a potential site where Conway's Law operates. When service boundaries do not align with team boundaries — when services are co-owned, or when teams are forced to coordinate constantly across service lines — you get the distributed monolith: the costs of distribution without the benefits of independence. The most successful microservices organisations treat team structure and service structure as the same design problem.