Episode 2: Squads, Scrums and Spotify

Host: We’re speaking to Henrik Kniberg, a developer and organizational consultant. With experience at Lego, Spotify, and Minecraft, he’s going to walk us through what a squad framework looks like, how we can apply it to any organization, and how leaders can help their employees adapt to more autonomous and agile ways of working. Stay with us.

Host: Hi, Henrik. Thank you so much for making the time to join us today. 

Henrik Kniberg: Hey, it’s good to be here. 

Host: I would love for us to hear a little bit about you, who you are, how you sort of started your journey. I know you started off as an engineer but got into organization management. And I’m just really curious what that journey looked like and what made you make that switch.

Henrik Kniberg: Oh, wow. That’s a deep topic. [00:02:00]

Host: You know, something easy, something light!

Henrik Kniberg: I’ve made several switches along the way, but I guess the first switch was I studied computer science. And then I kind of got yanked out by a friend and stumbled into a startup. This was in the nineties. During that time, it was the dot com boom, and their IT companies starting all over the place. So I got dragged into that in a classic kind of startup setting. And I was the tech guy doing all the coding, but then the company grew. So suddenly I was, you know, I needed to change focus and not be the guy writing the code, but being the guy hiring the people to write the code and then, you know, leading them and giving them the environment they needed.

And I was new at it and didn’t know what the hell I was doing, which I think is how most leaders start their journey. You stumbled into it and then you don’t really know what you’re doing. But anyway, when doing that, when organizing my own teams and building my own team, then. I wanted it to work, and I had been a consultant for a few years, a contractor being, you know, hired by typically large companies.[00:03:00] 

I just saw so many big projects just fail like badly. And I was a little bit cynical about like, okay, is this really the way it’s supposed to work? Like waterfall kind of projects, long cycles, and then kind of disasters at the end. So I knew exactly how not to build software. And now I was building up my own company, and I wanted to not suck at building products. So I was like, there must be a better way than what I’ve seen. And that’s how I sort of stumbled into the thing that later on came to be known as Agile. And it just worked so much better. Plus, it was more fun. We got, you know, we actually delivered products. Of course, we had our share of failures sometimes.

But, even the failures tended to be rather small and not these big disasters, right? In that sense. Later on, I ended up more companies that were actually doing really well. And I’m still not sure why I was there. But companies like Spotify, companies like Lego or Mojang, and, uh, again, learned so much, especially from Spotify, because that company was a, you know, real, like, fast-growing startup. And it was really fun to kind of be part of that journey. [00:04:00]

Host: That’s amazing. And you mentioned Spotify, so I do want us to talk a little bit about the nitty gritty of the Squad framework. And you did touch upon its benefits, but I would like to hear more on your take on why it’s so groundbreaking. 

Henrik Kniberg: Yeah, it’s a bit fascinating. I can’t say I have a really clear answer. It’s the same thing if you ask the Agile manifesto authors, why did Agile become so popular? A lot of them are like, we’re not really sure. Maybe it was the right timing or the right messaging. But what I think happened there was Spotify, like a lot of companies work the way they work because that’s how everyone else works. And there are all these kind of standard structures, standard assumptions about how organizations should work, about hierarchical structures and reporting lines and, you know, just things people do because that’s the way they think you’re supposed to do things. Spotify was an interesting company because the culture from the get-go was very much, we’re not going to just follow the default, we’re going to think. [00:05:00] 

And experiment and find a way that works for us. So this is a very kind of exploratory culture. And as part of that, as a result of that, they ended up with like a very interesting culture and kind of process that was, you know, perfectly optimized for that company at that time. 

Host: Of course. And can you talk to me a little bit on what does a typical squad look like in a company like Spotify?

Henrik Kniberg: Squad is just a word that, you know, that we kind of made up at Spotify for some reason. I think we wanted to use different words than what people are used to. Because if we say this is a team, a team can mean anything, right? Some people call the whole company a team. So there are all these, or the word department, what’s a department? So there’s all these words that could mean almost anything. So we decided to put our own words, use our own words that people don’t normally use. So squad, tribes, chapters, and then that forces people to say, wait a sec. What’s a squad? And that’s good because then we have to define it, right? But what it really was, squad is, was really just this, the Spotify word for a Scrum team that might not necessarily use Scrum. [00:06:00]

