Why ‘the Spotify Model’ won’t solve all your problems with Product Delivery
At least not immediately…
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)
- Small, Frequent Releases
- Data-Driven over Opinion Driven
- Impact over Velocity
- Experiment-friendly culture
- Trust over control
- Alignment and Autonomy
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.
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.
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.
- Share work early, share work often. One of my biggest learnings in building trust with the organisation was to share work as frequently as I could, regardless of the state. This is difficult at first because the audience isn’t used to it. Expect feedback on things like copy, namings, spacing for things as simple as a wireframe. Reaffirm this is a work in progress and get feedback or input. This has 3 main values: it lets you source knowledge from across the organisation (diversity is better), you have invested less work so changes are less painful and, you are getting constant buy-in (everyone is sharing in this work).
- Refer to work in terms of “Bets”. This is something that I learned from Basecamp’s ShapeUp article. The phrase repositions the work you’re doing as having a degree of risk (which it does). We can never be 100% sure we’re building the right thing and that should acknowledge that in the terms we use. One of the things I noticed in the past is when we started to refer to hypotheses and experiments, our move away from feature-lead roadmaps accelerated.
- Ensure the entire product team (squad) understand the core business model and financial metrics. You can use Tip 1 from my Product Onboarding to give you some insight. You have a team of incredibly clever people, give them the tools, knowledge and context to solve problems. I can’t stress this enough. As a Product Manager, you are not the gatekeeper of business knowledge or understanding. Every single person working for an organisation has a responsibility to return some kind of value. That’s much harder when you don’t have the full context. If your company is having trouble with customer retention, hiding that from the team won’t change the fact. Surely you want as many brains thinking through how to solve that problem!
- Create a Driver / KPI tree for your organisation. There are many articles on picking a “North Star Metric” for your organisation but, perhaps cynical, I believe it should always be centred around profit. Take this, and break down how you make money and where you spend money. From this work with your teams to understand the parts of the tree you impact and drive (NB: I’m working on an article dedicated to this topic — coming soon)
- Accept that all of this takes time. As I mentioned above, things like the squad changes are be implemented fairly quickly. Building trust between partners, autonomy in the teams and alignment in the organisation will take time. I’ve watched it happen but as you move through the maturity model things will start to get easier for your team and for the org.
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:
