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.
Does your team get stuck when it encounters a problem that’s beyond its expertise? What if your organization had a team designed to come in and save the day?
In Team Topologies, Matthew Skelton and Manuel Pais recommend dividing your workforce into four types of teams. One type is what they call “complicated-subsystem teams,” which are basically problem-solving teams.
Read more to understand how and when such specialized teams should be deployed.
Problem-Solving Teams
In Team Topologies, stream-aligned teams are generalists that manage multiple fields within a single stream (such as development and operations). In contrast, complicated-subsystem teams are specialized problem-solving teams. They work on tasks that require mastery of specialized knowledge to complete. They take on problems that would otherwise bottleneck another team’s progress, such as managing complicated mathematical algorithms or dealing with audio and video processing.
(Shortform note: When creating specialist teams to deal with complicated subsystems, it’s important that you consider the relationship between specialization and familiarity within a team. Studies have shown that specialist teams work more efficiently when there’s a high level of personal and technical familiarity among team members. Because of this effect, you should try to build complicated-subsystem teams from people who have worked together in the past and, as suggested earlier, give these teams a long time to work together, so they can reap the benefits of increased familiarity over time.)
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.
For example, suppose your organization wanted to include a voice recognition feature in your mobile app. A feature like that would require audio engineering knowledge that may not have many other applications in your organization. Because of the specialized nature of this feature, you’d want to create a complicated-subsystem team to manage it—it wouldn’t be worth your time to teach a stream-aligned team audio engineering skills that they won’t have any other use for at your organization.
(Shortform note: Making use of complicated-subsystem teams when a skill isn’t widely applicable can help you avoid over-specialization in your organization. Experts argue that employing too many specialists can limit creativity and slow down progress, especially in the early stages of product development. By using complicated-subsystem teams, you can limit the time and opportunity costs of training specialists, thereby keeping your teams flexible and protecting their creativity.)
As with enabling teams, your complicated-subsystem teams should prioritize different projects and tasks based on their assessment of the most pressing needs of the other teams. Due to the relatively rare nature of such complex systems, you generally won’t need to develop many complicated-subsystem teams.
(Shortform note: To avoid creating too many complicated-subsystem teams, encourage your other teams to solve problems on their own whenever possible. Thanks to the internet, there are near endless resources for struggling software engineers to share solutions and fixes with each other. You should only consider deploying a complicated-subsystem team when one of your teams is stuck on something, and they’re also unable to source a solution online.)
———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
