What It Says

In 1967, Melvin Conway submitted a paper to the Harvard Business Review. It was rejected. He published it elsewhere, largely unnoticed, and went back to work. Decades later, Fred Brooks cited it in The Mythical Man-Month, and the observation became one of the most empirically validated - and most routinely ignored - ideas in software engineering.

Conway's Law states:

"Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure."

Read that again. Not "tends to produce." Not "often produces." Will produce. Conway was not making a probabilistic observation. He was describing a constraint - one as real as any technical constraint you've ever worked around.

The mechanism is straightforward. When people design systems, they make decisions by talking to each other. Who they talk to is determined by org structure, reporting lines, team boundaries, and proximity. The interfaces in the resulting system therefore reflect the interfaces - formal and informal - between teams. Where there is no communication, there is no integration. Where communication is difficult, the interface is poorly defined or negotiated at arm's length. Where communication is easy and frequent, the interface is rich and well-understood.

This is not a metaphor. It is a structural consequence of how design decisions are made by groups of human beings.

Why It Matters More Than Most Leaders Realise

Most leaders who have heard of Conway's Law treat it as a curiosity - an interesting observation from the 1960s that gets cited in conference talks. They understand it abstractly. They do not understand it operationally.

Here is what it means in practice:

Your architecture is already determined by your org structure - before a single line of code is written.

If your organisation has three divisions - one for the web front end, one for back-end services, and one for data - your system will have three layers with poorly-defined contracts between them. Not because your engineers are bad. Because the people who own each layer don't talk to the people who own the adjacent layers often enough to build anything else.

If your security team is separate from your engineering teams - a centralised function that reviews designs at the end - your security will be bolted on, not built in. The architecture will reflect the organisational distance between those two groups.

If your database team is a shared service, every team that needs database access will create a ticket, wait, receive a schema they didn't design, and work around its limitations. The data model will reflect the bottleneck, not the domain.

The compounding effect is where it becomes dangerous.

Org structure shapes architecture. Architecture shapes what's easy and what's hard. What's easy and what's hard shapes how the organisation evolves. As the system grows, it becomes increasingly expensive to change the architecture - and since the architecture is coupled to the org structure, it becomes increasingly expensive to change the org structure too. You end up with an organisation and a system that are mutually reinforcing and mutually constraining.

Teams that have always owned separate things continue to own separate things, because the system has evolved to assume they will. Interfaces that were always poorly defined remain poorly defined, because neither team has the mandate or the incentive to fix them. Technical debt and organisational debt accumulate in parallel, and they compound together.

By the time this becomes visible - when delivery is painfully slow, when every change requires six teams to coordinate, when you can't release without a two-week regression cycle - the structural causes are years old and deeply embedded. The people in the organisation often don't even see them. They think the problem is the technology. Or the process. Or the people.

It is the structure.

The Inverse Conway Manoeuvre

If Conway's Law is a constraint, it is also a lever.

The Inverse Conway Manoeuvre - a term introduced by Jonny LeRoy and Matt Simons, later popularised by the Team Topologies work of Matthew Skelton and Manuel Pais - is the deliberate application of Conway's Law in reverse.

The standard direction of causality is: org structure → communication patterns → system architecture.

The Inverse Conway Manoeuvre reverses it: desired system architecture → required communication patterns → target org structure.

If you want a microservices architecture, you need teams that can own and operate individual services end-to-end, with well-defined APIs between them. If you design the org first - decompose the teams the way you want to decompose the system - the communication patterns will follow, and the architecture will follow from that.

This sounds obvious. It almost never happens in practice. Why? Because most architectural decisions are made by architects or technical leads, and most organisational decisions are made by line managers or HR business partners. These two groups rarely speak to each other before either decision is made. The architect proposes a target state for the system without asking whether the org can support it. The manager restructures teams without asking what the architectural consequences will be.

The Inverse Conway Manoeuvre requires that you treat org design and architecture design as the same problem, handled by the same people, at the same time. That is a significant change in how most organisations operate. It is also the only reliable way to get the architecture you actually want.

What It Looks Like in Practice

The monolith owned by a single team.

A small startup has one team. That team builds one system. The system is a monolith. This is perfectly appropriate. The communication overhead within a single team is low, so the integration within the monolith is high. Everything is cohesive. Decisions are made quickly. The system reflects the team - and the team is small and well-aligned.

Then the company grows. New teams form. But the monolith doesn't change - or changes slowly. The new teams all need to modify the same codebase, but they have different owners, different priorities, and different release schedules. Coordination cost explodes. The monolith becomes a liability not because it is technically wrong but because the org has outgrown it. The architecture is still reflecting the old org - a single unified communication structure - while the actual org has fragmented.

Microservices owned by siloed teams that can't deploy independently.

A large organisation decides to decompose its monolith into microservices. This is presented as a technical initiative. The org structure is not changed. Each service ends up owned by a different team - but those teams have dependencies on each other for every significant piece of work. Service A cannot be deployed without coordinating with Service B, which has a dependency on Service C, which is owned by a team in a different timezone.

