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 are team topologies? How do you know how much work to assign to a team? How can you set teams up for success?
Team Topologies, by Matthew Skelton and Manuel Pais, is a manual for restructuring your organization’s approach to software design. The authors recommend four types of teams and discuss various modes of interaction among teams that help them function effectively.
Keep reading for our Team Topologies book overview, including an exercise to help you put the principles into action.
Team Topologies: Book Overview
The authors argue that, by dividing your workforce into four types of teams, you’ll set your organization up to produce internal software that helps your organization communicate and work efficiently as well as software products that provide these same advantages to customers. Skelton and Pais argue that you should focus on team design because of a principle called Conway’s Law, which states that a piece of software’s architecture will mimic the structure of the team that produced it.
Skelton and Pais are software engineers, consultants, and authors of multiple books on software and team design. Published in 2019, their Team Topologies book is an attempt to synthesize many different schools of thought in software engineering. In doing so, they offer a powerful schematic you can apply to team design at your organization.
We’ll first consider Conway’s Law and its implications for the design of your teams. We’ll then move on to discuss the four team types recommended by Skelton and Pais. Finally, we’ll look at Skelton and Pais’s recommendations for how your teams should interact with each other.
Use Conway’s Law to Set Up Successful Teams
Conway’s Law shapes Skelton and Pais’s approach to team design. Specifically, they recommend that you create autonomous teams and assign those teams the right amount of work.
Conway’s Law
Introduced by computer programmer Melvin Conway in 1967, Conway’s Law states that the software a team produces will mimic the structure of the team. For example, a team that is socially isolated from the rest of your organization might produce software that makes it difficult for members of different teams to share information with each other.
Skelton and Pais assert that the best way to improve the quality and efficiency of your organization’s software is to focus on team design. They refer to this approach as an inverse Conway maneuver.
Let’s look at some strategies for taking advantage of its positive effects on your organization.
Create Small, Long-Term Teams
Based on Conway’s Law, your first priority should thus be to create strong teams that can operate autonomously. When teams aren’t autonomous and work too closely together, the software they create will be tightly coupled and rely on shared code, which means problems with that code will cause delays for many of your teams.
To encourage autonomy, your team assignments should be long-term. Teams that have more experience working together are able to hit the ground running on new projects. Additionally, when one of your teams develops a product throughout its entire lifespan, it becomes an expert in that product. This encourages your teams not to opt for quick, sloppy fixes.
Furthermore, you should limit your teams to 10 or fewer individuals. Smaller teams increase autonomy by allowing your team members to better understand each other’s strengths and weaknesses. As evidence for this, Skelton and Pais reference Dunbar’s number, which is the biological limit on how many people human beings can deeply know and trust.
Assign the Right Amount of Work
The authors argue that you should limit team responsibilities so that individual teams don’t end up overwhelmed. Software products produced by teams that are overwhelmed and lack expertise reflect this via Conway’s Law. These products will lack polish, and they may include a variety of features that aren’t fully fleshed out.
To keep teams from getting overwhelmed, consider the cognitive load when assigning tasks, or the amount of mental energy the task requires.
To assign the right amount of work, the authors recommend two strategies:
1) Divide work along fracture planes. These are naturally occurring splitting points between different parts of a piece of software.
2) Assign work based on your organization’s long-term goals, not individual problems. Skelton and Pais note that your teams should focus on bigger, longstanding projects because those projects have the biggest impact on your organization’s overall success.
The Four Types of Teams
Skelton and Pais recommend creating four types of teams (or “team topologies,” as the authors call them).
Stream-Aligned Teams
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. This allows them to seamlessly address problems as they occur, rather than sending them off to another team and waiting for a response.
Due to the demands of handling so many different tasks, you should make sure each of your stream-aligned teams includes individuals who have different skills.
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.
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.
Complicated-Subsystem Teams
Complicated-subsystem teams work on tasks that require mastery of specialized knowledge to complete. These teams should be deployed when there isn’t much benefit to enabling teams teaching another team the skills needed to solve a particular problem. 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.
Platform Teams
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?
As your business grows, new priorities and problems will emerge that may require you to reassign teams. 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. 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.
Three Modes of Interaction Between Teams
According to Skelton and Pais, there are three main ways your teams should interact with each other: collaboration, x-as-a-service, and facilitating. You should encourage teams to interact only when it improves the speed and quality of the work being done. While interaction modes should be well-defined, it’s important to note that these modes are not rigid.
The Collaboration Model
Collaboration occurs when two of your teams come together to work on a shared project. As Skelton and Pais argue, your organization can use collaboration to generate new ideas and ways forward by allowing two teams to work on the same project without having to wait on each other. However, you shouldn’t allow more than two teams to cooperate on a single project.
According to Skelton and Pais, collaboration allows different teams to bring their various skills and approaches to a shared problem. For collaboration to be successful, you should encourage both teams to take full responsibility for their shared project.
Because of Conway’s law, Skelton and Pais note that software produced by two of your teams working in collaboration will result in an architecture that splits operational responsibility between the two teams. This blurring of boundaries can cause cumbersome monoliths to form if you leave it unchecked. To prevent monoliths from forming, when it comes time to actually deploy a piece of software, you should encourage one team to take sole ownership of the project from that point onward.
The X-as-a-Service Model
In the x-as-a-service model, one team uses a software product provided to them by another team. This model increases efficiency by preventing your teams from wasting time on problems that other teams have already solved.
According to Skelton and Pais, your providing teams must have a clear understanding of the needs of the teams that use their products. The software they produce must be highly polished and easy for teams throughout your organization to use.
To streamline x-as-a-service interactions, instruct your providing teams to create guides for how to use their programs and how best to communicate feedback.
The Facilitating Model
Facilitating occurs when one of your teams needs assistance, expertise, or knowledge from another team. Your facilitating team focuses on imparting new skills and knowledge to another team, while the other team attempts to learn new skills they can apply to their projects, thereby increasing productivity.
Facilitating can occur between any two teams when one team needs specific knowledge that another of your teams has access to. In a guiding interaction, the guide team does not work on the other team’s software. This allows the team that’s receiving guidance to maintain full end-to-end ownership of their products.
Facilitating teams typically work with many other teams to increase productivity and sharpen skills across your organization. By providing their outside perspective, guiding teams can help your other teams identify areas for improvement.
Exercise: Assess Teams at Your Organization
Evaluate whether teams at your workplace are set up for success or failure.
- If you’re part of a team or manage a team at your workplace, reflect on your team’s most recently completed project. Was the project successful and completed on deadline, or was it difficult, and completed late, if at all? Consider Skelton and Pais’s recommendations for team size, longevity, and workload, and write down the reasons you think your team succeeded or failed, including anything you’d do differently next time.
- Which of the four team types does your team most closely resemble? Write down ways that your team is in alignment with Skelton and Pais’s recommendations for that type of team, as well as ways your team differs from the ideal team. Consider how these similarities and differences shape your team’s output and list any changes you could make to shift the team more firmly into one of the four types.
- Consider a recent interaction between your team and another team, and write down which of the three modes of interaction it most closely aligns with. Write down how the team either succeeds or fails to follow Skelton and Pais’s models for interaction. List any changes you could make to encourage the team to interact with other teams more effectively.
———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
