Thoughts on emulating Spotify's matrix organization in other companies
नमस्ते दुनिया! ("Hello World!" in Hindi)
If you (or your kids) celebrate Halloween, I hope you had a great time. Here in Seattle, there was an absolute downpour, but it didn't stop the kids from their trick-or-treating. My kid came home totally soaked but ecstatic with their haul.
I avoid talking politics here because this newsletter is not about politics (except the corporate kind). However, if you are in the US, please make sure you are registered and VOTE! For those with US employees on their teams, this coming election week will likely stir up a lot of concern and draw a lot of attention from your teams, no matter what the outcome is, given the contentious nature of the contest. The best thing you can do as a leader is to give the individuals space and grace and ensure that the contention stays out of the work environment. Lara Hogan's blog post on Managering in Terrible Times provides practical advice.
If you are new to the newsletter, please check out the archives on Substack. Of course, you can always buy the book.
I'm a guest on the Humanizing Work podcast this week
I've listened to the Humanizing Work podcast for quite a while and was honored to be a guest. I worked with one of the hosts, Peter Green, at Adobe and have a tremendous amount of respect for him. It was great to catch up. The episode should be available on November 4th. You can get a link to the episode on their website.
About this newsletter
If you are new to this newsletter, here's what makes it unique. Every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March. These chapters are not in sequential order, but each one is a standalone piece. In addition, a podcast serializes the audiobook in order, released in the alternate weeks from this newsletter.
The Latest Podcast
The latest episode of the podcast is "Management and Systems Thinking." In this episode, I talk about how I recognized the value of systems thinking and how it relates to managing technical teams. I also give a simple way for you to visualize the systems that your team is part of. I share how understanding the system you want to enable and arranging the bottlenecks relates to Conway's Law. I spend a bit of time talking about how understanding systems is critical if you are trying to create more autonomous teams.
You can get the episode at Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you get your podcasts (see pod.link for a more extensive list).
Drop me a line
I'm always eager to hear from you. If you have questions, want a signed copy, or simply want to say 'hi!', please email me at contact@itdependsbook.net. You can also share your thoughts on Substack or the various podcast platforms. Your feedback is invaluable, and I look forward to hearing from you.
Reader Survey
As we are past the halfway point of the book, I'm starting to think about what happens with this newsletter and the podcast once the serialization of the book is complete. I also want to know what you find more or less valuable. The survey is anonymous, so you can give your honest opinion. I tried to make it short so as not to waste your time. Please take a moment to fill it out: https://forms.gle/onptUZYjtyHxvp9D6
About this week's chapter
The chapter I'm sharing this week is my most-read article. I wrote it after being at Spotify for a few months and attending a conference back in the US. The Spotify Model whitepaper had gone viral and many people I spoke to told me that they were trying to adopt the Spotify model at their company and were having many problems with it. Former colleagues would ask me to meet with them because they were considering adopting the Spotify model but didn't understand how it mapped to their current hierarchies or how specific roles worked. It became apparent that company after company was trying to adopt the model without comprehending that it wasn't just an organizational structure but an entire engineering culture.
The misunderstanding was even more evident after posts on social media and blogs attacked the model, claiming that it didn't work and that Spotify was misrepresenting things since it produced poor results at their company.
This chapter was written as a response.
While Spotify still utilizes aspects of that original model, today's organizational structure is different as the company moved from an engineering-driven company to a product-driven one. Still, I can say definitively that the model was successful at Spotify while I was there and that Spotify's speed to market and quick iteration is one of the reasons that the company was able to out-compete Google, Amazon, and Apple.
This is chapter 27 of It Depends.
Thoughts on emulating Spotify’s matrix organization in other companies
Originally published on March 14, 2014
I was in San Francisco in December (2013) for a conference. While there, I connected with a few companies inspired by Henrik Kniberg and Anders Ivarsson’s whitepaper “Scaling Agile at Spotify”, who have been trying to implement some of those ideas in their own companies.
I think Henrik’s paper does an excellent job of describing the what and how, but it seems that the “why” and some critical ideas can get lost when others read it.
If you haven’t read Henrik’s white paper, I suggest reading it before reading the rest of the chapter. I will do a quick recap here, in any case.
Spotify’s engineering and product organization (now over 600 people) is split into several large groups called Tribes. Each Tribe is responsible for a set of related features or engineering functions. For example, our largest tribe is the Infrastructure and Operations Tribe, whose name is self-explanatory. I am the Tribe Lead of the Music Player Tribe. We handle importing audio from our label and distribution partners, storing and streaming the music, search, collection and playlists, artist pages, music metadata, and the music knowledge graph that supports things like the above, but also ads, discovery, radio, and the like.
While the whole company works on the same product, Spotify, each tribe is set up to work as independently as possible. As you will see below, a critical aspect of our organizational model is to give autonomy at every level. This autonomy helps remove decision-making bottlenecks and unnecessary dependencies, which improves velocity.
Each tribe is composed of squads. A squad is a team responsible for a single feature or component. For instance, among the teams, one is dedicated to handling searches while another manages the AB test infrastructure, among other specialized squads. We set up each tribe and squad to function as autonomously as possible. In the context of a feature development team, each must be full-stack. A full-stack team is responsible for both backend implementation as well as user interface implementation on all platforms.
A typical feature squad would have web service engineers, iOS, Android, web, and desktop engineers, as well as testers, an agile coach, a product owner, and a UX designer. With this staffing, the squad has everything they need to implement anything related to their feature. They don’t have to wait for another team to implement the necessary pieces. They also have autonomy and local decision-making ability, so there are few impediments to their speed of execution.
To this point, with Tribes and Squads described only, Spotify may seem like a traditional, hierarchical engineering organization, but this is where the similarity ends. Unlike a traditional organization, a squad does not have a single engineering leader whom everyone on the team reports to. In fact, there is not a single leader for the squad. The Product Owner and UX Designer collectively work with the engineers and testers to make decisions about their features.
Spotify is not a “no manager” culture, however. We strongly feel that managers have a role in supporting the people who work for them. Managers are essential as technical and career mentors and organizational communication conduits. Rather than have management hierarchies follow organizational ones (creating a de facto command-and-control structure), we instead have first-level managers responsible for technical functional areas across multiple squads.
We call these reporting and functional groupings “chapters.” Again, as an example, reporting to me, the tribe lead, are Chapter Leads. In my tribe, there are currently three backend (services) development chapters, two front-end development chapters (including all the UI developers), a core library chapter, and a test chapter. These seven Chapters span eight different squads. Almost every chapter lead has reports in two squads, and a few have direct reports in three. Nearly all chapter leads work within a team in some capacity as well, either as a developer or technical lead, and not necessarily within a squad with members of their chapter.
This chapter/squad matrix organization is critical to our organizational agility. It allows the squads and the tribe to be more fluid. We can spin up a new squad to take advantage of an opportunity or handle an issue without worrying about changing reporting structures. If a squad completes its goals and no longer has a reason to exist, we can dissolve it without punishing a manager. This variance is a significant difference to a traditional hierarchy because it gives us much flexibility and helps us avoid the old political issues around empire-building and resource contention.
In addition to our Tribes, Squads, and Chapters, we also have virtual organizations called Guilds. Guilds are cross-tribe organizations centered on different technical or interest areas, and their membership is voluntary. The guilds serve as ways to promote cross-tribe collaboration and communication, especially around things like best practices. For instance, we have guilds dedicated to a range of areas, including Web Development, Agile Practices, Leadership, and Test Automation, among others. The guilds foster developer-to-developer communication, which is one of the ways that we keep all these autonomous teams from going in entirely different directions.
From Henrik’s paper, this diagram illustrates the organizational structure I discuss above:
Figure 23 - Spotify Model Matrix Organization
Henrik Kniberg/Anders Ivarsson
I want to give some more background about why we have implemented this organizational model at Spotify, elaborate on our goals for implementing it, and discuss the aspects of our culture that have been critical to its success. It is remarkable that the way we work inspires other companies. Still, if you implement only parts of the model or try to impose it on a very different corporate culture, you will have difficulty achieving the same level of success that we have had.
If you are considering using the Spotify organizational model within your company, there are a few things that will be critical to your success:
Our organizational model assumes that engineering uses agile methodologies. Our goals for autonomy mean that we do not prescribe any particular development framework that our squads must subscribe to. However, all of the teams use agile development methodologies. While we do our best to minimize dependencies between squads and tribes, there will always be some since we are all working on the same product. Any individual squad choosing to build using a traditional waterfall or another non-agile process would be unable to keep up with the rapidly changing teams around them. If they tried to impose some sort of process on other groups so that they could follow a longer-term development plan, they would start slowing down the rest of the organization.
A critical requirement in making our organization model work well is that the entire company works with and understands agile practices and processes. For example, while our legal team isn’t doing scrum or kanban, they work with engineering teams that use agile methods. Having the entire corporation understand and agree with Agile means that no line of business area impedes the speed of implementation. Think of this in terms of Amdahl’s law applied to a development organization. Suppose your development teams work quickly in parallel, but marketing or legal does not support an agile approach. In that case, they will become a bottleneck that will slow down the overall speed of the company.
Similarly, implementing this with just one team as a test in a larger engineering organization will be prone to issues. Traditional engineering organizations usually don't set themselves up for autonomy. Adding a single autonomous team within that web of dependencies will likely hamper and frustrate that team and skew the experiment’s results.
While I’ve mentioned autonomy in several places, I cannot understate its criticality. We must empower each squad to make their own decisions, encompassing features, the development model, infrastructure, and implementation. Every decision requiring outside approval means a delay that slows development. Each dictated implementation or infrastructure decision means a technology that doesn’t fit the way the team works or something new to learn before the team can build. This autonomy is a challenge to coordination, but it isn’t as bad as it might seem in practice. Best practices and technologies spread from team to team through avenues like guilds. Teams adopt these practices and technologies on their schedule or pioneer new ways of working if it makes it easier for them to deliver value to our customers and then spread their learnings to the other teams.
Attempting to layer the tribe and squads model over a traditional reporting hierarchy would be very problematic. While we have many long-lived squads at Spotify, we are constantly creating and disbanding squads as new needs arise or the teams fulfill their missions. Squad membership will also ebb and flow as required by the needs of a squad’s mission. Traditional hierarchical organizations are self-perpetuating, and restructuring them is very disruptive to the management chains and the individual team members. You would gain some of the benefits of the Spotify model by building full-stack teams in a traditional organizational hierarchy, but you would lose many of the overall speed benefits that we leverage with our matrix organization.
In conclusion, if Spotify’s organizational model inspires you and you desire to improve the speed of your product development, there are a few things that you need to understand. Our model works because it is layered on top of our corporate culture. Our culture values autonomy, agile processes, democratic teams, and servant leadership, amongst other things. You can certainly take some of the ideas from how we work and apply them in your organization, but you may not get the same returns without the cultural underpinnings.
Reader Survey (Again)
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores