Conway's law

Conway's law observes that organizations design systems whose structure mirrors the communication structure of the organization itself.

Melvin Conway stated the idea in the late 1960s: an organization that designs a system will produce a design that copies its own communication structure. People who talk every day build parts that fit together closely. Groups that rarely talk build parts with a formal interface between them, or parts that do not fit at all.

The practical reading is that architecture and team structure cannot be decided separately. If four teams work on one frontend, the code will tend to split into four areas, whatever the architecture diagram says.

Example

A company has a catalog team, a checkout team and an accounts team. All three commit to one frontend application with a single release every two weeks. Each team waits for the others, and a bug in checkout delays a catalog feature. The communication structure has three groups. The system structure is one block. Moving to three micro-frontends with a small shared shell aligns the system with the teams, and each team can release alone.

Common misunderstanding

Conway's law is sometimes used as a recipe: split the frontend and the organization will become autonomous. The causality usually runs the other way. Splitting the code without changing ownership produces a distributed monolith. Five repositories still have to be released together, because the same people coordinate every change.

The reverse case also happens. A single team adopts micro-frontends and ends up maintaining several pipelines and contracts with nobody on the other side.

The deliberate use of the law is sometimes called the inverse Conway maneuver: decide the architecture you want, then shape the teams and their responsibilities to match. Before choosing an architecture, draw the teams and how they communicate. The guide Rewrite, hybrid or micro-frontends uses team structure as one of its main criteria.

Related terms

• Micro-frontend
• Monorepo
• Polyrepo