Spotify’s failed #SquadGoals

Abi: Jeremiah, thanks so much for sitting down with me today and taking the time to come on the show. Really excited to chat.

Jeremiah: Thank you so much for having me.

What the Spotify model is

Abi: Well, I’m really excited for today’s discussion because we’re talking about org design. Org design is something that has such a big impact on developer experience and developer productivity, and it’s really something that we get asked a lot about from leaders and that we think more leaders should be thinking about in terms of ways of optimizing the efficiency and productivity of their organizations.

I know you have so much insight and personal experience with this, particularly with the Spotify Squad model. And so I’d love to just dive into that. To start off with, for those who are not familiar with it, can you give a quick primer on what the Spotify Squad model is?

Jeremiah: Sure. So in 2012, Spotify published this blog post in a video about its way of working, and that became known as the Spotify model, even though Spotify didn’t call it that. It’s basically two ideas. The first is stream aligned teams, and the second is matrix management. And then they threw in some weird word choices just for fun. So Spotify had teams that it called squads, and a group of teams were organized into a department that it called a tribe. And then a business unit was called a mission. And each team was intended to be this autonomous mini startup. So it had a product manager acting as a mini CEO for an entire feature area.

These teams had all of the designers and software engineers with a range of specializations that they needed to deliver a feature. The idea is that they should have no dependencies or not have to rely on any other team and just focus on shipping that feature, go be successful.

So that’s not really a new idea. It’s what we would call a full stack team, multidisciplinary teams or agile feature teams back in the 2000 ops, or we might call it a stream aligned team today. But the other major element of the Spotify model was matrix management, and this is a much less common one. So instead of engineering managers, there were chapter leads. So these chapter leads would manage just a specific type of software engineer across a department. For example, you might have all of the software engineers who are working on backend engineers across all the teams within a department. They’d have one manager. And then all of the Android mobile engineers in the department would have a different manager. And so even though that API engineer and that Android mobile engineer worked on the same team, they would have two different managers. The intent for this was to allow engineers to basically move between teams within a department to best meet the business requirements without them having to change managers. It was well-intentioned, but I think had some drawbacks.

Jeremiah’s impression of the Spotify model as he joined the company

Abi: For sure. And we’ll get into some of those challenges and drawbacks later. But I remember when that article first came up from Spotify, it did seem very new to me. I remember, like you said, the concept of having these highly autonomous and flexible feature teams, that was very intuitive and really inspiring and positive. I remember the piece about decoupling management structure from the functional work being done was more interesting, and I think snowballed into a lot of different approaches in the industry today, which we’ll talk more about.

When you first learned about the Spotify Squad model, when exactly was that and what was your personal impression of it when you heard about it?

Jeremiah: Sure. I first learned about the Spotify model when I worked at Fitbit a few years earlier. At that time, Fitbit had been growing itself. I joined when the company was around 150 people and in just a few years, it had grown to around 700 people. And then it had a bad situation. For a variety of reasons that I can’t get into, it unexpectedly had to launch three hardware products simultaneously, and that nearly killed the company in terms of just burning out the entire company in order to do those three simultaneous launches.

So the leaders at Fitbit knew that they had to do something differently, and the Spotify model was one of those ideas that they discussed. So that was the first thing. And I think the idea that really resonated with Fitbit and its leaders at the time was really its first exposure to the stream aligned feature teams because our teams were organized primarily around discipline at that time.

Abi: That makes sense. So around that same time, I know you started looking into joining Spotify and then interviewed at Spotify. Maybe share a little bit more about that experience. I’m curious, were you partly attracted to Spotify because of the Squad model that had been published? I remember you mentioned you had learned some things about it throughout the interview process itself, so I’d love to learn more about that.

Jeremiah: So I actually left Fitbit because my husband got a job at Spotify and we moved to Sweden from San Francisco. So that was the original movement there. And then they were going for a two for one deal. I also interviewed at Spotify as well after I moved to Stockholm. But you’re right, I actually was interested in working at Spotify myself because I had heard good things and it was a great product. It had a great reputation and I tend to be attracted to companies that make products that I think are cool.

