Skip to content
    RU
    Architecture & organization designChapter 10

    Team Topologies — Short Summary

    Matthew Skelton and Manuel Pais on teams as the unit of delivery, four topology patterns for flow, and interaction modes that evolve over time.

    Book summaryworking35 minevergreen · reviewed Aug 13, 2026
    Staff+
    Engineering Manager
    Chapter outline

    Team Topologies

    Authors: Matthew Skelton, Manuel Pais
    Publisher: IT Revolution
    Length: 2019

    Primary source: the work itself

    Matthew Skelton and Manuel Pais on teams as the unit of delivery, four topology patterns for flow, and interaction modes that evolve over time.

    Team Topologies — original coverOriginal

    Brief

    The essential idea

    Team Topologies treats the stable, long-lived team—not the individual engineer—as the fundamental unit of value delivery. Organizational design should minimize handoffs and keep cognitive load within a team's capacity; common scale bands move from teams of roughly five to eight people to tribes and larger streams with progressively more explicit boundaries and interfaces.

    The model defines four team types—stream-aligned, platform, enabling, and complicated-subsystem—and three purposeful interaction modes: collaboration, X-as-a-Service, and facilitating. Neither topology nor interaction mode is permanent: leaders must diagnose bottlenecks and evolve both as the product, capabilities, and constraints change.

    Decision lens

    Key takeaways

    Stable, long-lived teams usually outperform temporary project groupings because context and trust compound.

    Stream-aligned teams own a value flow through production rather than a technical layer or temporary milestone.

    Platform teams provide self-service capabilities, enabling teams transfer capability, and complicated-subsystem teams protect specialist depth.

    Collaboration is an intensive temporary mode, X-as-a-Service is a clear consuming interface, and facilitating builds another team's capability.

    Cognitive load is a design constraint: broad ownership and constant context switching degrade both speed and quality.

    A topology should be judged by flow and bottlenecks, not by whether it resembles a fashionable org chart.

    Workplace experiment

    Apply it at work

    1. 1

      Classify each engineering team by its primary topology and identify teams with mixed or unclear missions.

    2. 2

      Assess the cognitive load of one stream-aligned team and remove or transfer a responsibility it cannot sustainably own.

    3. 3

      Label important team relationships as collaboration, X-as-a-Service, or facilitating and set an intended review date.

    4. 4

      Find one long-running collaboration that should evolve into a service interface or a completed capability transfer.

    5. 5

      Review delivery bottlenecks after the topology change and adjust boundaries rather than treating the design as final.

    Choose one action, define the observable effect, and keep the first test small enough to reverse.

    Evidence

    Sources and further reading

    Additional sources

    Channel, aggregator, and commentary links confirm the work; they are not the primary source.

    Local knowledge map

    A small, typed neighborhood instead of the full-catalog graph.

    Builds onConway's Law
    Previous chapterConway's LawNext chapterRemote Team Interactions — Short Summary