Conway’s Law

Experienced software architects typically resist general "laws" in software development. Good architecture is context-sensitive, tailored to trade-offs unique to each organization's circumstances. But there’s one principle that practitioners consistently acknowledge, respect, and wrestle with in every project I've encountered: Conway’s Law.

Melvin Conway famously expressed his insight as follows:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin Conway

At its heart, Conway’s Law says something profound yet intuitive: the software you build will inevitably mirror the structure of the team building it. If your team is divided into three separate groups, expect your software to naturally reflect those boundaries in its modular structure. Conversely, a tightly integrated team typically produces tightly integrated software.

I once observed a software architect on a project spanning multiple time zones say something that stuck with me: "My first architectural decision was figuring out how many teams we had. We had four teams across 3 continents (US, Europe and North Africa), so the system immediately became four distinct modules". He hadn’t decided on the modules themselves yet. But he recognized that communication friction, created by geographic separation, would inevitably become visible in the software's design.

Why does this happen? As my mentor and ex-boss Dr. Kurt Stirewalt  explained to me over a decade ago, “human communication enables software coupling”. When developers communicate frequently and informally, their software components grow interconnected because sharing information, assumptions, and understanding becomes easy. Conversely, when teams rarely speak, their software interfaces become more rigid, formal, and distant.

Ignoring Conway’s Law brings hidden costs. I’ve witnessed organizations attempt ambitious software designs that clashed directly with their organizational boundaries. Despite good intentions, these teams were quickly frustrated. The codebase began to reflect organizational silos rather than architectural intent. Design ideas that seemed elegant on paper turned into endless debates and workarounds as teams struggled against invisible barriers created by their own organizational charts.

Leaders facing this problem generally have three choices:

‍

1. Ignore Conway’s Law

Teams unaware of Conway’s Law stumble blindly into mismatches between their desired architecture and organizational structure. The result? Friction, frustration, and complexity.

‍

2. Accept Conway’s Law

Organizations that acknowledge Conway’s Law carefully align their architectural choices with their existing communication patterns. If your development team naturally separates into layers (frontend, backend, database), accept that your architecture likely will too.

‍

3. The Inverse Conway Maneuver

A more intentional approach, espoused by Thoughtworks, Martin Fowler and others, is known as the Inverse Conway Maneuver. It shapes development teams to intentionally influence software architecture. Want independent, loosely coupled modules? Structure your teams accordingly, making sure each team can independently own a business domain. Microservices teams widely adopt this strategy, forming small, autonomous teams to deliberately encourage small, autonomous services.

But beware: The Inverse Conway Maneuver isn’t magic. Reorganizing teams doesn’t immediately fix software architecture that's deeply embedded in code. Instead, changing team structure in established systems initially creates tension, as teams wrestle with software shaped by past communication patterns. Patience and incremental change become essential. Aligning code structure and team structure isn’t a one-time exercise; it’s a continuous balancing act.

Domain-Driven Design (DDD) complements Conway’s Law beautifully here. DDD encourages organizations to define clear boundaries—known as Bounded Contexts—around business domains, each with its own language and team. By deliberately structuring teams around these contexts, you align communication patterns and software boundaries naturally.

Ultimately, Conway’s Law teaches architects and leaders to respect the human foundations underlying software architecture. Technology, at its heart, is deeply human: our software designs reflect how effectively we talk, collaborate, and align as teams. Understanding Conway’s Law invites us to think beyond code, into team structures, communication patterns, and organizational design itself.

The next time you see complexity in software, don’t just look at the code, look closely at the teams behind it.