Conway’s Law is usually quoted with the same grim fatalism people reserve for gravity or taxes: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” Most engineering teams treat this as a warning to avoid, a kind of organizational original sin that dooms your microservices to mirror your silos.
They’re reading it backwards. Conway wasn’t issuing a prohibition, he was describing physics. And physics can be engineered.
The Diagnosis: Your Org Chart Is Already Running Production
If you overlay your system’s dependency graph with your org chart, you’ll find the same pattern in almost every codebase: the strongest dependencies run within team boundaries. The weakest, and most problematic, run between them. Poorly defined interfaces, implicit behavior assumptions, uncoordinated API versioning, all of these are usually communication problems masquerading as architecture problems.
Marvin Richter, an architecture consultant who analyzes systems for a living, describes a case study that should chill every CTO: a system with three loosely coupled modules separated by unusually clean boundaries. No obvious business logic demanded this specific tripartite split. Then he looked at the org chart. Three teams. The module boundaries matched the team boundaries exactly, not because anyone planned it, but because teams that don’t communicate write code that doesn’t communicate.
This isn’t a bug. It’s a property of the universe. When three teams work on a monolith with minimal coordination, they inevitably carve out three modules with sharp edges along team lines. When one team owns frontend and backend, they build interfaces optimized for their own collaboration, not for external consistency.
The Inverse Conway Maneuver: Architecture by Org Design
If Conway’s Law is a prediction, you can invert it. Instead of designing the architecture and assigning teams to it, structure teams so their natural communication paths generate the system boundaries you actually want. This is the Inverse Conway Maneuver, deliberately restructuring your organization to produce the architecture you need.
Matthew Skelton and Manuel Pais formalized this approach in Team Topologies, identifying three fundamental patterns that turn Conway’s Law from an obstacle into a lever:
The model isn’t a reorg template, it’s a diagnostic tool. When a team is constantly waiting on another team, that’s a signal that the team boundary doesn’t match the system boundary. As research in behavioral neuroscience confirms, Team Topologies treats cognitive load as a hard design constraint, teams should be sized and shaped so they can understand, operate, and improve their part of the system without drowning in coordination overhead.
The Controversy: Flexibility vs. Reality
Here’s where the conversation gets spicy. Conway’s original 1968 paper didn’t end with the famous law. It continued: “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.”
Critics argue that the Inverse Conway Maneuver is too rigid, structuring teams for current boundaries prevents adaptation when those boundaries inevitably shift. Organizations should explicitly decouple org structure from architecture, or they’ll change the former too often and the latter not often enough.
But this assumes organizational flexibility exists. In reality, across most companies, flexibility is almost nonexistent. While it would be optimal to adopt designs decoupled from organizational constraints, it’s actually more functional to embrace the organizational structure when designing systems. Strong boundaries at the team and org level, with single owners for each system part that align with the org structure, prove more sustainable than perfectly architected systems that fight the organizational gravity.
The counter-argument is that culture, not structure, determines outcomes. You can have the right team topologies and still ship a distributed ball of mud if your culture is a “low-awareness feature factory” optimized for velocity over thoughtfulness. Conway’s Law describes communication structures, but culture determines what those communications actually contain. Without clear ownership of interface boundaries, organizations used to handoffs and rigid hierarchies will struggle more than flat, “let’s get it done” cultures, regardless of how you draw the boxes.
The AI Disruption: When Two-Pizza Teams Become Two-Person Teams
The Inverse Conway Maneuver is facing its biggest stress test yet. As Jennifer Riggins explores in LeadDev, agentic AI is collapsing the assumptions behind traditional team sizing. When Claude Code or Cursor can handle delivery, the constraint shifts from writing code to making decisions.
Corey Latislaw, head of groceries and new verticals at Just Eat Takeaway.com, has radically restructured teams into “one product manager + one developer + agent swarms.” The PM holds intent and outcomes. The developer holds architecture and judgment. The agents handle delivery. This isn’t just smaller teams, it’s a different topology entirely, one where how AI tools influence architectural decisions becomes the primary design concern.
Manuel Pais, co-author of Team Topologies, notes that enabling and platform patterns remain fundamental, but their nature changes. Enabling becomes governance, guardrails for agentic squads embedded in platforms that reduce the drift ungoverned AI creates. The platform team ships AI as a service: approved models, shared prompt templates, retrieval over trusted sources, with clear observability and escalation paths when outputs conflict with reality.
Case Study: Anthropic’s Platform Play
Anthropic provided a masterclass in the Inverse Conway Maneuver over 90 days earlier this year. They shipped Claude Code, launched Channels, introduced Co-Work, opened a Marketplace, and formalized a partner network. Rather than scattered product launches, this was deliberate organizational restructuring to produce a platform architecture.
By restructuring toward platform organization, dedicated teams for Code, Co-Work, Marketplace, and partnerships, Anthropic ensured their org chart and product map aligned. When a company’s organizational structure mirrors the system it’s building, products don’t get orphaned or deprioritized. Each piece reinforces the others: infrastructure control (Claude Code), collaboration control (Co-Work), and distribution control (Marketplace).
This is the inverse Conway maneuver at corporate scale: restructuring teams to produce the architecture you want, rather than accepting the architecture your existing structure produces.
How to Actually Do This Without Getting Fired
If you walk into your next leadership meeting proposing a reorg based on “Conway’s Law optimization”, prepare to be ignored. The social aspect of software is massive, but framing it as an abstract law triggers organizational immune responses.
Instead, treat it as a diagnostic exercise:
- Map the pain: Document where teams wait on other teams. These friction points aren’t coordination problems, they’re boundary mismatches.
- Measure cognitive load: Research shows that cognitive overload impairs decision-making and increases risk aversion. If your teams are drowning in coordination, they can’t make good architectural decisions.
- Align ownership with boundaries: Ensure each service or module has a single team owner that matches your org structure. Don’t fight the current, channel it.
- Build for the org you have, not the org you want: While flexibility is theoretically optimal, organizational redesign for engineering efficiency must account for actual organizational inertia. Design systems that align with existing communication paths, then evolve the structure deliberately.
- Use AI to reduce extraneous load: Deploy AI tools to handle the “extraneous cognitive load”, dependency thrash, unclear decision rights, meeting overload, so teams can focus on intrinsic complexity.
The Physics Are Non-Negotiable
Conway’s Law isn’t a suggestion to work around. It’s a property of human organizations building complex systems. You can ignore it and watch your architecture fragment along invisible fault lines of communication, or you can wield it deliberately.
The Inverse Conway Maneuver doesn’t guarantee perfect architecture. But it guarantees that your architecture failures will be visible, owned, and fixable, rather than hidden in the gaps between teams that never talk. In an era where AI agents are rewriting the economics of software development, the constraint isn’t code, it’s coordination. Structure your teams accordingly.
