Copying Spotify or simply implementing any other blueprint of an agile organization is a fundamental mistake. Not because the models themselves were poor, but because implementing a model of an agile organization that has been chosen or developed by a few managers, experts or consultants from top to bottom contradicts the essential principle of self-organization. Agile organizations are always emergent in the sense that they result from the cooperation of self-organizing teams towards a common vision and are constantly evolving. Therefore, it is crucial for a sustainable agile transformation to withstand the pressure to deliver short-term successes and to empathetically and confidently give people the space and time to learn and grow together. As tempting as blueprints and their large-scale implementation may look, it is precisely this that leads the agile transformation into a dead end.
The essential and most important component in an agile organization is the self-organizing team. This is what you find in the principles behind the agile manifesto. And this autonomy of the teams is also at the core of Spotify. The Spotify model is based on exactly this fundamental principle and is therefore successful. Self-organization is the key, but also the challenge. For the transformation of a hierarchical organization into an agile organization of self-organized teams anyway, but also and still for Spotify:
What is the best thing about working at Spotify? What is the most challenging thing about working at Spotify? The answer for both questions is the same: Autonomy.
Joakim Sundén
Self-organization with a single team or with only a few teams is not a challenge. It only becomes difficult when the number of teams increases. This was also the case for Spotify, where the engineering team grew from 10 to 300 people between 2010 and 2013. And that’s exactly where this Spotify model emerged, which is now so often copied. But also something else was developed: “Agile à la Spotify”, a description of what this agile exactly means at Spotify. And it starts with:
Continuous improvement: At Spotify, part of my work is to look for ways to continuously improve, both personally, and in the wider organisation.
Agile à la Spotify
So the responsibility for the Spotify model clearly falls to those who have to work with it and in it. Everyone is continuously working to improve the organization at Spotify. This is the logical and necessary consequence of the principle of self-organizing teams. Admittedly, any form of organizing the cooperation of numerous teams is a restriction of the freedom of the individual team. However, this is necessary to make the organization and its product a joint success. One person’s freedom ends where another person’s freedom begins (Immanuel Kant). The fine but decisive difference is that these restrictions of the individual team’s freedom result from the cooperation of the teams and are decided by the teams themselves, and the teams are allowed to and trusted to do exactly that.
Trust: At Spotify we trust our people and teams to make informed decisions about the way they work and what they work on.
Agile à la Spotify
The task of leadership in this agile transformation is therefore not to choose the best model of an agile organization or to design a new and individual model and then roll it out from top to bottom. This seriously violates the central principle of self-organization and keeps people and teams dependent exactly where they should act autonomously. The actual task is rather to create a setting in which such an organizational model gradually emerges from the cooperation of self-organizing teams. This is a process of joint learning that cannot be accelerated with blueprints. If you try it anyway, you just introduce a new organizational model and conduct a transformation, but agile will be neither one.
Servant leadership: At Spotify managers are focused on coaching, mentorship, and solving impediments rather than telling people what to do.
Agile à la Spotify
4 Comments
I generally enjoy articles on Agile on this website, but I tend to disagree that using any blueprint or framework will lead to a dead end. At the very least it seems, a blue print or enterprise agile framework can be a starting point in Agile Transformation. How else will teams use/adherence to EA, solution architecture, security guidelines, regulatory compliance issues etc. A framework like SAFe or LaSS etc can also provide logistics of coordinating work between Agile teams.
Maybe I wasn’t precise enough. Not the models themselves are dead ends. In fact I consider them also as a good starting point (LeSS more than SAFe, but this is a different story). The point I tried to make was, that implementing those models as a given blueprint in a top-down fashion will not encourage self-organization in the sense of this quote:
Some shared and coordination standards do need to be globally set. Think “drive on the right side of the road” types of constraints. These however are very sticky and everyone will live with them a long time. Think the yards vs meters. Be sparing when creating a global standard and involve bottom up input and understanding when doing so.
Absolutely! I don’t object to global standards. What I object to is the way such standards are imposed from top to bottom. This is best summarized by this quote: