If you are a music lover, it is impossible to have not heard about the audio streaming subscription giant Spotify.
When it started in 2006, just like many other startups, it used the scrum methodology to manage its projects. As the company experienced exponential growth, it onboarded more people and had to adapt to the new conditions while maintaining the agile culture it was known for.
A key part of Spotify’s success is driven by the company’s unique approach to enhancing team agility. In this article, we’ll talk about Spotify’s agile model and how it works.
The first time we heard of the Spotify model was more than a decade ago in 2012. Henrik Kniberg and Anders Ivarsson — who were involved with Spotify at that time, of course — published the white paper “Scaling Agile @ Spotify.”
Henrik and Anders were part of the team that helped Spotify scale from a small startup. They wanted to share their experiences and learnings with others in the community.
The Spotify model is just the autonomous scaling of agile, as hinted at in the paper’s name. It’s based on agile principles and unique features specific to Spotify’s organizational structure.
This framework became wildly popular and was dubbed the “Spotify model,” with Henrik Kniberg credited as the inventor.
Henrik Kniberg later came out to confirm that he did not invent the model. He added, “I’ve noticed, via various blogs, articles, and presentations, that people sometimes seem to assume that I invented the Spotify model. I’m just the messenger.”
It later came out that Spotify doesn’t fully implement the Spotify model anymore (shocking). It was aspirational and never fully implemented throughout the company, and is not a sure-fire blueprint for a product development process.
Every other company wanted to adopt this framework for themselves. Spotify enjoyed a reputation for being innovative, and people assumed that if this framework worked so well for Spotify, it must also work great for them. Companies began to feel as if this framework was perfect, but nothing is perfect.
Spotify has changed its practices and ways of working over time — adapting its strategies and methodologies to changes in the market, user preferences, and more. The Spotify model itself was built with the company’s culture, values, and organizational structure in mind, with the ultimate goal of promoting cross-collaboration and innovation. As a result, it’s not a one-size-fits-all — the Spotify model was built around a foundation the company had already laid out.
Therefore, to embrace the Spotify model and implement it, it’s important to understand its elements and how it can be adapted to fit your own organization.
Now that you have heard that this framework became extremely popular and was adopted by other companies, you must be curious to know how this framework is implemented.
So, let’s dive deep into what makes the foundation of the Spotify model.
The original white paper describes squads as self-organizing teams that function like mini startups. Squad members are usually 6–12 people and have skills to “design, develop, test, and release products,” as well as the freedom to decide their work approach and how to get things done.
Each squad focuses on fulfilling a long-term mission for the product. They get to choose which Agile framework to use, like scrum, Kanban, or a mix of both.
Staying true to agile, squads work in short sprints to deliver value to the customer:
When multiple squads work together on the same feature area, that creates a tribe. Tribes are led by tribe leads, who coordinate the work of the squads.
Tribes are kept small, based on the Dunbar number, a suggested limit to the number of people one person should maintain a social relationship with, According to that, most people cannot maintain social relationships with more than 100 people.
Anyhow, regular tribe gatherings are held where squads can display their work and discuss what they’ve delivered and what others can learn:
Next, a chapter is a group of individuals with similar skills working in the same competency area within a tribe. They hold regular meetings to discuss their expertise and specific challenges.
A chapter lead manages the members and takes on traditional responsibilities, per Spotify. The chapter lead is also part of a squad, enabling them to stay connected with day-to-day work:
Guilds focus on topics, like frontend development or analytics, and provide a platform for knowledge sharing and collaboration across teams.
A guild is more fluid and serves as a group of people who want to share knowledge, tools, code, and practices:
In a short period, Spotify was able to bring out a framework to achieve its goals by adopting an agile scaling method that involves every individual in the organization, no matter the designation.
Their method proved helpful in several ways, both to the individual and to the organization as a whole:
The Spotify model has also been criticized and has potential disadvantages to consider. Let us look at a few of these to see why it may not always work.
First and foremost, it is certainly a complex structure. If you look at the previously-mentioned process with squads, tribes, chapters, and guilds, you may have realized that the method is quite complex. It has a lot of layers, and people who are not familiar with agile methods may have a hard time figuring out how the model works and what their role will be.
It also may create silos. The model is built around these squads, tribes, and guilds. It can lead to silos forming between different teams or departments, as each team becomes hyper-focused on its individual goals and expertise. This can be difficult, as it may minimize the need for cross-functional communication and collaboration — an important part of maintaining a cohesive organization.
Finally, there’s a lack of standardization. Formulating consistent processes and practices across teams can be difficult as the model is customized to each organization’s unique needs. For example, let’s say you work in product management for a big organization. One squad uses a specific project management tool for tracking their work, while an adjacent squad prefers an entirely different tool.
When the two squads need to come together and collaborate, they have to find a way to align their work without losing efficiency or causing confusion. Because there was no standardized process, this can lead to extra work and potential miscommunications, making it difficult for the two squads to fully capitalize on each other’s strengths.
To successfully implement the Spotify model in your organization, consider the following steps:
You can start with a small team or project first and test how it works out. You must be able to figure out if the method is effective or not and look into any issues that may pop up if implemented on a larger scale in the future.
Having specific metrics and KPIs to track will help you determine whether the model is achieving its intended objectives and will help you identify areas for improvement.
The method will only work if the organization is entirely sure and informed about how the model works, its principles, and what it tries to achieve.
It’s crucial to maintain effective communication with all team members to make sure they are on the same page before the implementation.
It is necessary to customize the model to fit your organization’s structure and processes. Do not try to follow it blindly — tweak it as per your company’s needs.
By following these steps, you can successfully implement the Spotify model and improve collaboration and agility within your organization.
Pro tip: Do not blindly copy-paste the framework💡
There are actually many well-known products and organizations that implemented the Spotify model to improve collaboration and agility.
A surprising and popular example of this implementation would be LEGO. They reorganized their teams into squads, tribes, chapters, and guilds, which led to faster product delivery and improved customer satisfaction.
LEGO is an interesting example because its products are all physical goods that land directly in the hands of consumers. But, like Spotify, many digital products and organizations benefit from it as well. Financial services company ING created cross-functional squads to accelerate their bringing out of new products and services.
Many businesses have successfully implemented the Spotify model, but blindly following it should not be considered a sure-shot way to achieve what Spotify could do. It worked well for companies that it blended well with in terms of how it functions, its culture, and its structure. Copy-pasting it for another organization and expecting it to make the firm flourish could be far-fetched.
The Spotify model has undoubtedly revolutionized the agile landscape. It’s been a great model for other organizations to try with its unique approach to squads, tribes, chapters, and guilds. Though the Spotify model promotes adaptability and creativity, we’ve also explored its drawbacks and potential pitfalls to consider before you go ahead and try it out.
Thank you for taking the time to explore the Spotify model in this blog. I hope you found this journey insightful and engaging!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Sanjay Modi discusses his role in leading a website security product portfolio through drastically changing customer needs.
The acronym SDK stands for software development kit. It contains platform-specific tools to run and develop software.
If you think about some of the businesses that market familiarity as a selling point, you actually don’t get negative vibes from them at all.