Welcome to the next lesson in our module on transforming the delivery process. In our previous session, we examined the "what" and "why" of scaled Agile frameworks and the importance of assessing your organization's delivery maturity. We established that choosing a framework is a profound organizational design decision. Now, we turn our attention to the "who": how do you structure the teams that will operate within this new model, especially when transforming to a microservices-based product architecture?
This lesson directly addresses that question. We will explore how to define team topologies and roles that are not just suitable for, but are in fact optimized for, a modern, microservices-based delivery model. The core idea we'll explore is that your software architecture and your team structure are two sides of the same coin, a concept famously captured by Conway's Law. You will learn a powerful and practical framework called Team Topologies that provides a clear vocabulary and set of patterns for designing effective, high-performing teams. For your work as an Organizational Design Consultant, these concepts provide a robust toolkit for architecting the human side of a technical transformation.
The Driving Forces: Conway's Law and Cognitive Load
Before diving into the solution, it's essential to understand the problem that modern team design aims to solve. A move to microservices often fails when the organization tries to force the new architecture into old team structures. This is because of two fundamental forces: Conway's Law and cognitive load.
Conway's Law states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In simpler terms, your software architecture will eventually mirror your team structure. If you have separate "frontend," "backend," and "database" teams, you will likely end up with a three-tiered monolithic application, regardless of any ambitions to build microservices. To successfully build a microservices architecture, you must first design an organization composed of small, autonomous, cross-functional teams.
The second force is team cognitive load. This refers to the total amount of mental effort being used by a team's working memory. As an organizational designer, managing cognitive load is one of your most critical levers for improving team productivity and effectiveness.
To grasp this crucial concept, please watch this section from a presentation by Matthew Skelton, one of the authors of the Team Topologies book.
Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load - Team Topologies
This video, "Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load," explains the theory behind cognitive load and its application to team design.
Watch the first segment explaining cognitive load. The speaker breaks it down into three types: Intrinsic: The fundamental, core knowledge needed to do the job (e.g., programming language syntax). Extraneous: The "tax" of getting things done that is not related to the business problem (e.g., wrestling with a clunky deployment process). Germane: The mental effort applied directly to solving the business problem. Then, continue watching the segment on limiting software size to a team's cognitive load, which introduces the principle of full ownership.
The key takeaway is that our goal is to minimize extraneous cognitive load so that teams can maximize their focus on the germane, value-adding work. A team that is overwhelmed by complex deployment pipelines, confusing testing environments, or endless coordination meetings has no mental capacity left to innovate on the business problem they are meant to solve.
A Framework for Organization: Team Topologies
The Team Topologies framework, developed by Matthew Skelton and Manuel Pais, provides a practical model for structuring teams to optimize for a fast flow of delivery and to manage cognitive load. The framework proposes that only four fundamental types of teams are needed to build and run modern software systems.
This quick reference card provides an excellent overview of the entire framework, which we will deconstruct in detail.
To get a quick, authoritative introduction to the four team types, please watch this short video from the authors.
What are the core team types in Team Topologies? - Team Topologies
The video "What are the core team types in Team Topologies?" provides a concise definition of each of the four topologies.
Watch the full video from start to finish. It will introduce all four team types and explain how three of them exist primarily to support the first, most fundamental type.
Now, let's explore these team types and their roles in more detail using the article "Building Effective Teams for Microservices."
Building Effective Teams for Microservices: A Guide Using ... - Omax
This article explains why specialized teams are necessary for microservices and provides detailed descriptions of the four team types and their interactions.
First, read the section The Need for Specialized Teams to understand the rationale for moving away from traditional structures. Next, focus on the section "Key Concepts from Team Topologies." Carefully read the descriptions for each of the four fundamental team types: Stream-aligned Team Enabling Team Complicated-Subsystem Team Platform Team Finally, read the descriptions of the three modes of team interaction: Collaboration X-as-a-Service Facilitating
Let's crystallize these concepts:
- Stream-Aligned Team: This is the most fundamental team type. It's a cross-functional team aligned to a single, valuable stream of work. In a microservices context, this often means the team owns one or more microservices that serve a specific business domain, customer journey, or user persona. They have end-to-end responsibility—"you build it, you run it." The primary goal of the other team types is to enable stream-aligned teams to deliver value quickly, safely, and independently.
-
Platform Team: This team's purpose is to enable stream-aligned teams to deliver their work with minimal extraneous cognitive load. They do this by providing internal services and tools as a product. Examples include CI/CD pipelines, observability dashboards, and identity services. The key is that they offer these capabilities "as-a-service" with a focus on usability and reliability, treating other internal teams as their customers. A core concept here is the Thinnest Viable Platform (TVP)—providing only what is necessary to reduce the cognitive load, and nothing more.
-
Complicated-Subsystem Team: This team is responsible for a subsystem that requires highly specialized and deep expertise (e.g., a proprietary video-processing algorithm, a complex financial calculation engine). Shielding stream-aligned teams from this complexity allows them to focus on their core feature delivery. This topology should be used sparingly, only when the complexity cannot be reasonably handled by a non-specialist team.
-
Enabling Team: Composed of experts in a specific domain (e.g., test automation, continuous delivery, security), this team helps stream-aligned teams acquire new capabilities. They act as expert coaches, working with teams for a short period to upskill them and then moving on. Their goal is to build autonomy, not create dependencies.
The three interaction modes—Collaboration, X-as-a-Service, and Facilitating—provide a clear language for defining how these teams should work together, reducing ambiguity and coordination overhead.
Applying Team Topologies in a Complex Enterprise
In a large B2B software company like those you have experience with, the "platform" is rarely a single entity. A more nuanced, domain-driven approach is often required. The following resource from the creators of Team Topologies introduces a layered model for platform services that is incredibly powerful for designing organizations at scale.
Designing Platform-Centric Organizations with Domain Thinking and ...
This article enhances the basic Team Topologies model by overlaying it with concepts from Domain-Driven Design, creating a sophisticated framework for platform-centric organizations.
First, study the section that introduces a four-layer service taxonomy. It begins just after Figure 1 and explains the layers from most abstract to most domain-specific. Read the definitions for all four layers: Foundational, Common Enterprise, Domain Backbone, and Unique Domain Services. Next, read the section Applying the DDPE Lens, which re-interprets the four fundamental team types in this more layered, domain-centric context. Finally, review the section that brings it all together. Focus on the text and diagram under the "Six Patterns" subheading. This section, including Figure 3, shows exactly how the Domain-Backbone and Common-Enterprise services can be mapped to the four team types, providing a concrete blueprint for your organizational design.
This layered approach gives you a much richer palette for organizational design. It acknowledges that not all "platform" work is the same.
- Foundational Services (e.g., CI/CD, observability) are the domain of a classic Platform Team.
- Common Enterprise Services (e.g., a company-wide CRM) might be managed by a dedicated Platform Team or a Complicated-Subsystem Team, depending on the technology.
- Domain Backbone Services (e.g., a reusable payment processing module for the BFSI domain) are a perfect fit for a domain-aligned Platform Team or a Complicated-Subsystem Team that serves a specific set of stream-aligned teams.
- Unique Domain Services are the responsibility of the Stream-Aligned Teams themselves.
By categorizing services this way, you can make much more precise decisions about team boundaries and responsibilities, ensuring that cognitive load is managed effectively across the entire organization.
Conclusion
In this lesson, we have moved from high-level frameworks to the concrete design of the teams that do the work. You now have a practical and powerful vocabulary for defining team structures and roles in a way that directly enables a microservices architecture and accelerates the flow of value.
Key takeaways from this lesson:
- Conway's Law dictates that your team structure and software architecture are intrinsically linked. To build microservices, you need teams structured for autonomy.
- Team Cognitive Load is a critical design constraint. The goal of modern organizational design is to minimize extraneous load so teams can focus on business problems.
- The Team Topologies framework provides four essential team types: Stream-Aligned, Platform, Enabling, and Complicated-Subsystem.
- These teams interact through three well-defined modes: Collaboration, X-as-a-Service, and Facilitating.
- In complex enterprises, a layered, domain-driven view of platform services allows for a more nuanced and scalable application of these topologies.
In our next lesson, we will focus on measurement and implementation. Now that you know how to design the teams, we will explore how to define key delivery performance metrics and plan a phased rollout of the new operating model. This will equip you to not only design the new organization but also to guide its implementation and demonstrate its success.