The Spotify Model - Real or Merely Aspirational?
In the early 2010's there was a lot of froth over organising teams using the Spotify Model: Chapters, Guilds, Squads and Tribes.
I heard last year that in the end, that model was merely "aspirational" and didn't really work that well in practice. That could've been a LeadDev video on YouTube; I can't remember.
I can't find a source for that, and I'm curious whether that's the case.
This type of question might be beyond the scope of Taro, and I apologise if I've overstepped by asking it;
I'm struggling to elevate the working practices and culture of my team, and I am concerned I'm trying to win over a bunch of developers' that don't have a growth mindset.
I'm not saying the Spotify Model would help, we're way too small for that, it just came up in my research today when reading a Packt book called "Engineering Manager's Handbook: An insider's guide to managing software development and engineering teams".
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(2 comments)- 0
a month agoTech Lead @ Robinhood, Meta, Course HeroI found an article which links the original whitepaper: https://productschool.com/blog/product-fundamentals/spotify-model-scaling-agile
It's cool you bring it up as I remember talking to the VP of Engineering at Course Hero about this back when I was there. He was considering using it to scale Course Hero's engineering org (we were hiring like crazy back then).
While the ideas seem cool, I honestly felt like it was way too complicated and idealistic. It's really hard to build solidarity groups outside of your immediate org-chart. If you want X group of engineers to regularly collaborate and cross-pollinate info, they should all just report to the same manager or skip manager. From there, have it baked into your leveling structure that engineers are expected to lead, collaborate, and cross-pollinate more as they get more senior (e.g. at staff, you are expected to regularly bring multiple teams together for a common goal).
- 0a month agoEng @ Taro
I hadn't heard of the Spotify Model before, so I'd love to get other people with more experience to chime in.
At larger companies, there are usually product, backend, infra, and platform teams. It seems that in the Spotify model, you have squads that could have elements of all of those teams.
I can see how it can be useful for moving quickly since you work in a "squad" and have the end to end autonomy to tackle problems at every layer in the stack, so you shouldn't ever be blocked by another team.
Conceptually, it makes sense, but I do see a few ways where it might break down.
- Usually, the backend, infra, and platform teams are very opinionated. I could see a lot of conflicts between different squads where you either a hit a roadblock because no one can decide on a best practice or there aren't any roadblocks but there are just multiple opinions and ways of doing things causing the codebase to be very random.
- A specialized platform team can think about the overall efficiency of all engineers that use their tools. The Spotify model sounds like it lacks this, so there isn't an incentive to keep improving tooling if it comes at the cost of pushing a project forward.
