Conway’s Law

The structure of a system mirrors the communication structure of the organization that built it.

“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 – Conway’s Law predicts what architecture you’ll get based on your organizational structure.
• Boundary – team and agent boundaries become system boundaries.
• Module – module boundaries tend to align with team ownership boundaries.

Context

You’re building software with a team, or with several teams, or with a mix of humans and AI agents. You’ve made architectural decisions about how to decompose the system into modules and components. But the structure you end up with often looks less like your architecture diagrams and more like your org chart.

Conway’s Law names the force that links organizational structure to software structure, and it applies whether you’re aware of it or not. Melvin Conway published the observation in 1967. It has held up for nearly sixty years across every kind of software organization.

Problem

Why do systems keep ending up with architectures that reflect team boundaries rather than domain boundaries?

You can draw the cleanest architecture diagram in the world, but if three teams need to coordinate on a shared component, that component will develop three sets of assumptions, three styles of error handling, and three implicit contracts. The teams communicate through their code, and the code absorbs the shape of that communication. When two concerns are owned by the same team, those concerns tend to get tangled together even when they should be separate. The path of least resistance is direct function calls rather than defined interfaces.

This isn’t a failure of discipline. It’s a structural force. People (and agents) build the interfaces they need to communicate across, and skip the interfaces they don’t. The system’s boundaries end up wherever the communication boundaries are, regardless of where the design says they should be.

Forces

• Teams that communicate frequently produce tightly integrated code. Teams that rarely communicate produce code with clear boundaries between their respective parts.
• Formal architecture plans compete with informal communication paths. When the two disagree, the communication paths usually win.
• Splitting a system across teams forces explicit interfaces at team boundaries. This can be good (clear contracts) or bad (artificial seams that split what should be cohesive).
• Reorganizing teams is expensive and disruptive. So the architecture often outlasts the original organizational reasoning behind it.
• AI agents inherit this law. When you assign different agents to different parts of a system, their communication channels (shared files, tool outputs, message passing) shape the architecture just as human team boundaries do.

Solution

Treat your organizational structure as a first-class architectural input. If you want a particular software architecture, design your team structure to match it.

This works in two directions. The passive reading says: look at your org chart and you’ll see your architecture. The active reading, sometimes called the “inverse Conway maneuver,” says: decide on your target architecture first, then organize teams so their communication patterns naturally produce it. Want three independent services? Assign three teams with clear ownership boundaries and minimal cross-team dependencies. Want a tightly integrated system? Put the people working on it in close communication.

The same principle extends to bounded contexts. Eric Evans argued that context boundaries should follow team boundaries because a model’s consistency depends on the people maintaining it sharing a ubiquitous language. Conway’s Law explains why this works: the team’s communication structure reinforces the model’s coherence. When two teams own one model, the model drifts into incoherence because each team evolves its half independently.

For agentic workflows, Conway’s Law becomes an explicit design tool rather than a background force. When you configure a system of agents, you choose what each agent can see, what tools it has access to, and how it communicates with other agents. These choices are organizational design decisions. An agent with access only to the billing module’s code, tests, and domain glossary will produce billing-shaped work. An agent with access to everything will produce work that cuts across boundaries in ways that may or may not be what you want.

Multi-agent systems make this concrete. Set up a planning agent that communicates with an implementation agent through a spec file, and the resulting system will have a clean separation between planning artifacts and implementation code. Give one agent both responsibilities, and those concerns blend together in whatever way the agent finds convenient. The communication pathways you design between agents shape the software they produce.

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 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.

Consequences

Conway’s Law gives you both a diagnostic tool and a design lever. When the architecture doesn’t match what you intended, check whether the team structure explains the divergence. Often it does, and reorganizing teams (or agent responsibilities) is more effective than refactoring code while the organizational pressure remains unchanged.

The inverse Conway maneuver is powerful but not free. Reorganizing teams to match 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.

For agent systems, Conway’s Law offers clearer leverage than it does for human teams. 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. But poorly designed agent topologies produce architectural problems faster, because agents work faster than humans.

Over-isolation is the main risk. Restrict each agent to a narrow slice of the codebase with no visibility into neighboring concerns, and you get clean boundaries but lose the ability to make changes that genuinely span them. Cross-cutting concerns like logging, authentication, or error handling need some mechanism for coordination. The answer isn’t to abandon boundaries but to design the communication channels that cross them deliberately.

Related Patterns

• Uses / Depends on: Architecture – Conway’s Law predicts what architecture you’ll get based on your organizational structure.
• Uses / Depends on: Boundary – team and agent boundaries become system boundaries.
• Uses / Depends on: Module – module boundaries tend to align with team ownership boundaries.
• Enables: Bounded Context – Conway’s Law provides the organizational rationale for why bounded contexts should align with team structure.
• Enables: Separation of Concerns – team separation produces concern separation in the code.
• Enables: Subagent – dividing work among specialized agents is an organizational design decision that shapes the resulting architecture.
• Contrasts with: Monolith – a single team naturally produces a monolith; splitting teams creates pressure to split the system.
• Refines: Coupling – coupling across team boundaries is costlier than coupling within a team, so systems evolve to minimize cross-team coupling.
• Refines: Cohesion – code owned by a single team tends toward higher cohesion because the team shares context.

Sources

• Melvin Conway proposed the law in “How Do Committees Invent?” (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 (1975).
• Matthew Skelton and Manuel Pais built on Conway’s Law in Team Topologies (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 (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 (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.