Use this code to get 25% off 'Competing with Unicorns' at pragprog.com until Dec 31, 2020: 0fc9b293b9
The Spotify model has been around for several years, and it has become extremely popular among tech companies. Yet recently, we’ve started seeing more and more reports that it doesn’t actually work.
How can that be?
Is it a misunderstanding? Or is the Spotify model flawed at its core?
We bring you an inside scoop to better understand the Spotify model overall, and what it takes to really make it work. Jonathan Rasmusson, author of 'Competing with Unicorns' and ex-Spotify employee shares his insight. The interview is from episode 30 of the Level-Up Engineering podcast, hosted by Karolina Toth.
Jonathan is currently working as an iOS engineer at his own company, Rasmusson Consulting Group. He has spent most of his career in software development. He started programming in the early days with Java and web, and later moved to .Net.
He became an agile project manager for a few years, but working at Spotify reignited his love for software engineering, and he turned into a full-time iOS developer. He wrote the book 'Competing with Unicorns' based mostly on his experience with the Spotify model, which shows you how to make your own processes better.
The biggest difference is their goals.
A big enterprise builds most of its software to automate and make processes more efficient. For example, automating back office work heavily improves efficiency. They have clear requirements, and it’s mostly driven by budgets and timelines.
Startups and younger companies like Spotify are different, because they have to figure out their product. They don't know what features they need, and they often don’t know who their customers are. They’re looking for product-market fit.
This forces them to look at software development differently. They need to find out what they need to build to become successful. Startups are all about learning rather than setting expectations.
Software engineers at a big enterprise often lose motivation. Working at Spotify and other companies before, I found that developer productivity and motivation are through the roof. There are two reasons for this:
This can turn a low-performing engineering team around. If you give your team a goal and let them figure out how to get there, they will be more engaged and have more ownership of the result. This leads to a higher quality product.
The difference in motivating their engineers is that they trust and empower them, rather than tell them what to do exactly. They give the team a mission, like bring music to Sony, or create the ultimate driving experience. They trust the team - what they call a squad - to find a way there.
This approach has a lot of implications in organizing and executing the work.
I always hear it’s too good to be true.
But it's not just Spotify that works this way. Every company has a slightly different engineering culture, but what all the unicorns, like Facebook, Google and Netflix, have in common is they all have employees direct their own work as much as possible.
These unicorns started out as small companies and experienced the efficiency and speed that comes with it. Eventually, it became a problem for all of them, as they scaled the engineering department. What works well with 10 people breaks down when you have 100 people.
Management focuses on assisting the squads to get there. They treat their employees as contributors to their ideas, rather than as workers to be told what to do. They aim to hit hypergrowth and get to an enterprise level while keeping the startup mentality.
A key element to this is holding on to small, autonomous teams. Squads have 5-10 people with various software engineers and designers, and they take responsibility for a part of the product. The rest of the company is built around this idea.
In 2014, Sony came to Spotify to set up a partnership, because their music service was shutting down. This instantly became our biggest project, and a lot of squads started working on making Spotify work on PlayStation. I was coaching a team working on this.
At one point, I realized that the launch date was coming up, and we were behind schedule. I thought we were in trouble. At the next all-hands meeting, I told everyone that the deadline was in jeopardy.
In any other company I’ve been part of before, this would have been a big deal. Instead, the program director said, “Thank you for the information. We'll let the team tell us if they think there's a problem.” Then she simply moved on.
This left me puzzled, because I expected the CEO and everyone else to get up in arms and demand action. This showed me how much trust Spotify puts in their teams.
This was the moment I realized that I haven’t heard the word project or budget at Spotify. They have a very light project management system.
Henrik Kniberg has a great video about breaking down how Spotify squads, tribes, chapters and guilds work. It’s easy to tell your people to organize themselves based on that model. The hard part is empowerment and trust.
All this doesn’t work unless senior management is willing to use a free-rein leadership style and to let these autonomous teams succeed and fail on their own. Experienced senior executives are used to working from a top-down point of view, and it has led to a lot of success. But the team ends up feeling like they have no responsibility, and they just wait for the magic to happen.
It takes a cultural shift to make this organizational model work. Every company has a different level of comfort with giving responsibilities to their teams and possibly letting them fail.
Young organizations don't have any baggage or history with the way they work. Spotify was founded in 2006, and it’s still a relatively young and small organization.
When a tribe grows beyond 100 people, it starts to become unmanageable, so the leaders at Spotify break it up and reorganize. They split the tribe in two, reform the squads, and move people around accordingly. They blow up the organizational structure and morph into a new one.
You can afford to do this with a relatively flat hierarchy.
Older and larger companies have a lot of organizational weight, and they can’t restructure easily on the fly in the name of efficiency. Many people have entrenched interests in maintaining the existing structure.
It comes down to the incentives. It’s about how people within leadership are rewarded and promoted in the organization. If engineering leaders only need to worry about their own metrics, and not about their peers' performance, they’re going to optimize for themselves.
The organization’s best interest may be for you to give up your best software engineer to help out another team, and it may not align with your own team’s best interest. The right incentives help leadership make the right calls in these situations.
Managers and leaders can start building this way of working within their own groups.
The first step is just to realize that you don't have to have the answer to everything. Under safe circumstances, it’s a good idea to let your team try something, even if you think it's going to fail. I’ve done this, and it’s scary, but more often than not, I've been proven wrong and the team has come up with a great solution.
There is great power in giving someone responsibility for a problem and letting them solve it as they see fit.
When I joined Spotify, I was amazed at how much data I had access to about signups, performance and finances. This type of data is normally only available at the top levels of a company. Spotify’s philosophy is that people make better decisions when they have the whole context.
The top metrics that kept coming up in town hall meetings (a.k.a. all-hands meetings) was the amount of monthly active/paying users and the monthly new signups. These encapsulated the success of the company.
This directed focus and helped everyone understand the impact of their work. This helped align and organize teams towards working in the same direction. Large enterprises often miss this.
Spotify runs a list of company bets. These are the top 10 projects going on in the company, but they are not traditional projects in terms of time and budget. It’s a prioritized list of the biggest initiatives.
If all of them are done by the end of the year, it was a great year. For Spotify, it may be a launch in Japan, or launching on PlayStation, which was the number one company bet until the original deadline.
This means that the company rallied around the teams working on these bets to give them what they needed or wanted. Teams working on the top bets have priority access to meeting rooms, specific engineers to solve specific problems and so on. It’s a very effective mechanism.
Any company can take this and apply it today. Create a priority list of the most important initiatives in your company. Figure out a way to communicate this, and align the work around it, because the rest of the projects are significantly less important.
This helps everyone in the company align with your top priorities.
KPIs are used strategically. They help you set specific goals to achieve for any given quarter. KPIs are useful when directing the high-level company strategy.
My manager took it upon himself to explain to me what was going on in the greater parts of the organization. Managers have insight into happenings their reports don’t see, and it’s a key responsibility for them to share some of it with their teams. They can communicate these messages down.
He would give me insight in events like why there was a hiring freeze, or what positions the company was looking to hire for. This insight helped frame the context. I personally like knowing what's going on in the broad organization, while others are fine focusing on their immediate environment.
On the individual contributor level, when you’re working in the trenches, the best management mechanism at Spotify, and many other companies use it too, is the weekly one-on-one meeting. In a one-on-one, a manager and one of their direct reports get together. My manager at Spotify made this a session about helping me become as productive as possible.
He was the best engineering manager I’ve ever known; his name is Marcus Frödin. He moved blockers out of my way and challenged me in great ways. When I was working on a course to explain how to do unit testing and test-driven design, he opened my mind to the possibility that it may be used beyond the team, maybe even beyond the organization.
Traditional enterprises rarely offer this kind of servant leadership to their employees.
Going through a performance review where it’s a bulleted list of what you wanted to do many months ago and having to report how you did on them can kill motivation. It’s almost like you only show up for the manager, because they will evaluate you and decide whether you should get a promotion or a raise. Weekly interactions in a one-on-one change the whole dynamic.
Try to put yourself in the shoes of your team members. If your team isn’t performing well, ask yourself these questions:
If they keep telling you the codebase needs a major refactoring, but you continuously ignore it and keep pushing deadlines on them, they’re in a bad place. They need opportunities to improve the workplace, whether in the code or in the product. You need to make sure they’re heard.
When it comes to missing deadlines, you have to analyze the context. Understand where the deadline is coming from, and who came up with it.
It’s different when your team has an opportunity to assess the work and to come up with a deadline than when it comes from a higher up engineering leader setting it arbitrarily. A deadline can be wrong. It’s certainly wrong if it’s impossible to hit.
Here are some things to look at when you analyze your process for setting deadlines:
It often isn’t black and white. Ideally, a team can release the feature or their software when they’re ready. You design, build, test, and ship it when you're ready - this is the dream in software development.
Yet there are valid business reasons for hard deadlines.
The Sony-Spotify cooperation was an example of this. We needed to have Spotify ready to go on a PlayStation by the agreed-upon date. I wish we had a couple more months to work on it, but we just had to be ready. The team piled up a lot of technical debt, and they paid for it after, but we shipped the product by the deadline.
Whenever you can afford it, let the team come up with a deadline and ship when they’re ready. When hard deadlines come around, support the teams in hitting them whatever it takes.
Unicorns make counterintuitive business bets that help them build a successful product. Spotify made the bet that people want to listen to all the music in the world, rather than buy individual songs. The internet wasn’t set up for this, so it took a lot of technical work.
These unicorns make tech employees first-class citizens in their company. Tech doesn’t have to be number one, but traditional companies can benefit from investing in technology and in building a sound foundation for their products. This investment is what enables companies like Spotify to iterate quickly.
For example, let’s compare your local cable company to Netflix. The cable company has been around for 40 years and should know its customers well, yet they tend to offer a clunky experience when customers sign up, with a lot of time spent on the phone.
Netflix, on the other hand, is completely seamless with a great onboarding process. You can sign up for them and start using their product in a matter of minutes. It’s because they invested in building the technical foundations.
Unicorns tend to be driven by tech. This is another reason it’s hard to keep up with them for older organizations.
🚀 Need developers for your team or project? Hire our experienced Angular or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.