In the late 1960s, computer programmer Melvin Conway observed something that the software industry would spend decades rediscovering. He was working on a complex software project and noticed that the resulting system's architecture closely resembled the structure of the team that had built it. Where teams had clear boundaries and limited communication, the software had clean interfaces. Where teams overlapped and communicated densely, the software was tightly coupled. Where teams were siloed, the software was fragmented in the same pattern.
Conway attempted to publish his observation in the Harvard Business Review in 1967. The editors rejected it — they considered it insufficiently rigorous. It was eventually published in Datamation in April 1968 under the title "How Do Committees Invent?"
The key passage:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." — Melvin Conway, How Do Committees Invent? (1968)
Conway's formulation was general. He did not say this applied only to software. He claimed it as a property of any complex system designed by an organization — because the design constraints that matter most are not technical but social: who talks to whom, how often, about what.
Conway's Law has since been validated empirically, cited by some of the most influential figures in software engineering, and become foundational to how leading technology organizations think about the relationship between team structure and system architecture. What Conway noticed informally in one project turns out to be a structural regularity that appears across industries, time periods, and technologies.
Key Definitions
Conway's Law — The principle that organizations designing complex systems will produce designs whose structure mirrors the organization's communication structure. Proposed by Melvin Conway in 1968. The law is descriptive, not prescriptive: it predicts what will happen, not what should happen.
Communication structure — The pattern of who communicates with whom, how frequently, and with what degree of formality in an organization. Communication structure includes formal reporting lines, team membership, physical proximity, shared tools, and informal relationships. Conway's Law claims that this pattern is reflected in the system architecture.
System architecture — The high-level structure of a complex system: its major components, the relationships between them, the interfaces through which they communicate, and the principles governing those relationships. In software, this includes decisions about services, APIs, databases, modules, and deployment units.
Coupling — The degree of interdependence between system components. Tightly coupled components cannot be changed independently; changing one requires changing others. Loosely coupled components have explicit, stable interfaces and can be developed and deployed independently.
The Inverse Conway Maneuver — The deliberate application of Conway's Law as a design strategy: structuring the organization to produce a desired system architecture. If the desired architecture has certain boundaries, create teams with those boundaries. Coined by Jonny Leroy and Matt Simons and popularized by James Lewis and Martin Fowler.
Team topology — The deliberate design of team structures, interactions, and responsibilities to optimize for a desired software delivery outcome. Made the subject of a 2019 book by Matthew Skelton and Manuel Pais, Team Topologies, which systematizes the Inverse Conway Maneuver.
Module — A self-contained component of a system with a defined interface and internal implementation. Software modules can be independently developed, tested, and deployed to the extent that their interfaces are stable and their internal implementation is encapsulated.
Technical debt — The accumulated cost of expedient design and implementation choices that reduce long-term maintainability. Often has organizational roots: boundary mismatches between teams create integration complexity that accumulates as technical debt.
The Mechanism: Why Communication Shapes Architecture
Design Requires Coordination
Software components that need to work together must be designed together. The people writing a client application must agree with the people writing the API it calls about what that API looks like. The people writing a data pipeline must coordinate with the people writing the systems that produce and consume the data.
This coordination happens through communication. Design decisions that affect multiple components require communication across the boundaries between the teams responsible for those components. The quality, frequency, and nature of that communication directly shapes the interfaces that emerge.
When two teams communicate frequently and directly, they can negotiate complex, tight interfaces because the cost of coordination is low. Tightly coupled designs are feasible when the teams that own the coupled components work closely together.
When two teams communicate rarely or through intermediaries, they tend to produce interfaces that are explicit, minimal, and stable — because they cannot afford the ongoing coordination that tight coupling requires. Loose coupling emerges from communication cost.
"The structure of the system will be congruent with the communication structure of the organization that builds it." — Fred Brooks paraphrasing Conway, The Mythical Man-Month (1975)
Organizational Boundaries Become Technical Boundaries
Every organization has boundaries: between teams, between departments, between geographic locations, between contractors and employees. People on one side of a boundary communicate less with people on the other side. Information travels more slowly across boundaries. Coordination requires more formal processes.
These organizational boundaries systematically appear as system boundaries. Services are owned by single teams because cross-team ownership creates the same coordination problems in maintenance that it created in design. APIs sit at the borders between team-owned services. The structure of the deployment system — what gets deployed together and what can be deployed independently — corresponds to what teams need to release independently.
This is not merely architectural convenience. It reflects the actual cost of coordination: if maintaining a component requires constant communication across organizational boundaries, that component will be fragmented, poorly documented, and progressively harder to maintain.
The Information Bottleneck Model
A complementary way to understand Conway's Law draws on information theory. Each team's design decisions are constrained by the information available to it. Information about a component's requirements, constraints, and use cases flows primarily through communication with the teams that use or depend on it. When communication bandwidth between teams is low, each team's design decisions are made with incomplete information about the adjacent systems.
The result is that interfaces — the points where components built by different teams meet — tend to be underspecified, poorly tested, and fragile, because neither team has complete information about what the other needs. The bugs and integration failures that occur at organizational boundaries reflect this information deficit as much as any technical inadequacy.
Researcher Alan MacCormack described this as a "mirroring hypothesis": the technical dependency structure of a software product mirrors the communication and coordination structure of the organization that built it, because information flows through organizational channels and design decisions are bounded by available information.
Empirical Validation
The MacCormack-Rusnak-Baldwin Study
In 2008, Alan MacCormack, John Rusnak, and Carliss Baldwin at Harvard Business School published a study directly testing Conway's Law by comparing software modularity across different organizational structures. They analyzed the design structure matrices of several software products — tools that map dependencies between software modules — alongside the organizational structures that produced them.
The key finding: open-source projects, built by distributed contributors with loose organizational coupling, produced significantly more modular software architectures than commercial products built by tightly coupled internal teams. The organizational coupling predicted the software coupling.
The study provided the first rigorous empirical confirmation of what Conway had observed informally four decades earlier. The correlation was strong enough and consistent enough across different types of software that the authors concluded it reflected a systematic organizational mechanism rather than coincidence. Crucially, the relationship held when controlling for other factors: the organizational structure effect was independent of team size, project age, and programming language.
Microsoft's Windows and DevOps Research
Nachiappan Nagappan, Brendan Murphy, and Victor Basili at Microsoft Research published a 2008 study examining what factors predicted defect rates in Windows Vista. Among all the factors they studied — code complexity, code churn, code coverage, developer experience — organizational metrics were the most powerful predictors of defect rates. Software owned by multiple teams had higher defect rates than software owned by single teams. Software at the intersection of organizational boundaries was the most defect-prone.
The result suggests not only that Conway's Law describes what architectures are built, but that the mismatch between organizational boundaries and system boundaries produces measurable quality degradation. The study found that organizational metrics predicted defect rates with higher accuracy than traditional software metrics — a finding that has been cited extensively in software engineering research and has influenced how teams think about ownership and accountability.
"If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." — Ruth Malan, architecture consultant (paraphrasing Conway's Law)
The DevOps Research and Assessment (DORA) Findings
The DORA State of DevOps research program, which has collected data from tens of thousands of software delivery practitioners annually since 2014, consistently finds that team structure is among the most powerful predictors of software delivery performance. Organizations where teams have clear ownership of services, minimal hand-offs between teams, and the autonomy to make independent deployment decisions — in other words, organizations whose team topology matches their desired service architecture — significantly outperform those where team boundaries do not match system boundaries.
The 2019 Accelerate State of DevOps Report found that organizations with loosely coupled architectures and team structures were twice as likely to achieve elite software delivery performance (measured by deployment frequency, lead time, change failure rate, and time to restore service). This is a real-world validation of the Inverse Conway Maneuver: the organizations that had deliberately aligned their team structure with their desired architecture outperformed those that had not.
Conway's Law in Practice: Case Studies
Amazon and the Two-Pizza Rule
Jeff Bezos famously instituted what he called the "two-pizza rule" at Amazon: no team should be larger than can be fed by two pizzas. This was an organizational decision, but it was simultaneously an architectural decision based on Conway's Law.
Bezos understood that large teams produce complex, tightly coupled systems that are hard to change. Small, autonomous teams with clear ownership of specific services produce simpler, more independent components that can be evolved and deployed separately. By mandating small teams, he was mandating the service-oriented architecture that Amazon would become famous for — not through architectural decree, but by shaping the organizational conditions that would produce it.
The result was Amazon Web Services: a collection of loosely coupled, independently deployable services with clean APIs. This architecture emerged, at least in part, from the organizational structure Bezos created. The internal "working backwards" document culture at Amazon — where teams write a press release for a service before building it, forcing clarity about what the service does and who it serves — reinforced the architectural thinking by requiring explicit service boundary definition as an organizational practice.
IBM and the Mainframe
Frederick Brooks, author of The Mythical Man-Month, managed the OS/360 project at IBM — one of the largest software engineering efforts of its time. The OS/360 architecture reflected the IBM organizational structure that produced it: dozens of teams, each responsible for specific components, with interfaces negotiated across team boundaries. The resulting system was complex, tightly integrated in some places and arbitrarily fragmented in others, and enormously difficult to maintain.
Brooks's analysis of why large software projects fail consistently goes back to organizational dynamics. His observation that "adding manpower to a late software project makes it later" (Brooks's Law) is another instance of Conway's Law: adding people adds communication overhead and increases the organizational complexity that the software will reflect. The communication cost grows approximately as the square of the team size — each new person must coordinate with every existing person — and this combinatorial explosion in coordination cost is directly reflected in the system's complexity.
Brooks estimated that in a large programming project, roughly one-third of calendar time should be allocated to planning, one-sixth to coding, one-quarter to component testing, and one-quarter to system integration testing. The large allocation to integration is a direct consequence of Conway's Law: the integration phase is where the mismatches between components built by loosely coordinating teams become visible and must be resolved.
Netflix's Microservices
Netflix's transition from a monolithic application to a microservices architecture in the early 2010s provides a contemporaneous case study. Netflix's engineering organization was restructured into small, autonomous teams, each owning specific services in the streaming platform. The organizational restructuring preceded the architectural migration: teams were defined first, and the system was decomposed to match the team boundaries second.
The resulting architecture — hundreds of small, independently deployable services — mirrors exactly what Conway's Law predicts from a highly distributed organizational structure with many autonomous teams and limited cross-team coupling. Netflix's engineering blog documented this transition explicitly: the architectural goal (microservices) was achieved by changing the organizational structure, not by imposing an architectural mandate on an unchanged organizational structure.
The Netflix case also illustrates the failure mode that preceded the successful transition. The original monolithic architecture had been built by a more centralized organization. As Netflix scaled and the organization grew more complex, the monolith became increasingly difficult to change — a symptom of the mismatch between the emerging distributed organizational structure and the centralized architecture. The solution was to align the architecture with the actual organizational structure rather than fight the organizational tendency through architectural enforcement.
Spotify's Tribes and Squads
Spotify's engineering organization structure — squads, tribes, chapters, and guilds — became widely discussed as a model for scaling agile development. The key insight, directly applying Conway's Law, is that each squad is a small, cross-functional team with end-to-end ownership of a specific product area. Squads have the autonomy to make technical decisions within their area, eliminating the coordination overhead that would result from requiring cross-team approval for every technical choice.
The squad structure is simultaneously an organizational design and an architectural design: each squad's bounded ownership of a product area corresponds to a bounded service or set of services in the technical architecture. The organizational unit and the system unit are deliberately aligned. Where other organizations create friction by having organizational and system boundaries diverge, the Spotify model embeds the Conway's Law alignment as an explicit design principle.
The Inverse Conway Maneuver
If Conway's Law describes how organization shapes architecture, the Inverse Conway Maneuver proposes using it deliberately: if you want a specific architecture, design your organization to produce it.
The logic is straightforward. If you want loosely coupled, independently deployable services, you need small autonomous teams with clear ownership. If you want a unified product with tight integration, you need a unified team with dense communication. You cannot create the organizational conditions for a monolith and expect microservices to emerge, nor vice versa.
Matthew Skelton and Manuel Pais, in Team Topologies (2019), systematize the Inverse Conway Maneuver into a framework for deliberately designing team structures to produce desired software architectures. They identify four fundamental team types:
| Team Type | Purpose | Conway's Law Application |
|---|---|---|
| Stream-aligned team | Owns a specific business capability end-to-end | Creates a self-contained service with clear boundaries |
| Enabling team | Helps other teams acquire capabilities | Reduces impedance without creating ownership boundaries |
| Complicated subsystem team | Owns a technically complex component | Creates a clean interface around complexity |
| Platform team | Provides a self-service internal platform | Creates clear platform/product boundaries |
The framework is explicit that organizational structure is not a consequence of technical decisions — it is a precondition for technical outcomes. Before designing the system, design the team structure that can produce it.
Skelton and Pais also identify three interaction modes between teams, each with implications for the interfaces that will emerge:
Collaboration: Two teams work closely together for a defined period, sharing knowledge and solving problems jointly. This interaction mode produces tightly coupled interfaces appropriate when the boundary between two domains is being actively defined.
X-as-a-service: One team provides a service that another team consumes through a stable, well-defined interface. This interaction mode produces the loose coupling appropriate for mature, stable boundaries.
Facilitating: One team helps another acquire capabilities they can then exercise independently. This mode transfers knowledge without creating ongoing coordination dependencies.
The deliberate selection of interaction modes — not just team structure — is part of the Inverse Conway Maneuver. The same team structure with different interaction modes will produce different systems.
Conway's Law and Technical Debt
One of the most practical applications of Conway's Law is understanding the organizational roots of technical debt. When organizational structure and system architecture are misaligned — when a system's components do not correspond to the communication boundaries of the teams that maintain it — technical debt accumulates at the boundary mismatches.
The mechanism: when a team owns a component that requires constant coordination with multiple other teams to change, that component will change slowly, incompletely, and with errors at the interface points. Documentation will be incomplete because knowledge is distributed across teams. Testing will be inadequate because no single team feels full ownership. The component will accumulate workarounds that avoid the coordination cost of proper fixes.
The technical debt is organizationally generated. Refactoring the code without changing the organizational structure will not eliminate it — the same misalignment that produced the debt will produce more. Conway's Law implies that technical debt elimination requires organizational restructuring as a prerequisite, not a consequence, of architectural improvement.
This has practical implications for large-scale refactoring initiatives. Organizations that attempt to decompose monoliths into microservices without first aligning their team structure with the target service architecture typically find that the new services replicate the coupling patterns of the old monolith — because the same teams, with the same communication patterns, are building the new system. The architecture changes; the underlying organizational dynamics do not; and Conway's Law reasserts itself.
The Seam Pattern
One practical technique for managing technical debt under Conway's Law is the seam pattern, described by Michael Feathers in Working Effectively with Legacy Code (2004). A seam is a point in the codebase where one part of the code can be separated from another without changing the code itself. Creating seams — especially at organizational boundaries — allows teams to evolve their portions of the codebase independently.
The seam pattern is most effective when seams are placed at organizational boundaries: where one team's responsibility ends and another's begins. This alignment allows each team to change its own seams without coordinating with the other team, reducing the coordination overhead that would otherwise accumulate as technical debt.
Conway's Law Beyond Software
Conway's formulation was explicit that his observation applied to "any organization that designs a system." The software industry has been the primary domain of application because software architectures are both important and unusually visible — but the principle extends to any designed system.
Hardware design: The design of integrated circuits, computer systems, and electronic hardware consistently reflects the organizational structures of the engineering teams that produce them. Chip designs developed by geographically distributed teams tend to have cleaner interfaces between sub-components than those developed by co-located teams — the communication cost of distribution forces explicit interface definition.
Organizational design itself: Organizations are systems, and organizations that design new organizations tend to produce organizational structures that reflect the communication patterns of the designers. A small executive team designing a new business unit will produce a structure that reflects their particular communication preferences and authority assumptions — often replicating the structure of their current organization in the new context.
Policy and regulatory design: Government agencies and legislative bodies produce regulations whose structure reflects the organizational structure of the drafting process. Tax codes designed by multiple committees with overlapping jurisdictions tend to be fragmented and internally inconsistent, reflecting the organizational fragmentation of the drafters. Single-agency regulations tend to be more internally coherent, reflecting the tighter communication structure of a single organizational unit.
Infrastructure and urban planning: Physical infrastructure — road networks, utility systems, building layouts — tends to reflect the administrative boundaries of the organizations responsible for planning and maintaining them. Municipal boundaries appear in street grid changes, utility system incompatibilities appear at county lines, and building code differences appear at jurisdiction borders. The physical world is shaped by organizational communication structures just as surely as software is.
Limitations and Caveats
Conway's Law is a descriptive generalization, not an iron law. Several conditions limit its applicability:
Experienced architects can partially override it. A strong architect with authority and explicit attention to interface design can create cleaner boundaries than the organizational structure would naturally produce. The resistance is significant, but skilled engineering leadership can work against Conway's Law for a time. The key limitation is sustainability: architectures that diverge from organizational structure tend to drift back into alignment over time, as the people who understood the original design intent leave and the system is modified by teams following their organizational communication patterns.
It is a tendency, not a determinism. The law predicts that organizational and system boundaries will tend to align over time. In the short term, intentional design can diverge from the prediction. The alignment becomes stronger as the system ages and as the people who understood the original design intent leave.
Remote and distributed work complicates the picture. Conway's Law was formulated when "communication structure" was largely determined by physical proximity and reporting structure. In distributed organizations with sophisticated digital communication tools, communication patterns are less constrained by organizational boundaries. Research on distributed software development suggests that the law still applies but that the relevant communication structure in distributed organizations is shaped by timezone overlap, collaboration tool usage patterns, and shared repository access rather than physical proximity. The law still applies; identifying the relevant communication structure is more complex.
Platform and tooling can partially decouple architecture from organization. Internal developer platforms that provide shared capabilities through well-defined APIs allow teams to build on common foundations without tight coupling — effectively giving teams access to capabilities maintained by other teams without requiring ongoing coordination. Platforms partially escape Conway's Law by making cross-team capability access as easy as within-team capability access.
For related concepts, see systems thinking and complexity, how organizations make decisions, and first-order vs second-order effects.
References
- Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28-31. http://www.melconway.com/Home/Committees_Paper.html
- MacCormack, A., Rusnak, J., & Baldwin, C. Y. (2008). Exploring the Duality Between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis. Harvard Business School Working Paper 08-039.
- Nagappan, N., Murphy, B., & Basili, V. (2008). The Influence of Organizational Structure on Software Quality. Proceedings of the 30th International Conference on Software Engineering (ICSE). https://doi.org/10.1145/1368088.1368160
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
- Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. https://martinfowler.com/articles/microservices.html
- Fowler, M. (2015). Conway's Law. MartinFowler.com. https://martinfowler.com/bliki/ConwaysLaw.html
- Richardson, C. (2018). Microservices Patterns. Manning Publications.
- Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- DORA. (2019). 2019 Accelerate State of DevOps Report. Google Cloud.
- Highsmith, J. (2002). Agile Software Development Ecosystems. Addison-Wesley.
Frequently Asked Questions
What is Conway's Law?
Conway's Law states: 'Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.' Proposed by computer programmer Melvin Conway in a 1968 paper submitted to the Harvard Business Review. The core claim is that the boundaries in a software system correspond to the communication boundaries between the teams that built it.
Why does Conway's Law happen?
Software components must be designed to communicate with each other. The people designing each component communicate most intensively with others on their own team and less with people on other teams. Components designed by people who communicate frequently end up tightly integrated; components designed by people across team boundaries end up loosely coupled with explicit interfaces — mirroring the communication pattern.
What is the Inverse Conway Maneuver?
The Inverse Conway Maneuver turns the law into a design tool: if you want a particular software architecture, deliberately structure your organization to match it. If you want loosely coupled microservices, create small autonomous teams with clear ownership. If you want a platform with distinct API layers, organize your teams to have those boundaries. Popularized by James Lewis and Martin Fowler in discussions of microservices.
Has Conway's Law been empirically validated?
Yes. A 2008 Harvard Business School study by Alan MacCormack, John Rusnak, and Carliss Baldwin compared software modularity across open-source and commercial projects and found that organizational coupling predicted software coupling. Commercial products built by tightly coupled organizations had significantly less modular software architectures than open-source projects with distributed, loosely coupled contributor structures.
Does Conway's Law apply outside software?
Yes. The principle applies wherever complex systems are designed by teams: hardware products, organizational processes, bureaucratic procedures, websites, and even physical spaces show the fingerprints of the organizational structure that created them. Conway himself stated the law in general terms, not specific to software.
What are the practical implications for software teams?
Organizations should design their teams intentionally, knowing that team boundaries will become system boundaries. Creating a new team for a new service is not just an organizational decision — it is an architectural decision. Merging teams will tend to merge their systems. Splitting teams will tend to split their systems.