Why ‘the Spotify Model’ won’t solve all your problems with Product Delivery

At least not immediately…

Image for post
Image for post
Photo by Annie Spratt on Unsplash

Since it’s introduction 5 years ago, the Spotify Model has rapidly become the foundation for how many tech companies organise themselves. It seems that almost everyone I speak to now has some variation of squads and tribes in their organisation, so much so that the term squad now seems almost ubiquitous with ‘tech team’.

However, for many, the Spotify Model hasn’t quite been the revolution they hoped for. They don’t necessarily feel they’re working quicker or driving the impact that was envisioned. During these conversations, the thing that is clear to me is the companies haven’t implemented the Spotify Model. Instead, they’ve only implemented a part of it.

It is important to note that when Henry Kniberg shared the Spotify Model on his blog, he was clear that the approach was something that was a work in progress. Parts of it were implemented and others were aspirational. It was intended to be a vision to guide the company and has naturally changed along the way. The shared model was not perfect and each organisation should adapt it as necessary. However, it does provide an excellent blueprint on being a truly agile company.

I’ve picked out a few themes are key components that the Model promotes:

  • Team Structures (Squads, Tribes, Alliances, Chapters, Guilds)

A common misrepresentation

Let’s start with the most commonly referenced and familiar part of this list — the team structures. The model made popular concepts such as Squads, Tribes, Alliances, Chapters and Guilds. In fact, they are so commonly referenced that they are often used to describe the model in its entirety. I’ve been guilty of this too. When discussing how we operate I have described it along the lines of, “squads, tribes — you know the Spotify Model”. Unfortunately, my limited definition does not do justice the wider concept that the Spotify Team were aiming for and that is what this article aims to call out.

I rewatched both the videos while drafting this article as a refresher. I was surprised to find quite how much more they spoke about than just the basic building blocks of squads and kin. Certainly, these units are referenced repeatedly during the video as they are the vehicle for delivering much of what Spotify is trying to achieve — that is, delivering more value through motivated and engaged employees. This is in the name of the post, “Spotify Engineer Culture,” not Spotify Org Structure. It is important to be mindful of this distinction.

Why does this matter?

It matters because a reorganisation was not the point of the model; to use a familiar expression in our industry: this was the output, not the outcome. Reflecting back on the list above, when thinking about my own organisations and talking with peers in the community the story is often the same. We associate the Spotify Model with the tangible, visible and, I’m afraid to say, the easy part of it. Most organisations only copy parts of the framework, those that are generally easier to replicate.

Image for post
Image for post
When running through a list of Spotify Model traits it is clear that some steps are easier than others.

We can reasonably state that we have implemented concepts such as the team structure by looking at the groups we have — people move desks, we rename slack channels and we add different disciplines to each squad. Voila, the composition is done. Similarly, we can see that our releases are getting quicker and smaller. Unfortunately, these are just a couple of the building blocks to achieve the overall intent of the model. Those items further down the list cannot be easily reproduced and take constant, conscious effort over a longer period of time by an organisation to wanting to embrace them. There is no easy blueprint for implementing them and, naturally, that’s where we can realise most of the value of the model.

Does the following sound familiar? The Quarterly Planning Processing is a large wishlist of features from across the organisation. There are some refinement and general prioritisation set at the leadership or department level and then your team is essentially asked, “how much of this can you build in a quarter?” You spend a couple of weeks scrambling to apply estimations and t-shirt sizes before rushing to deliver. Your success is measured on your delivery timeliness with a few metrics scattered in to show you’re data-driven. I’ve seen happen repeatedly. Unfortunately, in this situation, a collection of tribes and squads is not going to make a difference to your Time-to-Value, which is ultimately what we’re searching for.

There is increasing rhetoric in our community about how the best teams are empowered and autonomous. Product Thought-Leaders promote at length the value of these teams and I agree with them entirely. The concept is strong and simple, however, the reality of the situation is this doesn’t happen quickly or without investment. A statement that our teams “autonomous” doesn’t make any difference unless the organisation starts to practice that regardless of whom speaks the words.

Henrik Kniberg covers this in the original video when he talks about Alignment and Autonomy. He covers it in more detail in a subsequent slide deck he presented. This is a key concept that is often overlooked. The premise that alignment exists on one axis and autonomy on the other. The drive should be towards Aligned Autonomy where the teams have a clear direction with some guardrails and are tasked to go figure out the solution.

Image for post
Image for post
Henrik Kniberg — Alignment enables Autonomy. From the Spotify Model.

It is important to note neither the organisation nor the team can handle a shift from Build-Trap to Full-Autonomous teams between Friday and Monday. The team itself needs time to understand the wider context of their domain, their customer’s needs and the company’s business model in order to drive impact. The organisation as a whole needs time to build trust with the Product & Engineering teams as they take on this expanded responsibility and scope. As with anything, there is a learning curve where individuals need time to learn, understand and apply but it an effort the organisation needs to make and you, as a Product Manager, must champion. Don’t expect to build the organisations maturity overnight.

Tips for implementing more autonomy

With that being said, I wanted to offer a handful of tips for helping mature your organisation. As I mentioned above, there is no quick and easy blueprint but these tips will provide some more structure for you in that journey.

  • Remember, alignment enables autonomy. The most frequent cause of friction between product teams and their counterparts across the business is misalignment. Understand the priorities for your key stakeholders and what makes them successful. I can assure it’s not going to be shipping a particular feature, but the outcome they believe they will get from it: cost reduction, revenue expansion etc. Understand this well and you’ll find things get easier.

The most general lesson to be learned from the more successful cases is that the change process goes through a series of phases that, in total, usually require a considerable length of time. (John Kotter)

Conclusion

I highly recommend reading John Kotter’s Leading Change: Why Transformation Effort Fail. Adopting the Spotify Model is certainly a transformation effort for any organisation and the principles he describes in his article will help navigate some of the hurdles.

This is one of my favourite topics so feel free to reach out directly if you want to discuss in more detail (Twitter | LinkedIn).

Appendix I

I think it’s very important to call out the fantastic resources produced by the Spotify Teams and Henrik Kniberg that have been referenced through this article:

Written by

Senior Product Manager at @DeliveryHeroCom. Formerly @HelloFresh, @BBC, @Atos. Passion for product, business &tech. I like helping people solve problems. Berlin

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store