So because a Scrum team is a small cross-functional group of people that, you know, have some kind of mission that they iterate on. And that’s exactly what a squad is too. However, we wanted to decouple it from Scrum because we didn’t want to force all teams to use Scrum because Scrum is one flavor of Agile, but it’s not the only way of working in an agile way.

Host: Could you give us a final definition of Scrum?

Henrik Kniberg: So I think of Scrum as a way of working. Yeah. And it’s rooted in complex adaptive systems theory, which basically means stuff is complex and unpredictable and we don’t know exactly what’s going to happen. Therefore we can’t rely on big detailed plans. So any situation where there’s uncertainty and complexity, that’s where Scrum fits. And the process framework itself is based on creating small cross-functional teams that deliver a product in small increments in tight collaboration with the customer. 

Host: Amazing. I think that really sort of boils it down, and okay, at this point you’ve mentioned quite a few times terms such as tribes, chapter, I know you also have terms like servant, leaders, and guilds… [00:07:00] 

Which, to be honest, sounds a little closer to science fiction, something you find in a book or the Witcher. I would like to better understand what they are, what was their significance for the company structure, productivity, and employee satisfaction at Spotify when they were first introduced. 

Henrik Kniberg: So I guess tracing back a little bit, initially It was just a startup, you know, people sitting in an office doing, doing their thing. And if you’re a small enough team, you don’t need much structure at all. Just get the work done. Right. But as you grow, you need some structure. And that’s when, when I came into play, and we started doing, you know, Scrum basically. And at some point later on, the CTO at the time had the foresight to realize that when we start to get a lot of squads, because the company was growing very quickly, that’s going to become a coordination problem. [00:08:00]

So we needed some kind of a structure, like we needed to be able to group multiple related squads together into some, some larger structure, some kind of team of teams. And we need a name for that. So we decided to call it Tribe. And that came sort of from the Dunbar number. It’s kind of, it’s this research on like, how many people can get to know each other in a group before it starts fragmenting. And it seems that depending on the culture, depending on the situation, that’s somewhere around 150 people or so, plus or minus, right? And after that number, let’s say 150, then people start forming clusters that they don’t know each other anymore. I’ve never seen you before. I don’t know who you are, so I don’t feel, I don’t bond with you kind of thing. So we wanted to, the idea with tribes was they shouldn’t be bigger than that. And a lot of other companies have a similar thing where, you know, you want to have a number of people that work together on something where they can share a mission and share a culture. But if you, but you can’t have a thousand people doing that because they, they just won’t feel any, any, any connection. [00:09:00] 

So that was kind of where that deal with from tribes was that as we start getting dozens or even hundreds of squads. We should group them together into tribes that have a shared mission. So, for example, one tribe was working on infrastructure and operations kind of thing. So internally facing things, other, other tribes would working on listener-facing features, people listening, you know, using the product as a listener or maybe content creators. So a number of squads that share a common mission and also a common, like a shared management. So a tribe would have a tribe lead and things like that. So that’s just where tribes came from, but it was created as a way to handle scaling. 

Host: And you did talk about leadership and how it sort of started from the CTO. I want to touch on that a little bit and sort of talk about Agile product development, because a big part of the squad framework is also how it’s going to help with productivity overall. And you’ve mentioned in the past that taking on too much work is like shoving more paper into a printer just to make it print faster. [00:10:00] 

Henrik Kniberg: That’s when you get it wrong. Yes. 

Host: Yes. So, can you talk about the product backlog and how can leaders stay on top of it in order to keep their teams motivated and productive?

Henrik Kniberg: Yeah, and this is beyond Spotify. It’s like the general question, right? For many companies as they grow. And I think a really important principle that we had at Spotify and that a lot of other companies that worked at apply is this notion of autonomy, like autonomous teams or squads, whatever you choose to call it, right? And what that means is I like to use the metaphor of getting across the river. An autonomous team, you don’t tell it to build a bridge. Instead, you explain why it’s important for us to cross the river. And then you let them figure it out. And maybe they decide to build a bridge. Maybe they decide to build a tunnel. [00:11:00] 

