Conway's Law

The Diagram Nobody Meant to Draw

A few years ago, I was coaching a platform team at a mid-size retailer. They were rebuilding their e-commerce system - a monolith-to-microservices migration, which is fancy talk for “we’re going to take this one big thing apart and put it back together as many small things.” Noble goal. Clear technical rationale.

Six months in, they had four microservices. The checkout service. The inventory service. The customer profile service. And the promotions service.

Here’s the thing - they also had four teams. The checkout team. The inventory team. The customer profile team. And the promotions team.

The services looked exactly like the teams. Not because someone had thoughtfully designed it that way. Because nobody could have designed it any other way. The communication boundaries between teams had become the API boundaries between services. The org chart had quietly drawn the architecture diagram while everyone was busy arguing about REST vs. GraphQL.

That’s Conway’s Law. And once you see it, you can’t unsee it.

Melvin Conway first described this phenomenon in a 1968 paper called “How Do Committees Invent?” published in Datamation magazine. The paper was actually rejected by Harvard Business Review before it found its home - which feels about right for a piece of writing that basically told every organization in America that their carefully planned system designs were actually just mirrors of their reporting structures. (Not exactly the kind of thing HBR’s editors wanted to hear in 1968.)

Conway’s original formulation: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” Fred Brooks later cited it in The Mythical Man-Month in 1975, giving it the name “Conway’s Law” and cementing its place in software engineering lore.

The Law That Ships Whether You Believe In It or Not

Conway’s Law is one of those rare ideas that’s simple to state, hard to internalize, and impossible to ignore once you understand what it means for how you organize teams. Let’s break it apart.

The Original Observation

Conway noticed something that feels obvious in retrospect but was genuinely radical at the time: the structure of a system reflects the structure of the organization that built it. Not metaphorically. Literally.

If three teams build a compiler, you get a three-pass compiler. If two groups in different buildings design a user interface, you get a user interface with two distinct - and probably inconsistent - interaction patterns. If the database team and the application team don’t talk to each other, the integration between the database and the application will be painful.

This isn’t a suggestion. It isn’t a tendency. It’s a force - as predictable as gravity and roughly as negotiable. You can fight it, but the system will drift back toward mirroring the org chart every time. The communication structure of the organization constrains the solution space. Teams can only design interfaces that reflect the communication paths available to them.

The word Conway used was “homomorphism” - a mathematical term meaning a structure-preserving mapping. The org structure maps onto the system structure, and the mapping preserves the shape. It’s not a loose analogy. It’s a structural correspondence.

The Homomorphic Force

So why does this happen? It’s not that people are lazy or unimaginative. It’s that communication has friction.

When two engineers sit in the same room, they can design a tightly integrated component. When two teams sit in different buildings - or different time zones - they negotiate contracts. APIs. Interfaces. Handoff documents. The more friction in the communication path, the more formal and rigid the boundaries become in the system.

This is the homomorphic force at work. Communication boundaries become system boundaries. Reporting lines become module lines. Budget silos become deployment silos. The architecture isn’t designed in a vacuum - it’s designed through conversations, and the conversations that happen easily produce tight coupling, while the conversations that happen with difficulty produce loose coupling.

(This is also why merging two companies’ software systems is so painful. You’re not just integrating code. You’re forcing two entirely different communication structures to produce a single coherent design. Good luck with that.)

The homomorphic force operates in both directions, too. Once a system architecture is established, it reinforces the organizational structure that created it. The team that owns the checkout service develops expertise in checkout. They hire checkout-shaped people. Their standup is about checkout. Their backlog is checkout. Changing the architecture now means changing the team - and changing the team means changing the architecture. They co-evolve, and they resist being pulled apart.

The Inverse Conway Maneuver

Here’s where Conway’s Law goes from interesting observation to powerful coaching tool.

If the org structure determines the system architecture - then you can deliberately structure your teams to get the architecture you want.

This is called the Inverse Conway Maneuver, a term coined by Jonny LeRoy and Matt Simons around 2010. Instead of letting the org chart accidentally dictate your architecture, you intentionally design your team structure to produce the system boundaries you need.

Want independently deployable microservices? Create autonomous teams with full ownership of their service, including their own data store. Want a cohesive platform layer? Put the platform engineers on the same team with shared goals and tight communication. Want a seamless customer experience across web and mobile? Don’t split the teams by technology - split them by customer journey.

The Inverse Conway Maneuver is essentially proactive organizational design. Instead of building teams and hoping for the best, you start with the target architecture and work backward to the team structure that will naturally produce it.

