In many organizations, especially at the enterprise level, there are many types of teams, even teams who take on multiple roles. As the organization continues to grow and these team types continue to sprawl, it becomes increasingly hard to visualize the full organizational landscape, and, consequently, to get things done.
One of the most important things to remember, is that we can be intentional about how we build and organize teams. We can design our teams and our organization for the results we want (Conway’s Law).
So what does this intentional organization look like? The idea of organizing a company of hundreds, thousands, or even tens of thousands of people is daunting.
But, according to the research of Matthew Skelton and Manuel Pais, there are really only four fundamental team types.
What are the Four Team Types?
When used well, these four team topologies are the only team types you need to build and run modern software systems.
- Stream-Aligned Team
- Enabling Team
- Complicated-Subsystem Team
- Platform Team
As Matthew and Manuel say in their bestselling book Team Topologies: Organizing Business and Technology Teams for Fast Flow,
When these four team types are combined with effective software boundaries and team interactions, the restriction of these four team types acts as a powerful template for effective organization design.
Team Topologies: Organizing Business and Technology Teams for Fast Flow
Let’s dive into what each of these teams is in more detail.
A “stream” is the continuous flow of work aligned to a single business domain or org capability. A stream-aligned team is aligned to a single, valuable stream of work like a single product or service, a set of features, or even a user journey or user persona. This team is empowered to build and deliver value quickly, safely, and (this is key) independently. There shouldn’t be any hand-offs to other teams to complete parts of the work. They “own” it from beginning to end.
Stream-aligned teams should be the primary team type in an organization. All other team types exist to reduce the burden on stream-aligned teams.
Stream-aligned teams should be close to the customer so they can quickly incorporate feedback and monitor their software in production. This allows the stream-aligned team to react in near real-time and adapt to changes as needed. They are quick, agile, dedicated.
An enabling team bridges the capability gap. In Accelerate, we learn that high-performing teams are continuously improving their capabilities to stay ahead of the curve. This is difficult when you have end-to-end ownership of a value stream (as in stream-aligned teams). With all that work, it can be hard to find the time for research, learning, and practicing new skills.
Enabling teams are composed of specialists in a given domain of knowledge, which might be more technical, or more product-focused, or any other domain where there is a gap in skills in (part of) the organization. They cross-cut to stream-aligned teams and have the bandwidth for research, experimentation, etc. They bring this knowledge and expertise back to the stream-aligned team.
A successful enabling team should be strongly collaborative in nature. They must work to understand the problems faced by the stream-aligned team and then provide proper guidance. Enabling teams must avoid becoming an “ivory tower” of knowledge. They do not exist to dictate technical choices. Instead, an enabling team helps stream-aligned teams understand and comply with organization-wide constraints. They are the “servant leaders” of the team types.
The complicated-subsystem team is responsible for building and maintaining a system that requires heavy specialist knowledge. Each member on the team should be a specialist in that area of knowledge and be able to make changes to the subsystem.
The goal of the complicated-subsystem team is to reduce the cognitive load of stream-aligned teams working on the system. This is more cost effective than embedding a specialist onto every stream-aligned team, and avoids distracting the stream-aligned team from their main goal of delivery value.
A platform team enables a stream-aligned team to deliver work with substantial autonomy by providing internal services to reduce their cognitive load. A digital platform, as defined by Evan Bottcher, is
. . . a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.
The platform team’s knowledge is made available via self-service capabilities on the web or via a programmable API. These should be made easy for the stream-aligned teams to consume, instead of lengthy instruction manuals.
Ease of use is fundamental to successful product teams.
The Benefit of Restricting Team Types
Organizations that are struggling with rapid, sustainable software delivery typically have a wide and ever-expanding group of teams and team types. Usually these teams have poorly defined roles and responsibilities. By restricting teams to just the four fundamental types explored in the post and expanded upon in the book Team Topologies, the organization can focus their time on team interaction patterns that are known to promote flow and deliver value faster.
We’ll explore the three essential team interaction modes in an upcoming post.
– About The Authors
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.