What is the Spotify model for Agile scaling and how can you use it?

Reducing the Spotify model to just its Tribes and Squads is the classic failure pattern and this article is dangerously reinforcing it. This cherry-picking approach is where many organisations fail. The original content on the model was about a lot more than the squad model. But this is normally the only thing that orgs adopt. Please don't simply graft "Tribes", "Squads", "Guilds" and "Chapters" onto your existing organisational structure. It's oversimplified matrix management. Go and learn about matrix management properly rather than trying to copy the Spotify squad model for it (I recommend reading Highly Output Management by Andrew Grove)

Please remember, not each company is the Spotify. Some tips and tricks might get shared. Some good practices might be applicable, but whole model probably will not work on other companies.

I find the cross discipline model of squads and tribes enables team to deliver features effectively. In practice, I've seen most tribes more closely align to the organizational chart where each individual contributor sits on a team with a manager that is senior to them in their discipline. That manager helps them level up in their career. The squad is what determines the day to day work and is usually lead by the product manager for the team.

In my journey through Agile landscapes, I've been intrigued by the Spotify model's unique resonance. Encountering it was akin to discovering a new genre of music. It introduced me to 'Squads', 'Tribes', 'Chapters', and 'Guilds'. A 'Squad', I found, was much like a musical band, each member playing their part but with the freedom to improvise. They harmonize under 'Tribes', where multiple bands unite under a shared genre or theme. 'Chapters' and 'Guilds', to me, felt like conventions where musicians of similar instruments or styles gather, ensuring both individual mastery and collective harmony.

I did join an organization that boasted in the setup of squads and tribes. However, when I joined the organization it was clear that the appetite was there but the people lacked the basics of what his scrum and agile approach. This is where the buck stops. Make sure you address all the pieces before building the fortress.

I believe that one of the great benefits of the Spotify model is precisely the scale of knowledge (not just the scale of teams, because no company is like Spotify). So, taking due care with organizational design adjustments, some Spotify practices can be introduced to generate accelerated scale of knowledge and exchanges between members of a structure. This is the great benefit (and also challenge) of tribes and chapters.

Throughout my engagements, the Spotify model often stood out as a refreshing approach to Agile scaling. The beauty I discerned was in its organic structure, reminding me of the fluidity in a jazz performance. Empowering 'Squads' seemed to invigorate teams, leading to bursts of innovation and swift feature roll-outs. The synergy between Squads, Tribes, and Guilds ensured that while individuality flourished, there remained a steadfast alignment to larger organizational symphonies. This model, in my perspective, artfully wove individual passion with collective purpose, much like a harmonious musical ensemble.

If you are interested in applying the Spotify model, the first reminder is that even Spotify is no longer following the same model that made it famous. Instead of blindly applying the model, it is useful to review the best practices and understand if it make sense for your organization context. Read up on other framework and theories to brush up your tool-belt for agile scaling. Or in some cases, scaling may not be necessary or a good route.

Spotify don't use the Spotify model. They never really did (search "Spotify don't use the Spotify model" and see for yourself). Don't to attempt to blindly copy practices from other organisations. Especially not big tech like Google, Netflix, Spotify, Facebook etc. You'll most likely just end up cargo culting if you do - going through the motions without real benefits Frameworks and models are appealing as they feel like a shortcut, but they usually miss the nuances of your specific challenges (and why Scrum often gets a bad wrap). Be inspired, but don't copy.