PDF Summary:Team Topologies, by Matthew Skelton and Manuel Pais

In a competitive and rapidly changing marketplace, it’s a challenge for any company to efficiently produce software that meets customer needs, let alone create usable software for internal purposes. In Team Topologies, software engineers Matthew Skelton and Manuel Pais show you how to set up your development teams to work as efficiently as possible. By using their approach, you can ensure that your organization’s teams are able to work together to create software that exceeds expectations both internally and in the marketplace.

In our guide, we’ll first consider how Skelton and Pais’s approach to software development is influenced by Conway’s Law, which states that a piece of software’s architecture will mimic the structure of the team that produced it. Then, we’ll look at the four types of teams Skelton and Pais recommend dividing your workforce into. Finally, we’ll look at the three ways your teams can most effectively work together. We’ll also supplement the authors’ approaches with other ideas on how to design teams and effectively delegate work to them.

(continued)...

Educating Teams

Moving on from stream-aligned teams, educating teams (or as the authors call them, “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, educating teams help keep your organization efficient and up-to-date.

(Shortform note: Creating educating teams can contribute to a broader culture of ongoing education and learning in your organization. Since the 1990s, fostering learning internally has become an increasingly popular strategy for staying competitive in rapidly changing markets. Experts argue that in addition to practices such as creating educating teams and programming, it’s important that you reinforce a learning culture by using your role as a leader to foster dialogue and debate.)

Skelton and Pais note that as opposed to dictating practices to other teams, your educating teams should focus on giving (usually stream-aligned) teams the skills and information they need to determine their own best practices.

(Shortform note: It’s important that your educating teams focus on teaching skills instead of dictating practices because, as Marcus Buckingham and Ashley Goodall argue in Nine Lies About Work, top-down goal setting in the workplace often backfires and leads to decreased productivity. This happens because goals and practices dictated by outsiders often don’t relate to a team’s established day-to-day workflow. Instead, allow teams to determine their own goals and practices, and bring in educating teams to help them build the skills to achieve those goals.)

As Skelton and Pais argue, you should encourage your educating teams to focus on a single, specialized knowledge area instead of researching new technologies in general. By focusing on a single subject, your educating teams will be able to develop a higher level of expertise, which they can in turn share with other teams that encounter specialized problems.

For example, suppose a stream-aligned team at your organization is developing a mobile time tracking app for your employees to use. While in the final stages of putting the app together, you could encourage them to draw on the expertise of an educating team that specializes in mobile user experience (UX) design. By working together, the two teams can share skills and make sure the end product is as polished as possible.

(Shortform note: While Skelton and Pais suggest that specialized teams with high levels of expertise make the best educating teams, research suggests that experts don’t always make great educators. Experts may often leave out bits of information that they assume novices already know, in a phenomenon known as the Curse of Knowledge. To help keep your educating teams from falling into this trap, consider holding formal training sessions to help the members of these teams gain the skills they need to communicate their expert knowledge and grow as educators.)

Because your educating teams have no software projects of their own to attend to, they will often have more time to research and develop new skills than your stream-aligned teams. This surplus time often allows a single educating team to attend to the needs of multiple stream-aligned teams.

Once one of your educating teams has passed its expertise on to another team, that team will no longer require the educating team’s assistance to function. According to Skelton and Pais, depending on the scope of the project, this process may be a quick knowledge transfer, or a long-term partnership.

(Shortform note: To ensure that educating teams retain enough mobility to go where their help is most needed, experts recommend planning limited interactions between educating teams and your other teams. Specifically, experts recommend that educating teams only provide assistance the first few times another team works with a new system or concept. If the team being educated still struggles to operate the new system after a few sessions, it may be a sign that it’s too complex to be added to their workload. When this happens, you should consider limiting cognitive load by delegating the new system to a new team.)

Niche Problem Teams

The third type of team, niche problem teams (or as Skelton and Pais call them, “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), niche problem teams solve 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 niche problems, 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 niche problem 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 educating teams, which exist to provide your teams with widely useful new skills, niche problem teams should be deployed when there isn’t much benefit to educating 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 niche problem 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 niche problem 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 niche problem teams, you can limit the time and opportunity costs of training specialists, thereby keeping your teams flexible and protecting their creativity.)

As with educating teams, your niche problem 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 niche problem teams.

(Shortform note: To avoid creating too many niche problem 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 niche problem team when one of your teams is stuck on something, and they’re also unable to source a solution online.)

Infrastructure Teams

