Team Topologies – Complete Book Summary & All Key Ideas

Unlocking fast flow: a summary of team topologies

Quick orientation

“Team topologies: organizing business and technology teams for fast flow” by Matthew Skelton and Manuel Pais offers a practical and adaptive model for designing effective team structures in modern software organizations. The book aims to help businesses move beyond traditional, often counterproductive, organizational charts to achieve rapid and sustainable software delivery. Its relevance is paramount for any organization looking to improve team performance, reduce cognitive load, and strategically align its structure with its software architecture to thrive in a constantly changing technological landscape.

This summary will provide simple, clear explanations of every key idea from “Team topologies,” guiding you through its core concepts and actionable advice. We’ll explore how to rethink team structures, leverage Conway’s law, and evolve your organization for continuous innovation and rapid delivery.

Chapter 1: The problem with org charts

This chapter introduces the core issue the book addresses: traditional organizational charts are often misaligned with how work actually gets done, hindering fast flow and adaptability. It sets the stage for a new way of thinking about teams and their interactions within a sociotechnical system.

Communication structures and their impact

Traditional org charts depict hierarchical reporting lines, but actual communication for getting work done is far more complex and often lateral. Relying solely on the org chart for structuring work can lead to inefficiencies and bottlenecks.

Recognize reality: Understand that formal org charts rarely reflect the true communication pathways crucial for value delivery.
Identify informal structures: Acknowledge the “value creation structure” where work happens based on reputation and inter-team collaboration, not just formal lines.
Avoid local optimization: Be aware that org-chart-based decisions often optimize for one part of the organization, potentially creating bottlenecks elsewhere.
Embrace systems thinking: Focus on optimizing the whole flow of work rather than isolated team performance.
Shift from static views: Move beyond static structures like matrix management, which quickly become outdated in fast-evolving environments.

Team topologies: a new way of thinking

The book proposes Team Topologies as an adaptive model for organization design, emphasizing dynamic team structures and interaction modes. This approach aims to help teams achieve fast and safe software delivery.

Define team topologies: Understand it as a model for evolving team design to cope with technology, people, and business changes.
Introduce core elements: The model is built around four fundamental team types and three core interaction modes.
Prioritize humanistic approach: Recognize that Team Topologies values teams as indivisible units and respects their finite cognitive capacity.
Use as a strategic tool: See this approach as a way to facilitate solution discovery and align software with customer needs.

The revival of Conway’s law

Conway’s law, stating that organizations produce designs that mirror their communication structures, is presented as a critical concept. The book emphasizes using this law strategically.

Understand Conway’s law: Grasp that software architecture is constrained by the organization’s actual communication paths.
Apply the reverse Conway maneuver: Intentionally organize team structures to achieve the desired system architecture.
Link architecture and teams: Recognize that software architecture cannot be designed in isolation from team structures.
Prevent unintended designs: Use team structures that match the required software architecture to avoid undesirable outcomes.

Cognitive load and bottlenecks

The chapter highlights the importance of managing the cognitive load on teams, as exceeding this capacity leads to decreased performance and motivation.

Define cognitive load: Understand it as the total mental effort being used in working memory, which applies to teams as well as individuals.
Recognize overload symptoms: Identify when teams are spread too thin across too many responsibilities, leading to context switching and reduced mastery.
Prioritize team well-being: Advocate for restricting team cognitive load to improve intrinsic motivation (autonomy, mastery, purpose).
Use as a design tool: Consider cognitive load when deciding team size, assigning responsibilities, and establishing team boundaries.

This chapter ultimately encourages a rethinking of team structures, their purpose, and how they interact to overcome common obstacles to fast and safe software delivery.

Chapter 2: Conway’s law and why it matters

This chapter delves deeper into Conway’s law, explaining its critical importance for effective team and system design in technology organizations. It explores how understanding and strategically applying this law can lead to more efficient and adaptable software architectures.

Understanding and using Conway’s law

Conway’s law dictates that the structure of a system will mirror the communication structure of the organization that built it. This has profound implications for how organizations should be designed.

Acknowledge the constraint: Recognize that organizational communication paths inherently limit the types of solutions a team can effectively develop.
See the homomorphic force: Understand that there’s a natural tendency for software architecture and team structures to take on similar shapes.
Leverage strategically: Use this understanding to shape communication paths, making desired architectural outcomes more likely.
Involve technical expertise in org design: Ensure that those deciding team structures understand the architectural implications, as managers implicitly decide system architecture.

The reverse Conway maneuver

Instead of letting the existing organization dictate the system architecture, the reverse Conway maneuver involves consciously structuring teams to foster the desired architecture.

Define the maneuver: Intentionally design team intercommunications before the software is finalized to achieve a target architecture.
Support autonomous teams: Aim for an architecture that allows teams to work independently, minimizing high-bandwidth communication between them.
Align teams to services: For example, if microservices with independent data stores are desired, ensure teams have the necessary embedded data capabilities rather than relying on a central DBA team for all changes.
Anticipate architectural outcomes: Design team structures that will naturally lead to the software architecture you want.

Software architectures that encourage team-scoped flow

The architecture of software systems should be designed to enable and encourage fast flow within each team, as the team is the fundamental unit of delivery.

Prioritize loose coupling: Ensure components do not have strong dependencies on other components managed by different teams.
Strive for high cohesion: Design components with clearly bounded responsibilities and strongly related internal elements.
Maintain clear versioning: Implement clear and appropriate version compatibility to manage dependencies.
Enable team-sized ownership: Structure software to allow teams to understand, contribute to, and own their modules effectively, limiting module size to fit team cognitive load.
Design for change absorption: Partition architecture to gracefully absorb changes, making it an enabler rather than a hindrance.

Restrict unnecessary communication

Counterintuitively, more communication is not always better. Effective system design often requires limiting communication to focused, necessary interactions.

Define team interfaces: Set clear expectations about what kind of work requires strong collaboration and what doesn’t.
Identify unexpected communication: Investigate communication happening between teams that, logically, shouldn’t need to interact, as it may signal architectural flaws.
Aim for low-bandwidth interaction: Strive for minimal necessary communication between most teams to maintain modularity.
Avoid “everyone communicates with everyone”: This pattern leads to monolithic, tangled systems and should be discouraged by thoughtful org design.
Use physical/virtual separation: Consider office layout or chat tool structures to reinforce desired low-bandwidth communication paths.

This chapter establishes that Conway’s law is a critical force in software development, and by understanding and strategically applying it, organizations can design more efficient teams and achieve better architectural outcomes.

Chapter 3: Team-first thinking

This chapter champions the team as the fundamental unit of software delivery, rather than individuals. It outlines key principles for designing and supporting teams to maximize their effectiveness, focusing on size, longevity, cognitive load, and clear boundaries.

Use small, long-lived teams as the standard

The book advocates for stable teams of a specific size, emphasizing that this structure fosters trust, cohesion, and higher performance.

Define “team”: Understand a team as a stable group of five to nine people working as a unit towards a shared goal.
Respect Dunbar’s number: Limit team size to maximize trust and effective communication; Amazon’s “two-pizza teams” exemplify this.
Scale with Dunbar’s layers: Apply these size limits to groupings of teams (e.g., “tribes” of no more than 50-150 people).
Prioritize stability: Keep teams stable and “flow the work to the team,” as teams take time (weeks to months) to become highly effective.
Embrace team ownership: Ensure every part of the software system is owned by exactly one team to foster continuity of care and accountability.
Cultivate team-first mindset: Encourage members to prioritize team needs and goals over individual ones.
Value diversity: Recognize that diverse teams tend to produce more creative solutions and better empathize with user needs.
Reward the whole team: Shift from individual rewards to team-based recognition to foster collective effort.

Good boundaries minimize cognitive load

To ensure teams can effectively own and evolve software, their responsibilities must be matched to their collective cognitive capacity.

Define cognitive load types: Understand intrinsic (task-fundamental), extraneous (environment-related), and germane (learning/high-performance) cognitive load.
Minimize extraneous load: Aim to eliminate unnecessary tasks or complex processes that don’t add value, freeing up capacity for germane load.
Restrict responsibilities: Limit the size and complexity of the software or the number of domains a team handles to fit their cognitive capacity.
Measure cognitive load (qualitatively): Regularly ask teams if they feel effective and able to respond in a timely manner.
Limit domains per team: As a heuristic, assign no more than one complex domain or two to three simple domains to a single team.
Match software boundaries to team load: Design software subsystems to be “team-sized,” ensuring a team can comfortably own and manage their part.
Improve the team’s ecosystem: Enhance the working environment, minimize distractions, and provide good platforms to increase a team’s cognitive capacity.

