How to Build Your Own “Spotify Model”

It is early 2011 and you are the CTO of Spotify. You’re staring out of the window of a coffee bar in a snowy and dark Stockholm. It has been an amazing year. Your company is acquiring customers faster than ever and you’re launching in more and more countries. However, Google and Apple are catching up. It’s not a question if they will launch their own music streaming services, but when. To survive that eventuality Spotify must become a truly global player.

You have to do this while still figuring out how the music streaming business actually works. What do customers really want? What will they pay for? What do you need to do to convince someone to stop buying CDs or MP3s and instead be willing to pay for a monthly streaming subscription?

“We need to innovate, experiment and learn faster than the competition.”

To do all this on a global scale you have to grow your engineering team. It has been a huge challenge to grow your team from 10 to 100 in the last year. Some people predict you might even need to attract another 1,000 engineers to pull this off. You feel overwhelmed. How can you attract the right talent with the right mindset across the entire globe?

Managing a team of 100 is already complicated. But if you grow even further, how do you stay agile? How can you keep the start-up culture that has brought success so far and prevent becoming a lumbering bureaucracy?

Spotify’s organization design

Another two years have passed and the company now has 15 million customers. The engineering team has tripled in size to 300 people. A challenge that has been top of mind for a while now is, “With 30 teams, how do we make sure we build a castle that makes sense to the customer, instead of a pile of 30 bricks that nobody likes?”

The teams have started to experiment with a scaling model that uses Squads, Chapters, Guilds and Tribes who aim to implement ‘minimum viable bureaucracy’ and balance high autonomy with high alignment.

This structure is just one piece of the puzzle, though. Through a few workshops, the agile coaches came up with a set of organizational design principles with the autonomous team as the core concept. This extension of the agile manifesto is called “Agile à la Spotify”, and has been printed on the walls across the office:

• Continuous improvement: At Spotify, part of my work is to look for ways to continuously improve, both personally, and in the wider organisation.
• Iterative development: Spotify believes in short learning cycles, so that we can validate our assumptions as quickly as possible.
• Simplicity: Scaling what we do is key to Spotify’s success. Simplicity should be your guidance during scaling. This is as true for our technical solutions, as for our methods of working and organising the organisation.
• Trust: At Spotify we trust our people and teams to make informed decisions about the way they work and what they work on.
• Servant leadership: At Spotify managers are focused on coaching, mentorship, and solving impediments rather than telling people what to do.

Full autonomy is a trade-off

Fast forward to early 2018. Spotify has 140 million users in 61 countries. It has announced an DPO at a $20 billion valuation. Engineering and R&D is now 180 teams and 1,800 people. In total, Spotify employs over 3,500 people: the organization is no longer a startup, it’s a global enterprise.

A lot has gone really well. The culture is known for a high level of empowerment and trust, a focus on personal development, and is known for its sense of purpose. Teams are fully empowered to fulfill their mission and have the freedom to act independently. But as Joakim Sundén pointed out, it is far from an agile nirvana.

“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

Managing 180 autonomous teams can feel like herding cats, especially when it comes to projects that span across teams.

Some recent examples: implementing SOX compliance to enable the IPO, keeping up with new privacy laws and moving all infrastructure into the Google Cloud. Also, the lack of focus on architecture and technical standards has made it challenging to scale the platform to support its growing user base.

Implementing these initiatives top-down wouldn’t work in Spotify’s culture. A team can simply say “I don’t want to do it” and would need to be seduced to give these priority.

Over the years, the lack of central planning and standardization has enabled hyper-speed, hyper-growth and hyper-innovation. But it has made certain things a lot harder that are easy for more traditional organizations.

“There is no right or wrong, it’s all trade-offs” — Henrik Kniberg

Time will tell how Spotify will continue to evolve. It’s a challenging balancing act between doing the right things, doing the things right and doing things fast.

Don’t copy the model

As agile organization designers, we’ve been following Spotify closely. Over the years, we’ve visited their offices several times. It’s an awesome company and there is much to learn from them. We love how the engineering culture videoshave inspired thousands of people to start upgrading their organizations.

However, if you’re considering implementing the ‘Spotify model’, please think again. Is your organization building a music player? Is your organization still trying figure out its business model? Is your organization facing hyper-growth? Is “move fast and break things” applicable to your product?” Maybe. But, probably not.

When people copy the ‘Spotify model’, it often happens through a top-down directive, without taking a close look at what kind of culture and leadership is needed to make it work. Often the existing hierarchy is changed into a new, static matrix blueprint (even if the matrix is labeled with Squads, Chapters, and Tribes), instead of growing a culture of continuous participatory change. This will inevitably make things worse. Even people who work at Spotify recommend to not copy their model.

Don’t get us wrong: in order to enable agility in an organization, we do recommend that you move away from top-down management and focus on empowering capable teams. But to copy a pre-existing model and believe that your problems will also be solved, is short-sighted and naive.

“The only Spotify way of working that actually works is turning on the Spotify volume really loud and dance.” — Erwin Verweij

Evolve your own organizational model instead

Just as startups are focused on finding product-market fit, we believe you should start on a journey to find your organization-context fit. Spotify has been able to do both.

We love this quote that is at the heart of what we believe:

“Stop trying to borrow wisdom and think for yourself. Face your difficulties and think and think and think and solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up.” — Taiichi Ohno

So what can you do if you want to gain agility, speed and innovation? Where to begin?

First, ask yourself, is there a clear picture of what issues you’re trying to solve with a new organizational model? If possible, find a few measurable indicators of what needs to be improved.

Involve not only your leadership team, but also a wide variety of people in the organization to gather ideas and co-create a picture of the desired future state. A good question to ask is: what is holding you back from doing the best work of your lives?

Don’t forget to appreciate what is going really well and decide what you definitely want to keep.

Take inspiration from a wide variety of future of work practices and companies. Look at different models of self-organization that fit different scale and risk contexts. Look beyond Spotify and even look beyond agile to gain org-wide agility.

Figure out what the main capabilities are you need to upgrade and where in the organization they are rooted. The OS Canvas is a useful tool for this exercise.

Design and start a number of pilots that help you try out new ways of working and allows you to quickly learn if it fits your specific context. Expand the pilots that show promise. End the ones that don’t produce the effect you’re looking for. Build your organization’s ability to constantly try new behaviors and learning from those experiments.

At the end of the day, use the Spotify model as an inspiration for what’s possible when you spend time and attention developing your own operating system — not as a model for what your own system may end up looking like. Design, test, and evolve your own model as inclusively as possible. Don’t do a big-bang change towards a new static target operating model, but instead build the muscle for continuous participatory change.

Don’t “do the Spotify model” — do your model.

-------------------------

Authored by Roy Gielen, Agile enabler, trainer, coach and change agent at Ctree.

Co-authored by a friend of Ctree: Jurriaan Kamer (Agile change agent, speaker and organization designer at The Ready)

-------------------------

Ready to build your own model? Ctree helps organizations to excel, innovate and move faster to become and stay future proof in this fast changing world. In everything we do we challenge the status quo with respect for the company’s DNA and believe that real change starts at your heart!

Contact us to find out more.

Follow Ctree on: Twitter | Linkedin | Ctree.nl