So in the interview process, it was a part of the interview where I was going to get to talk with other engineers on the teams that I’d be working with. And I was like, “Oh, I’m really excited. I can’t wait to talk to people to hear more about how the Spotify model actually works in some detail.” And the recruiter, she was like, “About that, I think you’ll find that we work quite differently than what you might have read on our blog.” And that only intrigued me more. So I did end up asking engineers in the interview process and they all confirmed that, “Yeah, we use those weird words more than the ideas,” and that collaboration across the company was still one of the most difficult challenges that they faced as engineers inside of the company. Yeah.

Spotify’s progress in adopting the model as Jeremiah joined

Abi: That’s really interesting. As far as what they were actually doing, what was it then? In what ways was it aligned with the Spotify Squad model and what ways did you find it was different?

Jeremiah: Oh wow. Okay. So at that time, Spotify had more than doubled the size of the company within a year. And so they were going through this hyper-growth phase, and there was just a lot of everything going on. One of my favorite questions to ask when interviewing at a company is, “Tell me how something goes from idea to value delivery to a customer.” And every person I asked that question to, gave me a completely different answer. And I think that’s just really indicative of the strong autonomy culture inside of Spotify. So I’d say as far as things in the model, the thing that was most reflected in reality was just this extraordinary amount of autonomy that each team had. So that was true. And then of course, the unusual word choices they did call things squads and tribes. I still don’t understand that one, but that was true.

They had started to realize that the matrix management wasn’t working, and so they were starting to move to having chapter leads… They still kept the name, really be focused on a single team in managing all of those engineers within the team. It would actually be quite a challenge internally to get those renamed as engineering managers. That had started to shift when I was there. And then there was still so much, I guess, bottom up movement. Everything had to basically be done from the individual team level and build up. And teams got these very high level directions from above with the system that they called the bets system. So these are basically, here are the top priorities for the company. Some things would get some extra focus and staffing and whatnot, but there wasn’t much happening there in, there’s a growing middle section of the company to really drive alignment inside of the company.

Challenges with matrix management

Abi: That sounds like almost the middle layer of the management structure was too loose, not enough alignment from top to bottom. So it’s interesting you mentioned that it seemed to be there was growing recognition across the company that there were some challenges with the Squad model. You’ve also, of course, written this article about your personal observations. You touched on that already, but you mentioned that matrix management solved the wrong problem and there were challenges with it. So can you elaborate on that a bit further?

Jeremiah: So matrix management makes this assumption that you’re going to have these self-organizing teams and that they’re going to be constantly reorganizing. Well, I just don’t think that’s true for most companies in the way that they work. And that certainly was not true at Spotify, at least at the time that I joined it. You had long-lived teams that were basically consistently delivering with fairly long roadmaps within a particular area. So there was some movement happening within teams, but it’s more about shedding responsibilities or being able to focus on things as you got more staff than it was about the whole team reorganizing. So that’s just basically this one assumption.

The other aspect of this is what you just mentioned about that middle. It’s like, well, what should the role of managers be inside of this organization? And I think there was some general skepticism of the value of management in general, and that may have been okay when the company was smaller, but as you get bigger, I think management is important. Maybe it’s just me now working primarily as an engineering manager. But we need, those chapter leads or engineering managers, we need them to be more than career coaches and we need them to be more than servant leaders with no delivery responsibilities. I think that’s actually dismissive of the value of managers. Managers, I think, should be responsible for the performance of a team, not just the individuals on the team and not just the careers of those individuals on the team. Also, most of the problems that we tend to see within engineering teams are rarely technology problems. Those are people problems. And it’s really hard to solve people problems if you’re not actively involved on a day-to-day basis with all of the members on the team.

So I think there might be some situation in which matrix management can work, but it certainly was not working for Spotify when I joined, and I just haven’t really seen that situation in my own career arise where it would work well for an organization.

The role of the engineering manager

Abi: Yeah, really interesting points. I want to follow up on this last point first, which is around the fact that what’s the actual role of a manager and can they be effective if they’re not actually integrated into the work a team is doing.

In your opinion, is it an anti-pattern to have engineering managers who are only people managers and not involved in work? Because that something I think I’ve seen adopted in organizations even that aren’t trying to be prescribed to the Squad model. It seems to be a trend that was maybe born out of the Squad model that I’ve seen across the industry. So what are your thoughts on that?

