Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). See also Part 2.
This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)
Here’s the whole drawing:
Here is a full transcript.
Here’s Part 2.
(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)
49 responses on “Spotify Engineering Culture (part 1)”
Great video and content.
May I ask what tool for the animations you use, these little videos are excellent and I would love to create something similar.
Intuos 5 drawing tablet + Art Rage + Screenflow
This is phenomenal – thnx for putting this out there, Henrik. Bring on part 2…
I doubt this can scale for a 10,000 employee organization. You will start seeing problems as you grow.
Yeah, we’ve had problems all along, and we just have to keep evolving and adapting as we bump into new types of problems. But as long as we can retain the healthy culture it should help us grow without adding too much bureaucracy.
We are working through a similar change at IPC. The cultural ideas map very closely. We only have a 50 person IT group so our solutions don’t require the scale you have.
The latest change is around how a single team (squad) manages their workflow. One team that is too large, broken into 4 workstreams, has challenges keeping the build green, so we have identified a Guide role to focus on code quality and pre-push testing.
We already have the “monolithic app” problem you mentioned so some architectural changes need to come next.
This is excellent! I am looking forward to part 2. I sent it on to the boss of our agile coaches and it’s been making the rounds through email at our company. We are desperately in need of scaled agile for our “fat” IT department.
Thanks for sharing. This is a real good lesson to a lot of organizations and IT leaders who want more control.
Where is the Part 2
Thanks for sharing. The Spotify story is amazing to watch… particularly keen on how Spotify have evolved their culture…
Great video! I sent it to the whole IT department and the feedback has been great. One team even spent 13 minutes this morning watching it together!
The video and ideas are great. Thank you for publishing them.
I am curious how does all this fit with Spotify’s annual employee review process (if there is one). At the end of the day when it is time to get a raise or promotion, do managers rank all their employees against each other? How does your agile process deal with performance management?
Hi, I can’t give you a detailed answer at the moment. But I can say that we don’t have an annual employee review process, and we definitely don’t rank employees against each other.
Performance reviews, stack ranking, performance management – these are all things that promote fear and introduce distortion into systems. Focus on making the system better – continual improvement, and focus on hiring people who care and share your values, and you won’t need those things. A study of Deming’s management philosophy will help you grok why this is so powerful. Read The New Economics for a good start.
Hi Henrik, I’ve enoyed very much the video. It’s great to see the importance you give to agile values and principles.
I have just one question, How does a chapter lead coaches the other members of the chapter if he is algo working on a squad. Or, how much time does the chapter leader works on his chapter and how much on his squad.
Thanks for sharing Henrik!
The squads/tribes piece is really interesting. Our transformation over the past couple years went like:
1 ui team, 1 services team
2 ui teams, 1 services team
1 ui team, 1 services team, 1 ops team
Now our UI team is too big, but we like the sharing of the things we do and “feeling in the loop”. The reason we went from 2 teams back to 1 is because we felt our processes were diverging, and we weren’t in sync. It’s good to know this isn’t necessarily a bad thing.
I think the next step for us may be to consider “tribes” and form smaller squads that are able to focus better on stuff, rather than clinging on to “knowing it all”.
Looking forward to video 2!
Excellent presentation (content and delivery), cannot wait for Part 2….
Thanks for sharing this great video, Henrik! Looking forward to part 2…
Well we rarely see such a visually appealing presentation combined with amazing and high-quality content.
This is powerful stuff for all type organisation. I am surprised Spotify share this information with such a level of detail. Quike a contribution to the community.
I might present this video to our upper management before the next re-org (Banking industries, 40K employees, 1.5K developers).
Awesome video. Would really love to see the 2nd part soon.
One of the best things in this video are some key phrases, like the ones about trust and failure e.g.
I think if you get on board with a mentality like this then things will come. The process or the exact how to is not the essence although getting to see what other people really helps.
And that is the most important aspect of this presentation, that is sharing the mentality and culture.
A minor point I need to make based on past experience is that this sort of mental thinking requires commitment all the way and on all levels otherwise it will not allow the expected break through and will create problems.
Congratulations for getting everybody on board!
Thank you Henrik !
When do you plan to share the part 2 ? (I’m eager to see it 🙂
Part 2 is actually done, but still being reviewed internally and tweaked. Can’t promise a date for when it will be published.
Henrik, thanks for a vivid and laconic video about things that indeed work! One point I miss in this whole picture is how you actually define _what_ to do from business perspective (topics, features, stories, whatever)? As you moved from Scrum you have probably transformed PO role somehow. Have you introduced substitute roles inside or outside squads and what are they exactly? Also how does this align with marketing guys?
Hi! Some of that is convered in part 2 (currently being reviewed internally). Stay tuned.
Thanks a lot for the great video, Henrik. How is the status on the part 2? 🙂
Awesome video Henrik! Do they cover all these in on-boarding process for every new team member? Since this is very tailor-made, custom process of course with roots in agile principles it needs time to get adapted fully by new members, I guess…
Great video and thanks so much for posting. You mention processes a few times – so I’m presuming spotify has processes 🙂 How do you work with process in an agile mindset environment and do you document processes?
That is really fascinating, You’re ann overly professional blogger.
I’ve joined you feed and stay up for searching for extra of your fantastic post.
Additionally, I’ve shared yur skte in my social networks
I saw the Transcript doc for part 2, do you have one for part 1?
Do you feel the version control strategy from this post, http://www.infoq.com/articles/agile-version-control, is consistent with the Spotify Engineering Culture?
Just watched the video. As a visual thinker, I found this amazing. Thanks so much for sharing the video, as well as the tools you used. Inspirational!
Here we (Bill Li, Jacky Shen, Roger Chou) has made Chinese version of subsitutes, plz make a link.
Part I & II:
Here os a transcript of these two videos, if you’re interesting in reading it: peeela.com/blog/spotify-engineering-culture-video-transcript
Hi Henrik, although many years ago it appears the model is still as relevant when you first published it.
A couple of questions have come to mind which would be good to get some clarity on:
* How does organisational reporting lines look like in this model? I understand that chapter leads have line manager responsibility within a Tribe. But how about the Chapter leads themselves, who evaluates their performance, supports development, etc? Same question for roles such as Tribe leader, Agile Coach, etc.
* What are the pitfalls with this model in your opinion?
With reference to Spotify Engineering Culture (Part 1), want to know how we can train one on such tools and what will be the cost for same.