Design “team APIs” and facilitate team interactions

Teams need clear interfaces for interacting with each other, and the organization should support these interactions and continuous learning.

Define the “team API”: This includes not just code (runtime endpoints, libraries) but also documentation, practices, communication norms, and work visibility.
Focus on usability: Ensure a team’s API is easy for other teams to understand and use, facilitating smooth inter-team collaboration.
Facilitate inter-team learning: Provide time, space, and budget for communities of practice, guilds, and internal tech conferences to build trust and share knowledge.
Design the environment: Consciously shape physical (e.g., team-focused office spaces like at CDL or Auto Trader) and virtual environments (e.g., clear chat channel naming) to support desired team interactions.
Acknowledge foundational engineering practices: Recognize that effective team structures must be supported by practices like continuous delivery, test-first development, and a focus on operability.

This chapter emphasizes that by putting the team first—considering its size, stability, cognitive load, and interaction mechanisms—organizations can create an environment where teams thrive and deliver value more effectively.

Chapter 4: Static team topologies

This chapter transitions from foundational principles to specific team structures, exploring common patterns and anti-patterns in team organization, particularly in the context of DevOps. It argues for intentional team design rather than ad hoc formations, considering factors like organizational maturity and engineering discipline.

Team anti-patterns

Organizations often fall into detrimental patterns when team design isn’t deliberate, leading to inefficiencies and reduced flow.

Avoid ad hoc team design: Recognize that reactive team creation (e.g., a new team for all COTS software, or breaking up oversized teams without a plan) often fails to consider broader system interrelationships.
Prevent constant shuffling: Understand that assembling teams on a project basis and then disassembling them destroys cohesion and overlooks the cost of team formation and context switching.
Design teams intentionally: Proactively ask which team topology best fits the current skills, constraints, desired architecture, and business goals to optimize delivery.

Design for flow of change

Effective organizational design prioritizes the smooth and rapid flow of changes from concept to live software, emphasizing feedback and continuous learning.

Learn from Spotify (cautiously): Understand models like Spotify’s squads and tribes as examples of explicit design for flow, but avoid blindly copying them without considering context.
Optimize for feedback loops: Ensure that information from live systems flows back to development teams, enabling them to improve software rapidly and respond to user needs.
Embrace organizational sensing: Treat frontline teams as valuable sources of signals about the market and operational environment.
Move beyond linear hand-offs: Shift from a stepwise sequence of Dev-Test-Ops to cross-functional teams responsible for the entire lifecycle.

DevOps and the DevOps topologies

The DevOps movement highlighted the friction caused by misaligned team interactions. The DevOps Topologies catalog offers patterns to address these issues.

Understand DevOps origins: Recognize DevOps as a response to the “wall of confusion” between development, operations, and other siloed teams.
Use the DevOps Topologies catalog: Leverage this collection of team design patterns and anti-patterns to discuss team responsibilities, interfaces, and collaboration.
Recognize context dependency: Understand there’s no one-size-fits-all DevOps team structure; suitability depends on organization size, maturity, and goals.
Evolve topologies over time: View these patterns not as static endpoints but as snapshots that should adapt as the organization matures (e.g., Accenture’s client evolving from a siloed DevOps team to an evangelist model).

Successful team patterns and considerations

The success of any team pattern depends heavily on the surrounding environment, including engineering maturity and the support systems in place.

Support feature teams properly: Realize that cross-functional feature teams delivering end-to-end value require high engineering maturity and non-blocking dependencies (e.g., self-service platforms) to be effective.
Enable product teams: Understand that product teams, similar to feature teams, need a supportive ecosystem of easy-to-consume services (like Microsoft’s use of Azure) to maintain autonomy.
Reimagine cloud teams: Ensure cloud teams provide self-service capabilities for product teams rather than just replicating traditional infrastructure processes in the cloud.
Implement SRE strategically: Understand Site Reliability Engineering (SRE) as a dynamic model (like at Google) suitable for large-scale, high-reliability systems, requiring strong coding skills in Ops and clear error budgets. It’s not a universal solution.
Consider organizational context: Factor in technical/cultural maturity, organization size, software scale, and engineering discipline when choosing a topology (e.g., the TransUnion case study showing evolution based on these factors).
Break down silos by splitting responsibilities: For example, separate database development (embedding it in stream teams) from database administration (making it a platform service).
Track dependencies: Monitor inter-team dependencies and wait times to identify constraints and inform team design adjustments.

