TL;DR: Conway’s Law states that system architectures inevitably mimic the communication structures of the organizations that build them. If you do not actively design your team boundaries and communication paths, your software will default to a fragmented, inefficient reflection of your org chart rather than a clean, intentional technical design.
Whenever I look at a messy, fragmented codebase, I rarely see the result of poor technical skills. Instead, I see Conway's Law running on autopilot. It is easy to assume that a complex system of microservices was born from a highly calculated architectural design—but in my experience, it is usually just a mirror image of the organization's internal politics and communication gaps.
I like to think I design systems based on pure, logical principles like separation of concerns, high cohesion, or low coupling. But I've learned that the lines on an HR organizational chart have a far greater impact on system architecture than any design pattern or architectural framework I could ever choose.
What is Conway's Law and why does it affect software architecture?
In my view, Conway’s Law is the inevitable reality that an organization's software design will always mirror its internal communication paths. I find that teams naturally build software within their own boundaries, defaulting to integration points only where they are forced to interact with other teams.
To see this in action, imagine a scenario where a company is building an e-commerce platform. If there is a payments team, an orders team, and a warehouse logistics team, I can almost guarantee they will end up with three distinct microservices—one for payments, one for orders, and one for the warehouse.
This happens regardless of whether a three-service setup actually makes technical sense. I see developers build frictionless internal code because talking to their immediate teammates is easy. But because talking to other teams requires high-energy effort, they build rigid, often awkward boundaries. I call this the path of least organizational resistance.
How do team communication paths shape our technical boundaries?
I've observed that low-friction communication inside a single team leads to tight technical coupling, while high-friction communication between teams results in rigid API boundaries. When communication breaks down entirely, I usually see teams build redundant, "split-brain" services rather than collaborate.
I think of communication paths within a company as energy states. Talking to an immediate teammate is a low-energy path; you can send a quick Slack message or hop on a quick call. Communicating with another department is a high-energy path; it requires scheduling a meeting, aligning roadmaps, and navigating differing priorities.
When these communication paths are high-energy, I see teams avoid them entirely. Instead of working together to design a clean, shared service, I often see two separate teams build their own workarounds. This results in duplicate functionality or a "split-brain" service where a single database or application is pulled in two completely different directions.
| Communication Pattern | Resulting Software Architecture | The Architectural Risk |
|---|---|---|
| Siloed, independent functional teams (e.g., Payments, Inventory) | Hyper-fragmented microservices | Latency, data duplication, and "split-brain" integration issues |
| Cohesive, cross-functional product squads | Loose-coupled, domain-driven services | Overlapping domain boundaries if squads lack high-level alignment |
| Shared codebase with zero team-to-team communication | Monolith with spaghetti-like internal dependencies | Code conflicts, deployment bottlenecks, and ownership confusion |
How can you use the Inverse Conway Maneuver to design better systems?
I'm convinced that the secret to designing better systems is the Inverse Conway Maneuver, which means structuring your teams to match your target architecture. If I want a specific software design, I start by intentionally designing the communication channels and team boundaries first.
If I want a highly modular, decoupled service architecture, I know I cannot achieve it with a single giant engineering team where everyone works on everything. I would instead break the engineering group into smaller, focused teams that own distinct domains.
Conversely, if I need a shared service to remain cohesive, I make sure to establish strong, low-energy communication paths between the contributing teams. I might set up cross-team guilds or shared Slack channels to build those bridges. If I don't actively manage these paths, I know Conway's Law will step in and design the system for me.
Frequently Asked Questions
Can you avoid Conway's Law without changing team structures?
In my experience, no. You cannot bypass Conway's Law purely through technical guidelines or architectural mandates. If your team structures remain siloed, your software boundaries will eventually drift to match those silos, regardless of how many static architectural diagrams you draw on a whiteboard.
What is an example of a "split-brain" service in Conway's Law?
I define a split-brain scenario as one where two different teams are forced to share a single service but have weak communication paths. Instead of collaborating on a unified design, they build redundant, conflicting pathways within the same codebase, effectively creating two separate applications wrapped in a single deployable unit.
How does Domain-Driven Design (DDD) relate to Conway's Law?
I see DDD and Conway's Law as deeply linked through "Bounded Contexts." By defining your business domains first, you can align your engineering teams directly to those specific domains, ensuring that your team boundaries naturally produce clean, decoupled software boundaries.
Top comments (0)