Conway's Law

⏱ 3 min  ·  📅 2026

Conway's Law is an observation made by Melvin Conway in 1967 which states that organizations that design systems are inevitably constrained to produce designs that are copies of the communication structures of those organizations. Put simply: software architecture tends to mirror the organizational structure of the team that builds it.

Conway published the observation in the article "How Do Committees Invent?" (1967). Fred Brooks popularized it by citing it in The Mythical Man-Month (1975), where he called it "Conway's Law."

Practical implications

If an organization has three backend teams, two frontend teams, and one QA team, the resulting system will tend to have three backend modules, two frontend modules, and a QA layer, reflecting the organizational boundaries even if this is not the technically optimal architecture.

The interfaces between system modules tend to correspond to the communication interfaces between teams: the points where communication is difficult or costly are the same points where technical integration is difficult or costly.

The Inverse Conway Maneuver

The practical consequence of Conway's Law for system design is what is known as the Inverse Conway Maneuver: instead of designing the system first and then organizing the teams to build it, you first design the team structure you want to have and let the system reflect that structure.

In the context of microservices and distributed architectures: if you want a system with independent, autonomously deployable services, you need teams organized so that they can operate with real autonomy over their services.

Relevance in agile scaling

Conway's Law is central to agile scaling frameworks. SAFe, Nexus, and LeSS propose specific team structures precisely because they recognize that the way teams are organized determines the architecture of the resulting system.

Common mistake

Trying to change the architecture without changing the organizational structure. Teams may agree on a new technical architecture, but if the way work and communication are organized does not change, the code will tend to gradually drift back to a structure that mirrors the actual organization. Architectural refactoring without organizational change is a never-ending battle against gravity.

References

• Conway, Melvin E. (1968). "How Do Committees Invent?". Datamation.

See also

Systems thinking Agile scaling models SAFe Nexus Technical agility Developer

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.

Search calls

Agile Club