Author: Jurgen Appelo

The Spotify model is ten years old.

It’s time to upgrade.

Anders Ivarsson and I go back ten years. He gave me a tour when Spotify had just moved to their fancy new offices in Stockholm, offered me input for my book Managing for Happiness, and co-facilitated a mini-workshop with me at Agile2016.

Henrik Kniberg and I go back a similar amount of time, with some emails going back and forth and several events around Europe where we both presented as keynote speakers. I think we last saw each other at an Agile Lean Europe unconference somewhere.

It’s no wonder that I’ve always had a weak spot for “the Spotify model”, which is the name that the community decided to give to the document that these two gentlemen published together in Oct 2012 about scaling software development at Spotify, when the company was still only around 300 people. (It will likely grow to 8,000 people in 2022.) The document offered some excellent ideas by two intelligent people. However, it also contained an important disclaimer:

“This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed.”

Indeed, there is actually no Spotify model. The picture that Anders and Henrik created ten years ago was merely a snapshot of a work-in-progress of a company that is now thirty times larger.

For these and other reasons, the authors and many consultants insist that “the Spotify model” should not be copy-pasted to other organizations without thoughtful consideration and modifications.

So, let’s do that! In this post, I compare “the Spotify model” with my unFIX model, and I offer you my considerations and modifications. You could see the result as a new version of the Spotify model.

Here’s what you get when you upgrade... 😁

“The unFIX model pinpoints many of the problems we saw (and mostly fixed) at Spotify. Specifically, this provides more flexibility to fit different organizations, and more clear guidance on how to scale beyond a few hundred people.”

— Anders Ivarsson, co-author of "the Spotify model"

From Squad to Value Stream Crew

When you look at the original picture that Anders and Henrik created, the first thing you notice is that they drew vertical images of squads (their name for Scrum teams, Kanban teams, and other lean/agile teams). It is an unconventional stylistic choice as nearly every other model (including unFIX) draws horizontal value streams. Well, Spotify is a quirky company, so no surprise there. But just keep in mind that you need to turn their model (or my model) 90 degrees to allow for a sensible comparison.

In the unFIX model, Squads become Value Stream Crews because I like the word crew better than the word squad. (For me, squads have military associations, while crews go on journeys together.) Squads (or Crews) have direct contact with their stakeholders and no blocking dependencies between them. They have all the skills and tools needed to design, develop, and deliver their work into production. So far, so good.

But ten years have gone by, and we now live in a different world. (Hey, hello Covid! 🦠)

The original document described that the squad members sat physically together in the same office, with access to a lounge area, a huddle room, and more. (Indeed, I took a picture of Anders in one of these areas and published it in my book many years ago.) However, I am sure that many teams at Spotify work distributed and remotely nowadays, as development teams in many other companies do.

Similarly, the document said that each squad had responsibility for one part of the product for a long time so that they could become experts in that area. But since then, people have experienced that static teams easily lead to team silos, suboptimization at the team level, and the lack of cohesion and business agility for the company as a whole. Dynamic reteaming is one of the newest trends and one that I believe you should keep an eye on.

I created the unFIX model specifically to support remote working and dynamic reteaming.

From Product Owners to Experience Crew

In the Spotify model, each squad has a Product Owner who prioritizes the work and is not a formally appointed manager or leader. This role comes close to the Captain in the unFIX model, although I allow for the possibility that someone else with leadership skills on the Value Stream Crew is the Captain and that the Product Owner is simply one of the other roles on the Crew. So, unFIX is a bit more flexible in that. But yes, I expect that many Product Owners will end up being the Captain.

Furthermore, the Spotify model explains this:

“The product owners of different squads collaborate with each other to maintain a high-level roadmap document that shows where Spotify as a whole is heading, and each product owner is responsible for maintaining a matching product backlog for their squad.”

The problem I see here is that Anders and Henrik didn’t draw the collaboration between POs in their picture. A minor omission with, potentially, a significant effect.

The sad reality is that, in some organizations, squads only focused on their own work and their own goals, with little regard to coordination and cohesion between the various parts of the product. For example, there is a report that ING Bank moved from the Spotify model to LeSS because they found that the squads were sub-optimizing and, they wrote, “LeSS calls for a product-centric Product Owner who works with up to eight teams”.

