Understanding the 4 main team topologies

Modern software development is all about speed and agility. Project managers and engineers know that to meet customer demand and consistently deliver value, they must find new and better ways to work together and shorten lead time. 

The result has been a dramatic industry shift to an agile DevOps model, which promises greater efficiency, collaboration, quality, and speed. 

In their book Team Topologies, IT consultants Matthew Skelton and Manuel Pais describe the successful team patterns and interactions they observed in their own work. These four team topologies are designed to improve deployment frequency, elevate team culture, and increase collaboration across teams and departments. 

In this article, we’ll review team topologies and discuss how organizations and project managers can model those structures in their own teams for maximum impact.  

Identify your team’s current organizational structure

The first step to transforming your team systems is to understand your current organizational structure. 

Consider:

• How do your teams currently operate? 
• Do you have the right teams in place? 
• Are your teams well-balanced? 
• Do your teams have the support they need to succeed?
• What gaps or opportunities exist?

You need to identify both inter-team relationships and processes as well as intra-team patterns. This will help you uncover how well teams are currently collaborating, what support systems are already in place, and any skills gaps or capacity issues that are limiting performance.  

Use the Team Topologies framework to review how your current teams and processes stack up. As you identify and categorize patterns within the four team topologies, you will start to see opportunities to fill gaps and rework systems for greater efficiency and collaboration.

4 fundamental Team Topologies

Topologies describe how “constituent parts are interrelated or arranged.” In other words, how teams are organized and how they work together. 

Under the Team Topology model there are four types of teams:

• Stream-aligned teams
• Platform teams
• Complicated subsystem teams
• Enabling teams

Understanding how these teams work and interact is key to building and managing an efficient DevOps organization. 

Stream-aligned teams

As Skelton and Pais explain, a stream-aligned team is “aligned to a single, valuable stream of work, empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.”

In other words, stream-aligned teams focus on a single stream of work, such as a single product, service, set of features, or even a single user journey. Because stream-aligned teams are positioned to deliver value autonomously, they need to be cross-functional in order to build, test, and operate independently.   

Stream-aligned teams are common within software organizations and are often already agile. According to Skelton and Pais, the majority of teams in an organization should be stream-aligned while the other three types of teams exist to support their efforts and fill any gaps. 

Platform teams

Platform teams help make stream-aligned teams’ work easier by providing the internal structures and services stream-aligned teams need to build, test, and deliver value continuously. 

For example, a platform team might provide the infrastructure where stream-aligned teams run their products.

Platform teams and stream-aligned teams should have minimal collaboration, which has the potential to interrupt workflow and requires synchronization. Instead, platform teams work behind the scenes through an X-as-service model, providing supportive services that stream-aligned teams can consume on-demand.

Complicated-subsystem teams

Sometimes a stream-aligned team doesn’t have the right skills or capacity to fulfill a deliverable. That’s where a complicated-subsystem team comes in. These teams help fill the gap by providing specialized expertise so stream-aligned teams can focus on the work they do best.

Successful interaction between complicated-subsystem teams and stream-aligned teams will require both collaboration and facilitation to ensure a smooth workflow.    

Enabling teams

Similar to complicated-subsystem teams, enabling teams provide needed support to stream-aligned teams, helping bridge knowledge and capability gaps. 

Stream-aligned teams are focused on continuous delivery and adaptation, making it difficult to spend time on other activities like research and upskilling. Enabling teams come in for a temporary period of time to make informed recommendations, share best practices, and educate teams on emerging technologies. 

3 team interaction models

Within the Team Topology framework, there are three ways teams can and should interact:

• Collaboration—Two teams work together for a defined period of time towards a specific goal.
• X-as-a-service—One team provides a service and the other team consumes that service. (For example, a platform team provides X-as-a-service to stream-aligned teams.)
• Facilitating—One team supports and mentors the other team. 

There can be some overlap between the interactions—for example, an enabling team may both collaborate with and facilitate a stream-aligned team.

Together with team topologies, these models help organizations design, build, and operate better software with greater speed and efficiency. 

Following a team-first approach

A Team Topologies system is built on a team-first approach. This team-first lens assumes:

Teams are the building blocks of an organization. Individual team members can be great contributors, but organizations shouldn’t rely solely on individuals to deliver. Relying on one person means if they fail, the team fails. It’s more effective and risk-averse to spread the knowledge and responsibilities for delivery across a team.

Teams have limited cognitive capacity. One team cannot be and do everything within a department or organization. In other words, you don’t want your development team to be spread too thin, task switching repeatedly across broad, unrelated assignments. Specialized and focused teams allow organizations to scale and ensure each team can focus on what they do best. This leads to better quality and greater efficiency.

Teams need boundaries on communication and ownership. Communication is important, but you can have too much of a good thing. Unstructured interactions and over-communication across teams can lead to inefficiencies and cumbersome dependencies that can distract from priorities.

A team-first approach emphasizes clear boundaries and expectations for communication and responsibilities within and between teams. 

Teams need a clear digital and physical workspace to operate from. The best work gets done when people set their own terms. Teams should be given autonomy to operate within clear digital and physical workflows. 

Whether that’s sharing information and making hand-offs via project management platforms, or relying on a dedicated project manager to prioritize and assign issues to the group, teams need clear operating systems based on their preferences.

Why are team topologies important for project management? 

Well, the structure of your organization and the way teams collaborate directly impact what your teams produce. This is called Conway’s Law. And while it demonstrates how our organizational structures can limit us, it also opens the door to innovative ways of building teams and systems that drive the results we want. 

This is essentially the argument Skelton and Pais present in Team Topologies. We can consciously and intentionally design our organizations so that our teams naturally produce the systems and results we want. 

That’s why it’s crucial for project managers and DevOps leaders to understand how their teams are organized so they can create the systems and structures that will deliver the most value.

Organizing your team organizations within these team topologies will:

• Encourage flow of change
• Establish and clarify team responsibilities
• Promote team collaboration

As project managers reimagine their DevOps team structures, they can enable their teams to work better, faster, and more reliably to deliver end-to-end value for their customers.