Skelton and Pais’s final team type, infrastructure teams (or as the authors call them, “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 infrastructure 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. Infrastructure teams can accomplish this by creating easy-to-read webpages and manuals that help other teams make effective use of their infrastructure.

(Shortform note: When your infrastructure teams create easy-to-use platforms, you increase engineer efficiency and improve employee retention. By creating a more streamlined developer experience throughout your organization, platform teams are able to positively impact company culture, which in turn increases workplace satisfaction and gives your organization a competitive edge in keeping talent.)

The authors say that in addition to ensuring ease of use, your infrastructure teams should focus on making their products as reliable as possible, as these products are often used internally across many teams. Due to the effects of scale, even small infrastructure bugs can cause delays across your organization.

(Shortform note: One of the most important reliability factors for your infrastructure teams to consider is downtime. According to some estimates, an hour of downtime at a large firm can cause losses of as much as $1 million. To avoid losing out on revenue, encourage your infrastructure teams to patch services without downtime whenever possible and to intensively stress test new features before deployment to avoid surprise outages.)

To avoid wasting resources on unnecessary features, Skelton and Pais suggest instructing your infrastructure teams to create the simplest possible infrastructure that meets your organization’s needs.

(Shortform note: Depending on your organization’s needs, your infrastructure teams should consider the simplicity of low-code and no-code development platforms. Low-code platforms are exactly what they sound like—by using visual tools, these platforms make it easier for individuals without much coding experience to create and edit software. If your organization is just getting started and doesn’t yet employ many veteran programmers, your infrastructure teams can deploy low-code platforms to help your other teams operate efficiently until they have more experience.)

If your infrastructure software becomes large enough, you may need to assign several teams to maintain and expand it. You can use the other team types to your advantage here. Treat your infrastructure like any other product and assign stream-aligned, educating, and niche problem teams as needed. At times, you may even need to create additional infrastructure teams to work on smaller pieces of software within your overall infrastructure.

(Shortform note: As you split responsibility for your infrastructure among multiple teams, responsibility for the user experience also gets distributed. This distribution of responsibility can sometimes lead to negligence. Journalists have noted, for instance, that rapid growth at Facebook led the company to ignore privacy and moderation issues that have plagued the platform for years. To avoid this type of issue, when splitting responsibility for infrastructure, be sure that each infrastructure team includes someone tasked with preserving and improving the user experience.)

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, 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 niche problem 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.)

Three Modes of Interaction Between Teams

Now that we’ve identified the four types of teams, let’s consider the most productive ways for those teams to interact with each other. According to Skelton and Pais, there are three main ways your teams should interact with each other: cooperation, guidance, and the consumer-provider model.

(Shortform note: In addition to interacting with each other, your teams can also solve problems by interacting with your customers. Customers can be valuable sources of feedback, providing outside perspectives that can help your teams tune the user experience.)

Skelton and Paid argue that it’s important to explicitly define interactions among your teams because if one team needs to communicate with too many other teams to get work done, it can lead to delays. You should only encourage teams to interact when it improves the speed and quality of the work being done.

(Shortform note: To avoid the costs of unnecessary interactions, it may be helpful to explicitly state which projects will require interaction and which projects will not. This way, you can be sure that your teams will only interact in situations in which you know that your organization stands to benefit.)

While interaction modes should be well-defined, it’s important to note that these modes are not rigid, as your teams will often need to switch modes as their relationships and projects evolve.

Cooperation

The first mode of interaction is cooperation (or as Skelton and Pais call it, “collaboration”), which occurs when two of your teams come together to work on a shared project. As Skelton and Pais argue, your organization can use cooperation 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. When you bring too many teams onto a project, you increase the amount of time spent coordinating and reduce efficiency overall.

(Shortform note: In addition to generating new ideas, cooperation can also increase morale and contribute to a positive work environment at your organization. Cooperation allows multiple teams to get to know each other and increases team spirit by bringing many individuals together to work toward common goals. Over time, this can create cohesion in your organization, as through multiple iterations your teams will get a better sense of the organization’s big picture.)

According to Skelton and Pais, cooperation allows different teams to bring their various skills and approaches to a shared problem. If you notice that a team is working on a problem that extends beyond its areas of expertise, it may be helpful for them to cooperate with another team with complementary skills. Cooperation also serves as a powerful opportunity for members of both teams to share skills that will increase their autonomy after their cooperation ends.

(Shortform note: Cooperation between teams builds skills and practices that may be useful for other teams in your organization’s future. To capitalize on this, encourage cooperating teams to extensively document their work, especially any new solutions or work practices they establish. This way, if those skills or solutions become relevant to another team later on, they’ll be able to quickly access that information.)

For cooperation to be successful, you should encourage both teams to take full responsibility for their shared project. Your teams may cooperate more or less closely depending on how intertwined their projects are. At times, your teams will remain more distinct, offering each other unique knowledge and perspective. At other times, teams might more fully merge, acting as a larger team with many hands working toward one goal.

For example, suppose the team that works on your app’s content algorithm wants to cooperate with the UX team to innovate novel ways of presenting content to app users. This shared goal requires heavy use of both teams’ products, so these teams would likely need to cooperate closely. By contrast, if your UX team needed to cooperate with the team charged with your app’s security features, they likely wouldn’t need to merge as fully, as their respective projects are more distinct from each other.