This chapter stresses that team topologies must be chosen deliberately and evolved, matching the organization’s current context and aiming for a fast flow of change, with a clear understanding of how different patterns support or hinder this goal.

Chapter 5: The four fundamental team topologies

This chapter introduces the core of the Team Topologies model: a simplified set of just four fundamental team types. The authors argue that these four types are sufficient for building and running modern software systems, providing clarity and reducing ambiguity in organizational design.

The four fundamental team topologies

Restricting team variations to these four types helps organizations visualize their landscape, identify capability gaps, and balance team autonomy with necessary support.

Stream-aligned team: The primary team type, aligned to a continuous flow of work in a specific business domain or organizational capability (e.g., a single product, feature set, or user journey). Empowered for end-to-end delivery.
Enabling team: Composed of specialists who help stream-aligned teams acquire missing capabilities or adopt new technologies/practices, acting as internal consultants (e.g., a team helping others with CI/CD adoption). Their goal is to make other teams self-sufficient.
Complicated-subsystem team: Responsible for a part of the system requiring deep specialist knowledge that cannot be easily embedded in stream-aligned teams (e.g., a team managing a complex video processing codec or a real-time trading algorithm). Used sparingly.
Platform team: Provides a foundation of self-service APIs, tools, and services that stream-aligned teams use to deliver their work with more autonomy, reducing their cognitive load (e.g., a team offering an internal cloud platform).

Stream-aligned teams

These are the main delivery units in an organization, focused on a continuous flow of value to the customer.

Focus on a single stream: Aligned to one valuable stream of work, be it a product, service, feature set, or user journey.
Empower for end-to-end delivery: Possess the skills and authority to build, deliver, and operate their part of the system without hand-offs.
Embrace customer proximity: Work closely with customers, incorporate feedback quickly, and monitor their software in production.
Require diverse capabilities: As a team, cover areas like application security, design, development, infrastructure, metrics, product management, testing, and UX.
Prioritize flow and learning: Aim for a steady flow of features, quick course correction, and an experimental approach to product evolution. The Amazon “two-pizza teams” model is an example.

Enabling teams

These teams help bridge capability gaps for stream-aligned teams, facilitating learning and adoption of new skills or technologies.

Act as internal consultants: Composed of specialists who research, trial, and suggest tools, practices, and frameworks.
Focus on empowering others: Their primary goal is to increase the autonomy and capabilities of stream-aligned teams, not to execute work for them.
Avoid becoming ivory towers: Work collaboratively and ensure their guidance is practical and problem-focused.
Plan for their own obsolescence (in specific engagements): Once a stream-aligned team has acquired the needed capability, the enabling team moves on to help others. (e.g., the engineering enablement team at a large legal organization).
Differ from communities of practice (CoP): Enabling teams are full-time, focused engagements, while CoPs are more diffuse, voluntary learning groups.

Complicated-subsystem teams

These teams manage parts of the system that are exceptionally complex and require highly specialized knowledge.

Handle deep specialist knowledge: Created only when a subsystem requires expertise that most team members must possess to make changes (e.g., a face-recognition engine).
Reduce cognitive load for others: Offload the complexity of this specific subsystem from stream-aligned teams that use it.
Use sparingly: Unlike traditional component teams (often created for any shared component), these are reserved for truly complex areas where specialization is unavoidable.
Adapt interaction: Collaborate closely with stream-aligned teams during early development and shift to a more service-oriented interaction as the subsystem stabilizes.

Platform teams

These teams provide the underlying services and infrastructure that stream-aligned teams need to deliver their work efficiently and autonomously.

Enable self-service: Offer APIs, tools, services, and knowledge as a compelling internal product that other teams can consume.
Reduce cognitive load: Abstract away lower-level complexities (e.g., provisioning, monitoring, deployment) so stream-aligned teams can focus on business logic.
Treat the platform as a product: Focus on usability, reliability, and fitness for purpose, with internal teams as their customers.
Compose from other topologies (at scale): Large platforms may themselves be built by stream-aligned, enabling, and even lower-level platform teams (e.g., Auto Trader’s Infrastructure Engineering).
Aim for a “thinnest viable platform” (TVP): Provide just enough to accelerate delivery without becoming overly complex or prescriptive. Sky Betting & Gaming’s evolution of their platform team illustrates this.

