#0012 - Matrix team models aka the "spotify model"

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we discuss 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 organizational change. We share our experience with implementing this model in organizations and some of the anti patterns. Join us to learn how to use the Spotify model to scale your agile organization successfully.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And today we're going to talk about.

Scaling or the Spotify model.

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.

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.

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 be interested to see how you use them compared to how we use them.

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. You're 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 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 worked great because it provided a lot of support to the teams.

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.

Yeah, 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 turn 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 my 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 cause they're so used to just telling people what to do all the time. It's a very different role.

Yeah, I agree. And people who rock that role say things like, how 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.

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.

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.

So the vertical dimension of this model is the product teams and the horizontal dimension is the functions, or what they call chapters, which is 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. So 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.

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's probably gonna be able to will work with and lead three to six squads.

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

Yeah. So one customer I worked with, the person that worked with was leading the charge. She 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 need 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.

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.

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 their 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 gotta pick a way you wanna work and then experiment with it and see if it works.

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 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 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.

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

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 or different titles and expecting something else to change, which it never does.

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. The 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 because they can't provide that coaching that people need in the chapter.

We have to be fair to those people in 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 way you 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.

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.

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 at every part of the organization because they're all undergoing changes.

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.

Helping people with the change is important, but traditional change manager isn't what we need for that. As 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.

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.

Yeah, so there's no guild leader, no permanent guild leaders. Somebody may 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.

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 called 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.

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.

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 blockages everywhere. So you don't want to have too many of those.

So from the way Shopify described it, those internal tribes that support other internal tribes come about when the tribe is 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 high 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, Jerry. And they'd start using it because delivered what they needed 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, 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.

I agree with you. I worked for a large telco where the procurement group was incredibly influential because they were seen as cost saving group. You had to go through them, you had to use their vendors that they'd selected. No matter how shitty they were. You had to go through their slow bureaucratic process. Even if they just rubber stamped things, 90% 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, the opposite of what you want. You can't allow one of these platform teams to become this police force that Orders, everybody around.

Yeah, Unless there is actually a need for that police force in a bank. Risk teams, they have a bunch of rules that have to be followed, like anti money laundering. So I think within 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.

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.

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 matrixes 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.

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.

All right, good to catch up as always. And I'll catch you next time.

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.