In 1968, Melvin Conway submitted a paper with a claim that’s been haunting software engineering ever since: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Harvard Business Review rejected it. Not enough evidence, they said.

Fifty-two years later, every engineering leader I know treats it as a law of nature. Funny how that works.

We usually quote Conway as a warning. Your architecture will mirror your org chart whether you plan for it or not. But I’ve been thinking about it differently lately — if org structure determines system structure, then org design is architecture design. You can use that relationship intentionally.

The Inverse Conway Maneuver #

ThoughtWorks calls this the “Inverse Conway Maneuver” — deliberately shaping your team structure to produce the architecture you want. Instead of accepting that your org chart will bleed into your code, you design the org chart first and let the code follow.

Sounds obvious, right?

In practice, almost nobody does it. Most reorgs optimize for reporting lines, budget allocation, headcount politics. The question “what system architecture will this team structure produce?” rarely makes it into the room.

At TaskRabbit, I’ve watched this play out in real time. We have a marketplace with two user types (Taskers and clients), a payment system, and a matching algorithm that connects them. The teams that own these pieces have clear boundaries, and the system architecture reflects those boundaries cleanly. Conway’s Law working in our favor.

But when a feature crosses team boundaries — and the interesting ones always do — the communication overhead becomes the bottleneck. Not the code. The conversations.

Cognitive load as architectural constraint #

Matthew Skelton and Manuel Pais published Team Topologies in late 2019. I think it’s the most practical framework for this problem. Their core argument: team cognitive load should be a first-class design constraint. If a team has to understand too many things to do their job effectively, the system design is wrong.

They define four team types:

Stream-aligned teams own a slice of the business domain end-to-end. They build features, own their services, deploy independently. Most product teams should be stream-aligned.

Enabling teams help stream-aligned teams adopt new capabilities. They don’t own production services; they unblock other teams. Think of an SRE team that teaches observability practices rather than running a centralized monitoring platform.

Complicated-subsystem teams own things that require deep specialist knowledge — a recommendation engine, a payment processing layer, a machine learning pipeline. They exist because the cognitive load of that subsystem is too high for a stream-aligned team to carry alongside their domain work.

Platform teams provide self-service capabilities that stream-aligned teams consume. APIs, CI/CD pipelines, infrastructure primitives.

What makes this taxonomy useful isn’t the labels; it’s the interaction modes. Skelton and Pais define three ways teams should interact: collaboration (working closely together, high bandwidth, time-limited), X-as-a-Service (consuming another team’s output through a clear API), and facilitating (one team helping another build a capability).

Every other interaction mode is a smell. If two teams are constantly coordinating because their services are tightly coupled, the team boundary is drawn in the wrong place.

Communication patterns are the architecture #

Martin Fowler’s take on Conway’s Law emphasizes that it’s not really about org charts. It’s about communication patterns. Two engineers who sit next to each other will build tightly coupled components. Two teams that never talk will build isolated systems with clean interfaces. The communication structure determines the integration points.

This has practical implications for remote and distributed teams.

When TaskRabbit went fully remote in early 2020, some team boundaries that worked in the office stopped working. Informal hallway coordination disappeared. Teams that had relied on ad-hoc, face-to-face alignment to manage shared ownership suddenly had friction.

The fix wasn’t more Zoom calls. It was redrawing boundaries so each team could operate more independently.

That’s an architectural change driven by a communication change. Conway’s Law, running in reverse.

Applying this in practice #

If you manage engineering teams, here’s where I think this framework pays off:

Start with the architecture you want, not the one you have. Sketch the target system on a whiteboard (or Miro, or whatever). Draw the services, the data flows, the integration points. Then ask: what team structure would naturally produce this architecture? That’s your reorg target.

Watch for misalignment signals. The clearest one is cross-team coordination overhead. If two teams need to sync on every release, their services are coupled, which means their cognitive domains overlap, which means the team boundary is wrong. Either merge them or decouple their services.

Treat cognitive load seriously. When an engineer tells you “I can’t keep all of this in my head,” that’s not a performance issue. That’s an architecture signal. The domain assigned to their team exceeds what a single team can reason about effectively. Split the domain, split the team, and let Conway’s Law do the rest.

Don’t reorg for the sake of reorging. The Inverse Conway Maneuver works when you have a clear architectural target. Without one, you’re just shuffling boxes on an org chart and hoping for the best.

Start with the system you want to build. Let that drive the team structure. And accept that the communication patterns between your teams — not the code they write — are the real architecture.