Maybe they start questioning why we even need to get across the river, right? Or whatever, right? You unleash their creativity by giving them an inspiring goal. So, for example, at Spotify. At some point, like the leaders there were pretty good at this. This was part of the culture. So at some point, Daniel Ek, the CEO, gathered everybody in a town hall and told everybody when we were still quite small, said; Hey, everybody, we just built this amazing product with a music player. And you know, you can play it music. You just type the name of any song and it’ll play that song and you can share it with others. You can save it. It’s great. However, about half of all of our potential listeners in the world don’t know what they want to listen to. They want like a radio kind of thing. I’m going to go driving. I don’t want to stop and type the name of a song. I just want to say, give me music right now. Maybe, you know, give me some jazz or something, right? So our product is useless for that. He said at the time. And that’s the problem we need to fix so we can reach those users. But I don’t know what the best solution is. That’s why we hired you smart people. So go figure it out. I think a good example of, of autonomy and also trust, I guess, in a sense. We’re trusting the team to figure it out instead of giving them a task. You implement recommendations. You implement that. You implement this. It’s super powerful, but it takes some courage on the part of the leaders. [00:12:00] 

It takes some humility because you got to realize that maybe the teams will pick a different solution that you might have picked as a leader. And it also requires some organizational structure. Like you need a feedback loop. The team needs some way of evaluating. Are we on the right track? Are we succeeding? Things like that.

Host: And talking on sort of monitoring your progress, is there also a way to sort of monitor your success? In regards to how the company is actually doing, not just the company, but also in regards to your goal, the product. 

Henrik Kniberg: Yeah, it’s super important. And I think that’s kind of the key question organizations should be asking themselves all the time is; what does winning look like? How do we know if we’re succeeding and then make that data available to the teams? Some organizations have that in some departments somewhere, a finance department or some other, you know, department that is doing the math and following up like. Or maybe customer service, getting feedback from customers. [00:13:00] 

So often the data is there somewhere, but we got to make it visible and super visible. Everyone involved, especially the people building the product. So that’s also another place where I think Spotify, I think it was one of their success factors because most teams I saw had dashboards. They had like this big screen which showed data and then their mission was tied to data. So they could look at, like, how is our stuff affecting users? So let’s say I’m on a team working on playlists. If I make a change, and then I can ship that and then see how is that, how are people using playlists now? Are they using it more? Are they using it less? Are they sharing stuff more? Are they sharing it less? And then they can make adjustments. So that way you kind of get away from this hippo thing, the highest paid person in the room or whatever, that term, you know, principle where the loudest person gets to decide, you know, what we’re doing. Instead, it’s like, no, the team decides and we have data here, which gives us feedback. [00:14:00] 

So that, so that way we can make better decisions, faster decisions. Plus it’s also motivating. It’s kind of fun as a team to feel like, Hey, we can see how we’re doing, right? It’s like playing a game of soccer and I can see where the ball is and I can see where the goal is. 

Host: No, that’s amazing to be able to see exactly what effect every move you make has on your actual results. And it also sounds like it’s a way to safeguard the culture in a way when you don’t have that, that one person, the loudest person. 

Henrik Kniberg: Yeah. It has an indirect effect. They’re pretty powerful. Like when there’s enough transparency at all levels, then that almost automatically makes the company more rational, more data-driven, because it’s harder to just make stuff up because the screen is right up there, right? It’s showing stuff. And it’s hard to just ignore it. 

Host: Amazing. Perfect. And I’ve heard you mention terms like yesterday’s weather and Kanban principles as methods that can help leaders and their teams work in more agile ways without getting overwhelmed. Cause that’s also another big thing. It’s great to be able to see, you know, what effect your everyday work has, but how do you manage it all? [00:15:00] 

Henrik Kniberg: I think you mentioned Kanban there. And I think, I mean, that’s another one of the kind of Agile frameworks, you could say, and the key principle there is limit work in progress. And I think that’s kind of magical if applied at all levels. And what that means in practice… I mean, there’s different words for it, right? Some teams use the term yesterday’s weather, but what it really just means is the team pulls work when they have capacity. So there may be a to-do list somewhere, but there’s nobody committing on behalf of the team saying you need to finish these 18 things by next, you know, by next month. It’s more like. Here’s a potential list of stuff we could be doing, and it’s infinite. There’s always more stuff we could be doing. So we just list the top, you know, whatever, 20 or something. But it’s, we pay attention to priorities, like what’s the most important. And that’s where things like product owners or product managers come into play to make sure that those priorities are good. [00:16:00]

But then the idea is that the team pulls work based on capacity. So when they’re, you know, busy, when they feel like we’re, we’re about as productive as we can be right now, if we pull in more work, we’ll just be multitasking. So then they don’t pull in more work. They finish what they’re doing first, then they pull in more work again. And tools like WIP limits in Kanban, it’s just a tool to help. So it’s typically a, like, it’s a, it’s in a sense a crutch. It’s useful in the beginning, but more mature teams don’t need it. Typically a number you put on the board. So we have this board, and then we have a list of notes showing who’s working on what, and a big fat number on top, which says five or something. And then if there’s more notes than five, then that’s going to be like an alert where the team’s going to go, wait a sec, we’re doing too much stuff. Let’s not pull in any more work till we get this number down. Again, it’s a useful technique, but then another way, another approach is yesterday’s weather, which is if you work more like sprints and Scrum or you have like a cadence, let’s say a weekly cadence. [00:17:00] 

So every Monday you decide what work are we gonna do this week? Then yesterday’s weather basically just means let’s look at how much we finished last week and the week before and, and you know, quantify that somehow, and then use that number as a basis for how much we should pull in this week. So it’s really, really simple techniques. But they’re surprisingly effective. 

Host: And you talked about, you know, prioritizing being able to sort of self-monitor. That also comes to play a lot with autonomy. So what would you say are the major benefits of having that kind of autonomy within teams or tribes? And on the flip side, are there any potential consequences people should be concerned about?

Henrik Kniberg: So on the benefit side, better products is a very clear benefit because you’re using people’s capacity, creativity, and talent more when they can make decisions on their own. So better products, more innovation, and higher speed in some cases, dramatically higher speed because the team can make decisions without having to wait for someone else. [00:18:00] 

That means that the leaders in the company are less bogged down managing teams, and then they can actually lead more. And in terms of downsides or risks, well, there needs to be an acceptance from the team that they need to be willing to take that responsibility. So they can’t just sit there and wait for someone else to tell them what to do. They can’t just hope someone else is going to make the decision. If something needs to happen, they need to make it happen. They need to take initiative. So there’s some coaching needed sometimes for teams to kind of realize that, Oh, wait a sec. Okay. So we really are responsible.

Host: But again, like having that sense of responsibility also makes you treat the product and the work you’re doing with more care, you take it more personally. You want to see it succeed and grow and change.

Henrik Kniberg: If a system crashes, let’s say the playlist system crashes. We don’t need to tell the team that they need to fix it.  [00:19:00]

They’re going to be right on top of it because it’s their baby, right? 

Host: Exactly. Exactly. I really hope the playlist function doesn’t crash because I use it all the time. 

Henrik Kniberg: That’s also another thing though, now that you mentioned that, you need some architecture and some infrastructure because when you have this level of autonomy, teams won’t be allowed to make mistakes. Because if they’re not allowed to make mistakes, they’ll be scared, and there will be no innovation, and they’ll move very slow. So you need to build an architecture that’s resilient. So if the playlist team screws up, then first of all, that shouldn’t break the whole product. And ideally, it shouldn’t break playlists for all players either. So typically, when they’re going to roll out something that they don’t feel certain about, they’ll of course test it themselves, first of all, but, but then when they do ship it, they’ll ship it to just maybe 1% of all users. And then, if it breaks, it will affect only those users and only for a short period of time and not the whole product.

Host: That’s amazing because you really get that live feedback. You get to test out what you’re doing to people who already love the product, who are going to give it a second chance without, you know, risking major fallbacks of all sorts. [00:20:00] 

