In 1968, Melvin Conway published a paper titled “How Do Committees Invent?” with an observation buried in it that has outlasted everything else he wrote:

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

That sentence is Conway’s Law. It is not a metaphor, not a rule of thumb, and not a failure mode to be overcome with discipline. It is a structural claim about how software gets built. If three teams build a compiler, you get a three-pass compiler. If four teams build a browser, you get four layers with interfaces between them that look suspiciously like the boundaries between the teams. The software reflects the communication paths of the people who built it, because the software’s interfaces are the places where communication had to be codified to avoid continuous coordination.

This has two consequences, one obvious and one subtle. The obvious one: you cannot design an architecture that fights the org chart and win. The team whose boundaries do not match a service’s boundaries will either absorb the service or fragment it. The subtle one: if Conway’s Law is real, you can design software architecture by designing organizations. That second move — using team structure as a primary design tool — is what Matthew Skelton and Manuel Pais formalized in their 2019 book Team Topologies, and it is the framework this post spends most of its time on.

The inverse Conway maneuver

If the architecture mirrors the organization, then to get a specific architecture, shape the organization first. Want microservices aligned with business capabilities? Form cross-functional teams aligned with business capabilities, each owning its stack end to end, with well-defined APIs between them. The architecture you want will precipitate out of the team structure, because the teams will codify their boundaries into software interfaces and will absorb the rest.

This is the inverse Conway maneuver. It was named around 2010 and has since become close to consensus among people who have actually tried to land large-scale architectures. The consistent reports: attempting to impose microservices on a team structure organized by technology layer (UI team, API team, database team) produces a distributed monolith. Attempting to impose microservices on teams aligned with business capabilities produces something close to the intended architecture without sustained central direction.

The implication for architects is uncomfortable. The architecture decisions that actually matter are not diagrams. They are who is on which team, who they report to, and what they own end-to-end. If you cannot influence those, you are not doing architecture; you are decorating the inevitable.

Cognitive load as the design constraint

The premise of Team Topologies, and the most useful reframing Skelton and Pais offer, is that the binding constraint on team effectiveness is cognitive load. A team can only hold so much in its collective head: so many services, so many technologies, so many domain concepts, so many on-call rotations. Exceed that budget and the team slows down, makes more mistakes, and stops being able to absorb new work no matter how many people it has.

This reframes team design. It is not “how do we chunk the work into equal pieces?” It is “how do we give each team a coherent, bounded responsibility small enough to hold in their heads while still large enough to ship end-to-end value?” Teams that own too much become bottlenecks. Teams that own too little become bureaucracies — every piece of meaningful work requires coordination across several of them.

The concrete implication: a team’s ownership surface should be sized to its cognitive capacity, not to the org chart’s convenience. A team that owns eleven services, three of which nobody on the current roster has ever modified, is not actually owning those services. They are just on the hook for them. Cognitive load is an honest upper bound on how much ownership is real.

The four team types

Skelton and Pais argue that almost all the productive teams in software organizations fall into one of four types. Each type has a specific purpose, a specific shape of ownership, and a specific mode of interacting with others. The idea is not to have four teams. It is that every team should know which type it is, because the type tells you how it is supposed to work and who it is supposed to work with.

Stream-aligned teams. The default type. A stream-aligned team owns a single stream of business value end-to-end — a product, a customer journey, a business capability. It is cross-functional (has the skills to ship without handoffs), long-lived (it is not a project team), and aligned with a bounded context or a capability. Most teams in a healthy organization are stream-aligned. The other three types exist to reduce the cognitive load on stream-aligned teams so they can keep shipping.

Enabling teams. Short-lived, specialized teams that help stream-aligned teams acquire a capability they do not yet have. An enabling team might spend three months embedded with product teams teaching them how to adopt Kubernetes, or how to use a new testing framework, or how to apply domain-driven design. They are teachers, not doers. Crucially, they do not become the team that runs the thing — that would re-create the bottleneck. When the stream-aligned team is proficient, the enabling team moves on.

Complicated-subsystem teams. A team that owns a part of the system too specialized for every stream-aligned team to reasonably understand — a video codec, a risk-pricing engine, a real-time bidding optimizer, a math-heavy matching algorithm. The criterion for this team type is that the subsystem genuinely requires deep expertise, not that it happens to be complicated today. “Complicated” here means intrinsically complicated, not accidentally complicated; the latter is a refactor problem, not a team-type problem.

Platform teams. A team that provides a product — usually internal infrastructure — used by stream-aligned teams. The platform is a real product: it has users (the stream-aligned teams), it has a product manager, it has documentation, and it competes for its users’ usage against the alternative of those teams rolling their own. Platform teams’ success is measured in the reduction of cognitive load on their customer teams. A platform nobody uses is a failure, no matter how technically elegant it is; a platform everyone uses but complains about is a failure too. The platform is a product, and the metric is adoption-by-choice, not adoption-by-mandate.

The four types are not the interesting part by themselves. The interesting part is that every team in the organization should be one of them, and the shape of the interaction between them is what makes the system work.

The three interaction modes

Skelton and Pais argue that team interactions should also be deliberate — not “teams talk to each other as needed” but one of three explicit modes, chosen for each pairing.

Collaboration. Two teams work closely together for a defined period, usually to discover something new: a new integration, a new feature that spans their domains, a new capability that neither team has alone. Collaboration is expensive — it is high-bandwidth communication, lots of meetings, shared code — and it is justified only when discovery is actually happening. When the shape of the work is known, collaboration should end. If it does not end, the two teams have effectively merged into one, without anyone deciding so.

X-as-a-Service. One team consumes something another team provides — an API, a platform, a library — with minimal coordination. The provider team offers a stable interface, documentation, and support. The consumer team integrates and gets on with their work. This is the mode for most inter-team relationships in a healthy organization. A well-run platform team’s interactions with stream-aligned teams are X-as-a-Service: the platform provides, the stream-aligned teams consume, and neither has to coordinate daily with the other.

Facilitating. One team helps another team unblock itself — the mode for enabling teams. The helper is not doing the work; they are teaching the other team to do it. Pairing, workshops, code review, embedded consultancy. The interaction is time-bounded and aimed at transferring capability.

The point of naming the modes is that a pair of teams should know which mode they are in at any moment, and changing modes should be deliberate. The common failure is a pair of teams in permanent collaboration who think they are in X-as-a-Service — they claim to consume each other’s APIs, but they coordinate daily, their code co-evolves, and neither can ship without the other’s calendar. That is not X-as-a-Service; that is a shared ownership model masquerading as a contract, and it is how distributed monoliths are built at the team level.

When team boundaries move

Team Topologies is also explicit that team boundaries are not permanent. A platform team can start as an enabling team (facilitating) and transition to providing a platform (X-as-a-Service) once the capability is mature enough to productize. A stream-aligned team can discover that its stream is too broad and split. A complicated-subsystem team can discover that the subsystem has been tamed enough to be absorbed back into stream-aligned teams.

These transitions are good — they are the organization adapting to the work — and they are also the moments at which Conway’s Law bites hardest. A team split produces a software split. A team merge produces a software merge. The architecture is the org chart is the architecture; moving one without the other leaves residue.

The practical consequence: if you are about to reorganize, know what software boundaries the new structure will produce in six to twelve months, and check whether those are the boundaries you want. If they are not, either change the reorg or plan the refactor that will follow it. Letting Conway’s Law happen by accident is how you wake up with an architecture nobody designed.

The failure modes

A few recurring anti-patterns, each of which a Team Topologies lens makes legible:

• The “feature team” that owns everything, shallowly. A team assigned to “the checkout feature” that touches every service in the system. It is not stream-aligned (it does not own a stream; it coordinates across streams). It is not a platform team (it produces no product for others). It is, in practice, a perpetual collaboration across every team it touches, and it fails in predictable ways: every sprint ends with cross-team dependencies unresolved.
• The platform team that is really an operations team. It maintains the Kubernetes cluster, answers tickets about deployments, and firefights. It has no product manager and no roadmap. It absorbs every problem because nobody else will. It is a platform in name and a bottleneck in fact.
• The “DevOps team” that sits between developers and production. The definition of DevOps is that this team does not exist. A standalone DevOps team is how an organization tells itself it has adopted DevOps while keeping the old handoff intact.
• The “architecture team” with no implementation responsibility. They produce diagrams; the stream-aligned teams produce software; the two rarely match. The team has no lever other than influence, and influence without ownership decays. An architecture function is useful; a separate architecture team that does not ship is usually not.
• The subsystem team that should not be. A “complicated subsystem” that is, on inspection, merely unfamiliar. Anything that a stream-aligned team could reasonably absorb with a week of ramp-up is not a complicated subsystem; it is a piece of work being hoarded.

Each of these is a team-shape bug that produces a corresponding software bug. Fixing the software without fixing the team is futile.

The connection to every other architecture topic

Conway’s Law is the hidden premise under almost every architectural discussion.

• Microservices require stream-aligned teams; without them, the decomposition either does not happen or produces a distributed monolith.
• DDD’s bounded contexts presuppose that a single team owns the context’s model. A bounded context split across two teams develops two models and is not bounded.
• Platforms — internal developer platforms, data platforms, experimentation platforms — are Conway’s Law used deliberately. You spin up a platform team because you want the rest of the engineering org to treat certain capabilities as external services, not as things they build each time.
• Monorepo vs. polyrepo is mostly a team-interaction decision in disguise. A monorepo makes collaboration cheap and enforces a shared toolchain; it is a good fit when the organization wants stream-aligned teams to be able to reach into each other’s code. A polyrepo makes X-as-a-Service the default interaction by making reach-in expensive.

The practical takeaway after a few attempts: before arguing about services, APIs, or repositories, draw the team structure. Check that each team is one of the four types, with a clear purpose and a bounded cognitive load. Check that each pair of teams is in one of the three interaction modes, on purpose. If either check fails, the architectural conversation is premature — the team structure will produce a system that does not match the diagram, and the diagram will lose.

The rule

Design the teams you want the software to reflect. Give each team a coherent, bounded responsibility it can hold in its collective head. Name each team’s type. Name each team-pair’s interaction mode. Renegotiate when the work changes. Do this consistently and the architecture will mostly take care of itself, because Conway’s Law is doing the work for you. Ignore it and you will spend the rest of the project fighting the law, and losing — because it is not a preference. It is how the thing actually works.

The org chart is the architecture. Draw it like you mean it.