Jeremiah: I don’t think there’s one right answer for what a manager should or should not do. But I would go back to why do we have managers? What is the value that they are bringing to a particular team and to the organization? My perspective is that a manager should be the one that is accountable and therefore, responsible for the delivery of the team. And in order to have quality delivery on a team, you need to have someone who understands the needs to accomplish the work, who understands the competencies of the people on that team and where those gaps are and where the growth opportunities are, and where you might need to change staffing in order to fill in those gaps. And I just think that would be very difficult to do if you don’t have some level of understanding of the details of the work that has to get done and the career paths of the people who are going to be doing that work.

What the model was designed to solve

Abi: I’d agree with you on that, and it’s something I think you see that disconnect arise in the same way that you observed at Spotify, in lots of organizations that do decouple those responsibilities.

Earlier you talked about how one of the things that is inherent to the Spotify Squad model is this concept that teams can constantly change and reform and restructure. And in fact, in a lot of organizations I’ve seen that implement the Spotify Squad model, that becomes a part of the way they work. For example, I know of one organization that every quarter, reforms their squads based upon the projects for that quarter. I know your experiences that teams are often long lived, and that’s been my experience as well. But at Spotify, was this designed to support the way that teams are already working or did teams start reforming more often because of the Squad model? I guess I’m asking, was this designed to solve for the way that organization was already working at Spotify or was this a little disconnected in your view?

Jeremiah: This one is difficult for me to answer because I wasn’t there at the time when the document was written. But something that I did notice at Spotify is that, up until recently, Spotify solved basically every problem that it had by hiring more people. It’s one of these companies that is in this luxurious position where it can continually hire more people to solve particular problems.

So the reorganization that I observed when I was at Spotify tended to be like the company is growing and with more people, that allows us to have teams that are increasingly more focused on particular areas. And so that’s why the shuffling of people on teams was happening, not necessarily because there was someone being, “Reshuffle yourselves,” every quarter or something like that.

Good autonomy versus toxic autonomy

Abi: Right. There’s just a lot of growth and natural reformation as a result. That makes sense. I want to move on to another point you bring up in your article, which is this fixation on team autonomy. I can guess as to where that leads, but would love to hear more from you on what the problem is with that?

Jeremiah: Okay, so before I ever criticize autonomy, I want to say autonomy is good. Autonomy is a requirement for individual happiness in general. You want to be in control of your life, in control of your destinies. And I think that there are a lot of companies that suffer from too little autonomy on the individual contributor and the team level. So autonomy in the Spotify model, I think is very much influenced by Swedish society. It’s an aggressively egalitarian society, and I think hierarchies in general are treated with suspicion. And again, given all the inequality and inequity in the world, it’s probably a really great starting point. But it is a spectrum of things and autonomy is something that needs to be balanced out. So in general, my feeling is you have autonomy, which is, am I able to use the best of my ability is to solve this problem? And am I respected and consulted in the making of a decision that affects me? That’s good autonomy.

But you can also have toxic autonomy on this other end of the spectrum, which is like, I don’t take direction and my needs are more important than the team’s needs, or my team’s needs are more important than the organization needs, and I don’t want to collaborate with you and no one’s making me. So that’s the other spectrum of that. Well, this is a business. It’s not a commune. We do have to have some structure and we do need to value collaboration in our collective progress over individual or team progress. And I think trying to find that right balance is a difficult thing to do and it’s one of the biggest challenges that I witnessed when I worked at Spotify.

Abi: That’s really funny. I formerly worked at GitHub, which didn’t have Swedish roots, but funny enough, the history of GitHub, it also went through a multi-year period during its rapid growth where the development organization was against the idea of having managers. There’s been a lot written about this era, but it took many years thereafter to fix that problem and bring in a management layer. To be honest, it’s something the organization is still adapting to and struggling with today. So it’s really interesting to hear about the backstory at Spotify.

Jeremiah: Yeah. I also witnessed this within Stripe. I think autonomy, again, it’s a really good thing, but it’s also possible to have too much of a good thing. And especially as you grow, you do have to start thinking about how you balance autonomy with alignment and accountability. And both of those things get more difficult as an organization scales.

How Agile coaches were used at Spotify

Abi: Absolutely. One other thing I want to go to from your article, you talked about teams facing challenges with collaborating, and you also talked about the role of Agile coaches at Spotify. So I’d love for you to elaborate more on how did the matrix structure affect team’s ability to collaborate successfully? And for people who aren’t as familiar with Agile coaches, how did Spotify use Agile coaches to try to help bridge that gap or alleviate some of the challenges?

