Key takeaways

•  Why using the “Spotify Model” of team design is not enough
• How the three key team interaction modes enable fast flow and rapid learning
• How testers can play a crucial role in modern software delivery organizations
• How to address Conway’s Law, cognitive load, and team evolution with Team Topologies

At DevTest North 2019 I gave a keynote talk called Beyond the Spotify Model based on material and ideas from my new book Team Topologies: Organizing Business and Technology Teams for Fast Flow, co-authored with Manuel Pais. In this article, I share the key ideas from the talk.

The Spotify model for organisation design

For effective, modern, cloud-connected software systems we need to organise our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes.

In 2012 people at music streaming service Spotify published a well-known article describing how they organized their teams for a rapid flow of change using semi-autonomous Squads, Chapters of similar-skilled people, Tribes of related Squads working on similar product areas, and Guilds that act as cross-tribe communities. This model helps to emphasize a rapid flow of change because each Squad has a mix of skills – engineers, testers, business analysts, ops people, etc. – that allows the Squad to own a slice of the Spotify product and take an idea from concept through coding to Production. The software architecture also benefits because different business domain concepts are neatly separated into bounded contexts mapped to different Squads, which helps with a fast flow of change.

Many organisations have tried to copy the Spotify model but often with mixed results and limited success. Why could that be? There are several limitations which we’ll explore next.

Limitations of the Spotify model

Although the Spotify model is a useful starting point, it does not directly address several key aspects of modern software development, including:

• The size of software owned by (or assigned to) each team and the cognitive load on the team
• How the organization and software will be affected by Conway’s Law
• Patterns and models for team interactions
• Triggers to tell us when to change and evolve the organization structure

In fact, the authors of the original article, Henrik Kniberg and Anders Iversson, themselves warned against copying the model: “…by the time you read this, things [will] have already changed.”

How the ideas in Team Topologies can help

In 2013 I devised a set of team design patterns called DevOps Topologies that have become the de facto standard for thinking about modern organization design and team interaction for software delivery, used by organizations like Netflix, Conde Nast International, Accenture, and adidas to help find and evolve the most effective organization designs. Manuel and I curated and evolved these patterns with community help over the following years, but as we were consulting in various organizations around the world, we realised that the fairly static view of these patterns missed some important elements.

Eventually, we came to write the Team Topologies book, incorporating crucial dimensions like Conway’s Law, team cognitive load, patterns for well-defined team interactions, and organization evolution. In Team Topologies, we characterize what we see as the essential three team interactions modes, the only ways in which teams building and running software really need to interact. By adopting the three interaction modes, organizations can help their staff understand why different teams are interacting in different ways at different times, contextualizing the work in hand, and providing a way to detect misplaced boundaries and capabilities.

Getting started with the Team Topologies approach

A good place to start with applying these ideas is to map out the current team boundaries and how they relate to the software architecture. A big mismatch between the organization communication paths and the software communication paths probably indicates that the organization is spending a lot of time and money fighting against Conway’s Law – a real waste. As the organization begins to adopt the three key team interaction modes, it will become easier to diagnose problems with team relationships and therefore software architecture.

This is where testers have a hugely important role to play, because instead of just testing software, people with a testing mindset can start to apply those skills to testing the sociotechnical system that is a modern software delivery organization. If we know that Team 1 should be consuming something from Team 2 “as a service” but the two teams spend half their time collaborating on API changes, something is probably wrong. We can listen for and test these interactions within the organization in order to detect mismatched expectations. Organizations can develop a much clearer picture of the likely software architecture that will result from the communication structures in the organization and “course correct” much sooner than in the past by adjusting skills, capabilities, and responsibility boundaries to suit the changing business demands.

Written by Matthew Skelton, co-author of Team Topologies.