Henrik Kniberg: And you also get this kind of like cultural, almost like working agreements between the users and the developers. Like it was the same with Minecraft. Like we, we made mistakes, we made bugs sometimes, but our community has grown to learn that when there is a problem, it’s usually fixed fairly quickly. So, same with Spotify. So sure, the plate is broke this morning, but you know, it’ll be fixed by this afternoon probably or within an hour. So no worries, right? 

Host: Can you, very briefly, cause you talked about the architecture and how important it is. How can we actually go about building the architecture that can support these kind of approaches?

Henrik Kniberg: I think a big part of it is there needs to be an understanding at all levels through the company that we’re going to invest time in architecture.

And this is where Agile sometimes gets misunderstood because sometimes it looks like, Oh, there’s no architecture in Agile. The architecture just happens magically in the background. But no, you need to pay attention. You need to spend time on it. But that’s what allowed us to move quickly. So there needs to be kind of a long-term thinking on the part of the leaders, where they accept that we’d spent time building infrastructure. [00:21:00] 

As long as it’s not Big Bang though, it’s not like we should spend two years building the perfect architecture and then we build a product. It’s more like we build a little increments of the product, improve the architecture, build more increments of the product, stop, take a step back, think a little more long-term. Then iterate some more. So it’s kind of like continuous. 

Host: That’s absolutely amazing. So to my understanding, there’s a low level of standardization within a company as a result of high levels of autonomy. How can we make sure that our teams are using the best tools or opting for the best practices overall?

Henrik Kniberg: I’m actually glad you brought that up because this touches upon one of the potential disadvantages of autonomy. Okay. Or which is, you know, fragmentation and duplication where every team uses their own tool, makes up their own solutions, and you get the same wheels being reinvented all over the place, right? [00:22:00] 

So you need to deliberately counterbalance that potential disadvantage by, or counteract that by creating communities across teams, for example, to talk about those kinds of things. Where, you know, if, my team is about to implement a web interface for our service, If we know what other teams are using, then we’re more likely to use the same tools. Because then we can save time. But if I don’t know what the other teams are using, I might just pick something that’s different from what they’re using. And then, we suddenly have eight different web frameworks in the same company. Which is a waste and also cause it just doesn’t look nice for the users either.

So there needs to be cross-communication and also some level of standardization, although kind of need to keep it minimal. But for example, I would definitely like at Spotify, we were a bit late to realize that. So we had autonomy, we benefited a lot from it. But for a while, we had two different version control systems, essentially, because teams couldn’t agree on which one to use. [00:23:00] 

And that’s just stupid. So when we finally solved that, we’re like, listen, we should have done this. You know, a long time ago, just pick once. It doesn’t even matter if it’s the best solution, but it’s a solution that we all agree on, and then we can move on. 

Host: Rather than just arguing “What’s better?”

Henrik Kniberg: Yeah. So I like solution A, you like solution B, but we both want us to use the same solution. So just roll the dice or something, pick one and then move on. So identifying a core level of minimum standardization. But really keep it minimal because I’ve seen some companies that aren’t used to this way working when they start moving towards a squad-like approach, they over standardize and they each team has to use the same structure of boards, the same meeting format, the same templates and then they just slow everything down.

Host: Now you mentioned something really important and I’m just really curious because you talked about the ability to communicate across teams. [00:24:00]

And Spotify is a major company with multiple squads, so how do you keep everyone updated with what they’re using, what I’m using, and how that might also change through the course of developing a new product?

Henrik Kniberg: That’s actually super challenging. I don’t know how they work now because it’s been a while since I’ve been there, but at the time, that’s why we introduced this concept of guilds. So that the whole idea was that a chapter is a competency area, for example, back-end development or testing, which cuts across multiple squads. But then a guild is essentially the same thing but at the next level. So, for example, coaching guild or AI guild, right? Just anyone working in an area or interested in an area could join the guild. So it’s really a very quite loose community concept. But then we would organize get togethers like on conferences or other community meetups. [00:25:00] 

And quite informal, but it was still super valuable because during those beat-ups, that’s when people would find out what are other people doing? What are they learning, sharing knowledge? And then as a side effect, we would get kind of defacto standardization or ad hoc standardization where people say. Hey! You’re using that thing. So I’ll use that too, because you already have it all set up already. 

