You want to adopt the “Spotify Model”? I don’t think it means what you think it means!’
So your company has a matrix organisation model? Then you saw the Spotify organisation model with Tribes and Chapters and you thought; “Hey, we can keep our good old matrix organisation and simply rename it to “The Spotify Model!” Did you? Do you think this makes you a front-runner? Well, think again.
It doesn’t work to take this model:
Change some words:
And make it look more informal:
How did it miss the point of the Spotify engineering culture videos?
Yes, the organisation model in the video is a light matrix. But the chapter lead is a servant leader, focusing on coaching and mentoring the chapter members. This is a pivotal part of this organisation model. So ask yourself the question: is your former head of development — now chapter lead — indeed a servant leader? Or is (s)he still a traditional manager?
When the narrator — Henrik Kniberg — explains the model there also is this pivotal remark: “It’s a pretty picture huh? Except it’s not really true […] in reality the most valuable communication happens in informal and unpredictable ways”. This is supported by having Guilds, lightweight communities of interests. Even more striking is the following statement: “Most organisational charts are an illusion.”
Spotify puts community over structure. Is this what you had in mind when you copy-pasted the organisation model?
Here’s another important message in the video: “If you need to exactly know who makes the decisions you are in the wrong place”.
Are you considering all of this when you map your matrix organisation to a “Spotify Model”? Do you understand the nature of the “Spotify Model” if you think it is similar to a classical matrix organisation?
Don’t think that the “Spotify Model” gives you clarity and structure for years to come. Kniberg emphasises several times that the video shows a snapshot of a mix of the current situation combined with what they are aiming for. In the end, it is not about how the organisation is defined, but instead about how Spotify can adapt and change structure, practices, etc… towards what is needed at that time. Another important remark is that “healthy culture heals broken process.”
What else is of often totally missed?
I now touched the topic of organisational structure. But there’s more. These are videos about engineering culture, not about the organisational structure. That’s only a small part of the two videos. Here are some bad practices that are often not changed when adopting a “Spotify Model”:
- All squads have to use Scrum as a framework — Not according to Spotify! This was a Scrum organisation, but they made all Scrum practices optional. They found that some of the standard Scrum practices got in their way. They say “Rules are a good start, but break them when needed.” Spotify believes that Agile matters more than Scrum. You might not agree with this. Note that you then already deviate from how Spotify establishes self-organisation of squads.
- All Squads are in control of development. Deployment and operations are within another department — OK…. Spotify has teams with end to end responsibility for the stuff they build, including deployment and operations.
- All squads use Jira as the admin tool and the chapters determine what tools and techniques to use. Individuals can’t deviate from this. — Not at Spotify! They have very little standardisation and squads have a lot of autonomy. They value cross-pollination over standardisation and are experiment friendly. They love to see individuals try out tooling and find out what works best. Something that is working great then tends to be taken over by others: cross-pollination.
- You have part-time Scrum Masters — That’s not how Spotify does it. They have a bunch of full-time Agile coaches to help anyone to grow. By the way: Spotify’s Agile Coaches do the same work as Scrum Masters would do, but they allow the squads to find their preferred Agile way of software development.
- Squads and tribes work with roadmaps — Spotify values innovation over predictability and delivery over plan fulfilment. They work with a squad mission, product strategy and have short-term goals. It’s not that there’s no sense of direction, even without roadmaps.
- Squads focus on delivery (only) — sure, Spotify finds this important too, but they also leave room to experiment. Do you have something like hack time? Experimenting time? Spotify encourages people to spend 10% of their time on this.
- Your organisation wishes to avoid failure and as a result, is risk-averse. — At Spotify they welcome failure. “Fail fast →Learn fast → Improve fast.” Spotify recognises that when you wish to be faster than the competition that you need to experiment and while doing so you will fail sometimes. But it’s the learning and improvement that results from this that is important. They value failure recovery over failure avoidance.
Don’t fool yourself and others. The Spotify engineering culture is NOT about their organisational structure. It is how people are allowed to determine what to do. It’s about autonomy. It’s about having a culture of safety. Among others. I advise you to revisit the videos so that you can experience it yourself.
There is a reason why the “Spotify Model” has become so popular. The videos are a great watch, fun and inspirational. But don’t translate them to practices and structure only.
The “Spotify Model” is victim of a bandwagon effect. The same happened with Agile and Scrum. Before you know it uninformed people create a Frankenstein monster out of it. And this is where it starts to derail.
What is also important to understand is that the videos are from 2014. Surely, they are inspirational. But know that Spotify already moved on.
“Organisations are complex, adaptive systems. Be inspired to lead genuine change in your organisation. Don’t put lipstick on a pig.” — Paddy Corry
Note: Scrum is mentioned a few times in the Spotify videos. The passages reflect Spotify’s view on Scrum then. These may or may not be in line with the Scrum Guide.