Matrix team models aka the “spotify model”

Join Murray Robinson and Shane Gibson in a conversation on the “Spotify Model” for scaling agile teams.

We cover the role of leadership team structures. Tribe dynamics and the importance of coaching and support during organisational change.  We share our experience with implementing this model in organisations and some of the anti-patterns. Join us to learn how to use the Spotify model to scale your agile organisation successfully.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson. 

Shane: And today, we’re going to talk about scaling,

Murray: Or the Spotify model . 

Shane: Actually, it’s not a model. It’s just a bunch of articles on how they were working at that time. So while we all refer to it as a Spotify model, they didn’t actually believe it was a model. But from now on we’ll call it the Spotify model just because we don’t have anything else. 

Murray: Yeah, also, a lot of management consultants, McKinsey, Bain, BCG, are going to clients and saying, we’ll introduce the Spotify model. They’re rolling it out everywhere. Also I have implemented a version of this at the digital agency I was at. And it actually worked extremely well. 

Shane: Yeah, when I’ve worked with a couple of customers we’ve got to that stage where the initial team are rocking it and now we want to scale the team out. So we adopted patterns from Spotify for scaling and experimented to see if they worked. And the majority of them did in the scenarios that we tried to use them. So I think they’re really valuable patterns and I’d be interested to see how you use them compared to how we used them. 

Murray: Yeah most organizations are organized in specialized functions. What I would call the factory model. Your functional manager assigns you work and then you go and do it. And they also do recruiting and training and supposedly quality assurance. But because of this, you get a lot of delays waiting for things to go from one function to another. So in the Agile model we’ve changed all that. But if you just implement Scrum, all you get is cross functional product teams and maybe scrums of scrums and everything else goes. So there’s no management, no support, no nothing. And I actually find that, a real problem because people do need support. 

The Spotify model is a type of matrix organizational structure. It’s changing the functional manager’s role from telling people what to do to one of coaching, mentoring, training, supporting and recruiting. So if you have somebody in your team who specializes in development, then there would be a senior person in the team and that person would do some coaching and mentoring to the more junior people. And then above that I’d have your engineering manager. And they are coaching, mentoring and supporting all of those most senior technical people. Spotify calls this a chapter where your engineers belong to the engineering chapter. They’re recruited by that chapter. They do training with that chapter. They do a lot of knowledge sharing, and they’d have a career path through there, but the chapter doesn’t tell them what to do because the team is self managing. I found that works great because it provided a lot of support to the teams. 

Shane: Yeah. And same thing for me. So in the data space, when we started to scale to more than one squad, we’d end up with some people that were good at data engineering, some people that were good at visualization, some people that were good at analysis. But we didn’t leverage any of the learnings across the squads in those domains, and if we had somebody who was, junior in their data engineering capability we didn’t have a way of helping them. So that’s where that idea of a chapter lead, where there was a person who was at a mastery level, an expert or a coaching level in data engineering, they would then work on ways to help the rest of the data engineers increase their skills. We ended up splitting it out the pastoral care and the increase in skills. But that was purely because the organization wasn’t open to restructuring the hierarchy to create the chapter lead. And so from what I can tell of the way Spotify described it, that pastoral care and that skills capability was one person who was the chapter lead. 

Murray: Yeah did In the digital agency I moved everybody into long lasting, cross functional, agile teams that were client focused. I took the functional managers like the software engineering manager, the business analysis manager and other people like that, and turned those people into servant leaders who didn’t tell people what to do. I asked them to have weekly half hour one on ones with people who reported to them for their discipline. And I got the most senior people working across all of the teams and they got very involved in pitching for client work, coming up with solutions , and helping the team to start that new work. So even the most senior engineering manager was expected to spend about half his time doing client work and about half his time, doing, pastoral care. It’s quite different to have somebody a few levels up still doing hands on work. And it’s also very different to have the focus change to pastoral care, because they’re so used to just telling people what to do all the time. It’s a very different role.

Shane: Yeah, I agree. And people who rock that role say things like, how are you going? And what do we need to do to help you get better at what you’re doing? They’re asking questions and then going away and making those things happen versus mandating and pointing the direction for the team to go.

Murray: The other thing they do is identify common problems across teams and bring them to the attention of people who can resolve them. Teams can get stuck with something and the senior person can say, actually, I’ve seen this over here. You’ve got the same problem, and they tried this. Let’s talk to them Or there’s this other group that’s causing everyone a lot of problems So we need to go and meet with them. 

The sell from the big management consultants is you don’t need as many managers because you have self managing teams that are organizing themselves and the role of manager changes to coaching, mentoring and support. 

Shane: One of the interesting things you said was that within the chapter there is effectively a hierarchy. I haven’t got to the stage with a customer yet where we’re having 20 or 50 cross functional teams. So maybe when you get to that level of scale you need to bring a hierarchy into the chapter lead role. But I’m not convinced that’s the right thing to do. 