Jeremiah: Sure. Again, before I start criticizing Agile or Agile coaches, or critiquing it anyway, I want to say in general, I believe that Agile is the best guiding principle for creating software that we have. It’s a set of principles that I believe in and I think help make great organizations, but there’s a lot to learn there. And I believe that collaboration is specifically a skill in structuring work and problem solving within software. Those are also skills. And they’re not necessarily things that you get in a university setting. They’re primarily things that you infer from working with people or being in a particular environment.

So Spotify, like a lot of places I’ve been in, had a bunch of people who didn’t have a basic understanding of those Agile practices, and yet they were so autonomous that they also had the responsibility of figuring out. So Spotify had a whole bunch of Agile coaches who would basically float between teams to swoop in and see how the team was doing and try to identify some problems and suggest some things that you might try to do differently to basically find better ways of working. Not bad in concept, but I think this is one of those things where you need a longer engagement to effectively do that.

In this case, the Agile coaches didn’t have any… They weren’t effectively, were not responsible for anything because they were just floating across the organization. So they weren’t dedicated to making sure that the team’s delivery practices were actually creating positive results for the team, for the company.

So you need to educate people and you need to have some system in place for teaching people and giving them the knowledge and the vocabulary to understand how these practices can be applied and how to use them and how to evaluate if they’re being effective or not. But what you don’t want to do is just keep throwing ideas at teams where they’re like every few weeks or month or whatever, they’re just iterating, “Well, that idea didn’t work, so let me try this other Agile idea.” That that just doesn’t work.

Advice for teams who are struggling to implement the Spotify model

Abi: Yeah. Reinventing the wheel and also probably trying to train developers on Agile process things that they’re not maybe that interested in or passionate about, sounds like it could be a challenge as well.

We’ve covered so many aspects of how the Squad model runs into challenges and also how Spotify itself was facing challenges with the Squad model. Some of the takeaways so far, at least for me, have been the importance of having managers be responsible for delivery, not just people. And also tempering the balance between autonomy and standardization across an organization in terms of teams. So many organizations out there have gone ahead and adopted the Squad model based on the blueprint that Spotify published, and many other leaders are constantly asking whether they should. So I guess for these organizations out there, especially those that have already implemented it and it’s maybe not going great, what would be your advice on what they should do?

Jeremiah: So the premise is if a company has adopted the Spotify Squad model, it’s not going well. This is not an unusual thing, I think. I’ve spoken to several companies that say like, “Oh yeah, we adopted the Spotify model.” And I always ask, “Well, how’s it working out for you? And tell me about how you did it.” And the reality is there’s not much there there inside of the Spotify model. There are just not enough details to effectively replicate it to many organizations. So every implementation I’ve heard of has been slightly different, but I do tend to hear people having the same problems when they try to do it.

So if you’re a company and you’ve adopted the Spotify model and it’s not going well, first of all, I want to say good job on your willingness to try something new and for the self-awareness to evaluate that things are not going as well as you’d like because there are so many organizations that can’t do either of those things well.

But I’m going to ask you to compile a list of the problems that you’re observing and to interview people throughout the organization to try to deeply understand those problems and the causes before you make any more organization changes. And I am going to recommend that you read Team Topologies by Matthew Skelton and Manuel Pais. And if you’re really bought into the idea of matrix management, I’m going to challenge you and I’m probably going to recommend some other books on management to think about that one a bit more.

But I want you to try to figure out the types of work that need to be done in your company and then try to find the right team structures to get that work done. But before you implement any more changes, you need to be talking to your best performing individual contributors about that plan and get their feedback on that. Because what I’ve seen a lot of companies, there are these invisible support structures and processes within organizations that work really well, and it’s usually the things that are not being prescribed to people, but they’re basically the channels in which work actually gets done well. And as a manager, you want to find those. You want to make those visible and hopefully reinforce them with an organization structure and some new practices that you might introduce and just do a bit more research before you start making any more organization changes.

Advice for leaders who are starting to think about org design

Abi: Well, I think that’s great advice for leaders who are already living within the Squad model in their organizations. What about leaders who are just beginning to ask that question of what’s the best way to organize and design our org? For them, would your answer be to go read Team Topologies, and then more thoughts on how to approach that matrix management structure based on your own experiences?

