Conway's Law and the Reverse Conway Maneuver

Why Team Structure Determines System Architecture

Before introducing the Team Topologies framework, you need to understand the foundational insight it is built on: Conway's Law.

In 1967, computer scientist Melvin Conway observed: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations."

In plain terms: your software will look like your org chart. If you have four siloed teams — Frontend, Backend, Database, and Ops — you will build a system with four tightly coupled layers that require constant cross-team coordination to change. The architecture mirrors the communication patterns.

This isn't a bug in human behavior; it's a structural inevitability. Teams naturally build interfaces at the boundaries where they stop talking to each other.

The Reverse Conway Maneuver

If Conway's Law says "your org structure produces your architecture," then the Reverse Conway Maneuver says: deliberately design your org structure to produce the architecture you want.

If you want loosely coupled microservices with clear ownership, create small, autonomous teams aligned to those services. If you want a shared platform that all product teams consume, create a dedicated team whose sole job is building and maintaining that platform.

Team Topologies, a framework by Matthew Skelton and Manuel Pais, operationalizes this idea. It defines four specific team types and three interaction modes, all designed to optimize for fast flow of value and manageable cognitive load. The framework treats cognitive load not as a soft concern but as a hard engineering constraint — just like memory or CPU.