This chapter provides a clear and concise model of four fundamental team types, designed to simplify organizational structure, clarify responsibilities, and promote a fast flow of change.

Chapter 6: Choose team-first boundaries

This chapter focuses on how to define the responsibilities and boundaries of software systems in a way that aligns with team capabilities, particularly their cognitive load. It emphasizes that software architecture should be designed to support effective team ownership and flow.

A team-first approach to software responsibilities and boundaries

The way software is divided among teams has a direct impact on their ability to deliver effectively. Boundaries should be drawn with the team’s capacity in mind.

Align architecture with teams: Instead of designing a system in the abstract, design it and its boundaries to fit the available cognitive load within delivery teams.
Avoid distributed monoliths: Be cautious when splitting monoliths to prevent creating a complex web of interdependent services that hinder team autonomy.
Consider team context: Factor in team cognitive capacity, location, and interest when assigning responsibilities for new or refactored services.
Prioritize team ownership: Ensure that boundaries allow a single team to effectively own and evolve their part of the system.

Hidden monoliths and coupling

Monolithic characteristics can exist in various forms, not just in a single large application, and these can impede flow and team autonomy.

Identify application monoliths: Recognize single, large applications deployed as a unit that are hard to change and test.
Spot joined-at-the-database monoliths: Be aware of systems where multiple applications are tightly coupled through a shared database schema.
Recognize monolithic builds/releases: Identify situations where, even with smaller services, everything is built or released together, negating independence.
Challenge monolithic models/thinking: Avoid forcing a single domain model or a “one-size-fits-all” technology stack across diverse contexts, as it stifles appropriate solutions and team motivation.
Rethink monolithic workplaces: Question standardized office layouts (like pure open-plan) that don’t cater to different team needs for focus and collaboration.

Software boundaries or “fracture planes”

To break down monolithic systems or design new ones effectively, look for natural seams or “fracture planes” along which the software can be logically divided.

Define fracture planes: Understand these as natural seams in a software system allowing it to be split into parts that teams can own.
Prioritize business domain bounded contexts: Align most software boundaries with bounded contexts from Domain-Driven Design (DDD), where each part represents an internally consistent business area (e.g., Poppulo aligning teams to domains like email, calendar, people).
Use regulatory compliance as a boundary: In regulated industries (finance, healthcare), isolate systems subject to specific rules (e.g., PCI DSS for payment processing) to simplify auditing and reduce scope.
Consider change cadence: Split parts of the system that naturally change at different frequencies to allow faster-moving parts to evolve independently.
Factor in team location: If teams are geographically distributed, align software boundaries to minimize cross-location dependencies and leverage Conway’s Law.
Align with risk profiles: Separate subsystems with different risk appetites (e.g., high-risk marketing experiments vs. low-risk transactional systems).
Isolate for performance: Split off parts of the system with unique, critical performance requirements (e.g., a high-volume tax submission service).
Use technology as a boundary (cautiously): Consider this for integrating older or very different tech stacks (e.g., embedded vs. cloud vs. mobile in an IoT product), but avoid default tech-layer-based team splits (front-end/back-end).
Align with user personas: If distinct user groups have very different needs or feature sets (e.g., admin vs. regular users, free vs. paid tiers), this can be a valid fracture plane.
Test for “as-a-service” viability: Ask if a subsystem could be effectively consumed or provided “as a service” by a team; if yes, it’s a good candidate for a boundary.

This chapter guides organizations to choose software boundaries that respect team cognitive load and align with natural system seams, ultimately fostering faster flow and more sustainable software evolution.

Chapter 7: Team interaction modes

This chapter moves beyond static team structures to define how teams should interact. It introduces three essential interaction modes—collaboration, X-as-a-Service, and facilitating—to simplify and clarify the interdependencies needed for effective software delivery.

Well-defined interactions are key to effective teams

Poorly defined team interactions and responsibilities are a common source of friction. Clear interaction modes help manage these interdependencies.

Clarify interaction needs: Teams must decide whether to collaborate closely with another team or consume/provide a service with minimal interaction.
Avoid “all-to-all” communication: Curate communication pathways, much like a jazz band coordinates its music, rather than expecting all teams to interact with all others.
Recognize the value of intermittent collaboration: Research suggests that intermittent breaks in interaction can improve collective problem-solving.
Formalize interactions: Using defined modes helps assess effectiveness, define team interfaces, and, per Conway’s Law, influence software interfaces.

