This article is an excerpt from the Shortform book guide to "Team Topologies" by Matthew Skelton and Manuel Pais. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here.
What’s an enabling team? What type of team handles an organization’s infrastructure? What’s the most important team type?
Team Topologies is a manual for restructuring your organization’s approach to software design. Matthew Skelton and Manuel Pais argue that, by dividing your workforce into four types of teams, you’ll set your organization up for success.
Keep reading for an overview of the four Team Topologies team types, plus a discussion on when it’s time to reassign teams.
Team Topologies Team Types
The four Team Topologies team types are stream-aligned, enabling, complicated-subsystem, and platform. As Skelton and Pais assert, these team topologies are designed for your organization to benefit as much as possible from Conway’s Law—the software a team produces will mimic the structure of the team. Each type of team works autonomously on its own projects, ensuring that every team takes ownership of the software it produces, while also preventing monoliths from forming.
Type 1: Stream-Aligned Teams
The primary team type is the stream-aligned team. A stream-aligned team handles every aspect of a single product produced by your organization. According to Skelton and Pais, each stream-aligned team should have the authority to take full ownership of its projects from development to delivery and beyond.
Because your stream-aligned teams handle both development and delivery, they’re able to receive feedback on their products and use it to improve the quality of their fixes and updates. This allows them to seamlessly address problems as they occur, rather than sending them off to another team and waiting for a response.
Because they produce and deliver all of your organization’s products and services, Skelton and Pais consider stream-aligned teams to be the most important type of team. These teams are so important that the purpose of the other three types of teams is to support them.
Type 2: Enabling Teams
Moving on from stream-aligned teams, enabling teams are charged with researching new skills and technological advancements and sharing that knowledge with other teams in your organization. By keeping other teams informed, enabling teams help keep your organization efficient and up-to-date.
As Skelton and Pais argue, you should encourage your enabling teams to focus on a single, specialized knowledge area instead of researching new technologies in general. By focusing on a single subject, your enabling teams will be able to develop a higher level of expertise, which they can in turn share with other teams that encounter specialized problems.
Type 3: Complicated-Subsystem Teams
The third type of team, complicated-subsystem teams, work on tasks that require mastery of specialized knowledge to complete. Whereas stream-aligned teams are generalists that manage multiple fields within a single stream (such as development and operations), complicated-subsystem teams solve problems that would otherwise bottleneck another team’s progress, such as managing complicated mathematical algorithms or dealing with audio and video processing.
As opposed to enabling teams, which exist to provide your teams with widely useful new skills, complicated-subsystem teams should be deployed when there isn’t much benefit to enabling teams teaching another team the skills needed to solve a particular problem.
Type 4: Platform Teams
Skelton and Pais’s final team type, platform teams produce and maintain the infrastructure and services that all of your teams use to communicate with each other and perform tasks. Examples of these kinds of services include your internal security tools, remote work applications, cloud storage solutions, and internal network design.
Your platform teams should focus on producing interfaces that are easy for the other teams to use, which will in turn help those teams to work more efficiently. Platform teams can accomplish this by creating easy-to-read webpages and manuals that help other teams make effective use of their infrastructure.
When Is It Time to Reassign Teams?
Skelton and Pais note that it’s fairly easy to sort your workforce into the team types to suit your organization’s present needs. However, as your business grows, new priorities and problems will emerge that may require you to reassign teams. Sticking to old team designs when your organization’s needs have changed can hamper your organization’s productivity.
(Shortform note: One sign that your team designs are outdated is dissatisfaction within the teams. When employees feel underutilized, they lose satisfaction in their work, and in extreme cases, they may even leave the organization. In situations like these, reassigning teams will not only increase productivity, but it’ll also stop your organization from losing good employees by providing them with new challenges to explore.)
The most common reason you’ll have to reassign teams will be when a particular system has grown too large for one team to handle. According to Skelton and Pais, you’ll know if a system is too large for a single team if other teams are frequently waiting on a single team to respond to requests and solve problems. Once you’ve identified this problem, you can reallocate employees into multiple teams that handle different elements of the system, including infrastructure and complicated-subsystem teams as necessary.
(Shortform note: You may also have to reassign teams when software projects fail. According to experts, only one-third of new software projects successfully achieve their original goals. Software projects can fail for all kinds of reasons—developer inexperience, unrealistic goals and deadlines, and poor direction from management are all common reasons. When a software project fails, try to determine what went wrong and correct it in your new team assignments. For instance, if the issue was lack of experience, create a new team that includes more experienced engineers.)
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Matthew Skelton and Manuel Pais's "Team Topologies" at Shortform.
Here's what you'll find in our full Team Topologies summary:
- How to set up your software development teams to work as efficiently as possible
- The four types of teams you should create as a project manager
- The three main ways your teams should interact with each other
