Team Topologies

The Problem With Org Charts

Look beyond org charts: Recognize that traditional organizational charts fail to show how work actually flows
Focus on team interactions: Pay attention to how teams communicate and collaborate, not just reporting lines
Optimize for flow: Design organizations to optimize the flow of change from idea to production
Limit cognitive load: Structure teams to manage cognitive load and avoid overwhelming team members
Address Conway’s Law proactively: Understand that system architecture will mirror communication structure
Consider team cognitive capacity: Recognize that teams have limited capacity for complexity and change
Define clear team boundaries: Establish explicit boundaries between teams to reduce coordination overhead
Align team structures with business needs: Design team structures that support business capabilities
Reduce unnecessary dependencies: Minimize dependencies that slow down delivery
Revisit team design regularly: Continuously evolve team structures based on changing needs

Conway’s Law and Why It Matters

Understand Conway’s Law: Recognize that organizations design systems that mirror their communication structures
Design team boundaries intentionally: Shape team boundaries to influence system architecture
Use Reverse Conway Maneuver: Structure teams to reflect the desired system architecture
Address communication paths: Focus on communication paths between teams, not just within teams
Recognize sociotechnical nature: Understand that software development is a sociotechnical system
Design for effective collaboration: Create team structures that facilitate necessary collaboration
Limit unnecessary coordination: Restrict cross-team coordination to where it’s actually needed
Match organization to architecture: Align organizational structure with target architecture
Consider software boundaries: Design team boundaries that reflect desired software boundaries
Evolve structure with architecture: Change team structures as system architecture evolves

Team-First Thinking

Make teams the primary unit: Treat teams, not individuals, as the basic unit of delivery
Design for team stability: Maintain long-lived, stable teams rather than frequently reorganizing
Focus on team effectiveness: Prioritize making teams effective over individual productivity
Limit team size: Keep teams small enough to be fed with two pizzas (5-9 people)
Create psychological safety: Build psychological safety within teams to enable learning and innovation
Empower teams appropriately: Give teams the authority to make decisions about their work
Allow teams to form habits: Recognize the importance of team habits and routines
Respect team boundaries: Avoid disrupting teams with constant reorganization or resource reallocation
Provide team-level goals: Set goals and metrics at the team level, not just for individuals
Invest in team capabilities: Develop team capabilities systematically rather than focusing solely on individual skills

Static Team Topologies

Avoid copying team patterns: Don’t simply adopt team structures from other organizations
Beware matrix management: Recognize the limitations and challenges of matrix organizations
Don’t separate Dev and Ops unnecessarily: Understand the problems with separating development and operations
Move beyond project teams: Recognize the limitations of temporary project-based teams
Limit feature teams size and scope: Ensure feature teams are focused on manageable domains
Align teams to business capabilities: Structure teams around business capabilities rather than technology
Recognize component team limitations: Understand the drawbacks of organizing around technical components
Balance specialized and cross-functional teams: Find the right mix of specialized expertise and cross-functional capabilities
Avoid siloed infrastructure teams: Recognize the bottlenecks created by siloed infrastructure teams
Question front-end/back-end splits: Consider whether separating front-end and back-end teams serves your architecture

Fundamental Team Topologies

Limit to four fundamental team types: Use stream-aligned, platform, enabling, and complicated-subsystem teams as your primary types
Prioritize stream-aligned teams: Make stream-aligned teams your primary team type
Create platform teams to reduce cognitive load: Use platform teams to provide internal services that reduce cognitive load
Use enabling teams for knowledge gaps: Deploy enabling teams to help other teams build capability
Establish complicated-subsystem teams sparingly: Create complicated-subsystem teams only for genuinely complex components
Define team purpose explicitly: Ensure each team has a clear understanding of its purpose and type
Align stream teams to business value: Connect stream-aligned teams directly to business value streams
Design platforms for self-service: Build internal platforms focused on developer experience and self-service
Make enabling teams temporary: Treat enabling teams as temporary coaches rather than permanent dependencies
Keep complicated-subsystem teams focused: Ensure complicated-subsystem teams have a narrow, well-defined scope

Team Interaction Modes

Limit to three interaction modes: Use collaboration, X-as-a-Service, and facilitating as your primary modes
Choose interaction modes deliberately: Select the appropriate interaction mode for each team boundary
Time-bound collaboration: Limit collaborative team interactions to specific periods
Design clear service boundaries: Create well-defined interfaces for X-as-a-Service interactions
Focus facilitation on capability building: Use facilitating interactions to build team capabilities
Document interaction expectations: Make interaction modes explicit and documented
Change modes when appropriate: Evolve interaction modes as team relationships mature
Reduce cognitive load through interactions: Choose interaction modes that minimize cognitive load
Align interaction modes with team types: Match interaction modes to the types of teams involved
Measure interaction effectiveness: Assess whether interaction modes are working effectively

Team Boundaries

