My critique of “the Spotify Model”: Part 1

Jason Yip
8 min readJan 23

Part 2 here

People ask me about this, so I figured I’d write something.

NOTE: Although I was at Spotify for around 8 years, I‘m not familiar with how every area worked and I have my own biases, preferences, etc. AND things change

I will define “Spotify Model” as any concept or practice mentioned in the Spotify Engineering Culture videos. I’m only covering part 1 in this post.

Agile > Scrum

Spotify was mostly Scrum in the early years (before my time, so I can’t confirm this) but shifted to a more general Agile approach. There was no requirement for standard Scrum practices nor are there any Scrum Masters anymore, as far as I’m aware.

This principle reflected a general expectation of responsibility on autonomous teams. This still holds and I agree with it.

Having said that, I sometimes found what Squads chose for themselves to be sub-optimal and slower than I would have liked if I was actually on the Squad myself.

I think originally, there was a valid assumption that Squads had enough Agile background to make pretty good calls. As Spotify, and really the overall industry, has grown, there are more and more people with a shallow or warped understanding of Agile.

Agile > Scrum? Yes, BUT don’t assume that everyone has the same understanding of what “Agile” means.

Autonomous Squads

“Squads” at Spotify are not a synonym for “team” but specifically a cross-disciplinary, autonomous, product development team. Marty Cagan calls this an Empowered Product Team.

Every Squad has a mission but is responsible for deciding what to build, how to build it, and how to work together to accomplish the mission.

Common mistakes I saw with some Squads:

  • Seeing autonomy as a benefit “we get to do whatever we feel like!” rather than as a responsibility “we are both authorised and expected to do what is necessary to accomplish the mission”;
  • Missing that Squad responsibility includes coordinating or collaborating with other Squads as necessary;
  • Insufficient cross-pollination amongst Squads leading to unnecessary variation and relearning;
  • Missing context for how the Squad’s mission fits within broader strategy — which can lead…
Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl