Conway's Law, an observation made by computer scientist Melvin Conway in 1967, states that organizations design systems that mirror their own communication structure. A company with four separate, loosely-communicating teams will tend to produce a system with four major components, roughly along the same boundaries as the teams, regardless of whether that particular four-way split is actually the most sensible technical decomposition of the problem the system solves. A concise external treatment is available in Martin Fowler's Conway’s Law note.
Why this happens, mechanically
The mechanism behind the observation is fairly direct: a system's architecture requires the people building it to agree on interfaces and boundaries, and agreement is easier and more frequent within a team that communicates constantly than across teams that communicate less often or less directly. Over time, the parts of a system that are worked on by a single, cohesive team tend to develop clean, well-coordinated internal structure, while the boundaries between what different teams own tend to calcify into the system's actual architectural seams — not because those seams were deliberately chosen as the best technical decomposition, but because they're where communication was naturally more effortful, and effortful communication tends to get minimized by keeping the interface between the two sides simple and infrequently renegotiated. Leaders comparing organizational structure with measurable work patterns may also consult workforce analytics software.
This has a specific, practical implication that's easy to miss: if an organization changes its team structure without a corresponding, deliberate change to its system's architecture (or vice versa), the two will be in tension until one adapts to the other — a system architected for four teams doesn't naturally serve two merged teams well, even though nothing about the code itself changed at the moment of the reorganization.
The “inverse Conway maneuver”
A deliberate strategy that follows directly from the observation — sometimes called the inverse Conway maneuver — is to design the desired system architecture first, and then deliberately restructure teams to match it, on the theory that team structure will, per Conway's original observation, naturally produce a system architecture that mirrors it. If a desired architecture calls for a small number of independently deployable services (connecting to the monoliths-versus-microservices guide on this shelf), deliberately organizing teams around those same service boundaries, each with clear ownership, tends to produce and sustain that architecture more reliably than specifying the architecture on a document and hoping teams organized differently will maintain it.
- Before proposing an architectural change, consider whether the current team structure will naturally reinforce or fight against it — architecture and org structure tend to converge eventually, in one direction or the other.
- A reorganization without a corresponding architectural review often leaves a system's structure mismatched to the new team boundaries for longer than expected — the mismatch doesn't resolve itself automatically.
- The inverse Conway maneuver — designing team structure to match a desired architecture — is a legitimate, deliberate strategy, not just an observation to note after the fact.
- Where teams communicate constantly and informally, expect the system's internal structure in that area to be more fluid and less strictly bounded than in areas split across teams that communicate less often.
Why this matters more at scale
Conway's Law is most visibly consequential in larger organizations with multiple teams working on the same system, where the tension between organizational and technical structure has more room to manifest. In a small team or a single-team project, the observation still technically applies, but with far fewer team boundaries to create architectural seams, its practical effect is much smaller — which is part of why the observation, though made in 1967, has become considerably more discussed in the era of larger, multi-team software organizations than it was in the decades immediately following its publication.
Read alongside the monolith-versus-microservices trade-off discussed elsewhere on this shelf, Conway's Law suggests that question is rarely purely technical to begin with — how many independent teams need to work on a system independently is often the more fundamental question, with the resulting architecture following from the answer rather than preceding it.