I was in San Francisco in December for a conference. While I was there, I ended up connecting with a couple different companies who have been inspired by Henrik Kniberg’s whitepaper on Scaling Agile at Spotify, and who have been trying to implement some of those ideas in their own companies.

I think Henrik’s paper does an excellent job on describing the what and how, but it seems that the “why”, and some of the critical ideas can get lost when others read it.

If you haven’t read Henrik’s white paper, I’d suggest that you read that before reading the rest of the blog post. I will do a quick recap here though.

Spotify’s engineering and product organization (now over 600 people) is split into several large groups called Tribes. Each Tribe is responsible for a set of related features or engineering functions. For example, our largest tribe is the Infrastructure and Operations Tribe, whose name is pretty self-explanatory. I am the Tribe Lead of the Music Player Tribe. We handle importing audio from our label and distribution partners, storing and streaming the music, search, collection and playlists, artist pages, music metadata and the music knowledge graph that supports things like the above, but also ads, discover, radio and the like.

While the whole company works on the same product, Spotify, each tribe is set up so that it can work as independently as possible. As you will see below, a critical aspect of our organizational model is to give autonomy at every level. This helps remove decision-making bottlenecks and unnecessary dependencies, which improves velocity.

Each tribe is composed of squads. A squad is a team that is responsible for a single feature or component. For example, there is a squad that is responsible for search, a squad responsible for the AB test infrastructure, etc. As each tribe is set up to be as autonomous as possible, each squad is also set up to be autonomous. In the context of a feature development team, this means that each team is a full-stack team. A full-stack team is responsible for both backend implementation as well as the user interface implementation, on all platforms.

A typical feature squad would have web service engineers, iOS, Android, web and desktop engineers as well as testers, an agile coach, a product owner and UX designer. With this staffing, the squad has everything they need to implement anything related to their feature. They don’t have to wait on another team to implement the pieces they need. They also have autonomy and local decision-making ability, so there are few impediments on their speed of execution.

To this point with Tribes and Squads described only, Spotify may seem like a traditional, hierarchical engineering organization, but this is where the similarity ends. Unlike a traditional organization, a squad does not have a single engineering leader whom everyone on the team reports to. In fact there is not a single leader for the squad. The Product Owner and UX Designer work with the engineers and testers collectively to make decisions about their features.

Spotify is not a “no manager” culture though. We feel strongly that managers have a role in supporting the people who work for them. Managers have an important role to play as technical and career mentors and organizational communication conduits. Rather than have management hierarchies follow organizational ones (creating a de facto command-and-control structure), we instead have first level managers responsible for technical functional areas across multiple squads.

We call these reporting and functional groupings “chapters.” Again, as an example, reporting to me, the tribe lead, are Chapter Leads. In my tribe, there are currently three backend (services) development chapters, two front-end development chapters (including all the UI developers), a core library chapter, and a test chapter. These seven Chapters span eight different squads. Almost every chapter lead has reports in 2 squads, and a few of them have reports in three squads. Almost all chapter leads work within a squad in some capacity as well, either as developer or technical lead, and not necessarily within a squad that has members of their chapter.

This chapters/squads matrix organization is critical to our organizational agility. It allows the squads and the tribe to be more fluid. We can spin up a new squad to take advantage of an opportunity or handle an issue without worry about changing reporting structures. If a squad completes its goals and has no reason to exist anymore, we can dissolve it without punishing a manager. This is a very important difference to a traditional hierarchy, because it gives us a lot of flexibility and helps us avoid the old political issues around empire building and resource contention.

In addition to our Tribes, Squads and Chapters, we also have virtual organizations called Guilds. Guilds are cross-tribe organizations centered on different technical or interest areas and their membership is voluntary. The guilds serve as ways to promote cross-tribe collaboration and communication, especially around things like best practices. For example, we have guilds for Web Development, Agile Practices, Leadership, Test Automation, etc. The guilds foster developer-to-developer communication, which is one of the ways that we keep all these autonomous teams from all going off in completely different directions.

From Henrik’s paper, this diagram illustrates the organizational structure I discuss above:

I’d like to give some more background around why we have implemented this organizational model at Spotify; elaborate on our goals for implementing it, and discuss the aspects of our culture, which have been critical to its success. It is really great that other companies have been inspired by the way we work, but I think if you implement only parts of the model or try to impose it on a very different corporate culture; you will have a difficult time achieving the same level of success with it that we have had.

If you are considering using the Spotify organizational model within your company, there are a few things that will be critical to your success:

Our organization model assumes that engineering is doing development with agile methodologies. Our goals for autonomy mean that we do not prescribe any particular development framework our squads must subscribe to. However, all of squads use agile development methodologies. While we do our best to minimize dependencies between squads and tribes, there will always be some since we are all working on the same product. Any individual squad choosing to build using a traditional waterfall or other non-agile process would not be able to keep up with the rapidly changing teams around them. If they tried to impose some sort of process on other teams so that they could follow a longer-term development plan, they would start slowing down the rest of the organization.

A critical requirement in making our organization model work well is that the entire company works with and understands agile practices and processes. While our legal team isn’t doing scrum or kanban, they are used to working with engineering teams that use agile processes. Having the entire corporation understand and agree with agile means that no line of business area becomes an impediment to the speed of implementation. Think of this in terms of Amdahl’s law, applied to a development organization. If your development teams are working quickly in parallel, but marketing or legal is not supportive of an agile approach, they will become a bottleneck that will slow down the overall speed of the company.

Similarly, implementing this with just one team as a test in a larger engineering organization will be prone to issues. A traditional engineering organization is not usually set up for autonomy. Adding a single autonomous team within that web of dependencies is likely to hamper and frustrate the team and skew the results of the experiment.

While I’ve mentioned autonomy in several places already, I cannot understate its criticality. Each squad must be empowered to make their own decisions, not only on features, but also on development model, infrastructure, and implementation. Every decision that has to be approved outside the team means a delay that slows development. Each dictated implementation or infrastructure decision means that a technology that doesn’t fit to the way the team works or something new that must be learned before the team can build. This is a challenge to coordination, but in practice it isn’t as bad as it might seem. Best practices and technologies do spread from team to team through avenues like guilds. Teams adopt these practices and technologies on their own schedule or pioneer new ways of working if it makes it easier for them to deliver value to our customers and then spread their learnings to the other teams.

Trying to layer the tribe and squads model over a traditional reporting hierarchy would be very problematic. While we have many long-lived squads at Spotify, we are constantly creating and disbanding squads as new needs arise or missions are fulfilled. Squad membership will also ebb and flow as required by the needs of a squad’s mission. Traditional hierarchical organizations are self-perpetuating and restructuring them is very disruptive both to the management chains as well as the individual team members. You would gain some of the benefits of the Spotify model by building full-stack teams in a traditional organizational hierarchy, but you would lose a lot of the overall speed benefits that we leverage with our matrix organization.

In conclusion, if you are looking to improve the speed of your development and are inspired by Spotify’s organizational model, there are a few things that you need to understand. Our model works because it is layered on top of our corporate culture. Our culture values autonomy, agile processes, democratic teams, and servant leadership, amongst other things. You can certainly take some of the ideas from the way we work and apply them in your organization, but without the cultural underpinnings you may not get the same returns.

96 thoughts on “Thoughts on emulating Spotify’s matrix organization in other companies”

Comment navigation

Awesome stuff Kevin! The one thing I don’t see discussed is measurement. Could you talk a little bit about how KPI’s (traffic, frequency, conversion, retention, etc) are managed/cascaded across Alliances/Tribes/Squads. A few concrete examples would be extremely helpful. Thanks in advance.

Higher level metrics come to the Tribe or Alliance, depending on the scope. A metric should only be “owned” by the team that can actually move that metric and would have it’s mission to do so. So metrics like retention and MAU/DAU would be owner by the Consumer Alliance, while Conversion would be owned by the Revenue Alliance. Obviously, Revenue can affect retention (like by playing too many ads), and Consumer can affect Conversion (by providing a bad user experience), but each alliance is oriented towards success in those goals and can put checks on the others inadvertently ruining the commons.

Nice article…but one thing bothers me. How do you handle ownership of your features in cases like incidents. Lets say, there is some problem in streaming music feature. Who is responsible for analyzing it and later for solving it? Problem could be in front-end, in back-end, in database… Finding solution to the problem could involve cooperation with people from different chapters. But If I understood you correctly, no one is responsible for the feature as the whole(from technical point of view). Because squads are not permanent, and people in the chapters are responsible only for “their” part of the whole feature. And it’s not only about incidents….someone should supervise the entire feature(i.e. if it’s still functioning as it was intended).

I understand chapter leads are part of a squad and are involved in the day-to-day work, which helps them stay in touch with reality.
Next to that chapter leads are also line manager for their chapter members, with all the traditional responsibilities such as developing people, setting salaries, etc. (focus on technical excellence).