Murray: So the vertical dimension of this model is the product teams. And the horizontal dimension is the functions or what they call chapters, which are just another name for functions. And they call their team squads and a group of squads is called a tribe. So a tribe might be 60 people that is all focused on some sort of common goal. Typically, it’ll be a common product that has a common market. That tribe in the Spotify model has people who lead it across multiple squads. And those people are the product owner, an Agile coach, and a technical leader. So there’s a bit of a hierarchy there and it goes up another level if you have Multiple tribes . It’s all just a matter of how many people you can look after. So we know, that a people leader really can’t provide pastoral support for more than about 10 people. 

Shane: So when we have more than nine people working together, the lines of communication are like spaghetti, and we become inefficient. And That’s why we tend to talk about scrum teams or squads being somewhere between two and nine people. 

So if we say that in each of those squads, there’s three chapters of skills. So if each of the squads have three people in each of those chapters, then a chapter lead is probably going to be able to work with and lead three to six squads.

Murray: Probably three squads because you want to allocate at least an hour per person per week. Imagine if you’re trying to do a hands on role and you’ve also got 10 sessions with people in your chapter a week. 

Shane: Yeah, so one customer I worked with the person that was leading the charge wasn’t an expert in that domain, in the data space. She was just a bloody good leader. So she ended up being pastoral care lead for 26 people, and she would spend an hour a week with each one of them. So 26 hours of her week would be talking to the people and figuring out what they needed. And then the rest of her time would be making that happen. She wasn’t the chapter lead from a skills point of view. Somebody else was the chapter lead for the engineering team 

Murray: Yeah, I prefer to have leaders who do both roles. They provide the expert kind of mentoring and the people career development path. I’ve worked for an organization that employed a HR person to go out and spend time with all of the consultants and make them feel good and hear what their complaints were and it was very low value. 

Shane: I prefer that the people with the skills focus on those skills and the people who are good at helping people focus on that. Because I’ve often seen people who are experts or coaches at skills. But they’re not the best people people. And I’ve seen some other people who are really good at being that servant leader. But they’re just not technical, But I’ll take your point that it depends on the people you have. So in my view, they’re both okay, to have dedicated pastoral care leads and skills leads or one person who’s doing both. You just got to pick a way you want to work and then experiment with it and see if it works. 

Murray: When I’m promoting technical people I look for a really good technical person, who’s also a good people person. I explain to them how to improve their coaching skills and how to do one on ones as well as listen to all of the common problems that were coming up. 

Shane: For me, there’s four steps in a person’s career. They start off as a novice, they move to a practitioner, then they become an expert and then they jump to be a coach. That jump from expert to coach is a really big jump because that’s where we jump from being the best at those skills to somebody who can teach somebody else how to be better at them. 

Murray: There are mistakes that people have made in doing this. The biggest one is that they take their existing senior manager who is a terrible coach and they make them into a chapter lead because they want to do something with them 

Shane: We tend to see that when somebody picks up a agile framework. We’re not actually changing the way we work, the way the organization behaves. We’re just shuffling the slippers under different desks of different titles and expecting something else to change, which it never does. 

Murray: So I have seen general managers become product managers for a team of a hundred people and with the right people, it actually works really well. And I’ve seen people at that level become chapter leads and become very good at it too. But, not every manager is going to be suitable for these sort of roles, because it’s quite different. A servant leadership role as a chapter lead that’s quite different. And if you’ve got a general manager who’s been spending all their time doing politics and hasn’t done any real work in their field for a long time they’re just not the right person for that role. Cause they can’t provide that coaching that people need in the chapter. 

Shane: We have to be fair to those people and the fact that we’re changing everything. We’re saying the hierarchical organization that we used to have isn’t going to happen anymore. The way you get funding, the way work gets done, the wayyou get promoted that’s all changing. And so we need to support those people. When I start working with a new team, there are often people in that team that I don’t think they’re going to really gel with this new agile way of working. And I’m often surprised that they love it, it’s the change they’ve been looking for. And sometimes other people that I think they’re going to be fine. They’re the ones that go, hey, this isn’t for me. I don’t want to work this way. We need to put things in place to support them during that change. And that’s the same with the senior people in the organization, 

Murray: This is where the coaches come in. The Agile coaches are able to provide people with support and also help the organization put the right people into the right roles in this new structure. 

Shane: Yeah, we put coaching support in place for the teams because we know the changes we’re getting them to make are large, but often we don’t put that coaching support in for the managers in the organization. We just expect them to somehow adapt without any help. So we need that coaching role, that coaching help for every part of the organization because they’re all undergoing change.

Murray: Agile is a big change and people who think it’s not are just kidding themselves. Agile and design thinking are like going on a diet and exercise program for somebody who’s unfit, unhealthy, falling behind and facing a heart attack. It can lead to massive improvements, but you’ve got to be willing to put in the work and a lot of managers don’t want to. They just want to get the badge without having to do the work. 

Shane: Helping people with the change is important, but the traditional change manager isn’t what we need for that. That’s one of the things in the spotify document. There was no role for change it was just inherent. So a chapter lead helps their squads or their chapter with that change. The tribe Leads would do the same. 

