Introduction
Welcome to the next lesson in our module on Delivery Process Transformation. In the previous lesson, we focused on diagnosis. You learned how to use Value Stream Mapping (VSM) and DORA metrics to assess your current delivery process maturity and pinpoint critical gaps, such as long lead times and bottlenecks caused by handoffs between siloed teams.
Now that we know how to identify the problems, this lesson focuses on the solution. Our learning outcome is to define team topologies suitable for a microservices architecture such as stream-aligned and platform teams. This is where we start designing the organizational structure that will enable the fast, autonomous flow of value required by your company's planned shift to microservices and AI.
For you, as a leader of this transformation, understanding these concepts is paramount. This isn't just an academic exercise in drawing org charts; it's about fundamentally re-wiring how teams collaborate and deliver value, creating an environment where a modern microservices architecture can thrive.
The Problem: Why Traditional Team Structures Fail
Before we explore new team structures, it's crucial to understand why traditional, functionally-siloed teams (e.g., a 'frontend' team, a 'backend' team, a 'database' team) act as a brake on modern software delivery, especially in a microservices context.
The root cause is explained by a principle known as Conway's Law.
Team Topologies: The blueprint for Cloud & AI transformations
To understand why team structure is so critical, we first need to grasp a fundamental principle of socio-technical systems: Conway's Law. This article clearly explains this concept and how traditional team communication structures inevitably shape your software architecture.
Please read the section titled 'Conway’s Law: The hidden force shaping your architecture'. Focus on the example of how functional teams (Frontend, Backend, Database) naturally lead to a layered, tightly coupled architecture that requires multiple handoffs and slows down delivery.
As the article highlights, if your teams are organized in silos, your software architecture will reflect those silos, creating dependencies and communication overhead. The VSM you learned about in the last lesson would visually represent these as long wait times between process steps. This directly contradicts the goal of a microservices architecture, which is to have small, independent services that can be changed and deployed autonomously.
To achieve an architecture of loosely coupled services, you must first create an organization of loosely coupled teams. This is often called the "Reverse Conway Maneuver": intentionally designing your organization to achieve your desired architecture.
The Solution: The Four Fundamental Team Types
The Team Topologies model by Matthew Skelton and Manuel Pais provides a practical framework for applying the Reverse Conway Maneuver. It defines four fundamental team types and three interaction modes designed to reduce dependencies and optimize for a fast flow of change.
Let's start with a quick overview of the four team types.
What are the core team types in Team Topologies? - Team Topologies
This short video from the creators of the Team Topologies framework provides a concise introduction to each of the four team types.
Please watch the video from the beginning until 03:57. Pay close attention to the primary purpose of each of the four types: Stream-aligned, Enabling, Complicated Subsystem, and Platform.
Now, let's solidify those concepts with a more detailed reading.
Team Topologies: The Blueprint for Fast Value Flow
Let's dive deeper into the definitions and purpose of each team type. This article provides clear descriptions that will build on the video you just watched.
Please read the section 'The Four Fundamental Team Types: A New Language for Organization'. As you read, it may be helpful to create a simple table for yourself summarizing the purpose and an example of each of the four team types.
As the resources explain, the four types are:
-
Stream-Aligned Team: This is the primary team type. It's a cross-functional team with end-to-end responsibility for a single "stream" of business value—a product, a feature set, a user journey, or a single microservice. The goal is maximum autonomy.
-
Platform Team: This team’s purpose is to enable the stream-aligned teams by providing a reliable internal platform of self-service tools and services (e.g., CI/CD pipelines, monitoring, authentication). The platform is treated as a product, and the stream-aligned teams are its customers. This reduces the cognitive load on the stream-aligned teams.
-
Enabling Team: This is a team of specialists who help stream-aligned teams gain new capabilities. They act as expert coaches, typically on a temporary basis. For example, an Enabling Team might help a stream-aligned team adopt a new test automation framework and then move on.
-
Complicated-Subsystem Team: This team is only used when a part of the system is so complex it requires deep, specialized knowledge that cannot be easily embedded in a stream-aligned team (e.g., a complex proprietary algorithm). This team isolates that complexity behind a well-defined API.
For your transformation to a microservices architecture, Stream-Aligned and Platform teams are the most critical topologies to understand.
The entire model is designed to manage a crucial factor: team cognitive load. As the article "Team Topologies: The Blueprint for Fast Value Flow" points out, if a team is responsible for too many complex systems, its performance will degrade. Platform teams are the primary mechanism for managing this load, allowing stream-aligned teams to focus on delivering business value, not on underlying infrastructure.
Team Topologies in Practice: A Case Study
Understanding the theory is one thing; seeing how it's applied is another. Designing these teams isn't just about redrawing an org chart. It starts with analyzing your business and technical domains to find the right "seams" along which to create your teams.
This excellent case study from a company called Pirate Ship demonstrates the real-world process of moving from a monolithic structure to one based on Team Topologies.
Team Topologies in Practice: A Journey of Re-Teaming Using Architecture for Flow
This case study walks through the entire journey of reorganizing teams using Team Topologies, starting from the challenges of a growing monolith. It provides a practical, step-by-step view of the process.
This is a detailed video, so we'll focus on key segments. Please watch the following parts: The Problem: Understand the challenges Pirate Ship faced as they grew (00:46 - 04:14). You may recognize similar challenges in your own context. Architectural Foundation: Grasp how they used 'bounded contexts' from Domain-Driven Design (a way of modeling complex software domains) to find the seams to break up their monolith (08:51 - 10:20). Forming Stream-Aligned Teams: See the practical process they used, from collaborative workshops ('Event Storming') to cluster business domains and then letting teams self-select into the new structure (10:20 - 17:22). This is a real-world example of the 'Reverse Conway Maneuver'. The Need for a Platform Team: Understand how the challenges of shared components naturally led to the creation of platform teams to support the stream-aligned teams (19:41 - 23:31).
The Pirate Ship journey highlights a critical insight for your transformation: organizational design and software architecture are two sides of the same coin. The process began by mapping the business domain to define architectural boundaries ("bounded contexts"), which then became the ownership boundaries for the new stream-aligned teams.
Practical Application
Now, let's apply these concepts to your context. You have deep experience with financial software products like the Intellect Loan Origination System. Think about the high-level flow of value in such a system.
Exercise (5-10 minutes):
-
Based on your understanding of a loan origination process, brainstorm 3-4 potential "streams of value" that could be owned by a Stream-Aligned Team. For example:
- New Application & Data Capture
- Credit Underwriting & Decisioning
- Documentation & Verification
- Loan Booking & Disbursement
-
Choose one of your proposed streams (e.g., Credit Underwriting & Decisioning). Now, list 2-3 essential services or capabilities that a Platform Team would need to provide to help this team be successful and autonomous. Think about what would reduce their cognitive load. (e.g., A standardized deployment pipeline to production, a centralized logging and monitoring service, a self-service environment provisioning tool).
This simple exercise helps translate the theory of Team Topologies into the concrete reality of your business domain.
Conclusion
In this lesson, we have defined the key team structures that enable a successful microservices architecture. You've moved from diagnosing problems in the delivery process to designing the organizational solution.
Key Takeaways:
- Conway's Law dictates that your team communication structure will be mirrored in your software architecture. To build a microservices architecture, you need loosely-coupled, autonomous teams.
- Team Topologies provides a model for designing these teams, primarily through Stream-Aligned Teams that own a flow of value, and Platform Teams that reduce cognitive load by providing internal services.
- The other team types, Enabling and Complicated-Subsystem, serve specific, supporting purposes.
- The design process is not arbitrary. It involves analyzing the business domain to find logical "seams" (like bounded contexts) which then define the boundaries of team ownership.
Preview of the Next Lesson
We have now defined the types of teams needed for your target state. However, a topology is just a blueprint. To make it work, we need to define how these teams operate.
In our next lesson, we will address the learning outcome: "Outline key roles, responsibilities, and interaction modes within the target delivery operating model." We will zoom in on the internal workings of these teams, defining key roles (like Product Owner and Tech Lead), clarifying responsibilities, and formalizing the interaction modes that govern how the different team types collaborate effectively.