If we say that a squad member takes on the role of a back-end developer for 50 % and the other 50 % he does the testing for the squad, than to which chapter does that person belong to?
Who would be his line manager? Or would he than have two?

Hi Kevin
“While squads don’t have team managers, individuals do. The chapter leads are line managers and are responsible for handling issues that arise with the people that report to them.”
This is very clear to me as long as we look to individuals having roles within the squads wich are autonomous teams. But As you have a line manager for them you would need a line manager for the other roles : the Chapter leads for example who would be their line manager ? Same for Tribe leads or product managers.

I’m not 100% sure if I understand your question correctly, Francois. Every person in the squad has a manager. At Spotify, the product and UX teams have a more traditional hierarchy, but the other roles are managed by Chapter Leads. Tribe Leads report to Mission Leads (this is a more recent development to handle the increasing number of tribes), and the Mission Leads report to the CTO.

It is not uncommon in squads for people to take on responsibilities from other disciplines on a temporary or permanent basis. In that situation, though, they would just pick the chapter that they feel most aligned to. Once you are in a chapter, you probably wouldn’t leave it unless you wanted a change of manager or you switched tribes.

What’s the minimum number of people in your product + dev teams do you think is necessary to apply this organization? Looks like it only works if you have already plenty of resources available.
How do you manage people working in multiple squads?
Thanks!

To be sure, this is a lot more people and resource intensive over a more traditional organizational model. The minimum size of the team would be dependent on the mission of the team. Spotify had squads as small as three people, but a traditional feature squad supporting all of the Spotify consumer platforms would have usually been at least 8-10 people.

People should only be in one squad at a time. Otherwise, how do they know what they are supposed to work on day-to-day?

Hi,Kevin! Could you give some ideas about what squads are in Infrastructure and Operations tribe ? What are the general ideas behind this tribe ? From my point of view this tribe is a bit different from the tribe you are describing in the article. For example usually teams from Ops are 24*7 available and are often on duty.

We moved from an Ops model to each squad having operational responsibility for their own services. The “ops” team would respond to issues when they were related to networking or central routing services going down. The majority of infrastructure works on building tools to help build, deploy and manage Spotify’s micro-service architecture. Tools like monitoring, deploying, A/B testing, etc…

Hi Kevin,
Great article! I have some questions:
1. A squad is a team that is responsible for a single feature. Who/how/if decides about new features and long term roadmap?
2. How you keep consistency with a product vision? I can imagine UX dilemas like simplicity vs complexity.
3. How to avoid UI inconsistency beetwen features?
4. Who/how makes prioritization decisions for cross-tribes /squads ?
5. How to avoid situation when one team destroys work of other team working on other components. How do you sync that?

1. More feature area than a specific feature. A squad has a mission to solve a user problem, the features flow from that.
2. This was a big problem. It was solved by the UX team working together to definite a consistent design language, creating a set of shared controls and having the UX team work together one day a week to make sure that lots of folks were seeing designs in process.
3. see above
4. Cross-squad prioritization within a tribe comes from the tribe leadership. Cross-tribe comes from the alliance leadership or senior product leadership.
5. It happens from time to time that one team may inadvertently step on another teams toes. Try to avoid by being good citizens (make other teams aware of what you are doing). It doesn’t happen that often though, and it is better to solve the issues than to create a lot of processes or bottlenecks to avoid it.
6. Theoretically, you need to be ruthless about killing underperforming features. Very few companies, including Spotify, are great at it. Very few true “half-baked ideas” are ever shipped though because the company is good at A/B testing to make sure only things that perform go to 100% of customers. Then again, lots of things that were only slightly positive and shipped on one platform never got ported to the others, so technically that might count as “half-baked ideas.”

“If a squad completes its goals and has no reason to exist anymore, we can dissolve it without punishing a manager. This is a very important difference to a traditional hierarchy, because it gives us a lot of flexibility and helps us avoid the old political issues around empire building and resource contention.”

I think to form a team from a group of people takes time. How do you manage a group of people become a high performing team if the squad dissolves after completes its goals?

timelines on completing goals differ. In the tribes I ran, the goals would be permanent (because they were long-term product goals). In other tribes, goals would be completed on a much more frequent basis. The result of that was that people got used to working with a lot more folks in their tribe, and so the forming/storming/norming phases went a bit faster, but still less optimal than a team that has been together over a long period of time. A plus is that you can form a team to attack a specific problem, rather than having to use the same team in ways that don’t match their skill sets.

What I like about matrix organizational charts is that it can illustrate the responsibility levels regardless of the structure of the company. You can find various org chart templates designed on scenarios from the diagram community of Creately Org Chart Software

So great article and so good to see that you keep interacting with people who are so interested about the culture at Spotify!

As one of them, I would love if you could explain if all teams work in that agile/squad approach. I mean: teams who negotiate with labels/distribution partners/etc, marketing teams who launch engagement campaigns, and other “business/commercial” related activities. Are they also divided into squads with their own missions, or are they in a traditional org structure?

I would think that although their work is essentially different, maybe asynchronous with feature releases, they could also benefit from being in a squad themselves and being close to other dev squads… If you use different org structures for them, how do you keep them in the loop with the work performed by dev squads?

Thanks for the question. I get this one a lot. The answer is no. Teams outside of product development do not work with the tribe/squad model. I think that was a fundamental mistake in the Spotify structure. When the company was smaller and the development team dominated the rest of the organization in size, it didn’t matter as much. The other functions needed to align themselves to the development teams. As the organization grew and other functions grew big enough to have their own mass and gravity, they started to put pressure on the dev teams to conform to them.

Interestingly, a few companies that were inspired by the Spotify model made the mistake of assuming that the entire company was organized into squads, and set themselves up in that way. I visited one of them, Stylight, and was very impressed with how truly cross-functional their teams were (seeing the legal team’s kanban board was definitely eye-opening!) I definitely brought that lesson to Avvo when I left Spotify.

What we’re trying to do at Avvo is bringing the other parts of the organization into our cross-functional development teams. This has been working well for us. It has been hard for some teams to abandon their siloed nature, but we’re continuing to work on this.

Kevin , I was wondering if you could provide some insight on how a guild meeting looks like . I am trying to start this within my org and trying to see what kind of structure needs to be provided . Do we need a mission/goal for a guild ? Also how would you quantify progress ?

Basically , I would appreciate any help on how to kickstart this , setting the right mood .

Different guilds worked in different ways. There were more structured work-focused guilds with elected leaders, regular meetings with agendas, decision-drivers, and other formal roles. Then there were the very informal guilds which may be mostly a mailing list with an occasional meeting or event.

My suggestion would be to decide the role of guilds in your organization. If they are serving a specific purpose and that purpose is important, it might be best to start them more formally with an initial structure and then give them the freedom to change over time to suit their needs.

We had a couple architects, but they were really very senior engineers who would look across the squads and make sure that the teams were making good technical decisions. We didn’t have an architect designing systems for others to implement.

Hi Kevin,
Thanks for answering all the questions above in addition to the article in itself.
Can you please share the org model which surely involves other divisions which may not come in as squads(Budget, program management, business analysts, release train engineers, compliance etc..)

Streaming audio playback was handled from one Squad originally in my tribe. Over time we created the Playback tribe in my Alliance to handle ingestion, storage, metadata, and streaming of Audio and Video. Certainly, we were building on top of a foundation created by the Infrastructure Tribe/Alliance. Like all features.

Many of the Chapter Leads at Spotify were still working part-time as developers in squads. Even the ones with large enough chapters who were no longer daily developers were still close to the world, so the Chapter Leads were very technical.

The Tribe Leads were expected to be fairly technical, and that was part of the interview process. Tribe Leads weren’t expected to be hands-on, their organizations were too big for that, but as a Tribe Lead (and Alliance Lead) I was still ultimately responsible for any technical decisions made within the organization. I wouldn’t be in the squads reviewing check-ins, but if I saw or heard about questionable technical decisions being made in squads, I would talk to the team to make sure they did have good rationales for their choices.

So Chapter Leads were either still engineers or ex-engineers. Tribe Leads and Alliance Leads were ex-engineers. I do think that Spotify may have some non-engineers in Tribe Lead roles now, but I’m not 100% certain. It would definitely be a shift because those roles had a strong technical component when I was there.

Thanks for this article Kevin. I’m in marketing and we moving to this model. How would you see marketing forming part of the squad? Also how to you remunerate people if the corporate structure disappears in Favour of squads and you are no longer a leader.

Hi Kevin,
Great article and thanks for all the answers here. My biggest questions are:

1- One of the biggest challenges I’m facing is that management easily joins the agile bandwagon, but then completely compromises the model with politics by:
– Defining that if several teams are to merge (say commercial and technical) if there is a commercial Tribe Lead there also needs to be a Technical Lead. Sort of “one of my guys needs to be in the top position too”.
– Or defining that we will fully embrace agile, but we will commit officially to do these 50 features in the next fiscal year by date X, because that’s how we define budget.
How have you faced similar political pressures and handle them?