The three essential team interaction modes

These three modes cover the necessary ways teams can and should interact, taking into account team-first dynamics and Conway’s Law.

Collaboration: Two teams work closely together on a defined problem for a specific period, ideal for rapid discovery, innovation, and exploring new technologies. This blurs responsibility boundaries temporarily.
X-as-a-Service: One team consumes a well-defined component, API, or platform from another team with minimal ongoing collaboration. This provides clarity of ownership and predictable delivery.
Facilitating: One team (often an enabling team) helps another team learn, adopt new practices, or overcome impediments. The facilitating team doesn’t build the main system but improves the effectiveness of those who do.

Collaboration: driver of innovation and rapid discovery

This mode is best for situations requiring high adaptability and learning, though it comes with higher cognitive load.

Use for discovery: Ideal for exploring new technologies or techniques that span the expertise of two teams (e.g., cloud and embedded teams working on an IoT solution).
Share responsibility: Both teams take joint responsibility for the outcomes of their collaboration.
Expect higher cognitive load: Team members need to understand more about the other team’s domain, but this “collaboration tax” is justified by rapid learning.
Limit concurrent collaborations: A team should typically collaborate closely with at most one other team at a time.
Anticipate architectural blending: Conway’s Law suggests that close collaboration will lead to more blended software responsibilities and architecture.

X-as-a-Service: clear responsibilities with predictable delivery

This mode suits situations where one team needs a reliable service from another, allowing the consuming team to focus on their core work.

Use for predictable delivery: Best when a component or service is well-understood and can be provided reliably by a distinct team.
Demand good service management: The team providing the service must treat it like a product, focusing on usability (DevEx), reliability, versioning, and clear documentation.
Minimize ongoing interaction: The goal is for the consuming team to use the service with little day-to-day collaboration.
Ensure well-chosen boundaries: This mode only works if the service boundary is effective and the service meets consumer needs.
Expect slower boundary innovation: The clear API means the interface itself evolves more slowly than in collaboration mode.

Facilitating: sense and reduce gaps in capabilities

This mode involves one team actively helping another to improve, often by an enabling team assisting stream-aligned teams.

Focus on empowerment: The facilitating team aims to make the other team self-sufficient in a specific area (e.g., adopting new testing practices).
Identify cross-team issues: Facilitators can detect common problems or gaps in platforms/services used by multiple teams and advocate for improvements.
Avoid building the system: The facilitating team focuses on improving interactions and capabilities, not on direct software delivery.
Require experienced staff: Effective facilitation needs skilled individuals who can coach and guide without taking over.

Choosing suitable team interaction modes

Each of the four fundamental team topologies has typical interaction modes, though these can change based on context. (e.g., stream-aligned teams typically use X-as-a-Service or collaboration; enabling teams primarily use facilitation; platform teams provide X-as-a-Service). The IBM case study (Figure 7.6) shows a DevOps advocates team using facilitation. Using the reverse Conway maneuver often involves temporary collaboration and facilitation to establish new boundaries.

This chapter emphasizes that by defining and consciously choosing among these three interaction modes, organizations can improve clarity, reduce friction, and strategically shape both team dynamics and software architecture.

Chapter 8: Evolve team structures with organizational sensing

This chapter explores the dynamic nature of team topologies, emphasizing that organizations must adapt their structures and interactions in response to changing circumstances. It introduces the concept of “organizational sensing,” where team interactions and performance act as signals for necessary evolution.

How much collaboration is right for each team interaction?

The choice between collaboration and X-as-a-Service is not static; it depends on the goals and maturity of the interacting teams and the systems they are building.

Balance discovery and delivery: Collaboration is good for rapid discovery but costly in cognitive load; X-as-a-Service supports predictable delivery with lower load.
Restrict ongoing collaboration: Ensure any sustained collaboration provides clear value in discovery, capability building, or addressing deficiencies, as it’s expensive.
Use collaboration to establish XaaS: Teams might collaborate intensely to define a new service and its API, then transition to an X-as-a-Service model once the boundary is stable.
Enable strategic change: Intentionally shifting interaction modes can drive organizational change, as seen in uSwitch’s adoption of Kubernetes to change their team organization.

Accelerate learning and adoption of new practices

Deliberately changing team interaction modes can be a powerful tool for organizational learning and capability development.

