Conway's Law is Always Working — the Question is Whether You're Working With It or Against It

Mel Conway wrote the paper in 1967. The observation is not subtle: organisations produce designs that mirror their own communication structure. Put another way, the shape of your team eventually becomes the shape of your software.

Most engineering leaders treat this as something you can choose to engage with or ignore. That is the misunderstanding that gets teams into trouble. Conway's Law is not a principle you opt into. It is already in operation the moment you have more than one person writing code and communicating with one another to do it. The only question is whether the architecture that emerges from your communication patterns is one you intended.

What the law actually says

The precise wording: "organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations."

At Booking.com, where I spent several years, the engineering organisation was built around product verticals — accommodation, transport, attractions, payments. And the technical systems mapped onto those verticals with remarkable fidelity. The accommodation codebase was not a monolith shared with transport. It was a distinct system with its own data model, its own API surface, its own deployment pipeline. The teams communicated heavily within their product vertical and rarely across it. The software did the same thing.

This is not a coincidence. It is not even an accident. It is Conway's Law running as designed.

The inverse Conway manoeuvre

What the Team Topologies framework calls the "inverse Conway manoeuvre" is the application of this insight in the other direction: if your team communication structure shapes your software, then deliberately designing the team communication structure is a way to deliberately design the software architecture.

This is a more powerful idea than it first appears. Most architecture discussions are about technical choices: which database, which message broker, how to decompose services, where to draw the boundaries. What gets underweighted is that those decisions are not made once and then fixed. They evolve, and they evolve in the direction that the team's communication structure keeps pulling them.

If you want microservices with clean ownership boundaries, you need teams with clean ownership boundaries. If you want an event-driven architecture, you need teams whose communication norms are asynchronous and decoupled rather than synchronous and dependent. The technical choice and the organisational choice are not independent decisions.

Where this breaks down in practice

The most common failure mode is a team structure and a desired architecture that are pointing in opposite directions.

I see this repeatedly at early-stage startups: a team of eight engineers, all working across the full stack, all communicating continuously in one Slack channel, all deploying from one repository — and a stated architectural goal of modular, independently deployable services. The services either never get built (because the coordination structure does not require them), or they get built and then immediately start leaking dependencies across their boundaries (because the team communicates in ways that do not respect those boundaries).

The technical architecture is fighting the social architecture. The social architecture usually wins, eventually.

The practical implication

When you are designing an engineering team — or redesigning one — the architecture conversation and the org design conversation should be happening in the same room, not in separate threads.

"What team structure do we need?" is not a separate question from "what architecture are we trying to build?" They are the same question viewed from different angles. Getting them aligned is one of the highest-leverage things an engineering leader can do, and one of the most consistently undervalued.

If you are restructuring and you are not also thinking about what your desired architecture looks like in 18 months, you are likely to end up with a team structure optimised for an architecture you no longer have and a technical architecture drifting toward a team design you did not intend.

The architecture conversation and the org design conversation should be happening in the same room.

The nuance

Conway's Law is directional, not deterministic. A single team can build multiple architectural styles within a single codebase if the technical discipline is strong enough. Platform teams that produce a genuinely clean internal product can reduce the impact of team boundaries on software boundaries. And at very small scale — three or four engineers — the communication overhead is low enough that the constraint barely bites.

But as teams grow, the gravitational pull intensifies. The larger the team, the more inevitably the software reflects the org chart. The architecture is not just a technical artefact. It is a social one.

What to do

If you are designing or redesigning an engineering team, start by drawing the system architecture you are trying to build. Then ask: what communication structure between teams would naturally produce this architecture? That is the team structure you should be moving toward, not the one that emerged by default from how you hired and how you grouped people historically.

The Engineering Team Design Guide in this cluster covers the main structural models and how to choose between them. The how-to on applying Team Topologies at startup scale goes deeper on the specific team types that turn this principle into a practical framework.