This sounds elegant on a whiteboard. In practice, it means having uncomfortable conversations with directors about reporting lines, budget allocation, and office seating arrangements. Architecture decisions are org decisions. Org decisions are architecture decisions. They were always the same decision - Conway just gave us the vocabulary to say so.

Modern Relevance

Conway wrote his paper when most software was built by committees in a single building. But the law has become more relevant, not less, as systems have grown more distributed.

The microservices movement is essentially an applied case study in Conway’s Law. The promise of microservices - small, independently deployable services with clear boundaries - maps directly to the promise of small, autonomous teams with clear ownership. The architecture and the org design are the same bet.

Matthew Skelton and Manuel Pais made this connection explicit in their 2019 book Team Topologies. They identified four fundamental team types - stream-aligned, enabling, complicated-subsystem, and platform - and argued that deliberately choosing these team shapes is how you get the system architecture you want. Team Topologies is, in many ways, Conway’s Law operationalized into a practical playbook.

Platform teams are a particularly vivid example. When organizations create a dedicated platform team to provide shared infrastructure, they’re making a Conway’s Law bet: by giving the platform its own team with its own communication structure, they’ll get a platform that behaves like a coherent product rather than a collection of shared libraries maintained by whoever had time last Tuesday.

Even the DevOps movement can be read through a Conway’s Law lens. The old model - separate dev and ops teams - produced systems with a hard boundary between “building it” and “running it.” The deployment handoff was painful because the communication path between dev and ops was painful. DevOps dissolves that boundary by putting development and operations capabilities on the same team. Conway would have predicted the result: systems that are easier to deploy, because the people who build them and the people who run them are now the same people.

What This Changes About Your Coaching

Conway’s Law isn’t a methodology. You can’t “implement” it. But once you understand it, it reshapes how you think about at least four things that agile coaches deal with constantly.

Team Structure Decisions

Every time someone proposes a new team structure, ask: “What architecture will this produce?”

Most reorgs are designed around people - who reports to whom, how to distribute headcount evenly, which manager gets which group. Conway’s Law says the more important question is: what system boundaries will these communication paths create?

I’ve watched organizations split a single product team into “front-end” and “back-end” teams and then wonder why every feature now requires cross-team coordination, a shared backlog, and an integration testing phase that takes longer than the development. Conway’s Law predicted exactly that outcome. The moment you split the team by technology layer, you created an architectural boundary between the front end and the back end. The system now has a seam where the team has a seam.

In my classes, I sometimes ask people to draw their org chart and their system architecture on the same whiteboard. The nervous laughter when the diagrams start overlapping tells me everything I need to know. Nobody planned for the two pictures to match. They just do. Conway’s Law is the friend who points out that your haircut looks exactly like your dog’s - technically helpful, but also a little uncomfortable.

Agile Transformations

Large-scale agile transformations almost always reorganize teams. SAFe creates Agile Release Trains. LeSS creates feature teams. Spotify-model adoptions create squads and tribes.

Conway’s Law says: whatever team structure you choose, you’re also choosing your system architecture. If your ARTs are organized by business capability, your systems will develop clean boundaries along those capabilities. If your ARTs are organized by technology layer, your systems will develop clean layers with messy cross-layer integration. The reorg and the re-architecture are the same project.

This is useful coaching ammunition when leaders want to “do agile” without touching the org chart. Conway’s Law explains why that doesn’t work. You can’t get a new architecture from the same old communication structure. The system will keep mirroring the org.

Cross-Team Dependencies

When teams complain about cross-team dependencies, the instinct is to improve the coordination mechanisms. Better Jira workflows. More sync meetings. Shared Slack channels. Integration sprints.

Conway’s Law suggests a different intervention: change the team boundaries so the dependency disappears. If Teams A and B are constantly blocked on each other, the architectural boundary between their components might be in the wrong place - which means the team boundary is in the wrong place. Moving two people from Team A to Team B (or merging the teams, or redrawing the ownership lines) might eliminate a dependency that no amount of process improvement could fix.

I know, I know - moving people between teams sounds politically expensive. It is. But it’s less expensive than six months of coordination overhead that nobody budgeted for. The Jira workflow you’re building to manage the dependency is a tax. The team restructure is a one-time cost that eliminates the tax. Conway’s Law doesn’t care about your feelings. It cares about communication paths.

Architecture Reviews

If you’re ever invited to an architecture review - and as a coach, you should be - bring Conway’s Law with you. Look at the system diagram. Then look at the org chart. Compare.