Spotify was continually experimenting and changing the roles and the structure. They would do experiments and try different things and learn from each other and they said that everything they published was just a point in time. 

But coming back to it, So we’ve got squads, groups of people that are cross functional, self organizing, single focus on delivering something. They’re into a group called a tribe, a bigger group of people focused on the same outcome. We then have a matrix going across them, which are the chapters focused around skills. 

And then the last one is the guild, which is a community of practice 

Murray: I don’t think that’s quite right. A chapter is a community of practice, but a guild is a special interest group and it comes and goes depending on what people want to do. So a special interest group crosses over chapters and tribes. You might have a special interest group for aI, or crypto or something. it’s much more informal, just getting together to discuss things and share ideas and they can come and go. They don’t have defined leaders like chapters. 

Shane: Yeah, So there’s no Guild leader, no permanent guild leaders. Somebody might say, I’m really interested in this and I’m going to create a Guild. And if lots of people come along and are interested, we’ll keep running it. But if, I turn up to the Guild showcase and I’m on my own, the Guild’s going to stop, 

Murray: I don’t particularly like all this language of squads and tribes and chapters. it’s just something they did to be different. I just like calling it teams and product teams for tribes and chapters, I call them disciplines, but you can call them whatever you like, and guilds I called special interest groups. It’s just new names for old things that’s been around long before Spotify. 

Shane: I have no problem using those terms, but I also have no problem with an organization creating their own terms, as long as they define what the boundaries are for a team versus a bigger group. 

Murray: Let’s say your organization has 5, 000 people in it. How do you divide up your organization into all of these different tribes? Because not all of them will be externally facing. You will inevitably find that quite a lot of these tribes need an internal product or service to support them. Like a cloud group, for example, that provides a platform and other common services that all the teams use. 

Now there’s a little bit of a trap here, because if you set up a lot of specialized teams, you’re just back to functional structure again, and you get blockages everywhere, so you don’t want to have too many of those. 

Shane: So from the way Shopify described it those internal tribes that support other internal tribes come about when the tribe whose receiving that service, think it has value. They said any squad can use any product they want to support themselves. So they had a bunch of squads that used JIRA, a bunch of squads that used, I don’t know, monday. com and a bunch of others that Built their own tracking systems, so they had a higher range of variability in the tools they used to manage their tasks. When new squads stood up, they would go and ask the other squads what they were using. And they’d go, oh, Jira, . And they’d start using it because it delivered what they needed. It wasn’t something worth reinventing the wheel for. And then over time they worked out that actually if they had another tribe that looked after Jira for them it made their lives better. So they opted in for that. And so that organic creation of those tribes made sense. I think there’s a real risk that people will look at that and go right, so now we need to set up the Jira squad on day one and that’s not what it’s about. It’s about where the value needs to be created. 

Murray: I agree with you. I worked for a large telco where the procurement group was incredibly influential because they were seen as a cost saving group. You had to go through them. You had to use their vendors that they selected, no matter how shitty they were. You had to go through their slow bureaucratic process, even if they just rubber stamp things 90 percent of the time. They should have been a service to the product teams, but they set themselves up as a police force and made everybody do what they said. And that’s exactly the opposite of what you want. You can’t allow one of these platform teams to become this police force that orders everybody around. 

Shane: Yeah, unless there is actually a need for that police force. In a bank risk team they have a bunch of rules, that have to be followed like anti money laundering. So I thinkwithin organizations, there are sometimes groups where they need to be the police . But it’s very rare. It’s in highly regulated organizations. But you’re right. What tends to happen is people create these little fiefdoms and get the power and do that. 

The other thing is those tribes that serve tribes sometimes need help to optimize what they’re doing. 

Murray: Well yeah, In big organizations, you might have platform teams supported by other specialized teams. This is what the team topologies people talk about. There’s the customer facing product team. Then there’s the internal product who serves the customer facing team. Then there’s a platform team and there’s a special interest team. The key idea is that if you’re a internal team, then you think of the people you’re providing a service to as your customers. And as customers, they get to decide whether they use you or not, unless you are one of those small number of mandatory regulatory teams. 

Shane: Yeah. One of the things I really liked about Spotify was they did really cool videos with cartoons. You can watch those and get the story and the context and the problems they’re trying to solve. The other thing about that was it looked simple. So when we start drawing matrices that are complex and hard to understand, we should probably look back and say, how can we make it simpler? We can create a platform tribe, great. But then we could also take that simple concept and we can make it incredibly complex and bring in the organizational hierarchies and control points and ruin it. If you can’t draw it and explain it, simply have a think about whether you really need the picture to be that complex. 

Murray: This is just a way of structuring your organization to help your product teams be more effective. This model provides you with a whole, community of practice and leadership and coaching to support you, which is going to help you be a lot more effective. 

Shane: All right. Good to catch up as always, and I’ll catch you next time.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.