The architecture looks like microservices on a diagram. In practice, it behaves like a distributed monolith - all the operational complexity of distribution with none of the independence. The root cause is that the decomposition was done technically, not organisationally. The services were split along technical seams, not along the communication boundaries of the teams that own them.

The platform team that becomes a bottleneck.

A platform team is created to own the shared infrastructure - CI/CD pipelines, cloud accounts, observability tooling, golden path templates. This is a good idea. The problem is that the platform team is small, central, and in high demand. Every other team depends on it for things they cannot do themselves.

The platform team cannot keep up. Everything requires a ticket. The ticket queue is two weeks long. Teams work around the platform, building their own bespoke infrastructure. The platform team becomes a coordination overhead and a single point of failure - not because it was a bad idea, but because the interaction model was wrong. The platform team was designed as a shared service bottleneck rather than as an X-as-a-Service provider. The org structure produced the bottleneck. The bottleneck is in the architecture.

How to Use It

Step 1: Map your current communication structure, not your org chart.

Org charts show reporting lines. Conway's Law is about communication patterns. These are not the same thing. Map who actually talks to whom when building or changing systems. Use tools like dependency tracking, API ownership maps, or just honest conversation with engineers about who they have to coordinate with to get something done.

Step 2: Map your current system architecture.

Draw the actual architecture - the modules, services, or components, and the dependencies between them. Be honest about the dependencies. Include the implicit ones: shared databases, shared libraries, shared deployment pipelines.

Step 3: Overlay the two maps.

You will find that they match. Not perfectly - there will be places where they're misaligned - but the broad shape of the communication structure will match the broad shape of the architecture. Where you see misalignment, you have found a pain point: either a team that is trying to own something across a structural boundary, or a system component that no one really owns because it sits in the gap between teams.

Step 4: Design the target architecture.

What does the system need to look like in 2 to 3 years? What are the domains? What are the seams? Where do you want independent deployability? Where do you want strong coupling because the problem domain demands it?

Step 5: Design the target org structure.

For each domain or service cluster in the target architecture, ask: what kind of team should own this? What does that team need to know? What can they operate independently? What interfaces do they need with adjacent teams?

Step 6: Sequence the transition.

You cannot restructure everything at once. Identify the highest-value changes - the places where the current structure is causing the most pain - and sequence them. Change the org structure first where you can. Let the architecture follow.

Common Misapplications

"We'll restructure and the architecture will follow."

This is the most common mistake. Leaders announce a reorg - usually motivated by a business goal, a change in strategy, or a new leader with a theory - and assume that the technical architecture will adapt. It will not adapt on its own. The codebase does not restructure itself when you move boxes on an org chart. Engineers still have to change the code. Interfaces still have to be renegotiated. Data models still have to be redesigned. Without explicit technical work aligned to the new structure, you get the worst of both worlds: a new org structure that doesn't match the architecture it inherited.

"Conway's Law only applies to microservices architectures."

Conway's Law applies to every system - monoliths, monorepos, mainframes, SaaS platforms, enterprise software, data pipelines. It is a law about how organisations produce designs, not about any particular architectural style. A monolith designed by one coherent team is fine. A monolith designed by twelve teams that don't talk to each other is a disaster.

"We can solve Conway's Law with better documentation and standards."

Documentation describes how things should work. Conway's Law determines how things do work. You cannot write your way out of a structural problem. Standards help at the margin but cannot substitute for a communication structure that enables good design decisions.

"Our architects will maintain the integrity of the system."

Architects who are not embedded in the teams doing the work cannot maintain architectural integrity at scale. They become a coordination overhead and a bottleneck. Architecture that is not owned by the teams building the system will not be maintained by those teams. The architecture must be distributed into the team structure, or it will erode.

Connection to Your Operating Model

Conway's Law is not a technical concept that happens to have organisational implications. It is an organisational concept that has technical consequences. That distinction matters.

It means that every decision about team structure is an architectural decision. Every decision about ownership boundaries is an architectural decision. Every decision about how teams interact - through APIs, through tickets, through shared channels - is an architectural decision.

This is why Team Topologies is built on Conway's Law as its foundation. The four team types and three interaction modes in Team Topologies are not arbitrary design choices - they are the set of structures that, when instantiated correctly, produce communication patterns that lead to fast flow and independently operable systems.

It is why value stream thinking matters. If you align teams to value streams, the systems those teams build will be aligned to value streams. The architecture will enable end-to-end flow because the teams are designed to enable end-to-end flow.

It is why cognitive load is a design constraint. If a team owns too much - across too many domains, with too many external dependencies - the communication overhead becomes unsustainable. The architecture becomes incoherent because no one has a coherent enough picture of the whole to design it well.

If you are going to use this framework seriously, start here. Conway's Law is the lens through which every other concept in this section should be read. It explains why things are the way they are in your organisation. It gives you the lever to change them deliberately, rather than hoping they change on their own.