Conway's Law and Team Topologies

The structure of the teams that build a system and the structure of the system influence each other. Service boundaries that ignore team boundaries produce coordination overhead. Team boundaries chosen deliberately support the architecture. This article covers Conway's law, how to use it, and the Team Topologies model for organizing teams.

Conway's law

Conway's law, described by Melvin Conway in a 1967 paper (published in 1968), says that organizations that design systems produce designs that copy the communication structures of those organizations.

Mechanism: components that are built by different teams have interfaces where the teams communicate, and components built by one team are tightly integrated because communication within a team is cheap. Over time the software's module boundaries match the organization's boundaries.

Examples:

• Separate frontend, backend, and database teams tend to produce a layered system where each feature requires work from all three teams and handoffs between them.
• Four teams building a compiler tend to produce a four-pass compiler.
• A team split across time zones tends to produce modules divided along the time zone line, since synchronous communication is difficult.

Consequence for microservices: a service that is changed by several teams, or a team that needs to change several services for one feature, incurs coordination costs. Independent deployment requires independent ownership.

Team-per-service ownership

The recommended structure is stream-aligned, cross-functional teams, each owning one or more services end to end: design, development, testing, deployment, and operation ("you build it, you run it").

Properties:

• A service has one owning team.
• A team may own several related services (typically those in one bounded context), but its cognitive load has a limit.
• The team has the skills to deliver a change without handoffs (frontend, backend, data, operations).
• The team is on call for its services and so feels the effect of quality problems.

graph TD
    subgraph T1["Team A: Checkout"]
        S1["Cart service"]
        S2["Order service"]
    end
    subgraph T2["Team B: Fulfillment"]
        S3["Inventory service"]
        S4["Shipping service"]
    end
    subgraph T3["Platform team"]
        P["Deployment, observability, runtime platform"]
    end
    T1 -->|"uses"| P
    T2 -->|"uses"| P
    S2 -->|"events"| S3

Ownership anti-patterns:

Inverse Conway maneuver

The inverse Conway maneuver means shaping the organization to produce the desired architecture: first decide the target service boundaries (for example, from bounded contexts, see domain-driven design), then form teams around them. Structure follows from the design goal, rather than the other way round.

Steps:

1. Define the target architecture, based on business capabilities (see decomposition by business capability).
2. Form teams aligned to those boundaries, giving each ownership of its services and data.
3. Minimize the communication needed between teams by keeping boundaries stable and interfaces explicit.
4. Reorganize if the boundaries prove wrong. If two teams keep needing to coordinate, revisit either the boundary or the teams.

A mismatch between the organization and the architecture shows up as constant cross-team coordination for routine changes. That is evidence that either should change.

Team Topologies

Team Topologies (Matthew Skelton and Manuel Pais) is a model of team organization for software delivery. It defines four team types and three interaction modes.

Team types

Interaction modes

The intent is to make interactions explicit and limited: most day-to-day work happens within a team or through x-as-a-service interfaces.

Cognitive load

Team Topologies treats cognitive load, the amount a team can hold in mind, as the limit on team responsibilities. A team should own a domain and set of services it can understand and operate. Platform teams and enabling teams exist to remove load from stream-aligned teams, and boundaries are set to keep each team within its capacity.

Platform teams for microservices

Independent teams each running many services need shared infrastructure. A platform team provides it as a product to internal users:

• Continuous integration and deployment pipelines and templates for new services.
• Container orchestration and runtime environments (see Kubernetes basics).
• Observability: logging, metrics, and distributed tracing.
• Service discovery, configuration, secrets, and the API gateway.
• Security defaults (see microservices security and zero trust).

Design principles: self-service (teams use it without tickets), sensible defaults ("paved road") without forbidding alternatives, and treating stream-aligned teams as customers. A platform team that acts as a gatekeeper, by requiring tickets for each deployment, recreates the handoffs that microservices are meant to avoid.

Interview questions

• What does Conway's law state? The systems an organization designs mirror its communication structure. Team boundaries therefore become module and service boundaries.
• What is the inverse Conway maneuver? Deliberately structuring teams to match the desired architecture, so that the organization produces the intended service boundaries.
• Why should one team own a service end to end? It removes handoffs, gives clear responsibility, and lets the team deploy independently and respond to production issues.
• What is the role of a platform team? Provide self-service internal infrastructure (pipelines, runtime, observability) so stream-aligned teams can run services with lower cognitive load.
• What are the four Team Topologies team types? Stream-aligned, enabling, complicated-subsystem, and platform teams.