Jeremiah: Sure. Yeah. I think Teams Topologies is a fantastic book because it basically outlines four different types of teams that you’re going to see in any company that is producing software. You can basically use any organization structure with fewer than 150 people, you have this Dunbar’s number, as a company starts to grow. Then you have to start being a bit more methodical about how you start to do alignment and accountability and autonomy inside of an organization. But anything below 150, it’s probably going to work.

So it is a scale and a growth problem. But Team Topology basically gives you a little bit of a blueprint for the types of teams for the different types of work that happen inside of an organization and the number of each type of team that you’re going to need changes as a business grows. If you’re a really small company, you probably don’t need a whole bunch of enabling and platform style teams, but as your company grows, you need to start building up human infrastructure, and basically these are teams that are supporting other teams inside of a company.

And so it’s good to understand what your growth trajectory might look like so you can start to plan for the types of skills and the type of people infrastructure that you’re going to need to put in place in the future. And the other thing is, again, if you want to learn more about Scrum, the other book that I constantly recommend is Essential Scrum by Kenneth Rubin. He actually did all of the training on a quarterly basis at Fitbit for teaching people how to do Scrum. He’s a really great educator. In his book, lays out the ideas in ways that I think are very, they’re focused on delivery in a way that engineers can really buy into.

Abi: Thanks to that book recommendation. Was that the underpinning of the Agile philosophy at Spotify as well or was there a different set of books and people that Spotify was more designing around?

Jeremiah: Spotify had more Agile coaches than any company I have ever witnessed, and they were all rightfully really educated and up on the latest research and thinking as well. So there was a lot of stuff going on inside of Spotify, including several people who actually run consultancies and have written books and stuff on those now.

How Stripe approached org structure

Abi: I’d love to switch topics and talk about your experience at Stripe, which I know you recently left there. Stripe is an organization that a lot of people look up to in terms of their, at least from the outside in, their development acumen and thought leadership in terms of just where the industry is headed. So naturally I think a lot of listeners will be interested in knowing how does Stripe structure an organized team? So we would love to hear what your observation was on that while working there.

Jeremiah: I’m going to caveat this way. Stripe has an extraordinarily restrictive policy for what its employees are allowed to say publicly. So even though I don’t work there anymore, I still want to respect them in that regard. I will say that Stripe does have a more traditional organization structure. You’ll see a lot of the four types of teams subscribed in Team Topologies inside of Stripe, but it also went through a hyper-growth stage. During the pandemic, it more than doubled in size and even though it had this really great strong culture and some really good practices internally that really supported remote and asynchronous work even before they needed to do it because of the pandemic, scale will always present new challenges. And so the biggest thing that Stripe was figuring out was still how do you do alignment now that you’re more than 6,000 people? How do you do effective decision making? These are common problems inside of any organization and it’s really just trying to understand, again, how do you balance autonomy with alignment and accountability?

Abi: One of the benefits of the Squad model, one of the challenges as well, is that teams can change very quickly without having to change management structures. So I’m curious, under Stripe, I imagine there are many long lived teams, but in cases where teams did need to change, would that typically involve a manager change as well or would it follow the Squad model where the project teams would change without changing the underlying management structure?

Jeremiah: So I have to say, I was reorged three times within a year working at Stripe and every one was justifiable. They were shifting priorities and I generally agreed with the need to do so. So it’s really hard for me to say what the norm was in that situation. I would say Stripe understood the value of team cohesion and did as much as possible to try to keep effective teams continuing to work together even if the scope of the work changed. And managers play a critical role in that team cohesion. So again, as much as possible, you want to keep managers with the team and I thought Stripe did a very good job at that.

How org structure affects a platform team’s work

Abi: That’s good to know. At Stripe, I know you ran a platform team, and of course most of our listeners of this podcast are leaders of platform teams or DevX teams or developer productivity teams. In your experience, having worked at all these different types of organizations and then being a platform leader, how does the way that an organization is organized in terms of its team structures either benefit or create challenges for the work you do as a platform leader?

