The most important inventions of Spotify

Spotify’s published principles are intriguing to many. Probably a major factor in why agility just works at Spotify.

I’ll add my own interpretation. I also only know Henrik Kniberg’s public presentation at various conferences, hence my insert: it’s another interpretation.

For me, the success can be traced back to one essential reason: Agile Mindset is a matter for the boss and is consistently lived, e.g. in a rigorous orientation towards employee satisfaction. This has probably led to a very mature and responsible organization.

Beyond that, there are two key inventions that impressed me: Radical Loose Coupling and Scaling Trust.

Loose coupling

Teams (yes, they’re not called teams anymore, but still) can work very autonomously because Spotify has developed a policy to minimize code dependencies. In addition, one can clone and further edit another team’s code. A synchronous dependency, and thus a potential blocker, becomes an asynchronous task of regularly reconsolidating. As I said, a solution of a mature Organsiation.

Scaling trust

What is the source of credibility and trust? From proven competence, transparency, common goals and regular exchange. With the guilds and tribes, Spotify has the structures to live such an exchange and to regularly question the competence and transparency.

Full-time scrum master?

At Spotify, not every team has a full-time Scrum Master anymore – instead, they can call on coaches if they feel they need one. An example for me would be conflict mediation, or addressing an external problem that needs to be escalated.

This also corresponds to my experience in many teams: they need someone who regularly keeps the exchange going, most other tasks can be handled by an experienced team itself.

Aligned Autonomy

Alignment is a prerequisite for autonomy – that’s one of the phrases that has come out of the Spotify environment. Yes, true – I agree and still put the context of focus. More on this in an earlier blog post.


There are now several agile implementations that invoke the Spotify model. I have my problems with this: first, the authors deny that there is a general and well-defined Spotify framework. Second, I see a tendency to just adopt the nomenclature and overlook the mindset part. I don’t care if someone renames teams – but I dare to doubt if a new choice of words is really purposeful.