Organizations that have adopted the so-called Spotify Model have likely created a new type of silo around teams with relatively rigid missions and “parts” of the overall product. At any point in time, a substantial portion of the teams are likely to be working on lower value items than what is now the highest overall priorities. - Rowan Bunning, “ING improves on the so-called Spotify Model using LeSS”

But you don’t need to implement LeSS to solve the sub-optimization problem. Just read Henrik’s and Anders’ document better. Or upgrade to unFIX! 😎

The unFIX model suggests that you have an explicit Experience Crew, with a representative from each Value Stream Crew that offers value to (or has touchpoints with) the user and customer. The purpose of the Experience Crew is to ensure that, together, you optimize the customer experience, not the individual parts of the product. (And sure, the Captain of the Experience Crew could, in practice, be the leading Product Owner.) By making this element in the model explicit—and focusing on customer experience rather than the product—you can prevent a handful of Crews from becoming separate product silos.

From Agile Coaches to Facilitation Crew

In the Spotify model, each squad has access to an agile coach. This person “helps them evolve and improve their way of working”. The agile coaches assist with identifying impediments; they run retrospectives, do one-on-one coaching, and help the squads find and remove their dependencies.

Again, the agile coaches are not drawn in the Spotify picture—I’m not sure why. Maybe it got too complicated. In the unFIX model, I show an explicit Facilitation Crew whose sole responsibility is to work on the various Value Stream Crews and help them get their work done in better ways. And not only that, but Facilitation Crews should also strive for collaboration across Crews and harmonization of work methods.

Spotify did not define a common process for cross-team collaboration. Allowing every team to have a unique way of working meant each team needed a unique way of engagement when collaborating. Overall organization productivity suffered. [...] Squads were optimized for maximum autonomy. This is great for a fast-adapting startup, but created problems for a mature scale-up company. Spotify needed more consistency between teams to better manage the company’s fast growth and avoid duplication and avoid downstream complexity & technical entropy. - Jeremiah Lee, “Spotify's failed #SquadGoals”

From Tribe to Base

The Spotify document explains that the tribe can be seen as the “incubator” for the squads. In unFIX, I renamed tribe to base because I want to emphasize that (metaphorically) this is the home that every crew comes back to when they return from their journey. And tribe sounds a bit ... anthropological.

The primary purpose of the Base is to give workers a sense of belonging, a sense of purpose, and a way to get recognition for their contributions. Some Bases are Fully Integrated (making one product), others are Fully Segregated (like an incubator for startups), but they could also be Strongly Aligned or Loosely Aligned.

Similar to the tribe, the recommended maximum size for a Base is 150 people, which refers to the concept of “Dunbar’s number”. Tribes and Bases have regular gatherings and informal get-togethers, which underscores that their primary function is different from the Agile Release Train in SAFe and the Product Group in LeSS.

From Tribe Lead to Governance Crew

The Spotify model briefly mentions a Tribe Lead responsible for providing the best possible habitat for the squads within that tribe. In my opinion, this leadership part is so crucial that it deserves expanding.

I noticed in my travels across Europe and my visits to many startups and scale-ups that it was pretty common to have a trio of Chiefs leading a tribe or business unit. There was often one person responsible for product/innovation, one for marketing/sales, and one for technology/infrastructure, but the details of those primary roles differed per company. Either way, it was rarely one person! It was always a management team, not just one manager.

Product managers should have an equivalent peer for engineering. Product managers should be accountable for the prioritization of work. Engineering managers should be accountable for the engineers’ execution. - Jeremiah Lee, “Spotify's Failed #SquadGoals”

The balance of primary roles is an issue that remained unaddressed in the original Spotify model. Each squad had a Product Owner (and the POs were expected to coordinate across squads), but these product leaders didn’t have one person to talk to as their peer in technology or as their peer in marketing. The unFIX model resolves this by moving this crucial balancing act to the Chiefs in the Governance Crew.

As I discussed earlier, each Crew in the Base usually has one Captain. (Duos or trios are possible but likely too cumbersome to organize at the Crew level.) These Captains can be product-oriented, technology-oriented, or marketing-oriented—it depends on the kind of Crew they are on. A certain amount of balancing of the Value Stream Crews is already done by Facilitation Crews and Experience Crews. But no matter how the Base is self-organizing, any conflicts and trade-offs will end up with the team of Chiefs in the Governance Crew.

