Four Fundamental Team Types The core of the Team Topologies model is the identification of four distinct team types, each with a specific purpose and set of responsibilities. These team types are designed to address different aspects of software delivery and system support:
- Stream-Aligned Teams:
- Responsible for delivering value to a specific stream (e.g., a product, service, or customer segment).
- Aligned to end-to-end value streams and empowered to own the entire lifecycle of a product or service, from development to operation.
- Their primary goal is to deliver and optimize customer value continuously.
- Enabling Teams:
- Act as a supportive team, helping stream-aligned teams overcome technical obstacles or adopt new skills and tools.
- They have deep expertise in a specific area, such as DevOps, security, or a new technology stack, and work to upskill other teams through coaching and mentoring.
- Complicated Subsystem Teams:
- Responsible for developing and maintaining complex subsystems that require a high degree of specialized knowledge (e.g., a mathematical model, a machine learning engine, or a low-level optimization component).
- These teams support the other team types by handling components that would otherwise increase cognitive load for the stream-aligned teams.
- Platform Teams:
- Create and maintain internal platforms that provide self-service capabilities for stream-aligned teams (e.g., CI/CD pipelines, cloud infrastructure, monitoring).
- Their goal is to reduce friction and enable stream-aligned teams to focus on delivering value by providing reusable components and infrastructure.
<aside> đź’ˇ
Take a closer look at Fundamental Topologies in FOAM
</aside>
Three Modes of Team Interaction The Team Topologies model emphasizes that different teams need to collaborate in different ways depending on their goals and context. It identifies three primary modes of interaction, each serving a distinct purpose:
- Collaboration:
- Used for situations where teams work together closely for a limited period, usually to solve a complex problem or build a shared understanding.
- Typical in scenarios such as new feature development that requires cross-functional input or joint troubleshooting efforts.
- X-as-a-Service:
- In this mode, one team consumes a service provided by another team, such as a platform team providing cloud resources or an API managed by a subsystem team.
- Enables streamlined interactions, allowing consuming teams to access services without needing in-depth knowledge of the underlying implementation.
- Facilitating:
- Involves an enabling team providing guidance, mentorship, and expertise to a stream-aligned team.
- Typically used to upskill teams in new areas (e.g., adopting DevOps practices or improving code quality), fostering independence and capability.
Cognitive Load Consideration A central concept in Team Topologies is managing cognitive load—the mental effort required to perform a task or understand a system. The model emphasizes structuring teams to limit the cognitive load on each one, ensuring that they can focus on delivering value without being overwhelmed by unnecessary complexity.
- Cognitive load types:
- Intrinsic Load: Related to the specific work a team is responsible for (e.g., building a microservice).
- Extraneous Load: Caused by poorly designed processes, tools, or organizational structures.
- Germane Load: Effort expended in problem-solving or learning within the team’s area of focus.
By ensuring each team’s cognitive load is manageable, the model aims to create a sustainable and high-performance environment where teams can operate efficiently and avoid burnout.
Team API The concept of a Team API refers to a clear definition of how teams communicate and collaborate with each other, specifying interfaces, protocols, and expectations for interaction. A well-defined Team API includes aspects such as:
- Responsiveness: Expected turnaround times for queries or requests.
- Information Sharing: What information is shared and through which channels.
- Service Expectations: SLAs (Service Level Agreements) for any provided services.
This approach allows for smoother inter-team communication, reducing ambiguity and friction.
<aside> đź’ˇ
Take a closer look at Team Topologies’ Team API in FOAM
</aside>
Conway’s Law and Organizational Design The Team Topologies model takes inspiration from Conway’s Law, which states that an organization’s structure will influence the design of its systems. To achieve optimal software architecture, the model advocates aligning team boundaries and interactions with the desired software architecture.
- Team Topologies for Microservices:
- The model often maps stream-aligned teams to individual microservices, allowing for independent delivery and deployment.
- This alignment helps ensure that the team structure supports the desired system architecture, reducing coordination overhead.
Evolving Team Structures The model recognizes that static team structures are often ineffective in dynamic environments. It encourages organizations to evolve their team topologies over time based on changing business needs, technology, and product requirements. Key patterns for evolving team structures include:
- Team Splitting: Dividing teams that have grown too large or complex into smaller, more focused units.
- Team Switching: Reassigning teams to different areas of focus as priorities shift.
- Service Encapsulation: Shifting responsibilities to separate teams when a system component becomes too complex for a single team to handle.