(Shortform note: To encourage both cooperating teams to take responsibility for a shared project, you should provide shared incentives that they must work together to achieve. In The Five Dysfunctions of a Team, author Patrick Lencioni recommends setting goals across both teams and rewarding both teams for meeting these shared performance goals. By creating these shared rewards, you’ll encourage each team to prioritize shared results over the team’s individual interests.)

Because of Conway’s law, Skelton and Pais note that software produced by two of your teams working in cooperation will result in 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.

(Shortform note: When deciding which of the two cooperating teams should take ownership of the final product, you should give control to the team that is best equipped to manage the software going forward. Often, one team will be more technically qualified than the other in terms of professional experience and skills. If not, you should consider which team originally owned the project, as they’ll likely be more invested in its continued success.)

The Consumer-Provider Model

Skelton and Pais’s second mode of interaction is the consumer-provider model. In the consumer-provider model (or as the authors call it “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. As opposed to cooperation, one team may provide their product to however many of your teams can make use of it, thanks to the low communication requirements of the consumer-provider model.

(Shortform note: The consumer-provider model is especially relevant for your organization’s cloud computing services. Using cloud computing, you can ensure that your workforce can work and communicate no matter where in the world they are. As remote work becomes more common, you may need to assign more teams to provide cloud services to an increasing number of internal consumers.)

Consumer-provider interactions are common between infrastructure teams and other teams. For example, one of your infrastructure teams might develop and maintain the software that other teams in your organization use to communicate with each other in real time. While the other teams offer feedback, your infrastructure team maintains the software on their own, treating the teams that use it as consumers of their own product.

(Shortform note: The consumer-provider model has striking similarities to the concept of internal customer service, which is the idea that customer service principles can be applied within your organization to increase employee satisfaction and effectiveness. In the consumer-provider model, providing teams are responsible for the customer experience of internal software consumers, ideally providing them with a product that makes their jobs easier and incorporating their feedback the same way many organizations make use of customer feedback.)

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. Otherwise, it will only cause delays as other teams will have to wait on the providing team to troubleshoot and fix bugs. To avoid these kinds of situations, you can encourage the providing team to focus on features that improve the user experience.

(Shortform note: As they attempt to improve the internal user experience, providing teams should focus specifically on creating strong communication channels. By making it easier to access knowledge within their software, providing teams help consuming teams both use the software itself and communicate issues with the providing team.)

To streamline consumer-provider interactions, instruct your providing teams to create guides for how to use their programs and how best to communicate feedback. Using these guides will help your other teams to better understand and use the software products.

(Shortform note: Providing teams can use feedback from consumer teams to improve the quality of their software guides. Experts recommend that you use internal feedback to create FAQs (frequently asked questions) and troubleshooting guides that help address common problems consuming teams encounter with a piece of software. A well-made troubleshooting guide saves time for both teams in a consumer-provider interaction, as it empowers consumer teams to solve their own problems without waiting for assistance from a provider team.)

Guidance

The final mode of interaction Skelton and Pais describe is guidance. Guidance (or as the authors call it, “facilitating”) occurs when one of your teams needs assistance, expertise, or knowledge from another team. Your guide 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.

(Shortform note: The skill sharing that takes place in guidance interactions can be especially important in helping get new hires up to speed. While new hires will also learn from the other members of their teams, you can make use of guidance to speed this process along.)

Guidance should be the default mode for your educating teams and will be most common in interactions involving those teams. However, guidance 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 receiving guidance to maintain full end-to-end ownership of their products. Because the guide team cannot directly impact the other team’s software, it’s important that you encourage receiving teams to maintain an open mind. When the team receiving guidance is unable to accept help due to pride or other factors, they won’t fully internalize new information, which means your guidance team’s hard work will be wasted.

(Shortform note: Recent psychological research corroborates Skelton and Pais’s assertion that open-mindedness impacts a team’s ability to make use of guidance. Studies have shown that open-mindedness increases a group’s capacity to learn. Experts theorize that this occurs because open-minded individuals and teams are more able to recognize their own shortcomings, which in turn makes them more receptive to growth.)

Guidance 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.

(Shortform note: One way guidance teams can help sharpen skills is by conducting code reviews, in which they manually look over another team’s code. By getting hands-on with another team’s work, they can provide much more detailed feedback and training.)

As Skelton and Pais state, guidance teams can also help identify patterns in interactions among your other teams. For example, they might notice that many teams have the same issues with the code provided by a single niche problem team. They can then present these issues to the niche problem team and, if necessary, present new approaches that might help address them.

(Shortform note: To gain an even better perspective on areas for improvement, teams offering guidance should spend time using the software products of the teams they assist. By using these products, they can better come to understand the user experience, and can more quickly locate specific problems and software shortcomings.)