Where the two diagrams match, the architecture is stable. Where they don’t match, expect friction, rework, and slow delivery. A component owned by two teams will have inconsistent design. A service that spans three reporting lines will have three different ideas about what it should do. The architecture review is also an org review. They’re the same picture.

You don’t need to be a software architect to do this comparison. You need a whiteboard and the willingness to ask, “Who owns this?” If the answer is “well, sort of both teams,” you’ve found your next delivery bottleneck. (You’re welcome.)

What It Looks Like in the Room

Marcus had been a Scrum Master at a national retail chain for about eighteen months before they made him the agile coach for the digital commerce group. His first big assignment: figure out why the replatforming effort was nine months in and consistently missing its targets.

The replatforming was supposed to be straightforward - well, as straightforward as replacing a fifteen-year-old monolithic commerce platform can be. The new architecture was clean on paper. Five bounded contexts: catalog, pricing, cart, checkout, and fulfillment. Each would become an independent service. The architecture team had drawn beautiful diagrams. Leadership had approved the budget.

But the teams kept stepping on each other.

Marcus spent his first two weeks just observing. He sat in standups, refinements, and the weekly cross-team sync - which had earned the nickname “the apology meeting” because it mostly consisted of teams explaining why they were blocked on something another team owned.

The pattern crystallized during his third week. He pulled up the org chart and the target architecture side by side on his laptop and stared at them for a solid five minutes.

The org chart showed three teams. The “storefront” team handled everything customer-facing - product pages, search, and the shopping cart. The “transactions” team owned checkout and payment processing. The “operations” team handled inventory, fulfillment, and pricing.

The target architecture had five services. But the teams had three communication structures. So the actual system being built had - surprise - three natural boundaries, not five.

Catalog and cart were being built as one tightly coupled unit by the storefront team, even though the architecture called for them to be separate services. Pricing was being built by the operations team alongside fulfillment, inheriting fulfillment’s data model even though pricing had completely different scaling requirements. Checkout was clean - because it happened to map one-to-one onto a single team.

Marcus brought this to the engineering director with a simple visual. He’d printed both diagrams, drawn the team boundaries in red marker over the architecture diagram, and circled the mismatches.

“We designed five services,” he said. “But we have three teams. Conway’s Law says we’re going to get three services with some awkward internal boundaries. And that’s exactly what’s happening.”

The director’s first instinct was to add more coordination - a shared architectural review board, tighter cross-team standards, maybe a weekly architecture sync. Marcus pushed back gently.

“More coordination won’t change the communication structure,” he said. “If we want five independent services, we need five teams with independent ownership. Or - and this is worth considering - maybe five services is the wrong target and three is actually fine for where we are right now.”

(That second option - admitting the architecture should match the org you actually have rather than the org you wish you had - is the kind of pragmatism that makes Conway’s Law genuinely useful rather than just intellectually interesting.)

They landed somewhere in the middle. They split the storefront team into catalog and cart teams, each with a clear service boundary and its own deployment pipeline. They left pricing with the operations team for now but created an explicit interface contract that would make it separable later. Three teams became four, with a roadmap to five when the hiring plan allowed.

Within two sprints, the cross-team blocking issues dropped by about sixty percent. Not because the teams had gotten better at coordinating. Because there was less to coordinate. The team boundaries now matched the system boundaries, and the “apology meeting” quietly lost its nickname.

At the retro, Marcus drew Conway’s Law on the whiteboard in one sentence: “Your org chart is your architecture diagram - whether you planned it that way or not.” The engineering director took a photo of the whiteboard and sent it to the CTO.

Some laws you can debate. Conway’s Law just ships.

Go Deeper

• Conway, M.E. (1968). “How Do Committees Invent?” Datamation, April 1968. The original paper. Short, readable, and still startlingly relevant. Start here.

• Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. The modern operationalization of Conway’s Law into a practical team design framework. Essential reading for any coach working with engineering organizations.

• Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Chapter 7 explicitly cites Conway and explores the relationship between organization and architecture. The book that gave Conway’s observation its name.

• MacCormack, A., Rusnak, J. & Baldwin, C.Y. (2012). “Exploring the Duality between Product and Organizational Architectures.” Harvard Business School Working Paper. Empirical research validating Conway’s Law across multiple open-source and commercial software projects.

• Conway, M.E. melconway.com. Conway’s personal site, including the original paper and his reflections on how the law has been applied (and misapplied) over the decades.