BT

Spotify Wants To Be Good at Failing

| by Ben Linders on Jul 21, 2016. Estimated reading time: 5 minutes |

Spotify wants to be really good at getting it wrong quickly and optimized for experimentation, said Marcus Frödin, director of engineering at Spotify. At Spark the Change London 2016 he presented a concept to learn from mistakes and breed success and gave examples of failures at Spotify and how they learned from them.

Frödin mentioned that Spotify wants to be "embarrassingly parallel" and "good at failing". By embarrassingly parallel it is meant that they want to be organized in such a way that they can do a lot of stuff at once. To deal effectively with failure, Spotify wants to be a learning organization with short feedback loops.

Communication is often an issue in larger organizations. The trick is to assure that the need for communication goes down faster than the cost of communication goes up, said Frödin. To keep communication needs low, squads at Spotify are collocated and have all disciplines to develop and deliver.

Leaders spend their time communicating intent and to help propagate knowledge by picking up learnings that come up from the teams. Intent is the things that brings alignment, said Frödin. If someone has an idea, you want it to spread without using command and control.

Frödin went over the intent - hypothesis - feedback loop to explain how organizations can innovate. Between the intent and hypothesis there’s the alignment gap. The other gaps are the effects gap (between the hypothesis and feedback) and the knowledge gap (between feedback and intent). Most people focus on the alignment gap said Frödin, but as hypothesis and feedback lead to learning the effects and knowledge gaps are more important.

Intent-hypothesis-feedback loop from Spotify

Several people have shared views on learning and experimentation. InfoQ interviewed Tiago Garcez and asked him about using experimentation to learn from failure:

Failure is always option - it’s just that sometimes we don’t even want to imagine what would happen if it actually did happen (...). When you phrase it correctly ("failure is always an option") alternatives already start to emerge. Safe-to-fail, for example, is one of the terms that you hear a lot these days. The thinking there is simple: make sure, before starting any initiative where there are considerable risks, that you use controlled experiments where you know what success and failure look like, so that you can evaluate potential solutions or ways forward. Such an approach keeps failure from being expensive or mission critical, while still providing opportunities to learn (if you structured the experiments in a coherent way).

Frödin gave the example of the Spotify app store, an innovation which didn’t work out as expected. The idea behind the app store was to supply apps developed by third parties to the listeners, who would use them to listen to music and discover new stuff. This app store should support Spotify in becoming a platform for music, and help hem to become faster at shipping internal software by mimicking an operating system and using available web technology.

Spotify shipped the first version of their app store for desktops in 2011. Soon they had a couple of hundred apps in the store. But the number of apps didn’t go up significantly in 2012, and also metrics showed that Spotify listeners were not spending time with apps. In 2013 it became clear that mobile was taking off fast. They had to decide to either deploy the app store to the mobile world or shut down. Since the expectations of the app store were not met, they decided at the end of 2013 to phase it out. It took two more years before they were able to close it.

The main reasons that the app store failed was because it didn’t give sufficient possibilities to monetize, and that the number of users stayed low. Fundamentally there was a knowledge gap said Frödin. They learned that a special purpose app store can’t succeed at the scale that they envisioned.

In an InfoQ interview with Jeffrey Fredrick on harsh realities and learning, he explained how people can learn from mistakes:

I think, first of all, it is that mindset. It is the desire. Then try to be as self-critical as you can, while also being compassionate, to be able to accept the fact that you made a mistake. If you see the mistakes as part of yourself, as you see your person as an individual, it would be hard to get the learning from them. But if you see them as a behavior that you can change, if you have a growth mindset that is something that you can accept and therefore improve, and therefore you can deliberately practice and work on – coming up with that mindset and that type of practice identifying what specifically you would do differently to prevent this same mistake.

Frödin talked about the shift to mobile at Spotify. Making the change to mobile was hard. It took three years, where initially software for mobile was released once every six months with only one squad that was delivering. Spotify teams were doing demo’s on desktop while the company was going mobile. He showed an email that was sent out in February 2013 in which the Spotify CTO launched the strategy on how Spotify would become a mobile company. Spotify went from one squad to all squads delivering software for mobile platforms. Looking back they should have started earlier with mobile to build up knowledge, said Frödin, and should have put more emphasis on creating a platform for mobile.

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. One example of a culture DIBB is the "belief" that speed of iteration beats quality of iteration. The "bet" based on this belief is that Spotify has optimized their organization, culture, architecture and process for learning and execution speed opposed to things like developer resource utilization or cost per built feature. The underlying "insight" is that you can only learn when the code is in front of a consumer, therefore the more often you release code to users the more you can learn. You have to ship often to gain value. The "data" for this insight is that all modern methods for software development rely on short iterations with constant learning, and that there have been many ideas which didn’t work in practice; hence you have to develop and deliver to test ideas.

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.

Summing up the presentation, Frödin stated three things:

  • Autonomy & alignment interact: Empower peer-based teams, make sure failure travels fastest, and vocabulary shapes culture.
  • Iterate with a purpose to bat Darwin: Make failure expected and retrospect, copy with intention, and be Bayes not Darwin.
  • Over-reacting beats under-reacting: When in doubt ship it, put doers closest to value delivery, and hire for capability to change.

Rate this Article

Relevance
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.

Tell us what you think

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

Email me replies to any of my messages in this thread
Community comments

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

Discuss
BT