Shaping Org Structure with Conway’s Law

The art of aligning teams to craft better architectures.

Created with the help of MidJourney

To read this story for free, click here.

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.
- Melvin Conway

This is Conway’s Law, an observation made by Melvin Conway in 1967. While often treated as an abstract principle, its real-world implications are deeply practical. If you’ve ever dealt with mismatched APIs, siloed systems, or over-complicated software, Conway’s Law has likely played a role.

But here’s the nuance: aligning team structure and system architecture involves tradeoffs. Every decision influences the software, for better or worse. This article explores these tradeoffs and how to approach them thoughtfully, using real-world examples to illustrate the impact.

Understanding Conway’s Law: A Quick Recap

Conway’s Law highlights the intimate relationship between team structures and the systems they create. It’s not about good or bad team configurations — it’s about cause and effect.

For example:

• Siloed teams lead to siloed software, often with poorly integrated components.