Jeremiah: This is one of those things where, when you’re on a platform team, I think the biggest challenge that every company I’ve worked at has basically been getting priority in all of basically your internal customer teams backlogs. So as a platform, you’re providing some particular capability that a bunch of other teams depend on, and you do as much as possible to not create work for those teams, but you’re going to be in some situation where you’re going to need to do a migration or you’re going to need to do an upgrade and you’re going to have to push work back to those internal customer teams.

But in those situations, you almost never have authority to prioritize that work for those customer teams. And so you have to find a way of being to influence that prioritization. And this is where I think product management techniques are really helpful. You need to basically be able to explain the business value of doing the work that you’re asking and you’re trying to connect a company goal to the work that you’re asking teams to do. And in some cases, you might get some top-down help to bump up the priority of things in the backlog, but you really need to understand what are the key business value things that we’re driving for, how are we measuring the effectiveness of this. Yeah, so I think in general that’s like the biggest challenge just managing any sort of platform team.

‍Abi: And I imagine that challenge looks a little bit different if your boss is the same boss of those feature teams that you’re trying to convince. So I’m curious, that probably makes the job easier, but in cases where you’re working with teams that are in completely different chain of commands within the organization, that must be a lot harder. Right?

Jeremiah: It absolutely is. But if there is value in doing the work, you should be able to communicate the value of that and then you should be able to compare the value of that work versus the other work that also needs to get done. If you go looking for work, there’s always work to be done. But we have to be able to, I think is one of the big things about management, is you have to be able to connect the work that you’re doing to the business value that you are creating. And it might be related to more revenue, it might be related to reducing costs, it might be related to reducing risk for the business in some way. So I think it’s extremely important that managers are able to connect work to the business value and then that should give you at least the basic tooling to understand why this work should be done versus other work that’s in a backlog. And then a good organization is going to have ways for you to be able to escalate if it’s necessary.

Tracking engineering org structures

Abi: Speaking of connecting work and connecting the dots between teams and initiatives, one of the challenges I see brought up a lot is actually tracking org structures, particularly when they are somewhat matrix and decoupled from management hierarchy. I think almost all companies have an HR system that tracks who reports to whom, but seems very few companies have some sort of up-to-date system that’s capturing what the teams are and what they’re maybe colloquially called within the organization. So I’m curious, at Spotify and at Stripe, did you guys have any novel solutions to the tracking problem around teams?

Jeremiah: Yes, actually. This is a really great question. I’m glad you asked about this. So Spotify was an early adopter of Facebook Workplace, lovingly named Workface. I thought it was a very good tool for showing the true nature of a team because it was very easy for people to reflect reality in that tool. So I used it probably more than any other tool internally just to try to find out who is actually working with who. And then there’s another problem that Stripe had to solve. It built its own tool for this. Stripe has a phenomenal, can we say intranet anymore? I don’t know, an internal portal, something like that. Basically it was a tool specifically basically for this and I loved it. I haven’t actually seen anything similar like that.

Abi: And one question I have is how did Stripe keep this information up to date? I’ve talked to lots of organizations that have built internal tooling to capture this information, but the problem always seems to be, well, when do you actually update it? And typically they say, “Oh, we sometimes update it before an all hands or a company presentation.” Did Stripe have any sort of mechanism for making sure this was kept up to date? Was someone in charge of it or was it a bit ad hoc?

Jeremiah: Yeah, so there’s basically two separate systems. There’s one, the official HR system, which only people in HR can make those changes. And some of those changes then do get automatically reflected in other internal tooling. But each manager was responsible for, you could edit your team and then if you needed to go a higher level up to do something, you could move people to different places. But it was a fairly distributed thing in that regard. At least for keeping track of who is on which particular team. And then we used a completely separate process for team access controls and things like that. That actually for compliance reasons needed to be much more documented. So there was a process for doing that and then tracking those changes.

Why the squad model became so popular

Abi: That makes sense. Really interesting. Want to take a step back now and talk about the phenomenon, which was the Squad model, in terms of how it just really caught fire and spread across the industry. Seems like cargo culting is common pattern in our industry in general. We can look at things like microservices or the numerous new JavaScript frameworks that are constantly coming out and being adopted. So Squad model is similar to these in that Spotify published this article and you fast forward several years and so many organizations are jumping on the bandwagon and adopting it. So I’d love to just have a conversation about this. Why do you think the Squad model became so popular after it was announced?

