How Conway’s Law Shapes Your System Architecture and Team Structure

Conway’s Law

Conway’s Law, proposed by Melvin Conway in 1967, states that the architecture of a system mirrors the communication structure of the organization that designs it. In other words, a product is a reflection of its people’s communication patterns.

First Law

Communication dictates design.

Cross‑department communication is difficult, and system interfaces reflect information flow and collaboration. The communication cost grows quadratically with team size: n(n‑1)/2. For example, a 5‑person team has 10 communication channels, a 15‑person team 105, a 50‑person team 1,225, and a 150‑person team 11,175.

This explains why many internet companies prefer small teams: fewer communication channels lead to more efficient system design and development.

Second Law

There is never enough time to do something right, but there is always enough time to do it over.

Resources are never sufficient and work is never finished, but tasks can be tackled one by one. Agile development addresses this by enabling continuous iteration, delivery, rapid feedback, and improvement. No development can eliminate all bugs; instead, designs should tolerate some issues and allow quick resolution through redundancy, monitoring, and high‑availability strategies.

Third Law

There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

This law applies the first law concretely: if a company’s organization is distributed with product, development, testing, and operations roles in each team, but the system is monolithic, coordination costs become huge. Splitting the monolith into microservices lets each team own its part and expose interfaces, improving efficiency and aligning with high cohesion and low coupling principles.

Fourth Law

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.

As systems grow, more personnel are needed, and communication costs rise exponentially. Decomposition—splitting large systems into smaller, autonomous teams—is a common solution, allowing internal self‑management while maintaining unified external communication.

Conclusion

Architecture is not only technical; in large organizations it also involves politics. Technical decisions are political decisions, and successful architecture requires navigating collaboration, organizational structure, and communication dynamics.