PRODUCTHEAD: The backlash against the Spotify Model
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
any product can play guitar #
every PRODUCTHEAD edition is online for you to refer back to
tl;dr
The Spotify Model was only ever a snapshot in time at Spotify
It existed in the context of a company whose leadership valued trust, self-organisation and change
As Spotify grew, it failed to strike the right balance between autonomy and collaboration
Alignment to product strategy remains crucial for autonomous teams to deliver valuable work
hello
Following on from last week’s deep dive into team topologies, this week focuses in on the (in)famous Spotify Model.
The Spotify Model, as it’s come to be known, was an early example of a company successfully running multi-disciplinary Agile teams at scale. It used a ‘matrix’ team topology with small, autonomous multi-disciplinary ‘squads’ grouped into ‘tribes’ corresponding to a related product area.
Then to overcome the silo effect of the squads and tribes, members of the same discipline in different squads within a tribe would get together regularly as a ‘chapter’ to share best practice. Then, less frequently, the chapters from different tribes (all the designers, for example) would get together as a ‘guild’ to improve the state of the art, company-wide. A guild is similar to what I generally describe as a community of practice, per Emily Webber.
Did the Spotify Model have intrinsic value as an alternative to the then-standard practice of teams divided by job function? Or was it a misleading ideal that has over-promised, under-delivered and contributed to the Agile backlash of recent years?
The truth is somewhere in the middle.
Critics often accuse Spotify of being disingenuous by continuing to benefit from the idea of the Spotify Model, despite it no longer / never reflecting actual practice. The organisations that chose to adopt a similar approach feel that they were sold a lie. It’s fair to say that the approach spawned a thousand imitators (and consultants) and, as the saying goes, their mileage varied.
It’s worth noting that in the article that started it all, written by Henrik Kniberg and Anders Ivarsson, there’s a disclaimer on page one that says:
Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. 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.
‘Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds’ by Henrik Kniberg & Anders Ivarsson (October 2012, my emphasis)
Spotify itself had continued to evolve its approach, so at best you could take the original article as a suggested experimental starting point, not as a static end state. I suspect this detail became lost in translation.
I think there remains value in aspects of the Spotify Model, without needing to adopt every part of it (or its terminology) as originally laid out.
Multi-disciplinary teams — a team with all the skills it needs to accomplish its goal, whether as permanent or temporary members — just make sense. The alternative would mean a team repeatedly blocked or dependent on the actions of another team with different goals. This is a recipe for frustration.
I remain a firm believer in the value of communities of practice. Practitioners within a discipline need a support network of people who understand their craft. They should be free to develop their skills and knowledge within their community without the worry that it will reflect badly on them in a formal performance appraisal or salary review. (Unfair line managers equate a desire for coaching or training as being an admission of inability and weakness.)
Equally valuable are autonomy and empowerment, providing the team understands that they are operating within certain constraints such as the long-term strategic goals of the organisation (multi-year) and the shorter-term focus (annual, quarterly). Other potential expectations would be for them to use an existing technology stack rather than reinvent the wheel, and an obligation to communicate and work transparently and collaboratively with other teams in order to benefit from peer review and to minimise treading on each other’s toes.
It is true that Spotify moved on from the Spotify Model. For them it was a snapshot in time. They kept what worked and discarded what didn’t, and continued to try new approaches as their business, market, users and goals evolved.
For you this week #
We’ll start at the beginning with the original 2012 article by Henrik Kniberg and Anders Ivarsson. Fast forward to 2023, and Kniberg offers a review of the principles and context to the Spotify Model.
As a counterpoint, Jeremiah Lee writes about his own disillusionment on finding that the mythology of the Spotify Model didn’t match the reality of how the company worked.
And to round out this week’s edition, Marty Cagan collaborates with Crisp consultant Joakim Sundén to write about how Spotify’s approach mirrors Cagan’s product operating model.
Speak to you soon,
Jock
what to think about this week
Scaling Agile @ Spotify with tribes, squads, chapters & guilds
Dealing with multiple teams in a product development organization is always a challenge!
One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities.
[Henrik Kniberg & Anders Ivarsson / Crisp]
Summary of Henrik Kniberg’s session, about his thoughts on The Spotify Model, in the Leading Complexity program 2022
The Spotify Model. You have probably heard the term. But how did it come to life? How did it become a “thing”? What are the principles behind it? What happens when companies copy it? Should you copy it?
To kick off this series of summaries of the Leading Complexity program, we focus on Henrik Kniberg’s talk and highlight five key takeaways.
The model needs to be adapted to fit one’s specific context
[Leading Complexity / Crisp]
Failed # SquadGoals
I was excited to see the Spotify model in action when I interviewed for a product management role at its Stockholm headquarters in 2017. However, the recruiter surprised me before the first interview. She cautioned me to not expect Spotify to be an Agile utopia.
When mythology takes over from reality
[Jeremiah Lee]
The Product Model at Spotify
I have been a long-time fan of Spotify. The fact that they compete against some of the best product companies in the world (including Amazon, Apple and Google), yet they have continued to hold their own, and in many cases out-innovate their competition, has certainly earned my respect.
Yet I don’t think they get the credit in the product community they deserve. I believe that’s mostly because people that think they know “The Spotify Model” are focused on the wrong things, and not what has made them such a strong, long-term competitor. So my hope with this article is to do what I can to help correct that.
Product strategy, discovery and delivery
[Marty Cagan & Joakim Sundén / Silicon Valley Product Group]
recent posts
Why cake is important for product leaders
I see companies copying recipes from other organisations, but then freestyling their own attempt at it. They point to Henrik Kniberg’s description of Spotify’s engineering culture from back in 2014 or his description of iterative and incremental product development, and declare their product culture to be like that, seemingly without any real understanding of the concepts he describes.
I have a patchy record of baking cakes
[I Manage Products]
Assemble the right product team
According to GDS, the ideal team needs to be multidisciplinary, autonomous, and to keep the key roles separate. The make-up of the team and the way it works is vital for ensuring digital services and products are created in the right way. In fact, it’s so important that the GDS assessors will always check that the team is working in this way, and will not allow a digital service to progress if it’s not: it’s point 6 of their Service Standard.
The right people with the right skills, when they’re needed
[I Manage Products]
Start building a community of practice with the 3 minute challenge
A community of practice helps people to share their knowledge and expertise with others from their own discipline, while cutting across organisational silos, and creating a support network that can help with team happiness and engagement.
I’ve been in several organisations now as a head of product, and establishing a community of practice is always one of the first things I concentrate on.
[I Manage Products]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from olympic-level procrastination.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“I wish this book was published when I started out in product management. It gives a really wonderful overview of what product management is and involves on a day to day basis.”
— Keji Adedeji, product leader & coach
Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, X (formerly Twitter) and LinkedIn.