The pattern

You redraw the org chart. Six months later, the codebase has grown new seams along the new team boundaries. The teams reshaped the software without intent.

That pattern has a name: Conway’s Law. Any system you ship will reflect the communication structure of the people who built it. Modules align with teams. Interfaces form along reporting lines. Coordination friction shows up as code friction.

This matters because technical leaders keep treating organizational problems as technical problems. A microservice split fails when two teams still own a single service. A monorepo grows congested because four teams edit the same file. The architecture is doing exactly what the org chart told it to do.

What Conway’s Law says

Melvin Conway wrote it in 1968:

“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)

The unit of measure is communication, not headcount or reporting lines. Two engineers on different teams who pair regularly share a communication path. Two engineers on the same team who never speak do not. The org chart is a rough guide; the real driver is who talks about what with whom.

The consequence is a homomorphism, a structure-preserving map, between the social graph and the code graph:

graph TB subgraph Org["Teams"] T1[Alpha] T2[Beta] T3[Gamma] T1 <--> T2 T2 <--> T3 end subgraph Code["Modules"] M1[A] M2[B] M3[C] M1 <--> M2 M2 <--> M3 end T1 -.mirrors.-> M1 T2 -.mirrors.-> M2 T3 -.mirrors.-> M3 style T1 fill:#e1f5fe style T2 fill:#f3e5f5 style T3 fill:#e8f5e8 style M1 fill:#e1f5fe style M2 fill:#f3e5f5 style M3 fill:#e8f5e8

Each team’s communication boundary matches a module boundary. When teams communicate, their code interconnects; when isolated, their code stays separate.

Why Conway’s Law exists

Software records the decisions of people who can reach each other.

When two engineers can resolve a question in five minutes (same room, same Slack channel, same standup), they design code that crosses their boundary freely. They share types, call each other’s functions, and accept implicit contracts. The code reflects the cheap conversation.

When two engineers must schedule a meeting, file a ticket, or wait a day for a response, they design code that minimizes crossing. They define a strict interface and avoid touching each other’s internals. The code reflects the expensive conversation.

Architecture, then, is the residue of communication cost. The same forces that shape how a team works shape what it builds.

Communication paths wear ruts in a codebase the way footpaths wear ruts across a lawn. People walk where it is cheapest to walk; code grows where it is cheapest to write. The org chart hints at where the desired paths will form, and Conway’s Law says the code will follow them.

Remote teams often produce more modular code than co-located teams. Reaching a teammate across time zones costs enough to force clearer interfaces, and that cost is real architectural pressure.

How Conway’s Law works in practice

Three forces drive the alignment between team shape and code shape.

Ownership. Whoever maintains a module sets its boundaries. Splitting a module means deciding who owns each half. Most teams resolve that by drawing the boundary at the team line, the cheapest place for any seam.

Review and merge friction. Pull requests crossing team boundaries take longer to review, leading engineers to avoid those changes. Over time, this avoidance creates module walls. You can measure this directly in git history.

Cognitive load. Each team has a limit on the context it can hold. Modules exceeding that limit are reshaped, refactored, or split until they fit. The cognitive load cap determines module size.

Add the three, and the system converges on a structure matching the team graph, regardless of the architect’s whiteboard drawing.

How different org shapes predict different architectures

Different companies develop unique communication structures, as evidenced by their code. Manu Cornet’s sketch (Organizational Charts) depicts six, each indicating a distinct architectural style.

Amazon: strict hierarchy

graph TB A1[Leadership] A1 --> A2[Two-pizza team] A1 --> A3[Two-pizza team] A1 --> A4[Two-pizza team] style A1 fill:#fff3e0

Amazon’s tree predicts a service-per-team architecture: each small, two-pizza team (usually six to ten people) owns one end-to-end service with clear interfaces.

Google: overlapping matrix

graph TB G1[Leadership] G1 --> G2[Team] G1 --> G3[Team] G1 --> G4[Team] G2 <--> G3 G2 <--> G4 G3 <--> G4 style G1 fill:#e1f5fe

Google’s matrix predicts shared platforms with cross-cutting libraries, where teams share state laterally, resulting in shared libraries and platforms.

Facebook: peer network

graph TB F1[Team] <--> F2[Team] F2 <--> F3[Team] F3 <--> F1 F2 <--> F4[Team] style F1 fill:#f3e5f5 style F2 fill:#f3e5f5 style F3 fill:#f3e5f5 style F4 fill:#f3e5f5

Facebook’s peer network predicts a mesh of services that communicate freely without a central authority, leading to proliferating services talking to many neighbors.

The reverse holds as well. Show someone a codebase, and a skilled reader can sketch the org chart that produced it: where the meetings happen, where rivalries sit, and where silos draw walls.

Coordination bottlenecks and congested modules

Conway’s Law’s key diagnostic is congestion: a module many teams edit. Adam Tornhill’s CodeScene visualizes this with team commits overlayed on file paths. Congested files often predict bugs, delays, and outages.

graph TB T1[Team A] -->|edits| M[Shared Module] T2[Team B] -->|edits| M T3[Team C] -->|edits| M T4[Team D] -->|edits| M M --> X[Merge conflicts] M --> Y[Meetings] M --> Z[Slow delivery] style M fill:#ffebee style X fill:#ffebee style Y fill:#ffebee style Z fill:#ffebee style T1 fill:#e1f5fe style T2 fill:#f3e5f5 style T3 fill:#e8f5e8 style T4 fill:#fff3e0

Conway’s Law shows why patching modules fails: congestion from four teams sharing it. Splitting reduces contention; tests slow conflicts but don’t change the source. The real fix is organizational: assign clear ownership or realign team responsibilities with the existing structure.

Senior engineers learn to read git history because the commit log reveals the social graph hidden in file diffs.

The inverse Conway maneuver

If communication structure shapes code, designing it becomes architectural leverage. This is the inverse Conway maneuver: pick your architecture, then organize teams so their boundaries match.

A team that owns a service end-to-end creates a more cohesive product than one that shares it with others. Daily pairing with another team results in tightly coupled code across the boundary, regardless of the interface contracts.

The maneuver leverages Conway’s Law: the org chart shape determines the production outcome.

Skelton and Pais’s Team Topologies outlines four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes (collaboration, X-as-a-service, facilitating). Each combination reflects deliberate decisions about who interacts and how.

Trade-offs and limitations

Conway’s Law explains what happens but doesn’t tell you what to build. Treat it as a model with edges.

What it gets right

  • It predicts where modules will form, given the team graph.
  • It explains why pure technical refactors fail to dislodge organizational seams.
  • It directs leadership attention to team design as a primary architectural lever.

What it leaves out

  • Communication shapes code, but code also shapes communication. A monolith requires teams to coordinate despite independence, with feedback flowing both ways, and stable systems balancing these forces.
  • The org chart and the communication graph are different things. Two teams reporting to different vice presidents but sharing an architecture pair daily. Conway measured communication, using org charts as a starting hypothesis.
  • Conway’s Law leaves the right structure unspecified. Your code will include the chosen structure, but selecting the right one is a separate problem without a universal answer.
  • Time matters. Conway’s Law explains the lag between organizational changes and system architecture; teams often continue producing code reflecting old structures long after reorganization.

A different framing helps when these limits bite.

The Team Topologies counterpoint

Skelton and Pais view Conway’s Law as a deliberate tool, not a constraint. Their reframing:

  • Conway’s Law says: “Your software will look like your org.”
  • Team Topologies says: “Decide what your software should look like, then build the org that will produce it.”

Both views are valid. Conway’s Law explains what occurs; Team Topologies advises on action. Having only one leaves you fatalistic (Conway alone) or naive (Topologies without recognizing Conway’s significance). Wiring the Winning Organization makes a related argument from the delivery-systems side.

How GenAI changes the calculus

Conway’s Law persists in generative AI, which adds a new node to the communication graph and shifts the boundary-crossing costs. The homomorphism remains; only the inputs change.

Three shifts matter most.

The AI is a participant, not a tool. An engineer working with a large language model interacts with a system that has access to multiple teams’ code, either during training or retrieval. All engineers sharing the model have a partial communication link, making the team graph a hub connecting everyone.

Communication cost drops asymmetrically. Conway’s mechanism suggests crossing boundaries needs a meeting or ticket, but a language model with codebase context simplifies this. Engineers can understand and modify other teams’ code without direct communication, turning costly conversations into cheap queries, leading to tighter code coupling. Heavy reliance on AI may cause interfaces to evolve beyond organizational predictions.

Code drifts toward the model’s defaults. A team’s code reflected its mental model. AI also shows the training distribution. Public patterns get amplified, while unique domain patterns are smoothed out unless resisted. The homomorphism now includes communication structure and model bias.

The inverse Conway maneuver now involves granting a team’s coding assistant access only to that team’s services and to others’ documented APIs, making the model the new gatekeeper. It operates through the tooling layer instead of the org chart.

The risk is orphan-shaped modules: code that appears uncrafted by the team and resembles a generic model. When the code no longer reflects the team, Conway’s Law’s diagnostic power diminishes, and the organizational fingerprint disappears. Read AI-generated commits as carefully as human ones; without that signal, team friction is harder to detect.

Common misconceptions

“Conway’s Law is about the org chart.” Communication structure relies on reporting lines, which are often weak. Pair programming, shared channels, and informal mentorship foster stronger communication than formal hierarchy.

“Conway’s Law means microservices need siloed teams.” No. Service boundaries match team structure. Build teams accordingly: share databases for shared services, isolated teams for independent ones.

“You can ignore Conway’s Law if your architecture is well-designed.” A well-designed architecture that fights the org chart loses to it over time. The architecture either adapts or pulls the org with it; static designs on paper die.

“Inverse Conway is a one-time fix.” Team structures shift as people leave and projects merge, making Inverse Conway a continuous process. Reorgs are architecture decisions that require org reviews.

“Small teams always produce better architecture.” Smaller teams create smaller modules, usually desirable. However, the ideal team size depends on the work’s cognitive load. A two-person team handling complex tasks may generate fragile code, while a fifteen-person team managing simple tasks might produce bloated code.

Conclusion

Conway’s Law states that the structure of your communication reflects the structure of your software. Treat org design as architecture, as it is.

When the code feels wrong, check the org chart and commit log. Stubborn code often traces back to untouched seams in the org. Seeing the homomorphism reveals the lever.

Where to go next

Apply the theory:

Read further:

References

  • How Do Committees Invent?, Melvin Conway’s 1968 paper that introduced the homomorphism between organizations and the systems they produce.
  • Team Topologies, Matthew Skelton and Manuel Pais on the four team types and three interaction modes that let you steer Conway’s Law on purpose.
  • Organizational Charts, Manu Cornet’s sketch of Amazon, Google, Facebook, Microsoft, Apple, and Oracle org shapes and the architectures they imply.
  • CodeScene, Adam Tornhill’s tool for visualizing team-to-code alignment and detecting congested modules.
  • The Inverse Conway Maneuver, ThoughtWorks Technology Radar on using team design to steer architecture.