Conway's Law
Defining and Describing Conway's Law
Conway's Law says that the shape of a system tends to mirror the communication structure of the organization that built it.[1][2]
- Conway’s Law is usually stated as: “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”[1][2]
- It applies when teams, departments, or reporting lines strongly influence software, products, and other designed systems.[1][2]
- The core idea matters because it explains why siloed communication often produces siloed architecture, and why changing team structure can change system design.[1][2][3]
Uses in Context
- In Software Architecture, the term is used to explain why team boundaries often become service boundaries or module boundaries in the resulting system.[1][2][5]
- In product design, it is invoked to warn that fragmented internal conversations can create fragmented user experiences.[6][1]
- In operating-model discussions, it is used to argue that organizational design should come before platform or AI design, because the system will reflect the organization that creates it.[3]
- In engineering management, it is used as a diagnostic for Organizational Silos, especially when cross-functional collaboration is weak.[6][2]
- In AI transformation discussions, it is used to suggest that AI outcomes depend as much on organizational structure and context as on model choice.[3]
- In practical software delivery advice, it is used to justify aligning teams around domains, creating shared decision processes, and reducing handoff friction.[5][6]
History of Use
Origins
- The term traces to computer scientist Melvin Conway’s 1968 paper “How Do Committees Invent?”, where the law was first articulated.[1][2]
- The original phrasing is commonly quoted as: “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”[1][2]
- Modern summaries describe it as a foundational observation about how organizational communication shapes technical design.[1][2]
Evolution
- 1968 — Conway’s original paper framed the idea in the context of committee-driven design and early computing organizations.[1][2]
- Later software-engineering usage — the idea was broadened from committees and large systems to everyday software architecture, team topology, and product organization.[1][2][6]
- 2020s AI and operating-model discourse — the law has been re-applied to platform strategy and AI transformation, with commentators arguing that “operating model matters more than the AI model itself.”[3]
Best Real-World Examples
- Microservices architecture — teams often split services along organizational boundaries, making architecture reflect communication patterns.[1][5]
- Enterprise website navigation — a “Shop / Learn / Support” structure can mirror sales, marketing, and support departments rather than user needs.[1]
- Product trio decision-making — product, tech, and design leaders are used to counteract fragmented ownership and reduce Conway-style drift.[6]
- Domain-aligned platform teams — AI and platform programs are increasingly organized around business domains so the system follows the operating model.[3][5]
- Siloed legacy organizations — rigid hierarchies often produce rigid systems with hard handoffs and low coherence.[2][6]
- Cross-functional product development — organizations that change communication patterns can change the resulting product shape.[4][6]
Case Studies
Conway’s original 1968 formulation is the root case study for the law itself. Melvin Conway introduced the idea in “How Do Committees Invent?” after observing that organizations building complex systems tend to produce designs that reflect their own communication structures.[1][2] The enduring significance of the paper is that it turned an organizational pattern into a design principle: the technical architecture is rarely independent of the human architecture behind it.[1][2]
A contemporary example appears in product and UX advice aimed at avoiding fragmented experiences. One article warns that if the organization is split into separate functions, the result can be a product whose interface and behavior feel equally split, because the system “mirrors” internal communication instead of user needs.[6][1] The practical lesson is that collaboration design is architecture design: if teams do not share context and decision-making, the product often inherits those seams.[6]
Recent AI-oriented commentary extends Conway’s Law beyond software decomposition to operating-model design. A Forrester piece argues that “your operating model matters more than the AI model itself,” then recommends starting with roles, workflows, governance, and context before choosing tools.[3] That interpretation shows how Conway’s Law has evolved into a broader management heuristic: when leaders redesign the human system first, they improve the odds that the technical system will be coherent, governable, and aligned to business domains.[3]