The important part of the Spotify Model

The Spotify Model, as it is commonly referred to, has become a popular way of structuring medium-to-large agile product engineering organisations.

(Aside: Be sure to watch part 2 of this as well. Both parts need to be considered together.)

The most commonly referenced part of the wider illustration is this one:

Look! Squads! Tribes! Chapters! Guilds! That looks well-organised!

It gets my goat when companies outright copy these structures without considering that they were developed by Spotify to help with the situation they found themselves in at the time.

These structures are all about how decisions are made, and by whom. For a small organisation consisting of only one team, the cross-team structures are redundant. The team makes decisions informally and just-in-time easily enough, because the group size is small enough to work that way. Usually there’s a tech lead who has ultimate ownership for technical decisions.

One of the big challenges of scaling an organisation comes when a second cross-functional ‘squad’ (or ‘team’ if you like) is created. A whole bunch of new questions start cropping up. Who owns the overall architecture? How do we manage dependencies between teams? Is what we’re doing useful to the other team?

Again, with just two teams, it’s still just about possible to handle most of these questions as they crop up using informal communications and a healthy dose of mutual trust. But this doesn’t scale well.

In many organisations, when the total headcount gets beyond around 20, it’s common for the ivory tower architecture roles to start appearing. These are the people the sit outside delivery teams and make proclamations about How Things Should Be Done. The problem with this approach is that it challenges team autonomy by introducing previously absent external ownership.

This is why Spotify created Chapters and Guilds. The aim was to maintain autonomy, but prevent the descent into misaligned chaos that comes from having no structure.

That’s why it’s better to focus on this chart from that same Spotify illustration:

In the top right, the pointy-haired manager type is communicating the problem that needs solving, but also paving the way for teams to solve it with some light structure, and yes, bureaucracy.

Ultimately it’s the principles behind Spotify’s approach that are worth copying, not their specific implementation.

Take a look at the above chart. Where does your organisation sit? And what can you do about it?

All the best,

– Jim