--- slug: conways-law type: concept summary: "A system's structure mirrors the communication structure of the organization that built it, revealing the org chart hiding inside the architecture." created: 2026-04-05 updated: 2026-05-23 related: architecture: relation: uses note: "Conway's Law predicts what architecture you'll get based on your organizational structure." boundary: relation: uses note: "Team and agent boundaries become system boundaries." bounded-context: relation: enables note: "Conway's Law provides the organizational rationale for why bounded contexts should align with team structure." business-capability: relation: enabled-by note: "Aligning team boundaries to capability boundaries shapes the resulting architecture." cohesion: relation: refines note: "Code owned by a single team tends toward higher cohesion because the team shares context." coupling: relation: refines note: "Coupling across team boundaries is costlier than coupling within a team, so systems evolve to minimize cross-team coupling." enabling-team: relation: informs note: "The communication patterns between the enabling team and the stream-aligned team are deliberately temporary. The enabling team dissolves the coupling after knowledge transfer, unlike a permanent dependency that would shape the architecture." inverse-conway-maneuver: relation: depended-on-by note: "The Inverse Conway Maneuver is the active application of Conway's Law. Without understanding the passive force, the maneuver doesn't make sense." module: relation: uses note: "Module boundaries tend to align with team ownership boundaries." monolith: relation: contrasts-with note: "A single team naturally produces a monolith; splitting teams creates pressure to split the system." ownership: relation: depended-on-by note: "Ownership boundaries become architectural boundaries; unowned code sits in the cracks between teams." platform-as-a-product: relation: informs note: "The interface between platform team and stream-aligned teams shapes the architecture. A self-service API produces a clean integration boundary. A ticket queue produces a human bottleneck." separation-of-concerns: relation: enables note: "Team separation produces concern separation in the code." stream-aligned-team: relation: depended-on-by note: "Stream alignment is the inverse Conway maneuver applied: organize teams around the architecture you want, and the system structure follows." subagent: relation: enables note: "Dividing work among specialized agents is an organizational design decision that shapes the resulting architecture." team-cognitive-load: relation: depended-on-by note: "Conway's Law predicts what architecture you'll get; cognitive load explains why teams produce architectures that match their communication structures." --- # Conway's Law *The structure of a system mirrors the communication structure of the organization that built it, and the phrase is what lets a team see the org chart hiding inside the architecture.* > **Concept** > > Vocabulary that names a phenomenon. > "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." > — Melvin Conway, 1967 ## Understand This First - [Architecture](architecture.md) — Conway's Law predicts what architecture you'll get based on your organizational structure. - [Boundary](boundary.md) — team and agent boundaries become system boundaries. - [Module](module.md) — module boundaries tend to align with team ownership boundaries. ## What It Is Conway's Law is the name for a structural force: the shape of a system tends to copy the shape of the communication paths between the people (and now the agents) who build it. Two parts of a system that need to talk to each other end up with an interface between them wherever the humans owning those parts had to coordinate. Two parts that almost never need to coordinate end up cleanly separated, sometimes more cleanly than the architecture diagram demanded. The force runs in the background of every design decision. The phrase is what makes it visible. Melvin Conway published the observation in 1967 ("How Do Committees Invent?") after watching the same effect happen at organizations he'd consulted for. Fred Brooks named it Conway's Law in *The Mythical Man-Month* in 1975, and the name stuck. The claim has held up for nearly sixty years across every kind of software organization: startups, banks, research labs, open-source projects, and now teams of humans working alongside AI agents. The phenomenon has two readings, both useful, and the vocabulary admits both. - **The passive reading.** If you want to know what the system actually looks like, look at how the people who built it actually communicate. The org chart is a forecast; the communication network is the architecture. When the two disagree (and they usually do), the network wins. - **The active reading, sometimes called the *inverse Conway maneuver*.** If you want a particular architecture, design the team structure (or agent topology) so that its communication paths produce that architecture as a side effect. The shape of the org becomes a lever, not just a description. Conway's Law isn't a rule someone enforces. It's a regularity that emerges whether anyone is paying attention. A team that hasn't named it will still be subject to it. A team that has named it can start to design around it. In agentic-coding terms, the same force applies to systems of agents. Each agent's access boundaries, tool permissions, and communication channels become the joints in the architecture the agents produce. The actors are different; the law is the same. ## Why It Matters A team without the phrase explains each instance one at a time. "The payment service grew weird seams because the platform team and the payments team kept passing the ticket back and forth." "Our notification module ended up split because two squads were both touching it." "The agents we set up for the migration somehow produced a backend that mirrors the way we drew their boxes in the kickoff." A team with the phrase recognizes the same force underneath all three stories and stops treating them as unrelated mishaps. Naming the force is what makes it designable. The most common misreading of an architecture-versus-org-chart mismatch is that the *architecture* is wrong and needs refactoring. Sometimes that's true. Often the architecture is fine and the organization is what's producing the drift; refactoring the code without changing the communication pattern just re-creates the same drift in slightly different shape. Conway's Law gives a team the diagnostic ("look at the org chart before you blame the code") and the lever ("change the communication pattern if you want the code to change"). The vocabulary also bounds two related but distinct ideas. Conway's Law is the passive observation that org structure becomes system structure; the inverse Conway maneuver is the active practice of choosing org structure to produce a target system structure. Confusing them is what makes an "inverse Conway" project go wrong: the team reorganizes without first knowing the architecture they want, and ends up with a new shape that's just as misaligned as the old one. For agentic workflows the diagnostic urgency is higher. Agent topologies (who talks to whom, what each agent can see, where the handoff files live) are organizational design decisions, and they're cheap to change. A team that doesn't have Conway's Law in its working vocabulary will treat the resulting architectural drift as a code-quality problem and try to fix it in the code. A team that does have the vocabulary will look at the topology first. ## How to Recognize It You're looking at Conway's Law in action when the architecture and the org chart line up too well to be a coincidence. A few concrete signs: - **The architecture diagram looks like the org chart.** Each microservice corresponds to a team, and each team owns roughly one service. Sometimes deliberate; often not. - **Shared components grow inconsistent internals.** A library or service touched by multiple teams develops several styles of error handling, several flavors of logging, and several implicit contracts — one per team — even though it's nominally one component. - **Reorganizations leak into the code months later.** A team split or merge eventually shows up as new seams, abandoned modules, or duplicated functionality. The architecture is catching up to the org chart that's already changed. - **The release schedule mirrors team meetings.** Components that "should" be independent end up shipping together because the teams owning them coordinate at the same standup. - **Cross-team interfaces are sharper than within-team interfaces.** Within a team, modules call into each other freely. Between teams, there's a defined API, a queue, or a ticket process — because that's the only place the communication friction was high enough to force an interface to exist. - **The seams move when the people move.** A long-tenured engineer who informally bridged two teams leaves, and a year later the two parts of the system they connected start drifting apart. - **Agent topologies show up in the artifacts.** A planner agent and an implementation agent that communicate through a spec file produce a codebase with a clean spec/implementation split. A single agent given both jobs produces work where those concerns blur. The artifact mirrors the topology. Conway's Law also surfaces in the *absence* of seams. Code that "belongs to everyone" inside one team tends to be tangled (direct calls, shared mutable state, implicit invariants) because the team never had to negotiate an interface to talk to itself. That tangle is not a discipline failure; it's the same law operating in the other direction. A monolith built by one tight team isn't a mistake; it's what the communication structure produced. > **💡 Tip** > > The honest test for Conway's Law in your own system: redraw the dependency graph and label each edge with which teams (or agents) had to talk to make that edge work. The labels will trace your communication structure, not your design intent. ## How It Plays Out A startup has one engineering team building an e-commerce platform. The codebase is a monolith: catalog, ordering, payments, and shipping all share the same repository and database. The team communicates constantly, and the code reflects that closeness. Functions in the ordering module call directly into payment internals. Catalog queries join against shipping tables. It works while the team is small. The company grows and splits into four teams. Within six months, the ordering team's changes break payment tests. The catalog team waits days for shipping to review a shared-table migration. Management decides to extract microservices, drawing the service boundaries along team lines. Each team gets its own service, its own database, and a defined API. The architecture didn't change because someone read a book about microservices. It changed because the communication structure changed, and the code followed. A platform team and a product team negotiate the interface between them once, formally, at the start of a quarter. For the rest of the quarter, the interface between the *components* they own (what calls reach across, what schema is shared, what error codes leak) is the interface between the *teams*. When the platform team later restructures into a smaller core group plus a "platform-as-product" enablement function, the component interface inherits the new shape within a release or two. Nobody asked it to. The architecture is keeping pace with the org chart in the background. A development team sets up three specialized agents: one for backend API work, one for frontend components, and one for database migrations. Each agent has its own tool access, its own subset of the codebase, and its own instruction file. They communicate through a shared task queue where the backend agent can request a migration from the database agent. After a month of operation, the codebase has clean separation between layers, with well-defined contracts at the boundaries. The team didn't enforce this through code review. The agent communication structure produced it naturally. > **💡 Example Prompt** > > "You are the backend API agent. Your workspace is src/api/ and src/shared/types/. You don't modify files outside these directories. When you need a database schema change, write a migration request to tasks/migration-requests/ with the table name, the change needed, and the reason. The database agent will pick it up." ## Consequences When a team has the vocabulary of Conway's Law and uses it deliberately, two things change. The architecture diagram stops being read as a wishful drawing of how things ought to be, and starts being read as a forecast that needs to be checked against the actual communication network. And the org chart stops being treated as a separate concern from the technical decisions; reorganizing teams becomes a recognized design move, on par with choosing a database or a deployment topology. The honest tradeoffs are worth naming. - **The maneuver isn't free.** The inverse Conway maneuver — choosing team structure to produce a target architecture — requires that you know what architecture you want and that the organization is willing to restructure around it. Both are hard. In practice, many teams discover their architecture through Conway's Law rather than designing it in advance, and then rationalize the result. - **Over-isolation is a real failure mode.** Restricting each team (or each agent) to a narrow slice of the system with no visibility into neighboring concerns produces clean boundaries but loses the ability to make changes that genuinely span them. Cross-cutting concerns like logging, authentication, or error handling still need some mechanism for coordination. The answer isn't to abandon boundaries but to design the communication channels that cross them deliberately. - **The architecture outlasts the org.** Teams reorganize on quarterly or yearly cycles. Software changes faster but ossifies harder; once a system has absorbed the shape of one organization, it can carry that shape into a successor organization for years. Many "weird seams" in old codebases are fossils of org structures that no longer exist. - **Agent topologies are unusually plastic, in both directions.** Agent communication structures are explicit and configurable. You don't need to move desks or change reporting lines. You change a configuration file, an instruction prompt, or a tool access list. The inverse Conway maneuver is cheaper to execute with agents, and so is its mirror. A poorly designed agent topology produces architectural problems faster than a poorly designed human org, because agents work faster than humans. The goal isn't to obey Conway's Law or to fight it. The goal is to see it operating, decide whether the shape it's producing is the shape you want, and pick the cheaper of two interventions when the answer is no: change the code, or change the communication structure. ## Sources - Melvin Conway proposed the law in "[How Do Committees Invent?](https://www.melconway.com/Home/Committees_Paper.html)" (*Datamation*, April 1968), arguing that system design is constrained to reflect the communication structure of the organization that produces it. The observation was later named "Conway's Law" by Fred Brooks in *[The Mythical Man-Month](https://openlibrary.org/works/OL3510570W)* (1975). - Matthew Skelton and Manuel Pais built on Conway's Law in *[Team Topologies](https://teamtopologies.com/book)* (2019), introducing the concept of team cognitive load and arguing that team boundaries should be deliberately designed to produce the desired architecture — the "inverse Conway maneuver" in practice. - Eric Evans connected organizational boundaries to model boundaries in *[Domain-Driven Design](https://www.domainlanguage.com/ddd/)* (2003), showing that bounded contexts work because they align model consistency with team communication, which is Conway's Law applied to domain modeling. ## Further Reading - James Lewis and Martin Fowler discuss the inverse Conway maneuver in the context of microservices in their [Microservices article](https://martinfowler.com/articles/microservices.html) (2014) — the clearest practical explanation of using Conway's Law as a design tool rather than a constraint. - Ruth Malan and Dana Bredemeyer, "What Every Software Architect Should Know About Conway's Law" — explores the recursive relationship between architecture and organization, including how Conway's Law applies at multiple scales simultaneously. --- - [Next: Team Cognitive Load](team-cognitive-load.md) - [Previous: Socio-Technical Systems](socio-technical-systems.md)