← Patterns

Conway's Law

Core Concept

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Your software architecture mirrors your org chart. If three teams build a compiler, you get a three-pass compiler. This isn’t a choice — it’s a force of nature.

Where It Applies

Team Structure → Code Structure

If you want a microservices architecture, you need small, autonomous teams. If you have one big team, you’ll get one big monolith — no matter what the architecture diagram says.

The Inverse Conway Maneuver

Deliberately structure teams to produce the architecture you want. This is one of the most powerful tools a VPE has. Want loosely coupled services? Create loosely coupled teams.

Stage/Pipeline Boundaries

Stage boundaries should align with natural decision boundaries, not organizational convenience. Architecture is a separate stage from implementation because they’re genuinely different decisions.

The OrangeQC Lesson

The siloed agency model (Thoughtbot on Rails, Foxbox on Android, Hugo on iOS) produced siloed products with no shared conventions. The communication structure was the architecture.

The Insight for Leaders

You can’t fix architecture without fixing org structure. If two teams don’t talk, their systems won’t integrate well — no amount of documentation or API specs will overcome the communication gap.

Cross-References

• Software-Laws — hub for all seven laws and how they interact
• Postel’s Law — Conway says boundaries shape systems, Postel says be tolerant across boundaries. Together: draw boundaries carefully, but don’t couple tightly across them.
• Chesterton’s Fence — Conway hides constraints behind boundaries; if a boundary hides a fence, someone will unknowingly tear it down