Spotify Tribe Model: Is it or is it not a Scaling Model?

Spotify has cemented itself as one of the best music streaming apps surpassing Apple Music, Amazon Music and Youtube Music. With over 30 teams spread across the globe and having more than 1500 employees, Spotify is thriving. Unlike many organizations that owe part of their success to implementing a well known agile framework, the Spotify Tribe Model is different. They consider their uniquely crafted framework the secret recipe for their success.


In an ocean of knowledge available on the internet in this day and age, there is barely any updated information available for what really drives the development at Spotify. Which begs the question, can the Spotify way of working be considered a scaling framework model and can it really be adapted by anyone?


We will aim to uncover the many mysteries that surround this topic in this article by talking about what we know about the framework and how we can learn from Spotify.

What We Know

In the start of 2010’s, a series of blogs started rolling out that talked about the unique way of development at Spotify. It was called the Spotify Framework. Around 2015, videos were uploaded on Youtube that discussed the framework in great detail but the information dispensed in these videos showed a completely different implementation of what it actually talked about in the blogs written before even changing the name to the Spotify Tribe Model.


According to the information gathered about the framework, this is the breakdown of the structure of the framework:

  1. Squad: The team that designs, develops and tests a feature
  2. Tribes: Multiple squads that work on one feature area
  3. Chapter: Consisting of specialists
  4. Guild: Individuals from different tribes focused on one area
  5. Trio: 3 individuals of leading roles of every tribe
  6. Alliance: Combination of 3 trios

To further understand the structure of the teams in the Spotify Tribe Model read this insightful article here.


Undoubtedly, the style of development being used at Spotify is Agile. Their style of development ensures that each feature area remains completely independent of the other ensuring a very decoupled approach.


The Squads are free to pick out and decide what they want to work on. What is really fascinating is that even though these squads might be spread across the world, they would be working on different features, components or widgets. The Chapters and Guilds ensure a consistent output determined by product management and also support continuous integration.


What truly makes the Spotify Tribe Model great is its ability to do what feels the best to work with and adapt swiftly to it. The squads do incorporate some practices of Scrum and Kanban but they are not bound by it. They can adapt any practice that suits them and abandon whenever they want. So every squad could be utilizing a working approach towards reaching their goals that could be different from the other squad. They have dedicated Agile Coaches that facilitate, guide and help the teams through the process of becoming agile completely.


What We Don’t Know

Is the Spotify Tribe Model really a scaling model? Even though the teams are located in different countries of the world, it is still hard to say that this method of working for Spotify can actually be considered a scaling model based on the limited knowledge available.


After learning about the basic construct of how the Spotify Tribe Model is designed, it is often thought to be a very straightforward implementation, when in fact it is much more complicated than that. When starting to implement the framework, it is hard to discover what shall be the starting point. It is rather unclear why people make the switch to implementing the Spotify Tribe Model in the first place.


As you start to dive deeper, it really becomes confusing to understand how the tribes and the chapters should be formed as there is no clear information on how the components need to be broken down. It makes sense for a music platform but how do we break down complicated products or value streams and have them as independent components or widgets, that is not known.


Value Stream mapping is a very vital step in planning the series of steps taken by an organization to develop a solution or a service from concept to delivering value to the customer. This concept remains absent for the Spotify Tribe Model and becomes a problem on how you should scale the value stream method in a larger or a complicated organization.


When a framework is scaled, it is made sure that the same principles and practices are applied across to maintain a sustainable level of output. Popular scaling industry frameworks like the Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) and Nexus do provide this and they have a huge amount of consistent, updated and transparent information coupled with success stories available that completely supports it. But unfortunately, the same cannot be said about the Spotify Tribe Model.


There is a lack of having complete and updated knowledge about the Spotify Tribe Model when compared with the above mentioned frameworks.It has gotten around to people mostly by word of mouth or coming across reading or watching old outdated content. Similarly there are other aspects listed below that remain a mystery about the Spotify Framework.

  • There is no information on who created and owns the framework
  • No clear and definitive documentation of what each part of the framework does
  • Inability to keep track of the updates made to the framework
  • Lacks a formal definition of their processes
  • No workshops to show how the framework operates
  • No certification opportunities that lets you gain a grasp on how the framework operates

What We Can Learn

Despite the scarce availability of information, we can still learn a lot from the Spotify Tribe Model. It is important to know before implementing any known agile framework, that it is never a one size fits all situation. Every organization is different. Thus a major aspect of it may remain the same but some parts of it have to be adjusted in order to suit the organization’s culture.


A great amount of time and effort is spent on completely communicating the information from the top to the bottom layer. Spotify has done really well in knowing exactly how things operate. They have Agile and the right mindset as their foundation and have built up on it keeping the terminologies and roles specific to them.


This definitely is not an easy task as it has taken years and years of hard work in finding the sweet spot to find the right balance and the tempo for running a company of such a size.


Any organization can have their own version of an Agile framework but in order to successfully execute this, having a clear understanding of agile is very important. It is pertinent to understand that any framework that an organization maintains or incrementally improves during the course of time, based on the lessons learnt, indeed make it a Scaling Model. It might have a mixture of methods from other frameworks but as long as the foundation of it remains Agile it will definitely maintain its status as a Scaling Agile Model. So to answer the question: Is the Spotify Tribe Model a Scaling Model? It is…for Spotify.

Kendis Solves the Need for Visibility

Regardless of how your framework operates, you cannot ignore the need for visibility. In a world of changing requirements where the teams deal with emerging dependencies and risks, maintaining a track and a transparent view of it all is very important.
Kendis allows you to seamlessly create and track all of your work items, dependencies, risks and objectives and seamlessly track them with rich analytics all in one place.


You can create and map squads,Tribes, work items, dependencies, risks and objectives, all of which can be transparently viewed to you on its digital board. Kendis empowers you to seamlessly track all of your progress using insightful and rich analytics that will benefit you in making better and informed decisions.


Want to learn more about Kendis? Click here


Leave a Reply

Your email address will not be published.Required fields are marked *