2- How do you make the decision if something should be a Chapter or a Squad. I’m thinking in a fairly small team that develops across multiple devices, starting an AppleTV app for example might be a chapter as all the features would be in that device too, but at start it might not make sense to have a developer of each device in each squad, all the knowhow and experience is really isolated to a small number of people. A squad dedicated would make sense but that would mean that product owners in squads would not be considering how their features evolve in AppleTV, which contradicts the original purpose…

3- In some projects we use software houses to develop the code for us, so there isn’t actually any development in the squad. Development in this case is more development management, setting priorities and features decisions. Have you found that doing squads and agile still makes sense in projects / companies that don’t actually have internal development?

Thanks for your questions:
1) This is pretty common, change is hard, even for management! So it is easy to say, I want my team to embrace the change, but I don’t want to change.
– There is nothing that says there can be only one lead for a group, at Adobe we had the different functions working together to lead the team. At Spotify, there was a Tech Tribe Lead, a Product Lead, and a Design lead. The question would be how the leads work together for the interests of the whole team and not just their function.
– Absolutely! The best way I have seen to be truly agile within a budgeting framework is to embrace priorities and not projects (or features). A feature is created to service some business goal. Instead of saying we will ship these 50 features to increase our revenue 20%, instead make the goal to increase revenue, dedicate resources to the teams best in position to achieve the goal and let them figure out the best way to achieve it within their scope. If the teams have freedom to make decisions and aren’t dependant on other teams to get their work done, they should be able to be accountable to their commitments.
2) Chapters and Squads are two different things. A Chapter is a people management construct, usually representing a single function (like mobile development). A Squad is a product development team, cross-functional by definition (like the search team).
3) I don’t have experience with that, but I would say that it doesn’t match the model since those teams aren’t autonomous.

I want to reiterate something from the post. Do not copy the Spotify model, be influenced by it. The Spotify Model made sense for Spotify when it was at a certain size, growing quickly and wanting to retain the nimbleness of a startup. It reflects a very team-oriented, non-hierarchical, development culture. Copying the model and applying it to a different team culture is unlikely to be successful. Instead look at the ideas, understand why they were adopted and see what things make sense for your current company and culture.

Spotify has continued to grow as a company and while many aspects of the “Spotify Model” are the same, many are different. This makes absolute sense as the core of the model was that it was continually adapting and iterating as the company grew. Since I’ve left Spotify, I’ve applied the ideas in other companies. Taking my own advice, I didn’t make copies of the model, but I used some of the core ideas. The core principles hold up very well in different businesses and with different team structures and different size organizations.

The core idea is to be thoughtful about your goals in your team structure, be mindful of your culture (support it, don’t try to change it with an organizational model), and let it breathe, flex and adapt as the organization grows. That keeps the values evergreen even as the organizational structure and development processes evolve as the company does.

Given that marketing as a discipline was much smaller than product development, it wasn’t involved in every squad, but it definitely was represented in squads when they were working on new products or on projects closely aligned with marketing. To be autonomous the squad needs to have the functions represented so that it can make decisions. Marketing is often a critical part of product decision making. At Avvo, we had a team (we didn’t follow the Spotify model, but were influenced by it) that was focused on acquisition. That team had a full-time marketing person as part of the group. At Adobe and at Spotify, we had marketing folks involved closely with the teams, but working across multiple “squads” because there weren’t enough of them to be full-time on a single team.

I could question why certain functions tend to combine management with seniority without having an individual contributor growth track. That said, UX and Product are two functions that worked this way and maintained those hierarchies within the Spotify model. There was no “Product Chapter” or “UX Chapter.” There is no reason that the management hierarchy would need to be dissolved for a marketing function.

That said, if you could find a way to innovate within your organizational structure to allow all functions to operate in a team structure with a true matrix management structure, I think it could be beneficial.

When a squad decides to use a tech which hasn’t previously been used in the company how would this work together with the infrastructure teams?

Would the squad introducing the technology kick off the implementation or would this be a potential “problem” which made a squad less autonomous, e.g. if an infra squad would have to figure out the deployment part etc before it can go to production. Chances are deploying a new tech would imply no tooling is available.

No tooling would be available, the team would be responsible for building their own tooling as needed in order to take responsibility for their systems. Pn practice at Spotify, when I was there, it was hard enough to build the frameworks needed to be a full-fledged production service that it happened rarely. In later companies, with less complex infrastructure needs, it was easier to add new technologies and that was more common.