Conway's Law

Melvin Conway's observation that organizations design systems that mirror their communication structures. A company with four development teams will produce a four-module system. A siloed organization produces siloed software. The insight runs deeper than organizational charts: the architecture of any complex product reflects the social architecture that produced it, because the boundaries of human communication become the boundaries of technical components. Conway's Law is both descriptive (explaining existing architecture) and prescriptive (design teams to mirror the architecture you want).

When to use it

When system architecture doesn't match desired product architecture; when organizational restructuring and system redesign need to happen together; when technical debt persists despite engineering effort (the organizational structure may be the root cause); when designing teams for new products and want to influence the resulting architecture.

How it can help

Use Conway's Law as a design tool: if you want a specific system architecture, organize your teams to mirror it. Want a modular product? Create independent, modular teams. Want an integrated experience? Create cross-functional, integrated teams. The reverse application: when diagnosing why a system has a particular architecture (often a dysfunctional one), look at the organizational structure that produced it. Technical debt often reflects organizational debt—the system can't be cleaner than the organization that built it.