Facilitate cross-skilling: Bringing teams with different expertise (e.g., cloud and embedded software specialists) into a collaboration mode can help both teams learn and improve practices.
Discover platform needs: Such collaboration can also reveal whether a particular technology or service area (like cloud or embedded systems in the example) should evolve into a platform.
Evolve team relationships: The TransUnion case study demonstrates a multi-year evolution from separate Dev and Ops teams to collaborating build teams, then a merged enabling team, and finally to Dev teams owning operations with a supporting platform.

Constant evolution of team topologies

Team interactions and structures should be expected to change over time as systems mature, technologies evolve, and organizational needs shift.

Move from discovery to establishment: Teams may start with close collaboration to explore a new area, then transition to more limited collaboration, and finally to an X-as-a-Service model as solutions stabilize.
Expect simultaneous evolution: In a larger organization, different teams will be at different stages of this evolutionary pattern at any given time.
Design for adaptability: The key is not a fixed organizational shape but the rules and heuristics used to adapt as challenges arise.
Evolve slowly but deliberately: Team topologies change over months, not days, allowing for considered adjustments to interaction modes and software architecture. The Sky Betting & Gaming case study shows platform teams evolving into product-driven units.

Triggers for evolution of team topologies

Recognizing signals that indicate a need for structural change is crucial for maintaining adaptability and flow.

Software grows too large for one team: Symptoms include a startup exceeding Dunbar’s number, teams waiting on a single overloaded team, or implicit specialization within a team becoming a bottleneck.
Delivery cadence slows down: If releases take longer, velocity drops, or WIP increases due to inter-team dependencies, the current topology may be a constraint. This can also be due to accrued technical debt or new silos.
Multiple services rely on many underlying services: When stream-aligned teams struggle with complex integrations to numerous lower-level services, a “platform wrapper” might be needed to provide a consistent DevEx and better telemetry.

Self-steer design and development

Modern organizations should use operational feedback as a primary input for development, creating a cybernetic system for self-steering.

Treat teams as sensors: Use team interactions and performance (both internal and customer-facing) as signals to sense the organizational and market environment.
Use IT operations as high-value input: Ensure rich feedback loops from operations to development, as advocated by The Three Ways of DevOps. This means Ops and Dev should be closely aligned, ideally on the same team or stream.
Foster continuity of care: Avoid separate “maintenance” or “BAU” teams. Instead, have stream-aligned teams responsible for both new development and the ongoing operation/evolution of existing systems, promoting learning and preventing repeated mistakes.
Staff operations with skilled people: Ensure those in operational roles can quickly and accurately diagnose issues, providing high-fidelity feedback.

This chapter underscores that team topologies are not a one-time design but an evolving system. By actively sensing through team interactions and responding to triggers for change, organizations can continuously adapt and improve their ability to deliver value.

Big-picture wrap-up

“Team topologies” provides a compelling and actionable framework for organizing business and technology teams to achieve a state of fast, sustainable flow. It moves beyond simplistic org charts to address the sociotechnical dynamics of modern software development, emphasizing clear team purposes, well-defined interactions, and continuous evolution. By focusing on team cognitive load, leveraging Conway’s Law strategically, and using a constrained set of team types and interaction modes, organizations can create an adaptive system that thrives on change.

Core takeaway: Effective organization design for fast flow requires a team-first approach, using a limited set of well-defined team types (Stream-aligned, Platform, Enabling, Complicated-Subsystem) and interaction modes (Collaboration, X-as-a-Service, Facilitating), while strategically applying Conway’s Law and managing team cognitive load.
Next action: Start by evaluating your current team structures and identify one or two teams whose purpose and interactions could be clarified using the fundamental topologies and modes. This is crucial because clear roles and responsibilities are the foundation for reducing friction and improving flow.
Strategic thinking: Understand that team boundaries and software architecture are deeply intertwined (Conway’s Law); design them together, not in isolation.
Human-centric design: Always consider team cognitive load; software should be sized for teams, not the other way around.
Embrace evolution: Team topologies are not static; continuously sense and adapt your organizational design in response to new challenges and opportunities.
Platform as a product: If you have platform teams, ensure they treat their offerings as internal products with a strong focus on developer experience (DevEx).
Interaction clarity: Explicitly define and manage how teams interact to avoid ambiguity and improve overall system health.
Reflective question: How does our current organizational structure help or hinder our ability to deliver value quickly and adapt to changing customer needs?