**Author:** [[3. Resources/Authors/Matthew Skelton, Manuel Pais|Matthew Skelton, Manuel Pais]] # Book Overview ![[Team Topologies Visual.excalidraw]] ## About the Author Matthew Skelton has been building and operating commercial software systems since 1998, working for organizations including the London Stock Exchange, GlaxoSmithKline, FT.com, LexisNexis, and the UK government. He's Head of Consulting at Conflux, co-authored *Continuous Delivery with Windows and .NET* and *Team Guide to Software Operability*, and holds degrees in computer science and cybernetics, neuroscience (Oxford), and music. Manuel Pais is an independent DevOps and Continuous Delivery consultant focused on team design, practices, and flow. He co-authored *Team Guide to Software Releasability*. Together, they've worked with organizations worldwide on rethinking team structure for modern software systems -- a consulting practice that predates and directly feeds the book's frameworks. ## Central Thesis The way you organize teams is the way you'll get software. That's Conway's law, stated in 1968, and most organizations still ignore it. Skelton and Pais argue that org charts, matrix management, and project-based team shuffling are actively hostile to fast software delivery. The alternative: four -- and only four -- fundamental team types (stream-aligned, enabling, complicated-subsystem, and platform), combined with three explicit interaction modes (collaboration, X-as-a-Service, and facilitating). Teams aren't just units of people. They're the fundamental unit of software delivery, and their cognitive load, boundaries, and communication patterns directly shape the architecture of what they build. The book extends this into a dynamic model. Team topologies aren't meant to be static. They should evolve as the organization's needs change -- moving from close collaboration during discovery phases toward X-as-a-Service relationships once patterns stabilize. The organization itself becomes a sensing system, using team interactions as signals to detect when structures need to change. ## Why This Book Matters Most organizations treat team structure as an administrative concern -- something HR and managers handle separately from technical decisions. Team Topologies makes the case that team design *is* a technical decision, and a strategic one. The insight that team boundaries will become software boundaries (whether you plan for it or not) reframes every reorg, every new hire, and every cross-team dependency as an architectural choice. For engineering leaders, this book provides a vocabulary and a set of patterns that replace the vague instinct of "we need to reorganize" with specific, testable structures. It's one of the few books that connects organizational design directly to software delivery performance with concrete, applicable frameworks. --- # Chapter Summaries ## Chapter 1: The Problem with Org Charts The opening chapter attacks the traditional org chart as a fiction. Org charts show reporting lines, not communication patterns. Real work flows through informal networks that the org chart doesn't capture. Skelton and Pais trace how this disconnect creates problems: teams that don't match the software they're building, communication overhead that slows delivery, and reorganizations that destroy institutional knowledge without improving flow. The chapter introduces the idea that team structures should be designed intentionally to match the desired software architecture, not left as an afterthought. ## Chapter 2: Conway's Law and Why It Matters The theoretical foundation of the book. Conway's law says organizations produce system designs that mirror their communication structures. This isn't a suggestion -- it's a constraint. The chapter walks through the "reverse Conway maneuver": instead of letting org structure accidentally dictate architecture, design your teams to match the architecture you want. The authors cite research from Harvard Business School showing that loosely coupled organizations produce more modular codebases. The key insight: if you want independent, deployable services, you need independent teams. If your teams are tightly coupled through shared code reviews, shared databases, or shared deployment pipelines, your architecture will be tightly coupled too, regardless of what's on the whiteboard. ## Chapter 3: Team-First Thinking This chapter introduces cognitive load as the governing constraint for team design. Drawing on John Sweller's cognitive load theory, the authors identify three types: intrinsic (the problem itself), extraneous (the environment and tooling), and germane (the learning required for high performance). A team's total cognitive load across all three types determines what it can effectively own. If you pile too much onto a team -- too many services, too many domains, too many operational concerns -- quality and speed collapse. The chapter also introduces the "team API" concept: a team's interface isn't just the code it produces but includes its documentation, onboarding process, communication preferences, and interaction patterns with other teams. Dunbar's number appears here too -- the anthropological limits on group trust (roughly 5, 15, 50, 150) that set practical upper bounds on team size and inter-team relationships. ## Chapter 4: Static Team Topologies A survey of anti-patterns and patterns in team structure. The authors catalog common team arrangements -- feature teams, component teams, matrix structures, DevOps teams -- and evaluate which ones support fast flow and which ones create bottlenecks. The Spotify model gets a measured treatment: the chapter acknowledges its influence while noting that organizations that copy its structure without understanding its context often produce worse outcomes. The key message: there's no one-size-fits-all team structure. The right topology depends on the organization's size, technical maturity, domain complexity, and Conway's law constraints. Case studies from TransUnion and Adidas appear here, showing how real organizations mapped their team structures to the four fundamental topologies. ## Chapter 5: The Four Fundamental Team Topologies The core framework. Skelton and Pais argue that all effective software organizations can be built from just four team types: **Stream-aligned teams** are the primary type -- the majority of teams in any organization should be stream-aligned. They own a continuous flow of work aligned to a business domain, user journey, or product stream. They have cross-functional skills and can deliver without depending on other teams for most changes. Stream-aligned teams are "you build it, you run it" teams. **Enabling teams** exist to help stream-aligned teams acquire missing capabilities. They don't build software that stream-aligned teams consume. They teach, coach, and facilitate -- then move on. A good enabling team works itself out of a job with any given stream-aligned team. Their interaction mode is facilitating, not building. **Complicated-subsystem teams** handle parts of the system that require deep specialist knowledge -- things like video codecs, mathematical models, or real-time trading engines. They exist to prevent stream-aligned teams from being overwhelmed by domain complexity that isn't their primary concern. These teams should be rare. If you have a lot of them, you're probably misclassifying. **Platform teams** provide internal services that reduce cognitive load for stream-aligned teams. The platform isn't necessarily a sophisticated custom system. It can be as minimal as a wiki with clear documentation on how to use underlying infrastructure. The concept of "thinnest viable platform" -- the minimum platform needed to accelerate stream-aligned teams -- pushes back against the tendency to over-engineer internal platforms. ## Chapter 6: Choose Team-First Boundaries This chapter addresses how to split software into team-sized pieces. The authors introduce "fracture planes" -- natural seams in a system along which it can be divided. The fracture planes include: business domain boundaries (bounded contexts from DDD), regulatory compliance, change cadence, team location, risk profiles, performance isolation requirements, technology type, and user personas. The critical insight: not all fracture planes are equally useful for every organization. The right ones depend on what's constraining flow. If regulatory requirements are the primary constraint, split along compliance boundaries. If different parts of the system change at very different speeds, split by change cadence. The chapter warns against the common mistake of splitting by technology layer (frontend team, backend team, database team), which creates cross-team dependencies for every feature. ## Chapter 7: Team Interaction Modes The book's second major framework: three -- and only three -- ways teams should interact: **Collaboration** is two teams working closely together on a shared goal. It's high-bandwidth, high-cognitive-load, and expensive. It's good for discovery and rapid learning, bad for long-term predictable delivery. Collaboration should be time-boxed and have a clear purpose. **X-as-a-Service** is one team consuming something another team provides, with a clean API boundary between them. Low cognitive load, high predictability, low innovation speed. This is where most team relationships should end up once discovery is done. **Facilitating** is one team (usually enabling) helping another team learn or adopt a new capability. The facilitating team doesn't own the work -- they help the other team build the capability themselves. The chapter introduces promise theory from Mark Burgess as a framework for team interactions -- teams make promises about what they'll provide, rather than imposing demands on other teams. Any interaction that doesn't fit one of these three modes is a signal that team boundaries are wrong. ## Chapter 8: Evolve Team Structures with Organizational Sensing The final chapter makes the framework dynamic. Team topologies aren't static structures you set once. They should evolve as the organization learns. The core evolution pattern: teams start in collaboration mode during discovery, then gradually move toward X-as-a-Service as the domain and technology become well understood. The chapter introduces "organizational sensing" -- using team interactions as signals to detect when structures need to change. Triggers for evolution include: software growing too large for one team, delivery cadence slowing, multiple business services depending on shared underlying services, and teams consistently needing to coordinate for routine changes. The TransUnion and Sky Betting & Gaming case studies get extended treatment here, showing multi-year evolution of team structures. TransUnion's system-build and platform-build teams took three years longer than expected to merge -- a useful corrective to the idea that reorganizations happen quickly. The chapter argues against separating "new development" from "maintenance" teams, since this breaks the feedback loop between building and operating software. --- # Key Themes and Highlights ## Conway's Law as Strategy, Not Trivia Most engineers know Conway's law as a fun observation. Skelton and Pais treat it as a first-class strategic tool. If team structure determines software architecture (and the research says it does), then team design is architecture design. The reverse Conway maneuver -- designing teams to produce the architecture you want -- is the book's most directly actionable idea. It transforms org design from an HR exercise into an engineering discipline. ## Cognitive Load as the Governing Constraint The application of cognitive load theory to teams is the book's most original contribution. Instead of asking "how many microservices should we have?" the right question becomes "how much can each team effectively own?" If a team has to understand too many domains, too many technologies, or too many operational concerns, it doesn't matter how talented the individuals are. The cognitive load will exceed capacity, and quality and speed will suffer. This reframes architecture decisions as fundamentally human decisions. ## The Team as the Unit of Delivery Individual contributors don't deliver software. Teams deliver software. This sounds obvious, but most organizations undermine it in practice -- through matrix management, shared-services models, project-based staffing, and constant team reshuffling. The book's insistence on stable, long-lived teams with clear ownership is a direct challenge to the project-oriented thinking that dominates most organizations. ## Platform as a Product, Not an Empire The "thinnest viable platform" concept pushes back hard against the tendency to build elaborate internal platforms that nobody asked for and nobody wants to use. A platform team's job is to reduce cognitive load for stream-aligned teams -- period. If the platform creates more cognitive load than it removes, it's failing. The platform should be treated as a product with its own users (stream-aligned teams), its own roadmap, and its own feedback loops. ## Evolution Over Reorganization The chapter on organizational sensing presents an alternative to the painful, periodic "big reorg" that most companies inflict on themselves every few years. Instead, team structures should evolve continuously in response to signals. Collaboration tightens during discovery and loosens as patterns stabilize. Teams split when cognitive load exceeds capacity. Platform capabilities emerge from patterns that multiple stream-aligned teams need. This evolutionary approach treats organizational change as a continuous process rather than a disruptive event. --- # Analytical Reading ## Main Arguments 1. Conway's law is a constraint, not a curiosity. Team communication structures will be reflected in software architecture whether you plan for it or not. 2. The reverse Conway maneuver -- designing teams to produce the architecture you want -- is a primary strategic tool for software organizations. 3. Only four fundamental team types are needed: stream-aligned, enabling, complicated-subsystem, and platform. Other team types create confusion and impede flow. 4. Three -- and only three -- team interaction modes should exist: collaboration, X-as-a-Service, and facilitating. Interactions outside these modes signal structural problems. 5. Cognitive load, not headcount or skill inventory, is the governing constraint for what a team can effectively own. 6. Team topologies should evolve over time, not remain static. Organizations that treat team structure as fixed will fall behind. 7. Platforms should follow the "thinnest viable platform" principle -- the minimum needed to reduce cognitive load for stream-aligned teams. 8. Stream-aligned teams should be the dominant team type. All other team types exist to support them. 9. Team boundaries become software boundaries. Splitting systems along fracture planes that match team capacity produces better architecture than technology-first decomposition. ## Methodology The book is practitioner literature built on a foundation of established research. The authors draw on Conway's law (1968), Dunbar's research on group size limits, cognitive load theory (Sweller), the Accelerate research (Forsgren, Humble, Kim), and promise theory (Burgess). Case studies from real organizations -- TransUnion, Adidas, Sky Betting & Gaming, uSwitch, CDL, OutSystems, and others -- ground the frameworks in practice. The case studies span multiple industries (finance, e-commerce, insurance, media) and organization sizes. There's no original empirical research; the book synthesizes existing research with consulting experience to produce a practical framework. ## Strengths The framework is genuinely practical. Four team types and three interaction modes is a simple enough vocabulary that an entire organization can learn and apply it. The cognitive load lens gives teams a concrete reason to push back when they're asked to own too much. The fracture planes concept provides a systematic way to make splitting decisions that are usually made by instinct or politics. The case studies are detailed enough to be useful -- TransUnion's multi-year evolution story is particularly valuable because it shows the messy reality of organizational change, including timelines that ran three years longer than planned. The book also avoids the common trap of treating its framework as sufficient by itself. The conclusion explicitly lists what Team Topologies doesn't cover: organizational culture, engineering practices, funding models, and business vision. This honesty makes the framework more credible, not less. ## Limitations The book is strongest on structure and weakest on people. How do you actually get teams to change their interaction modes? How do you handle the political dynamics when a team is told it's no longer a "platform team" but a "complicated-subsystem team"? The human resistance to organizational change gets very little attention. The framework assumes a degree of organizational maturity and rational decision-making that many companies don't have. The four-topology model can also feel reductive when applied to organizations with genuinely unusual structures. Research teams, internal audit teams, and sales engineering teams don't fit neatly into any of the four types. The book acknowledges this to some degree but doesn't fully resolve it. The case studies, while useful, are almost entirely from European and North American technology-oriented companies. How the framework applies in organizations with very different cultural contexts -- high power-distance cultures, heavily unionized environments, government bureaucracies -- isn't explored. The treatment of the Spotify model deserves more nuance. The book correctly notes that copying Spotify's structure without context often fails, but it doesn't fully explore why the model was so widely adopted in the first place or what it got right that other models didn't. --- # Personal Reflection ## Key Takeaways The cognitive load framing is the most useful idea in the book. It gives you a concrete, defensible reason to say "this team owns too much" that doesn't reduce to "we want more people." Three types of cognitive load -- intrinsic, extraneous, and germane -- map directly to decisions about team scope, platform investment, and enabling team deployment. If you're spending most of your team's capacity on extraneous load (deployment complexity, cross-team coordination, figuring out how to use internal tools), you have a platform problem, not a team problem. The reverse Conway maneuver is the most actionable idea. If you accept that team structure determines architecture, then every team design decision is an architecture decision. This changes the conversation about reorgs from "how do we reorganize for efficiency" to "what architecture do we want, and what team structure will produce it." ## Questions Raised - How does the framework handle teams that are genuinely cross-cutting -- SRE teams, security teams, data engineering teams? These don't map cleanly to "enabling" since they often own production systems, but they serve multiple streams. - The "thinnest viable platform" is a great concept, but how do you prevent it from becoming an excuse for underinvestment? Where's the line between "thin" and "neglected"? - The book assumes that stream-aligned teams should own the full delivery lifecycle. In regulated industries where segregation of duties is legally required, how does this work in practice? - How do the interaction modes work when one team is remote and the other is colocated? The book was published just before the pandemic made this question universal. - The framework is designed for software organizations. How well does it translate to hardware-software organizations, or to organizations where software is a supporting function rather than the core product? ## Connections to Other Works - [[Accelerate]] by Forsgren, Humble, and Kim -- the research foundation that validates many of Team Topologies' claims about team structure and delivery performance. - [[The Mythical Man-Month]] by Fred Brooks -- Brooks's law on adding people to teams anticipates the cognitive load arguments. Conway's law first appeared in the same era. - [[Domain-Driven Design]] by Eric Evans -- bounded contexts from DDD directly map to the fracture planes concept and inform how stream-aligned teams should be scoped. - [[High Output Management]] by Andy Grove -- Grove's concept of task-relevant maturity connects to how interaction modes should evolve as teams gain capability. - [[The Phoenix Project]] by Kim, Behr, and Spafford -- the narrative illustration of what happens when teams aren't aligned to flow, and the bottleneck patterns that Team Topologies aims to prevent. - [[Execution]] by Bossidy and Charan -- Bossidy's social operating mechanisms parallel the team interaction modes as structured ways to shape organizational behavior. --- # Reading Notes - Conway's law as stated in the original 1968 paper is more nuanced than the bumper-sticker version. The full implication isn't just "teams copy their communication into code" but that *flexibility of organization is important to effective design* -- the system design may need to change, so the org must be able to change too. - The "team API" concept -- treating a team's interface as code, documentation, onboarding, and communication preferences -- is useful beyond software organizations. Any team that other teams depend on has an API whether they've defined it or not. - Dunbar's number applied to teams: trust drops off sharply beyond 5 people, and practical working relationships top out around 15. This puts a hard ceiling on team size that most organizations ignore when they create 20+ person "teams." - The distinction between enabling teams (who teach and leave) and platform teams (who build and maintain services) is sharper than it first appears. Confusing these two types is a common mistake -- the enabling team that starts building things becomes a bottleneck, and the platform team that tries to "enable" instead of providing a product frustrates its users. - "Thinnest viable platform" is this book's version of "minimum viable product." It's a useful corrective to the tendency to build enormous internal platforms before anyone has asked for them. A wiki page with clear instructions can be a platform. - The fracture plane concept deserves more attention than it gets. Splitting systems by technology layer (frontend/backend/database) forces every feature to cross team boundaries. Splitting by business domain lets most features be delivered by a single team. This is obvious in hindsight but still rare in practice. - The collaboration-to-X-as-a-Service evolution pattern is the book's most practical contribution to organizational design. It gives teams a reason to collaborate intensely for a defined period and then back off -- instead of either permanent tight coupling or permanent isolation. - The uSwitch quote stands out: "We didn't change our organization because we wanted to use Kubernetes; we used Kubernetes because we wanted to change our organization." Technology adoption as an organizational lever, not just a technical decision. - The book's five-step "getting started" guide in the conclusion is worth more than many full books on organizational change: start with the team, identify streams, identify a thinnest viable platform, identify capability gaps, share and practice interaction modes. - The argument against separate "maintenance" and "new development" teams connects directly to the DevOps movement's core insight: separating build from run breaks feedback loops. Teams that only build never learn from operational reality. Teams that only maintain never get to apply what they've learned.