Define explicit team boundaries: Make team boundaries clear and explicit to everyone
Use APIs as team boundaries: Treat APIs as important team boundary mechanisms
Create team interaction design: Design team interactions intentionally, not accidentally
Document boundary expectations: Make boundary-crossing expectations explicit
Reduce cognitive load at boundaries: Design boundaries to minimize cognitive overhead
Align team boundaries with business domains: Match team boundaries to business domain boundaries
Respect team cognitive boundaries: Honor the cognitive limits of teams when designing boundaries
Review boundary effectiveness: Regularly assess whether boundaries are serving their purpose
Evolve boundaries as needed: Change team boundaries as business and technical needs evolve
Balance boundary flexibility and stability: Find the right balance between adaptable and stable boundaries

Evolving Team Structures

Expect team topologies to evolve: Design team structures to change as business and technical needs evolve
Sense and respond to need for change: Develop mechanisms to detect when team structures need to change
Prioritize architectural evolution: Evolve team structures to support changing architecture
Change deliberately, not haphazardly: Make team structure changes intentional and considered
Recognize signs of poor fit: Learn to identify when team structures aren’t working well
Evolve platform teams with needs: Develop platform teams as organizational needs mature
Shift interaction modes appropriately: Change interaction modes as relationships and needs evolve
Allow for team discovery: Enable teams to discover better ways of organizing themselves
Measure team effectiveness during change: Track whether changes improve team performance
Communicate changes clearly: Provide clear communication about why team structures are changing

Cognitive Load and Team Design

Measure and manage cognitive load: Actively assess and manage the cognitive load on teams
Distribute domain knowledge appropriately: Allocate domain knowledge across teams to manage complexity
Balance three types of cognitive load: Consider intrinsic, extraneous, and germane cognitive load
Reduce extraneous cognitive load: Eliminate unnecessary complexity and distractions
Align team size with cognitive capacity: Size teams appropriately for the cognitive load they handle
Design teams around bounded contexts: Use domain-driven design bounded contexts to manage complexity
Create cognitive load-reducing platforms: Build platforms specifically to reduce cognitive load
Monitor cognitive load warning signs: Watch for signs of excessive cognitive load on teams
Balance domain complexity across teams: Distribute complex domains across teams appropriately
Design for team growth and learning: Create space for teams to expand their cognitive capabilities

Design for Team APIs

Think of teams as APIs: Design team interaction points as clear, well-defined APIs
Define explicit team interfaces: Make team interfaces explicit and documented
Create discoverable team capabilities: Ensure team capabilities are easy to discover
Design for clear expectations: Set clear expectations for cross-team dependencies
Document team interaction protocols: Make communication protocols explicit
Version team APIs appropriately: Consider versioning for major changes to team interfaces
Respect team API boundaries: Honor the boundaries established by team APIs
Optimize for reduced coordination: Design team APIs to minimize required coordination
Test team APIs for usability: Ensure team interfaces are easy for other teams to use
Evolve team APIs with feedback: Improve team interfaces based on user feedback

Platforms as a Product

Treat platforms as products: Design internal platforms with the same care as customer-facing products
Focus on developer experience: Prioritize excellent developer experience in platform design
Create self-service capabilities: Design platforms for self-service rather than requiring tickets
Limit cognitive load through platforms: Use platforms explicitly to reduce cognitive load
Align platforms with business needs: Design platforms to enable business-aligned delivery
Avoid the build-it-and-they-will-come fallacy: Understand customer needs before building platform capabilities
Start small and evolve: Begin with minimal viable platforms and evolve based on needs
Measure platform effectiveness: Track whether the platform is meeting its goals
Provide excellent documentation: Create clear, comprehensive documentation for platform users
Balance standardization and team autonomy: Find the right balance between consistent platforms and team flexibility

Conway’s Law in Reverse

Design organization for desired architecture: Structure teams to produce the desired system architecture
Use team design as architectural tool: Treat team design as a way to influence architecture
Address architecture and organization together: Make architectural and organizational decisions in tandem
Test organizational impact on architecture: Assess how organizational changes affect architecture
Use organizational design to fix architectural problems: Address architectural issues through team structure changes
Create space for architecture evolution: Design team structures that allow architecture to evolve
Balance team autonomy with architectural coherence: Find the right balance between team freedom and system coherence
React to emerging architectural patterns: Respond to emergent architectural patterns with organizational changes
Address Conway’s Law consciously: Make explicit decisions about how Conway’s Law will affect your systems
Align boundaries across teams and systems: Ensure team boundaries and system boundaries are aligned

Key Takeaways

Prioritize team structure: Design team structures intentionally to support business and technical goals
Limit to four team types: Use stream-aligned, platform, enabling, and complicated-subsystem teams as your primary types
Manage cognitive load: Structure teams to keep cognitive load at a sustainable level
Design team interactions: Define explicit interaction modes between teams (collaboration, X-as-a-Service, facilitating)
Create clear boundaries: Establish explicit team boundaries with well-defined interfaces
Address Conway’s Law: Use organizational design to influence system architecture (and vice versa)
Evolve team structures: Continuously adapt team structures to changing business and technical needs
Design for flow: Optimize team structures for smooth flow of change from idea to production
Build team-first organizations: Make teams, not individuals, the fundamental unit of delivery
Treat platforms as products: Design internal platforms with the same care as customer-facing products