The Spotify Model
How To Create, Dissolve, And Remix Teams To Be More Dynamic And More Innovative
Hola a todos ("Hello everyone" in Spanish). I want to thank everyone who subscribed, read, and shared this newsletter! Reactions to both the newsletter and podcast have been incredible so far. Please help spread the word if you find this valuable!
Some news on the book! The pre-order for the softcover edition of the book is now live on Barnes & Noble. It will be available from all your favorite booksellers in March, but if you can't wait… https://itdependsbook.net/lnk/bn.html. As a reminder, the Kindle pre-order is available at https://itdependsbook.net/lnk/amzn.html.
Also, don't forget the podcast. The latest episode, "The Challenge of Top-down Change and the Microsoft Layoffs," is available on Spotify, Apple, YouTube, and anywhere else you get your podcasts.
All details and links will always be available at itdependsbook.net
A Question
Please keep the questions coming! I answered two questions from listeners/readers on the most recent podcast and will answer another question in this newsletter. If you have a question, please send it to contact@itdependsbook.net. When you do, please let me know if it is ok to use your name.
This question comes from an old pal, outstanding engineering leader, and former co-worker, Jet Villegas.
Hi from Tokyo!
I just got through your latest podcast (2024/02/04) where you revisited your thoughts on Yahoo and Microsoft. Great episode! You spoke about the transition from bottom-up change and top-down change. I find myself in the midst of that shift between both. You mentioned the rivalry/competition between teams that becomes more apparent as resources become more limited. As a Director at a company (i.e, that middle area between top-down & bottom-up,) how did you deal with that?
Being caught between can be challenging.
A lot will depend on the culture of your company. When I was at Microsoft, I saw managers actively try to kill other projects so they could co-opt their resources. At Spotify, the understanding and expectation was that you would do the right thing for the team and the company. Directors or VPs would willingly move teams into different orgs when it was the right thing to do. At Adobe, it was much more collaborative than Microsoft, but not as much as Spotify.
Coming from Microsoft, I was shocked at Adobe when a peer suggested that my team take in two developers from hers because we were taking over the technology they had been building to expand its use, and it made sense for the developers to transition.
So, the first question is, what kind of company are you working for? If your team is working on a project well aligned with company priorities, do you think another team that is not might help you? Here is how you can tell: is your performance review based on hitting specific deliverables or team metrics during the year? Does your manager adapt your goals for the year based on what is going on in the company? If the answer to these questions is no, your peers are not incentivized to help you and are unlikely to offer help willingly.
If your company is more on the collaborative (vs competitive) side of the cultural spectrum, ask your peers for help when needed! Hopefully, your company is doing a good job communicating priorities, so it should be clear why other teams would help you. This collaboration is a two-way street. You should help other teams when they ask if what they are working on is a higher priority than what your team is working on. Make sure your manager (VP/CTO) is aware of what you are doing and is supportive.
You may need to work the hierarchy to get support if your company is more competitive. You can ask your peers for support, but if they refuse without a good reason, raise the issue with your manager. Do your homework to demonstrate how you can't hit your objective with your current staffing. Make a case for temporarily transferring one or more people from other teams (be specific about the people and why they are needed) or re-tasking another team to support yours temporarily. This escalation will cause some friction with your peers, but sadly, this is the system that the company has set up. Make sure you operate in as transparent and respectful a way as possible, and make sure that you recognize both the team members you borrow and their teams. If you can, offer to help them hit their goals once your team completes the project.
If you want to follow up with more specifics, I can try to go a bit deeper, but this is an excellent question that many of us have had to deal with over the years.
About this chapter
This article is one of my most popular. I wrote it at the request of the Popforms (now Ink+Volt) team for their blog and later reposted it to my site.
For many years, the Spotify model captivated the industry as a new way to organize around autonomous teams. My three years as an executive there were transformative in how I approach software development. The model was an essential part of how Spotify could innovate at scale and quickly. The model was dynamic and constantly evolving to fit the company's needs as it grew. I thought it was important to help people understand some of the core ideas so they could try to implement them within the context of their organizations.
THE SPOTIFY MODEL: HOW TO CREATE, DISSOLVE, AND REMIX TEAMS TO BE MORE DYNAMIC AND MORE INNOVATIVE
Originally published on January 6th, 2015
One of the most challenging parts of managing a traditional, hierarchical, organization is being responsive to new opportunities; especially those that require leveraging skillsets outside your own team. At Spotify, our organizational model allows us to create, dissolve, and remix teams with minimal disruption to individuals or managers. This gives us tremendous abilities to address both temporary and long-term opportunities.
How it used to be
As a manager at Microsoft and Adobe, I was always challenged when there was a problem or opportunity that required repurposing a team or adding on additional scope to an existing team.
This kind of thing comes up all the time: a business development opportunity, or integration with another product. Often, this would require small efforts from multiple specialized teams.
It would cause disruption as those teams had to change their current plans and coordinate around a new challenge while still making progress towards their existing goals. Given that people and resources were managed within the team, and managers were still responsible for delivery of their existing commitments, often it would be hard to motivate them towards supporting this new effort.
Creating a new "tiger" team is often the solution in these situations, but that isn't always an adequate solution for long-term or permanent projects since it essentially punishes the managers of the existing teams and requires finding a new temporary manager for the new team.
Another problem in existing organizations is figuring out what to do with a team whose project has been canceled.
If the team is a high-performing team you may try to turn the team onto a new problem, which may or may not be a good fit for their skills and experience. You may instead dissolve the team, assigning the members to new teams based on the needs of those teams rather than the preferences of the individuals. You may leave it up to the individuals to find new roles in the company or face layoffs if they are unsuccessful.
These solutions end up punishing both the individuals on the teams and their managers, often for reasons beyond their control. In an organization seeking to innovate (which requires some amount of failure), it sends a counter message to one of experimenting and taking chances.
How we remix teams at Spotify
At Spotify, we wanted to create an organization that allowed us to be dynamic around our staffing, and adaptable in our teams.
We embrace failure as being important to learning and innovation, so we didn't want dissolving a team to be a punishment. We put this new organizational model into effect over two years ago and have been working with it since. In that time, the technical organization has grown from 250 to over 600 people. We went from having three engineering offices to five, and from having 30 teams to over 70.
We focused on building full-stack, autonomous teams, built around a single, clear, mission. The expectation is that it will dissolve once the team's mission has been fulfilled.
To this end, new teams are constantly being created and old teams dissolving, with their members building new teams or moving into existing teams if they need additional staffing. Rather than create a formal manager role for these teams, we decided instead to make the teams collectively responsible for fulfilling their mission.
With this model, changing teams does not mean changing your manager, and dissolving a team doesn't leave a manager looking for a new role.
We do have a strong belief in the role of the manager as a mentor to their reports, so we have a strong managerial culture; it is just manifested in a matrix, rather than a hierarchical model.
Why Chapter Leads work better than traditional managers
Our technical managers are called Chapter Leads. They are usually responsible for managing a narrow range of developer disciplines within their larger organizations, for example: mobile developers, or backend developers. A Chapter Lead usually has direct reports in multiple teams in the organization.
For an individual, it is common to change teams, but it is less common to change managers. As each team is responsible for their full stack and all platforms, a team may include members from several chapters.
An example is the search team in my organization. Its members come from five different chapters: the backend chapter, the mobile chapter, the keyboard and mouse (desktop and web) chapter, the agile coach chapter, and the test chapter. Additionally, there is a product owner and a UX designer, both of whom are part of the product organization (which is organized more traditionally).
The Chapter Leads are not responsible for deliverables directly. Instead, the Chapter Leads are responsible for staffing the teams appropriately, for working with the individuals in the team to help them grow; and for working with the Product Owner and the Agile Coach to make sure that the team is performing well together.
Since the Chapter Lead has visibility into multiple teams, they can often identify short or long-term skill set needs and are empowered to resolve them.
Sometimes, this means switching two developers in two teams temporarily for a skill set need. Sometimes, this means moving a developer to a different team to address a short-term staffing need. This also means that if there is a new mission to be addressed, the chapter leads can work together to staff a new team to address that mission out of the existing teams in the organization.
A benefit of this model for an individual is that there are many opportunities for them to work on new projects or develop new skillsets since there are new projects spinning up on a regular clip.
When and how we remix and dissolve teams
This remixing is not constant throughout the technology team. We do have several very long-lived teams that are focused on features in the product, but even those teams will shift people between each other based on short or long-term needs. In some parts of the organization, specifically the infrastructure teams, they tend to be focused on short-term projects and are creating new teams more often. Those teams dissolve when they have completed their project.
We will also dissolve teams if we believe their mission is no longer necessary. Usually, this is the result of the team invalidating their mission themselves. We celebrate these conclusions just as much as the successful completion of the project since we value the lessons from a "failed" project. Celebrating your failures as valuable lessons encourages risk-taking, experimentation, and innovation.
By striving towards a model that gives the individual consistency (their manager, and their Chapter) while still offering the organization fluidity and adaptability, we've found a happy balance that lets us extend our agile-first values beyond the work that a team performs to the organization as a whole. This has allowed us to focus on innovation and leverage opportunities that slower-moving organizations would have difficulty addressing.
Several companies have attempted to adapt our model, but there is something critical to understand. Our organization model is fluid and continues to change and evolve to support its needs. The specifics of our implementation are less important than the underlying values and ideals that created it.
If you want the benefits of a dynamic organization, you will need to build something suited to your organization's values. I would argue that a central requirement is endowing teams with autonomy and decision-making authority. If you cannot support this, then you should look instead to adapt your existing model to remove impediments and bottlenecks instead.
Thanks again for reading! If you find it helpful, please share it with your friends.