Conway’s Law: Software Architecture Mirrors the Team That Builds It
Software architecture is a field deeply resistant to general laws. Yet there is one observation that commands near-universal respect: Conway’s Law. It is powerful enough to shape every system you work on, and ignoring it is a sure path to friction and rework.
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
Put simply, the architecture of a software system tends to look like the organizational chart of the team that built it. The classic illustration: a single team writing a compiler produces a one-pass compiler, while two teams produce a two-pass compiler. Although we usually discuss it in software terms, the observation applies to systems of all kinds.
Chris Ford, a colleague of ours, captured the underlying mechanism neatly: software coupling is enabled and encouraged by human communication. When you can talk easily to the author of some code, you build a richer understanding of it. That makes it easier for your code to interact with theirs, creating tight coupling. The effect goes beyond explicit function calls — it extends into shared assumptions and a common way of thinking about the problem domain.
When an architecture is designed at odds with the development organization’s structure, the strain shows up in the software. Module interactions that should be straightforward become tangled because the responsible teams don’t communicate well. Promising design alternatives are never even considered, because the relevant groups aren’t talking to each other.
When Conway’s Law Bites
For a team of a dozen or two people, informal and deep communication is natural — such teams will, predictably, produce a monolith, and that’s usually fine. The law only becomes a real force once the humans require formal organization.
One sharp technical leader learned this lesson the hard way. Newly made architect of a large project spanning six teams in cities around the world, he announced his first architectural decision: six major subsystems. He had no idea yet what they would be — but there were going to be six of them. He understood that geography, with its different time zones, is a fundamental constraint on communication. Components built across such distances need well-defined, limited interactions, by necessity of the humans who can’t chat casually.
Location is not the only factor. In a remote-first setting, Conway’s Law follows the online communication patterns instead, but time zones still exert a powerful influence on who talks to whom.
One of the most common violations of the law comes from activity-oriented team organizations. When teams are built around software layers (front-end, back-end, database), the resulting architecture mirrors that split, via a PresentationDomainDataLayering structure. This tends to be problematic because each feature needs close cooperation across all the layers. Splitting teams along lifecycle stages (analysis, design, coding, testing) is just as costly — a feature idea is subjected to a series of hand-offs before it ever reaches production.
The Inverse Conway Maneuver
Accepting Conway’s Law is better than fighting it, but there’s a more proactive stance: deliberately restructure the organization to encourage the architecture you want. This is the Inverse Conway Maneuver. It’s a common play in the world of microservices, where advocates suggest building small, long-lived BusinessCapabilityCentric teams, each housing all the skills needed to deliver customer value. Such autonomous teams naturally produce similarly autonomous services, able to evolve and deploy independently. In that sense, microservices are fundamentally a tool for organizing a development team, not just a technical pattern.
| Ignore | Don't take Conway's Law into account, because you've never heard of it, or you don't think it applies (narrator: it does) |
| Accept | Recognize the impact of Conway's Law, and ensure your architecture doesn't clash with designers' communication patterns. |
| Inverse Conway Maneuver | Change the communication patterns of the designers to encourage the desired software architecture. |
The maneuver is not a silver bullet. If you’re facing a longstanding system with an entrenched architecture, simply reshuffling the org chart won’t fix things. You’ll just end up with a new mismatch between developers and code, which only adds friction to future work. In that situation, Conway’s Law still matters — you need to account for the existing structure while you incrementally change both the code base and the team. Taking small steps and watching for feedback is sound practice.
Domain-Driven Design can point you toward sensible organization structures. A central DDD concept is the BoundedContext, which defines its own UbiquitousLanguage shared by the people within that context. These contexts naturally become a way to group people around a subject matter, aligning human boundaries with the flow of value.
The Key Move: Design Both Together
The essence of Conway’s Law is that you must consider the decomposition of the system and the decomposition of the development organization as a single, continuous act. This isn’t a decision you make once at project inception. Architecture and human organization must co-evolve for the entire life of an enterprise.
Budding architects would do well to study IT organization design as part of their craft. Two useful resources are Agile IT Organization Design by Sriram Narayan and Team Topologies by Matthew Skelton and Manuel Pais.
