Team topologies fix the Spotify model

The Spotify model

The Spotify model [SPOM] describes an organisational structure which aims at maximising agility through removing friction. The building block of the Spotify model is the squad, a team which is responsible for the entire lifecycle of a product from inception to implementation, operation and retirement. Friction is removed by maximising squad autonomy: squads don’t have to obtain permission or resources from anyone outside their boundaries which minimises bureaucracy and dependencies on others. In order to prevent squads from devolving into autocracies, the Spotify model foresees tribes (parent organisations of squads) and chapters (thematic groups of interests) to foster collaboration and align squads within the organisation.

Issues with the Spotify model

A former Spotify associate explains [SPOF] why the model failed and why Spotify isn’t using it any more. The model focuses on increasing squad autonomy which drives teams to decrease dependencies on outside resources, services and decision makers. Squads end up incorporating more and more functionality in order to avoid dependencies on others, which causes squads to grow in head count, responsibility and scope. Engineering managers quickly lose control as more peripheral and auxiliary competencies reside within their squads and as those competencies start replicating in other Squads instead of being shared, the engineering organisation cost and complexity grows. Chapters become ineffective and fail to share competencies across squads as they don’t contribute to the core squad objective of maximising autonomy.

Team topologies to the rescue

Team topologies [TTOP] is an organisational structure popularised by Matthew Skelton and Manuel Pais which fixes the squad autonomy problem by formalising team collaboration and reduce cognitive load on teams by placing a hard upper bound on team sizes.

The first, refreshing, difference from the Spotify model is that teams don’t overlap any more in various, ill-defined groups. There are no tribes or chapters, just teams with clearly defined missions.

Next, there are (only) four team types whose names actually describe what they do. Stream-aligned teams are the usual value stream (eg. product or service) teams which run a value stream end-to-end. All other teams exist only to make the stream-aligned teams’ life easier by reducing their cognitive load. Enabling teams bring innovation to other teams and solve hard problems. They move freely around the organisation and interact with other teams when needed. Complicated sub-system teams are placeholders for specialised activities (Matt Skelton mentions maths PhDs as an example) that cannot otherwise be carried out and require their own expert team. Platform teams concentrate shared responsibilities of other teams (eg. cloud infrastructure management), maximise quality and minimise cost through economies of scale and reduce cognitive load for other teams.

The team topologies organisational structure improves the Spotify model because it enforces a growth constraints on teams: the domain a team works on must fit in everybody’s head. Once the domain complexity increases beyond an individual’s understanding, the domain must be partitioned into multiple teams. This constraint on team size forces teams to collaborate with each other. The Spotify model promotes collaboration through the vaguely defined chapter which is largely based on volunteering and thus more or less optional, while team topologies enforce collaboration by making it mandatory for everyone: stream-aligned teams must trim their domains by offloading complexity to the platform team, new stream-aligned teams or specialised complicated sub-system teams, the enabling team proactively identifies topics for improvement and implements them through its do-don’t-tell mentality and the platform team’s job security is tied to the services it offers to other teams.