Book SummaryTeam Topologies, by Matthew Skelton and Manuel Pais

1-Page Summary1-Page Book Summary of Team Topologies

Team Topologies, by Matthew Skelton and Manuel Pais, is a manual for restructuring your organization’s approach to software design. 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...

Team Topologies Summary Use Conway’s Law to Set Up Successful Teams

In this section, we’ll examine Conway’s Law in greater detail to give you a better understanding of how it shapes Skelton and Pais’s approach to team design. Then we’ll look at the two main strategies they recommend for using Conway’s Law to build strong teams. 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.

Use Conway’s Law to Set Helpful Deadlines

In addition to shaping the work output of individual teams, Conway’s Law also has implications for time management practices at your organization. The book that popularized Conway’s Law, Fred Brooks’s The Mythical Man-Month, argues that [setting accurate estimates for how long a project will take actually helps speed the project to...

Team Topologies Summary The Four Types of Teams

Now that you know how individual teams should look, let’s consider the four types of teams (or “team topologies,” as the authors call them) that Skelton and Pais recommend creating: stream-aligned teams, educating teams, niche problem teams, and infrastructure teams.

As Skelton and Pais assert, these team types are designed for your organization to benefit from Conway’s Law as much as possible. 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.

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. This product could be anything: a specific microservice, a mobile application, or something more nebulous, such as innovating ideas for new software. 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.

(Shortform note: Skelton and Pais’s term, “stream-aligned team,” references the concept of flow, which is the idea that a piece of...

Team Topologies Summary 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...

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