Jeremiah: I have a lot of theories on this. I think for starters, I think Spotify is one of the coolest companies in human history. So I think people are just naturally curious and drawn to anything it talks about. It’s also a widely successful tech company and that success brings people who are interested in wanting to know more about what might possibly help make that company successful.

But I also think that there’s a lot of companies, especially in more established industries, that are undergoing digital transformation and they feel threatened and they’re looking for quick fixes. The Spotify model is almost unintentionally a great misinformation campaign. It’s deceivingly simple and it says things that people want to believe are true, like autonomy is important. So when it starts to then prescribe the other things, they feel like they must also be good ideas. Everything you read about it is super compelling and you really want to believe there is a simple, correct solution to very complex nuanced problems. So I think that’s part of the allure.

Abi: Yeah, I would largely agree with that. It does seem like every time a Google or a Spotify or Netflix comes out with some new way they’re approaching technology or management… For example, Netflix Culture Doc, that was something that really caught fire as well. I think engineering is still such a new discipline in the context of human history. And so when something new comes out from someone who’s been very successful, I think naturally a lot of people pay attention to it. And to your point, those tools that are published by the big companies aren’t always things that should be adopted wholly by every organization out there, but maybe just more studied to see what bits and pieces of those frameworks or approaches can be integrated into what they’re already doing.

Jeremiah: Absolutely. I think there are multiple biases at play because we assume that what those companies do must be the reason that they are successful businesses, but unfortunately, most businesses are not differentiated in the marketplace because of their tech stack or their team structure or their culture doc. Those are just rarely competitive advantages for a business. And I think that can be hard for engineers who get excited about technology or Agile coaches who get excited about org structures and practices to understand. So it’s fine to be excited about those things, but you all just also have to balance that by understanding that those are rarely areas of innovation that will differentiate a business.

What the original authors may have felt about the popularity of the model

Abi: It’s really interesting you included some quotes in your article from the co-authors of the Spotify model. I’ll just read little bits of them out loud. One of the authors wrote, “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation.” And another author wrote, “It worries me when people look at what we do and think it’s a framework they can just copy and implement.” I’d love to know, do you know more about the original authors feelings and thoughts on what has transpired with the Squad model?

Jeremiah: Yeah. I do quote multiple other people who worked at Spotify and worked at Spotify at the time when these docs came out, Andesh Sheveson, he’s actually somebody that I worked very closely with at Spotify. So I was actually really excited to get to meet him after I joined and to talk about some of the thinking behind the original white paper and how it evolved and played out. And then the other Agile coaches, I think both of them came after that, but have both worked at the company for quite a while. All three of them have given multiple conference talks and podcast interviews and other things, trying to explain reality to people. Like, “It’s great that you want to be Agile, it’s great that you recognize these particular problems, but this was really something about documenting Spotify’s thinking at a specific point in time in its history.” It was working a bit more in the open when it did that, and then it got really busy changing the music streaming business and it didn’t really tell people about how it was continuing to evolve and what things actually worked.

It actually came as a great surprise to Andesh when he was going to a conference and people were like, “We’re using the Spotify model.” And he was like, “Oh, you are?” And they’re like, “Yeah, we just rolled it out to thousands of people who were even bigger than Spotify at the time.” I think it just had much greater reach than, at least, Andesh ever imagined. And even today, I think the only people who are still really promoting the idea are people who are now running consultancies that are tied to the positive sentiment to it. But I think a lot of the other people who continue to work at Spotify have tried to be more truthful about how things evolved and what things continue to not work. And that self-reflection is really great. Unfortunately, the truth is harder to spread than an idea people really want to believe in, and that’s part of the challenge.

‍Abi: Well, I think this is a pattern that’s repeated itself many times in the history of software development industry and will continue to repeat itself. So at the very least, it’s really great to be able to get the ground truth, perspective, and history in this conversation from you today. Jeremiah, thanks so much for coming on the show. I think this is going to be so valuable to leaders and listeners out there who are wrestling with the problem of org design. Really appreciated this conversation. Thanks again.

Jeremiah: Thank you so much for inviting me to be able to set the record straight and hopefully encourage people to keep studying organization design. There are no simple answers. These are questions that are worthy of looking at the past, seeing what works, and then hopefully finding something that works better for you.

Abi: Thanks so much, Jeremiah.

‍