From Operations Team to Platform Crew

The Spotify document suggests that a separate operations team could give the squads support for releasing code themselves. They could do this in the form of infrastructure, scripts, and more. The unFIX model offers two ways of organizing this.

The first option is to have a DevOps crew. Its members would perform their actual work directly on the Value Stream Crews, helping them with releases and deployment, but in the meantime, they would also form their own Facilitation Crew. You could say that the DevOps crew would facilitate and enable the other crews to be responsible for their own operations.

The second option is to have a separate Platform Crew. When infrastructure gets too heavy and complicated to share across the Value Stream Crews, a Platform Crew could handle most of the heavy-duty work under the hood while offering a service (possibly with APIs and a service level agreement) to the squads. A combination of the two options is also possible.

From System Owner to Capability Crew

With squads responsible for feature sets and parts of a product, you inevitably come across the situation that multiple squads need to work with the same component or subsystem. For this reason, the Spotify model suggests having System Owners who are the persons to go to for any technical questions regarding a specific part of the system. The system owner focuses on quality, documentation, technical debt, and other issues. He is typically a regular squad member who does “system ownership” of a subsystem on the side.

On top of that, the Spotify model also describes the Chief Architect role. This is a person who “coordinates work on high-level architectural issues that cut across multiple systems”. Like the System Owners, the Chief Architect is mainly an advisory role, ensuring that squad members avoid common mistakes and that their designs align with a shared architectural vision.

The most effective pattern for an architecture team is as a part-time enabling team (if one is needed at all). The team being part-time is essential: it emphasizes that many decisions should be taken by implementing teams rather than left to the architecture team. Some organizations compose a virtual team from members of other teams. This virtual team meets regularly to discuss and evolve the architecture aspects of the systems. This is akin to the chapter or guild terminology used by Spotify. - Matthew Skelton, Manuel Pais, Team Topologies

Again, there are two ways of implementing these two roles in the unFIX model. You could introduce Facilitation Crews (see above) that focus on specific subsystems or architecture. Or you could have one or more Capability Crews whose goal is to offer rare skills and capabilities to the various Value Stream Crews. No matter which option you choose, as with the Spotify model, all work is always done exclusively on the squads / Value Stream Crews. No ivory towers in sight! 🗼

Note: Another possibility is that high-level architecture is the responsibility of one of the Chiefs in the Governance Crew.

From Chapter to Forum

Anders and Henrik recognized the need for people with similar skills to get together regularly to discuss their competency areas. To enable this, they described the concept of chapters. A chapter is everyone in a tribe (across multiple squads) within the same competency area. There could be a testing chapter, a UX chapter, a backend chapter, and so forth.

In the unFIX model, I introduced the Forum as a similar concept, but I made it broader than the chapter. The Spotify model describes a Functional Forum: that is, everyone in a similar function. But you could also have a Geographic Forum: everyone in a similar region, a Market Forum: everyone in the same market, and a Technological Forum: everyone working with similar technologies.

Forums of various types can exist simultaneously, overlapping in multiple ways. For example, someone could be a member of the UX Forum to discuss user experience with her peers and at the same time participate in the South America Forum to discuss localization of products for the South American region. (This is quite different from chapters, where each squad member belonged to one chapter only.)

Like traditional forums on a bulletin board and the channels on a chat group, Forums are simply a way of organizing discussions and sharing experiences across people with similar interests. Each Forum is led by a Chair who merely is the moderator of the Forum and the “first among equals” with no special powers other than to guide the discussions (and maybe decide who is in and who is out).

From Chapter Lead to Chair

As you may have guessed already—because I know you’re smart—the most significant difference between the Spotify model, as described in the original document, and the unFIX model is that Chapter Leads are managers and Chairs are not! (That’s why people can freely participate in more than one Forum.)

The original chapter lead is a line manager with the traditional responsibilities such as developing people, compensation, promotion, etc. And OMG, this means WE HAVE A PROBLEM. You end up with a matrix organization (as also pointed out in the original document). Perhaps this was not so well established in 2012, but nowadays, the matrix structure counts as a failed model according to experts in organization design.

