InfoQ Homepage News Don't Copy the Spotify Model

# Don't Copy the Spotify Model

The Spotify model can help you to understand how things are done at Spotify, but you shouldn’t copy it in your own organization. It changes all the time as people at Spotify learn and discover new things. There is no one way in which software is developed at Spotify.

The way that Spotify develops software was first described by Henrik Kniberg and Anders Ivarsson in Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. Their 2012 paper provided a snapshot of the way of working at that time at Spotify, as Kniberg explained in the InfoQ interview scaling agile at spotify:

It wasn’t a big re-make, more like a continuous stream of small iterative improvements to our organization and process. We have been growing for three years, and the way we work today has evolved naturally over time.

Spotify has been growing and the way that software is developed keeps on changing. There is no one way in which software is developed at Spotify; Spotify encourages their employees to learn and adapt their way of working continuously.

In the 2015 InfoQ interview learning fast at Spotify, Simon Marcus explains how Spotify tries to grow up and mature without losing their founding spirit and culture:

The problems that a company like Spotify faces on a day-to-day basis trying to serve twenty million daily active users are just widely different from the problems that a startup trying to find its market faces. Our constraints are different, the boundaries of our work are different, the fact that in an early stage startup you just kind of know everybody and everybody does everything, that’s not really feasible in an organization the size that Spotify has gotten to be- about fifteen hundred people now, seven hundred in tech product and design. So our approach is what futurist Warren Benes calls an ad-hocracy, which is an organization that is intentionally designed for flexibility and adaptation, and is maybe less concerned about extracting every last dollar of every activity that you engage in, and what this means is that we have, as I talked about, a relatively high tolerance for failure. And we have a relatively high tolerance for inefficiency in the name of making sure that we are doing the right thing.

One of the core guiding principles at Spotify is autonomy. Kristian Lindwall and Cliff Hazell from Spotify explained in a 2015 conference talk why autonomy is at the heart of agility in the InfoQ interview role of autonomy in agility:

Autonomy has a Greek origin; it means having the freedom to choose. Autonomy is always within boundaries. Boundaries come in forms of clarity and constraints, something that you should aim to make as explicit as you can (often together with the teams themselves). Overall, Spotify aims to have a culture of highly autonomous, well aligned teams. You can have both, but you need to work for it, said Lindwall and Hazell. Always make sure teams have access to their stakeholders and know their purpose.

Marcus Frödin, director of engineering at Spotify, explained the framework for adopting the culture at Spotify in Spotify wants to be good at failing:

Spotify uses a concept that they call Data Insights Beliefs Bets (DIBBs). DIBBs are "things that we believe about the world, where we want to understand why we believe it" said Frödin. DIBBs are applied for both strategy and culture. (...) Spotify maintains a board with company bets; the things that they have to do right now. This board with bets is open to everyone in the company.

Marcin Floryan, chapter lead at Spotify, spoke at Spark the Change London 2016 about Spotify's current approach to product and software development. This is a summary of his talk there is no Spotify model.

People look at the Spotify model as an example to follow or imitate. This can result in a halo effect bias, argues Floryan, where people look at something which is successful and expect to be successful when they do the same in their company. This is not the most useful way to look at the Spotify model, said Floryan; imitating is a really tricky path to take.

He suggested to looking at the Spotify model as a simplified description of a system or process. The model can help you to understand how things are done at Spotify, but it is not something that you should copy in your own organization.

Floryan mentioned the organizational culture model by Edgar Schein, which indicates that you can only see a small part of the culture.

Culture is also an abstraction, yet the forces that are created in social and organisational situations deriving from culture are powerful. If we don’t understand the operation of these forces, we can become victim to them.

Things like basic assumptions are so well integrated in the way of working that they are hard to recognize. Internally, Spotify tries to talk about those aspects of culture and wants to make them visible; for them that’s a way to look under the surface, said Floryan.

One of the basic assumptions of Spotify is autonomy. Squads are based on this assumption. They are small, empowered cross functional teams who have full life cycle ownership. Squads make it possible for Spotify to move at much greater speed. They do not rely on other parts of Spotify to achieve their goals and deliver value.

Autonomy is futile without alignment, said Floryan. To achieve autonomy is very hard- there are lots of challenges. For example, trust is important in making autonomy work. As an example of trust at Spotify, Floryan explained how the supply of IT hardware is done. There’s a cupboard in the Spotify office where things like keyboards, cables, batteries, etc., are stored. If an employee needs something they can take it, they don’t need to order it, get permission or sign off.

