When building digital products, we all want to feel like we’re doing it the right way. And nothing feels more satisfying than feeling like you’ve finally found the perfect framework or methodology that’ll help you do that.

Unfortunately there are so many to choose from! So it’s important to do your research and figure out which ones are worth trying.

You might have heard of the billion dollar company, Spotify. And you might even have heard of their innovative framework for organising teams and scaling products in agile. Even if you’re not building a music streaming platform, the model presents a new way of empowering self-organizing teams and building a product loved by millions of users.

What Is the Spotify Model?

The Spotify model dates back to 2011 when Henrik Kniberg & Anders Ivarsson, at the behest of their colleagues, published a whitepaper: Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds.

Kniberg is often credited as being the ‘inventor’ of the model, but he’s the first person to tell you that’s not the case! And he’s also keen to impart that it was never meant to be something that people copied, or implemented at their own companies. “It’s just an example of how one company works.”

It was never intended to be published as a framework, but rather as a generic overview of how product development is organized at Spotify. It includes the team hierarchy, how teams are organized, and the kind of company culture needed to make the whole thing work.

As an agile company, Spotify’s model champions the needs for collaboration, transparency, and simplicity, which makes it very attractive for other agile companies looking to make the methodology work for them.

Structure of the Spotify Model

Image credit: Scaling @ Spotify

The Spotify model has a lot of moving parts, which can look a little complicated at first glance:

Squads

A squad is described as the most basic unit of development, and is probably the most familiar for PMs who have worked in ‘typical’ agile teams. Each squad is designed to function like it’s own mini-startup, with all of the skills needed to build a product, (design, testing, engineering, etc).

Teams are self-organizing, and each squad can choose the framework that works best for them, which could be Scrum, Kanban, or whatever else that squad fancies. This allows teammates to work in a way that best suits them, which maximizes their productivity and makes their working lives easier.

Each squad has their own long-term mission, and own a particular slice of the overall product. While leadership doesn’t dictate how squads work towards that goal, squads are encouraged to employ lean product principles like A/B testing and releasing MVP s. Squads have agile coaches to help them understand how to build in the right way, and a product owner who helps their teammates to prioritize their tasks.

Tribes

Squads are built to function by themselves, but that doesn’t mean they work in isolation. Squads are organized into relevant tribes depending on which part of the product they’re working on. Eg. backend infrastructure. While there is no official hierarchy, the tribe lead is assigned to each tribe, who ensures that everyone has what they need to thrive. Tribes are designed to be less than 100 people to make organization manageable, and informal gatherings are regularly held so that everyone has the opportunity to be up-to-date with what other squads are doing.

Crossover between squads is inevitable, which creates certain dependencies. These dependencies slow teams down, which is something that the model aims to cut down on as much as possible. This helps to rid development of bottlenecks and keep things moving at speed.

Chapters

Collaboration is the key, so perhaps it seems a little strange that Spotify chops its workforce into smaller autonomous teams that seem to not be working together. That’s why the model introduces chapters.

Members of different squads with similar skills or who work on similar problems form cross-squad chapters. The chapters will meet regularly to keep eachother up to date on what they’ve been working on, and to share solutions to common problems. This frequent knowledge sharing ensures that there is helpful communication between the squads, and also helps the members of those squads to innovate together.

Guilds

Guilds are a little messier, as you can see from above. Where chapters are based on the official role of an individual within their squad, guilds are more general areas of interest. For example, testing. Everyone directly involved in testing will join the guild, but even those who don’t need it for their day-to-day job, but are simply interested in it, may also join in order to learn.

You might also be interested in: How to Get a Product Management Job at Spotify

Benefits and Challenges

Challenge: Risk to system architecture

Spotify has 100 distinct systems which form the overall product. When squads update one, they usually need to update several to implement the changes they’ve been working on. The risk here is that the architecture can go awry if everyone is only focusing on a small chunk of it at a time. Having a System Owner, someone (or a pair of someones) who owns the integrity of the architecture, mitigates this risk.

Benefit: Autonomy

The results across many companies speak for themselves; autonomous work is the future of successful agile product development. The main benefit of the Spotify model is that teams are empowered to make their own decisions and work in the way that best suits them. This encourages transparency, trust, collaboration, and experimentation, leading to better products.

Benefit: Fewer bottlenecks and red tape

When teams run themselves and make their own decisions, they’re able to work faster and avoid time-wasting bottlenecks. The model encourages informal gathering and information sharing, without too much ceremony or formal process.

Challenge: It won’t work for every company

The model looks fantastic from the outside, but choosing to implement it simply because it worked for Spotify is a mistake. The model fits the company culture, which is much more difficult to change than the framework you’re following. Rearranging the structure of your company is a big risk and a huge investment, and because the Spotify model was not designed to be copied by other companies, it may not be a good fit for yours.

Should We Implement The Spotify Model?

That’s what you might be asking yourself.

If it worked for Spotify, can it work for us?

When choosing any new framework, research is key. The first thing to figure out is what problems you’re currently facing as an organization. Do you have a problem with cross-team communication, or do you have leadership that is set on sticking with the slow-moving waterfall method? Perhaps you’re suffering with bottlenecks. Or perhaps you’re not quite sure what’s wrong, and you’re looking to copy a successful company as an easy fix?

You’ll never solve your problems if you don’t get to the root of them. Gather feedback from every single team member on the problems they face that are caused by company culture/structure, and work to come up with a list of the most common ones. Then compare those to the solutions presented by the Spotify model.

The Spotify model isn’t a case of all-or-nothing. You don’t need to strip down your org chart and rebuild it according to the model. A much more reasonable step would be to start implementing some of the agile principles that make the most sense for your teams.

If you’re looking for frameworks to boost your work, we’ve got everything you need right here. Check out our full collection of product management templates.

Learn from Spotify Product Leaders

If you enjoyed learning about the Spotify model, you’ll also love these talks by Spotify PMs that we’ve picked out for you:

I’m Carlos González, CEO at Product School, and I enjoy sharing weekly tips for Product leaders!

Are you interested in Product Management? Check out our certifications here.
Looking for a good read? Because we’ve launched “Ship It” as a free resource.

This article was also published on The Product Management Blog.