Spotify Blog 2 : How they nail their process

by Lawrence Walsh | Mar 26, 2019

time icon 5 mins

How many of you have started your business, had one awesome team that was perfectly aligned and harmoniously in sync, thought to yourself “This is awesome, let’s expand and conquer the world – WE’RE READY!”, taken on more staff, developed more teams and then have ended up with something that can only be expressed like this: spotify

Yeah? Then this blog’s for you!

As promised, but slightly later than hoped, this is the second blog in my series of Spotify and the world of OKRs. If you haven’t read the first one yet then I recommend checking it out here before reading this one Spotify ~ Part 1: People & Culture

Today I’m going to take you on a whistle-stop tour of some of the highlights of how Spotify nail their process, to stop the pandemonium above from taking place. The basics come from how they set up their teams, as I mentioned in my previous blog they are formed into autonomous squads which allow for quick scale and eliminates the dependency and coordination struggles we see in the illustration above.

The vital thing is that these squads are all aligned with product strategy, company priorities & the other squads. This is exactly what OKRs allow within a business, we encourage complete transparency in every team and individual’s OKRs, the reason being that they allow alignment in priorities in every part of an organisation. Not only this, but when using Cross Functional OKRs (something which we highly recommend and you can read more about here – Cross Functional OKRs – Breaking Through the Silos on the Death Star – groups of employees very similar to Spotify’s Squads will naturally start to form.


Spotify has a mantra of enablement over servitude; supplying the Squads with everything they need to get the job done the best way they know how. They are not tied into using certain software or doing things a certain way, because that’s what the powers that be have dictated. Instead, they have 3 very basic forms of squads; feature squads which (you guessed it) focus on the features of the software, Client App squads which concentrate on fulfilling the bigger picture app hosting and finally Infrastructure Squads which are there to enable and support the 2 other squad types to operate at full efficiency.


Alongside the human element of squads, technically Spotify has an Open-source model of de-coupled architecture. The result of such a model is that new feature releases can be worked on incredibly quickly and any spotifymistakes only have an impact on a very small part of the system. They are not held back by dependencies on other departments, if they want something changing then they can crack on with it. Typically, a squad would ask the squad responsible for the piece of code they want changing to work on it, but if this is going to cause delays then this isn’t mandatory. Instead, they will work on the piece of code and ask the other squad to review their work. What a refreshing change that can only be born out of the trust and culture that I discussed in the first blog.

Whilst in OKRs we typically encourage multiple functions to come together to achieve a result, if this isn’t possible then they could easily be used to allow a similar process to occur. For example, perhaps you wouldn’t allow a Key Result to be marked as 100% attained until it had been tested and approved by the department responsible for the feature in question.



Another fairly unique feature of Spotify’s process is their use of ‘Release Trains & Feature Toggles’. The idea behind this concept is that in each week’s release of features they will release everything they have been working on, even if it is not finished. They get away with this using feature toggles, so whilst the feature is there behind the scenes it will never be visible to the end-user until the toggle is switched on. The reasoning for this is that it allows other future features to still be tested against it in the back end development.

This system of carrying over something unfinished reminds me of a very common question we get asked about OKRs:

“What do we do if we know an Objective is going to take more than 3 months?”

Our stance on this is fairly straightforward, it is absolutely no problem at all to carry an Objective over into a second quarter – but it is absolutely vital that the Key Results change each quarter. OKRs being used in this way could hugely help in ensuring Spotify’s releases are achieved efficiently, despite not entering the ecosystem at 100% readiness.


Finally, I just want to leave you with the image above as it highlights such fantastic ways to get traction and buy-in behind any sort of team management process. In order to get unrivalled traction towards OKRs it is vital everyone is bought into the new system. Nothing is better for this than visualisation of progress towards OKRs, whether via physical boards or virtual for the more remote teams (try Asana or Trello). There is also of course a whole host of OKR specific software out there and you can read more about those here Recommended Software Providers.

Above all though, traction is gained via recognition and reward – I’m not talking about pay rises and bonuses here, but allowing your staff the ability to show off the progress they have made at things like Daily Syncs and Weekly Demos. When they do make sure they are received with a lot of public recognition – you’ll soon have all your staff aligned behind the company’s vision, no matter how your internal processes work.