Team Topologies

The organizational structure and interaction patterns between teams, deliberately designed to minimize cognitive load and communication overhead while enabling fast, independent delivery.

What are Team Topologies?

Team topologies is a framework (from the book of the same name) for organizing engineering organizations to optimize for flow and reduce friction. The core insight: the structure of your organization constrains the architecture of your product (Conway’s Law). If your teams are siloed, your systems will be. If teams collaborate freely, your systems will integrate seamlessly.

Rather than asking “how many engineers do we need?”, team topologies asks “how should our teams interact to enable fast delivery?” The answer shapes team size, specialization, and reporting structure.

Four Team Types

Stream-aligned teams (feature teams) are organized around customer value streams—they deliver end-to-end capability. Enabling teams (similar to platform teams) provide tools, infrastructure, and knowledge. Complicated-subsystem teams manage areas requiring deep expertise (machine learning, cryptography). Platform teams provide self-service infrastructure.

The key is match: not all work fits into a stream-aligned team. Highly-specialized or infrastructure-heavy work needs dedicated ownership.

Interaction Modes

How teams interact matters as much as structure. Collaboration mode is real-time partnership—useful for early-stage, uncertain work. X-as-a-Service mode is asynchronous and decoupled—platform teams provide infrastructure; feature teams use it without coordination. Facilitating mode is temporary—an enabling team helps a stream team learn a new skill, then steps back.

Mismatches are friction: trying to collaborate asynchronously (slow), or trying to decouple work that requires tight integration (integration failures).

Cognitive Load

The core metric in team topologies is cognitive load: how much a team needs to understand to do their work effectively. If cognitive load is too high, teams get lost in complexity. If it’s too low, they’re underutilized. The goal is Goldilocks: just enough complexity to be interesting, not so much that focus fractures.

This drives team size. A team with simple, well-scoped work (low cognitive load) can be 3-5 people. A team managing complex distributed systems (high cognitive load) might be 6-8 people. Beyond 8, cognitive load typically becomes unsustainable.

Why It Matters for Product People

Team topologies directly shape delivery velocity and quality. Organizations with poor topologies suffer constant friction: teams waiting on each other, unclear ownership, and duplicate work. Organizations with clear topologies move faster with less chaos.

As you scale hiring, resist the default of “add more people to the team doing the work.” Instead, ask: Are we creating cognitive overload? Should we split off a supporting team? Should we create a platform to reduce coordination? Deliberately designing topology as you scale prevents the crisis of scaling.

Also, topologies guide hiring and skill development. If you need a platform team but have all generalists, you need to either develop depth or hire specialists. Without clear topology, you can’t make coherent hiring decisions.

Team topologies connect to organizational design, feature teams and platform teams (specific topology patterns), and system architecture. It also relates to communication patterns—how teams interact shapes what information flows and how quickly decisions propagate.