One key finding from organizations with matrix structures is indeed that higher-level managers become overloaded because lower-level managers are unable to resolve conflicts and therefore refer conflicts to the executives. In other words, an unintended consequence of a matrix structure is actually to make the organization more centralized and to remove accountability from lower-level managers. - Nicolay Worren, Organization Design: Simplifying Complex Systems

With a matrix organization, you have conflicts bubbling up the hierarchy.

Any disagreement within the team often had to be resolved between multiple managers, and without consensus, then had to be escalated to the Director of the ‘Tribe’ (Department). - Brad Swanson, “Spotify Doesn’t Use the Spotify Model”

With the unFIX model, I try to steer clear of the typical matrix organization problem. Nobody in a Base is a line manager, except the Chiefs in the Governance Crew. They are the managers of everyone, and because this is a lot of work for a large Base, they will feel increased pressure to delegate as much non-management work as they can to the Crews and the Forums in their Base. This is by design.

Of course, two members of one Crew can indeed have two different managers, but that’s not a problem. Their managers will always be two Chiefs of the same Governance Crew, which works as one team, with one purpose and one set of objectives. Each conflict can escalate only one level up.

Say goodbye to the matrix.

From Guild to (Super-)Forum

The Spotify model says that a guild is a community of interest, a group of people that want to share knowledge, experience, and practices. The guild always spans multiple tribes and often includes various chapters of the tribes working in the same area. For example, a testing guild across several tribes includes all testing chapters of each tribe.

With the unFIX model, I realized that nothing else was needed. When you remove line management out of a chapter, the chapter is just a small version of a guild. Therefore, I see guilds and communities of interest as scaled-up versions of Forums. We can call them Super-Forums. You could have a Super-Forum for functional, technical, geographical, and market discussions. Spotify’s “guild coordinator” would then be the same as a Chair for a Super-Forum.

This removes the need to introduce a new element type when we scale things up. The large could be the same as the small, with Super-Bases, Super-Crews, and Super-Forums. I’m sure that design purists will appreciate that this could make the unFIX model fractal and scale-invariant. 😁 (To be honest, I am just hypothesizing here. I have no personal experience with this.)

Conclusion

Anders Ivarsson and Henrik Kniberg never intended the document they published in 2012 to become “the Spotify model” that people are still talking about ten years later. Spotify has moved on, and so did the rest of the world, except for those who are still clinging on to a picture of a snapshot of a work-in-progress of ten years ago. I would suggest these organizations start planning their upgrade.

With the unFIX model, I tried to capture these improvements:

The Spotify model is based on one ten-years old snapshot; unFIX is based on insights from many sources.
The Spotify model shows value streams vertically; unFIX shows them horizontally.
The Spotify model suggested co-located squads; unFIX allows for remote working.
The Spotify model assumed long-lived squads; unFIX nudges toward dynamic reteaming.
The Spotify model has PO collaboration—not shown; unFIX introduces the Experience Crew.
The Spotify model has agile coaches—not shown; unFIX introduces the Facilitation Crew.
The Spotify model mentions one tribe lead; unFIX introduces the Governance Crew.
The Spotify model mentions an operations team; unFIX introduces the Platform Crew.
The Spotify model mentions the system owners; unFIX introduces the Capability Crew.
The Spotify model has only functional chapters; unFIX has four types of Forums.
The Spotify model has the chapter lead as a manager; unFIX has Chairs who are not managers.
The Spotify model is a matrix organization; unFIX is not.
The Spotify model offers guilds beyond the tribe; in unFIX, the entire model is fractal.
The Spotify model was a picture of one company; unFIX is like LEGO: build whatever you want.

I find the last item particularly important. The Spotify model was described as a snapshot of what Spotify was doing ten years ago. Its goal was not to suggest options or alternatives. It was merely one case study.

The unFIX model is different. I hope that people see the analogy with LEGO. There are just a few elementary building blocks of various types, and they are optional, reconfigurable, repeatable, and scalable. You may not need a Capability Crew; you may not want a Platform Crew, and perhaps you do not need Forums. Okay, fine. It’s all up to you.

It’s your business. You build it.

Now upgrade!

😀

Learn about unFIX partnership

Let’s Unfix the Spotify Model