Conway’s Law Never Stopped Being True

What exactly did Melvin Conway claim in 1967?

Conway observed that organizations designing systems are constrained to produce architectures that mirror their own communication structures, and 57 years of evidence have only strengthened this observation.

The Harvard Business Review rejected Conway’s original paper. They found the claim too obvious to be interesting. This is perhaps the most fitting irony in the history of software engineering: the most consistently validated principle in system design was dismissed as trivially self-evident by people who did not build systems.

Conway’s insight was not merely that teams build what they know. It was deeper than that. He argued that the communication channels available to an organization become the channels available to its architecture. If two teams cannot easily talk to each other, the systems they build will not easily talk to each other either. The architecture does not just reflect the org chart. It reflects the actual flow of information, the hallway conversations, the Slack channels, the meetings that happen and the meetings that do not.

Why do architects keep rediscovering this law the hard way?

Architects rediscover Conway’s Law because the industry trains them to think about technology choices in isolation from organizational reality, as if systems exist in a vacuum of pure technical merit.

I watched a fintech company spend 18 months and $2.4 million building a microservices architecture. They had 4 development teams. They designed 23 services. Each service was supposed to be independently deployable, independently scalable, and owned by a single team. On paper, it was textbook.

In practice, 3 of the 4 teams needed to coordinate on every release because the service boundaries did not match the team boundaries. The payments team owned 7 services but needed changes in 4 services owned by other teams for every feature. The deployment pipeline required a 90-minute coordination call every Thursday. They had built a distributed monolith, which is a monolith with network latency and 23 deployment pipelines instead of 1.

The root cause was not technical incompetence. The engineers were skilled. The tooling was modern. The root cause was that they designed their service boundaries based on domain-driven design workshops that treated the organization as an abstract entity rather than a concrete collection of people who communicate in specific patterns. Conway’s Law does not care about your domain model. It cares about who talks to whom.

How does the “Inverse Conway Maneuver” attempt to use this law constructively?

The Inverse Conway Maneuver, popularized by Thoughtworks, proposes restructuring teams to match your desired architecture rather than accepting that architecture will mirror existing team structure.

This is the constructive response to Conway’s Law: if your architecture will inevitably mirror your organization, then design your organization to mirror the architecture you want. Amazon’s two-pizza teams are the canonical example. Jeff Bezos mandated that every team should be small enough to feed with two pizzas (roughly 6 to 8 people) and that teams should communicate through well-defined APIs. The organizational structure was designed to produce the architectural outcome.

The results speak in concrete numbers. Amazon went from deploying software every 11.6 seconds in 2015 to processing over 200 million deployments per year by 2023. Each team owns its services end-to-end, from development through operations. The organizational design produced the architectural outcome. Not the other way around.

But the Inverse Conway Maneuver has a prerequisite that most organizations ignore: it requires genuine organizational authority. You cannot restructure teams around desired architecture if the VP of Engineering has already organized teams around business functions, and the CTO has already committed to a platform architecture that assumes a different team topology. The maneuver works when architectural thinking and organizational design share the same decision-making table. In my experience across 14 enterprise clients, that alignment exists in fewer than 30% of organizations.

What does this mean for the practice of system design?

System design that ignores organizational structure is fiction writing, not engineering. The first artifact of any architecture effort should be a communication topology map, not a component diagram.

When I begin an architecture engagement, I spend the first 2 weeks mapping communication patterns. Not drawing boxes and arrows of desired systems, but observing actual human interactions. Who reviews whose pull requests. Which teams attend which standups. Where Slack channels go quiet for days and where they overflow with cross-team negotiation. This communication topology is the actual architecture of the system, regardless of what the documentation claims.

The Team Topologies framework, developed by Matthew Skelton and Manuel Pais, formalizes this insight into 4 fundamental team types: stream-aligned teams, enabling teams, complicated-subsystem teams, and platform teams. Each type has defined interaction modes: collaboration, X-as-a-Service, and facilitation. The framework’s core argument is that you must design team interactions before system interactions, because the former will determine the latter whether you plan for it or not.

I applied this framework to a healthcare SaaS company with 83 engineers in 2024. We identified that their 4 “independent” product teams all depended on a shared database team that had become a bottleneck. Every feature that touched the data layer required a ticket in the database team’s backlog, with an average wait time of 11 days. The architecture reflected this: a single PostgreSQL cluster with 340 tables and no clear ownership boundaries. Conway’s Law had produced exactly the architecture that the organizational structure predicted.

We restructured into 3 stream-aligned teams, each with embedded database expertise, and 1 platform team providing shared database tooling. Within 6 months, the average time from feature conception to deployment dropped from 34 days to 12 days. The architecture evolved naturally: each stream-aligned team migrated toward its own schema, with the platform team providing migration tooling and shared conventions. The system changed because the organization changed first.

Is Conway’s Law a constraint or a tool?

Conway’s Law is both a constraint and a tool, just as gravity is both the force that keeps you on the ground and the force that holds the planets in orbit. The difference is in whether you account for it or pretend it does not exist.

• Map before you model: Before drawing any architecture diagram, map the actual communication patterns in your organization. Use Slack analytics, PR review patterns, and meeting attendance data. The architecture you can actually build lives in this map, not in your whiteboard sessions.
• Align boundaries with autonomy: Service boundaries should match team boundaries. If a team cannot deploy its service without coordinating with another team, the boundary is in the wrong place. Redraw the boundary or restructure the team. Tolerating the mismatch produces the worst possible outcome.
• Budget for organizational change: Every architecture migration is also an organizational migration. If your project plan includes 6 months for technical work and 0 months for team restructuring, your plan is incomplete. I budget 30% of architecture engagement time for organizational design work.
• Accept the law’s jurisdiction: There are organizations that cannot restructure their teams. In those cases, design the architecture to match the teams you have, not the teams you wish you had. A well-designed monolith that matches your team structure will outperform a microservices architecture that fights it.

Conway’s Law is not a curiosity from the 1960s. It is the most reliable predictive model in software architecture. Every system I have seen fail at scale failed because someone believed they could design technology independently of the humans who would build and maintain it. Every system I have seen succeed at scale succeeded because someone understood that architecture is, at its foundation, a human endeavor shaped by human communication. The org chart is the first architectural diagram. Everything else follows from it.