Another example of trust is that at Spotify anyone can deploy any piece of software, at any time, from any place (with some restrictions, for instance on credit card transactions handling systems). Everyone can see the business metrics, has access to most of the documentation, and the earning goals are also internally published.

Being trusted without being given the right information leads you down the wrong path, said Floryan. He went back to the supply of hardware at Spotify, where the price of each article is mentioned on a tag on the cupboard. Knowing the price employees can better decide if they need a new keyboard, or not. Giving information enables people to make the right decision in their context, said Floryan.

You have to have a purpose in your autonomy to make people do the right thing. People at Spotify found out that the way of thinking and how things are done aligns with the ideas from Daniel Pink on autonomy, mastery and purpose, so they decide to try out other things from Pink’s book Drive. Floryan stated that this again shows that you should not start with a model or a book and try to implement that, but instead look at what you want to reach and use whatever helps you to get there.

Being good at Spotify means that you are really good in working in a team. We solve problems in groups instead of asking experts, said Floryan. The offices at Spotify provide space to collaborate. A squad usually has three people who are the leaders and work together: someone who represents a product (a product owner), a technical lead or chapter lead who represents technology, and an agile coach who represents the process. The leadership principle is used at all levels, so a tribe or alliance will also have three people leading it from a product, technical and process perspective.

Who you can become matters more than who you are now, argued Floryan. When hiring people Spotify looks at the potential that a candidate has, the ability to grow and develop new skills.

Diversity is where different perspectives and viewpoints collide. Diversity stimulates innovation; that is why Spotify pays a lot of attention to this topic and for example organizes diversity summits, said Floryan.

Floryan mention several beliefs from Spotify. He stated "we believe it’s a marathon, not a sprint". That is why Spotify gives people time off to recharge. Another belief is "whoever learns the fastest wins". We aim to make mistakes faster than anyone else, said Floryan, quoting Daniek Ek. Spotify has to be able to recover from failure, to have very fast feedback loops, and have the data, tools and an infrastructure that allows to create insights for more effective learning.

The Spotify model changes all the time as people at Spotify learn and discover new things. We look at what we do, we examine the problems, and solve them, said Floryan. He quoted Taiichi Ohno stating, "you have to think for yourself and face your difficulties instead of trying to borrow wisdom".

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• ##### Nice, but

by Michał Mela /

• ##### Re: Nice, but

by Ben Linders /

• ##### $206 million dollar loss = Successful development model? by Doug Husovsky / • ##### Re:$206 million dollar loss = Successful development model?

by Roland Heimdahl /

• ##### There is a Spotify model that you should copy

by Tom Whiteley /

• ##### Nice, but

by Michał Mela /

Your message is awaiting moderation. Thank you for participating in the discussion.

Very interesting article.

Unfortunately, half of the links in the article lead to what look like dummy URLs.

• ##### Re: Nice, but

by Ben Linders /

Your message is awaiting moderation. Thank you for participating in the discussion.

• ##### $206 million dollar loss = Successful development model? Your message is awaiting moderation. Thank you for participating in the discussion. As Spotify continues to loose money one must wonder if the development model continues to contribute to the losses. If there was a stronger focus on revenue maximization or a shift to proven development models would the losses be reduced? For me the losses alone are a red flag and a reason to stay away from their model. • ##### Re:$206 million dollar loss = Successful development model?

Your message is awaiting moderation. Thank you for participating in the discussion.

Your assumption is basically wrong, they connection between the losses is that they are investing, not thay their development is expensive (although that might true too). If they invested in fewer features and started to show profits on the last line. Would the development-model be better then, even though it didn't change at all?

• ##### There is a Spotify model that you should copy

by Tom Whiteley /

Your message is awaiting moderation. Thank you for participating in the discussion.

I agree with a lot of what you say, but there is something that you talk about that everyone should be trying to copy. Your first quote talks about how it has been a "continuous stream of small iterative improvements". The model of constantly making regular, small iterative changes with the input of employees is what everything should be trying to emulate.

I've put my full thoughts in the following blog, in case anyone is interested:
medium.com/@tomwhiteley44/there-is-a-spotify-mo...

• ##### A better version of your company, NOT cut and paste

Your message is awaiting moderation. Thank you for participating in the discussion.

Continuous experimentation, learning, adaptation, and change IS the Spotify model. The outward appearance of how Spotify organizes and executes is merely a reflection of this deeper "system". For those who want to learn more about how to implement such a system check out our executive brief entitled "Big Pivot" - www.gearstream.com/whitepapers/the-big-pivot/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.