Team Topologies learning path: everything to study, topic by topic

How communication structures of an organization constrain and shape the architecture of the systems it produces, and why this homomorphic force cannot be ignored.

Deliberately designing teams and communication structures to encourage the desired software architecture, instead of letting architecture emerge accidentally from the org chart.

Intrinsic, extraneous, and germane cognitive load on a team, and why limiting the total load a team carries is essential for sustainable fast flow.

Sizing software, domains, and responsibilities to fit within a single team's cognitive capacity, making the team — not the individual — the fundamental unit of delivery.

The primary team type, aligned to a single valuable stream of work (a product, service, or user journey) and empowered to deliver value end-to-end with minimal hand-offs.

A team of specialists that helps stream-aligned teams acquire missing capabilities, then deliberately steps back — avoiding becoming a permanent dependency or a center of expertise silo.

A team owning a part of the system requiring deep specialist knowledge, created only when the cognitive load of that subsystem would overwhelm a stream-aligned team.

A grouping that provides internal services as a compelling product to reduce the cognitive load of stream-aligned teams, treated as a product with internal customers.

Two teams working closely together for a defined period to discover new things, accepting higher cognitive load and blurred boundaries in exchange for rapid learning.

One team consuming something another team provides as a service with minimal collaboration, optimizing for clear responsibilities and predictable delivery once a domain is well understood.

One team (usually enabling) helping another to learn or adopt a practice, clearing impediments and raising capability without taking ownership of the work.

Selecting and evolving the right interaction mode between teams based on the maturity of the domain, the goal of the interaction, and the cognitive load implications.

Making the long-lived, stable team the fundamental means of delivery — assigning work to teams rather than individuals and investing in team cohesion and shared ownership.

The explicit interface a team exposes to the rest of the organization: code, documentation, ways of working, communication norms, and expectations that make the team easy to interact with.

Cognitive limits on the number of trusting relationships humans can maintain (≈5, 15, 50, 150) and how they bound team size and the structure of groupings of teams.

Aligning organizational boundaries with the limits of trust and cognitive capacity, so teams can move fast within high-trust zones and use clear interfaces across them.

Natural seams along which to split software and teams — business domain, change cadence, risk, performance, technology, and user persona — to minimize coupling and cognitive load.

Keeping a platform as small as possible while still reducing cognitive load — resisting platform gold-plating and treating the platform as a curated, compelling internal product.

Optimizing team and architectural boundaries for the fast, safe flow of change through the system, minimizing hand-offs, dependencies, and wait states across teams.

Drawing system and ownership boundaries explicitly around what a team can sustainably understand, using cognitive load as a first-class design constraint.

Using the team structure as a sensory organ — teams detecting signals from the systems and markets they touch — to inform where the organization should adapt next.

Treating team structure as continuously evolving rather than fixed — shifting team types and interaction modes deliberately as products, domains, and technologies mature.

Recognizing the signals that should trigger a change in team topology — slowing delivery, rising cognitive load, a new product line, scaling, or a major technology shift.

Designing a deliberate, organization-wide team topology strategy that combines team types, interaction modes, platforms, and fracture planes to sustain fast flow as the organization scales.