Host: Perfect. And would you say there are any specific cases that you’ve come across where squads might not actually be effective? 

Henrik Kniberg: So what’s interesting is like, I’ve seen a lot of companies, surprisingly many companies just take this framework and apply it, although it wasn’t even intended to be a framework. It was just an example of how one company worked at the time, right? But and I followed up with some of them, and some of them have reached out to me and I’ve visited a few of them. And the pattern I’m seeing is some companies saw major improvements. I’m not sure if it was because of the model itself or just because our model inspired them to change. [00:26:00] 

And then that was the trigger. Maybe they would have changed anyway, I don’t know. But in some cases, I’ve seen like radical improvement, and it’s really inspiring. In some cases, I’ve seen very small improvement. Small incremental improvement. And in some cases, nothing happened. They just renamed stuff. So, hey, our teams are called squads now. But nothing else changed. And they just feel a little cooler. And that’s it. Also, no damage done, really. So I’ve actually, so far, never seen a situation where a company got in trouble because of this, where things got worse. So I think, in that sense, it’s pretty safe. And I think the reason maybe is because… When companies apply a framework, they tend to change it. And some people scoff at that and say, Ha ha, you misunderstood the Spotify model. Look, you’re doing it wrong. I say the opposite. I say, if you apply a model for another company, you do it by the book exactly how they do it; you’re probably doing it wrong because you’re not adapting to your context. So they take the model and the parts that don’t work, they stop doing. It’s just kind of human nature.[00:27:00]

If they don’t like having chapters or guilds, they’ll stop it. And that’s not because the model failed. It’s because they’re doing the right thing and adapting it to their needs. So that’s why I haven’t seen any big failures because I haven’t seen any company dumb enough to keep doing it if it’s not working.

Host: Fair enough.

Henrik Kniberg: I’m not sure there are cases. I just haven’t seen it. 

Host: Absolutely fair. And that sort of leads me into my next question, which was about any tips, any advice you would have for organizations when they’re about to switch the squad framework. So I guess your major tip would be, make sure to tailor it to you and your organization.

Henrik Kniberg: Yeah, don’t let anyone tell you you’re doing it wrong. But I guess another thing is, I think you could compare this to Lean and Agile in the sense that, let’s say Lean, for example. Lean was just the Western word for the Toyota production system, right? It’s from Toyota, a car company, right? What happened when Lean became really popular was people started trying to copy Toyota and do exactly what they did. [00:28:00] 

And I think this is kind of similar to what happened with the Spotify model. It’s one company, and their approach started getting popular, and people tried to copy it. But the companies that really do well though, they’re the ones who don’t copy their practices, they copy their principles. Okay. So they get, let’s say the notion of autonomous squads that can make decisions on their own. That doesn’t mean you have to have guilds or that you have to do this or that. So I would say, look at the model, get inspired by it, shamelessly copy-paste. I mean, that’s what we did at Spotify too. There’s no reason to reinvent the wheel, right? Copy-paste the parts that you get inspired by, but try to distinguish between practices and principles. So when you see that Spotify did this in that way, there could be a different way of achieving the same principle. So you don’t have to have to follow the exact same approach. And most importantly, whatever you do, then keep experimenting, right? Keep tweaking it. 

Host: Amazing. And just one final question. In one sentence, how can we keep it simple if we want to bring squads to our organizations? 

Henrik Kniberg: In one sentence. I would say «minimum viable bureaucracy». 

Host: Thank you so much. That is the perfect way to close the squad framework episode. 

Henrik Kniberg: Great. Enjoyed the talk.

Host: Want to train your people on Agile, Kanban, and Scrum principles, but creating courses from scratch just isn’t your thing? Well, it doesn’t have to be when you’ve got Talent Library, the growing collection of ready-made courses available on TalentLMS. You can skip course creation and get right into training today.

Thanks for tuning in. In the next episode, we’ll be speaking with gamification and microlearning expert, Karl Kapp.[00:30:00] 

You can find Keep It Simple on all podcast platforms. Be sure to subscribe so you don’t miss an episode. This episode of Keep It Simple was brought to you by TalentLMS, the training platform built for success and designed with simplicity in mind.

For further resources on today’s topic, visit talentlms.com/podcast