Team Topologies: Organizing Business and Technology Teams for Fast Flow

Team Topologies: Organizing Business and Technology Teams for Fast Flow

Authors: Matthew Skelton & Manuel Pais
Published: 2019

Overview

Team Topologies provides a practical, pattern-based approach to designing team structures and interactions for effective software delivery. The book introduces four fundamental team types and three core interaction modes that enable fast flow and reduce cognitive load.

Key Ideas

The Four Fundamental Team Types

1. Stream-Aligned Teams

   • Primary team type aligned to a flow of work from a customer segment or business domain
   • Empowered to build and deliver customer or user value as quickly, safely, and independently as possible
   • Should be long-lived and funded, not project-based
   • Minimize handoffs and dependencies

2. Enabling Teams

   • Help stream-aligned teams overcome obstacles and detect missing capabilities
   • Composed of specialists in a given technical domain
   • Work closely with stream-aligned teams for a limited time to increase their capabilities
   • Focus on building awareness and skills, not doing the work for other teams

3. Complicated-Subsystem Teams

   • Build and maintain parts of the system that require specialized knowledge
   • Reduce cognitive load on stream-aligned teams by taking on complex subsystems
   • Examples: video codec optimization, mathematical models, specialized algorithms
   • Only needed where complexity justifies the separation

4. Platform Teams

   • Enable stream-aligned teams to deliver work with substantial autonomy
   • Provide internal services to reduce cognitive load on stream-aligned teams
   • Treat platforms as products with internal customers
   • Focus on developer experience and self-service capabilities

The Three Team Interaction Modes

1. Collaboration

   • Two teams work closely together for a defined period
   • High interaction and mutual respect required
   • Use when discovering new approaches or rapid innovation needed
   • Time-boxed to avoid permanent dependencies

2. X-as-a-Service

   • One team consumes services provided by another team
   • Minimal collaboration needed
   • Clear API/contract between teams
   • Enables autonomy and reduces cognitive load

3. Facilitating

   • One team helps another become more effective
   • Enabling team to stream-aligned team relationship
   • Focus on increasing capabilities, not permanent support
   • Time-limited engagement

Conway’s Law and Team Design

• Organizations design systems that mirror their communication structures
• Use “Reverse Conway Maneuver” to intentionally design team structures to achieve desired architecture
• Team boundaries should align with software boundaries
• Minimize cross-team dependencies to enable fast flow

Cognitive Load Management

• Intrinsic load: Fundamental aspects of the problem space
• Extraneous load: Environment and deployment complexity
• Germane load: Value-added learning and problem-solving

Key principle: Minimize intrinsic and extraneous cognitive load on stream-aligned teams so they can focus on germane load (delivering value).

Team API

Each team should define a clear “Team API” covering:

• Code: Runtime endpoints, libraries, APIs
• Versioning: How consumers are notified of changes
• Documentation: How to use the team’s services
• Communication: Slack channels, email lists
• Work information: Board links, issue tracking
• Practices: Workflows, definition of done

Fast Flow Principles

1. Restrict team responsibilities to match cognitive capacity
2. Design team interactions to enable flow
3. Detect and remove workflow blockers
4. Optimize for team-first architecture
5. Measure and evolve team effectiveness

Practical Takeaways for Principal Engineers

1. Design for cognitive load: When splitting services or creating new teams, consider the total cognitive load, not just lines of code or architectural purity

2. Limit team size: 5-9 people per team (Dunbar’s number for close collaboration)

3. Team-first architecture: Design software boundaries to match team boundaries, not the other way around

4. Explicit interaction modes: Make team interactions explicit and time-bound to prevent accidental dependencies

5. Platform thinking: Build internal platforms that genuinely reduce cognitive load and enable stream-aligned teams

6. Evolution over revolution: Team structures should evolve as the organization and technology mature

7. Measure flow metrics:

   • Lead time for changes
   • Deployment frequency
   • Mean time to restore
   • Change failure rate

8. Avoid common anti-patterns:

   • Ad-hoc team design
   • Shuffling team members
   • Software too big for teams
   • Confusing team mission
   • Too many dependencies

Questions for Reflection

• What type of team are you currently on? Is it the right type for your mission?
• What’s the cognitive load on your teams? Where can it be reduced?
• Are team interactions explicitly designed or accidental?
• Does your architecture enable or hinder team autonomy?
• Are platform teams treating their internal customers as products?

Why This Matters

For organizations building complex software systems, team design is as important as software architecture. Team Topologies provides a vocabulary and framework for intentionally designing organizations that deliver value quickly and sustainably, making it essential reading for principal engineers influencing org design and technical strategy.