This is a transcript of episode 118 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

We reach into the archives for an interview with Matthew Skelton and Manuel Pais, authors of the definitive guide to optimizing software team structures: Team Topologies.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

###Introduction Listen to this section at 00:14

Squirrel: Welcome back to Troubleshooting Agile. So Jeffrey isn’t here because this is a special edition of Troubleshooting Agile. We’ve got a recording of an interview with Manuel Pais and Matthew Skelton, authors of Team Topologies. And it’s perfectly timed because today is Wednesday, 29 April 2020 when we’re releasing this podcast is exactly when they are holding a webinar and I.T. revolution. Their publisher and our publisher is discounting the book and otherwise promoting the book. So please have a look in the show notes if you find Matthew and Manual’s ideas interesting on how to structure teams, because you’ll find there a link to their webinar and their book. So with all of that out of the way. Well, let’s go ahead and listen to the recording from last October. Back when in ancient times, you know, when we were allowed out of our houses, Jeffrey and I went to Las Vegas and interviewed Matthew and Manual. Here they are.

Squirrel: Welcome back to troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi Squirrel.

Squirrel: So we’re here in Las Vegas looking out at the beautiful Las Vegas Strip. By the way, don’t try to walk down it. Always take a car. I got lost on the way here, but I made it in time. So life is good. And we’re here at the Dev Ops Enterprise Summit Conference put on by IT Revolution Press, which is our publisher for our book, Agile Conversations. And we’re talking to a whole host of very interesting authors from IT Revolution Press. Who have we got here today, Jeffrey?

Jeffrey: We have Matthew Skelton and Manuel Pais. Is that correct?

Manuel Pais: That’s good enough.

Jeffrey: The authors of Team Topologies organising business and technology teams for fast flow. We were talking a bit before this about the kind of problems that you’ve seen. And you said one of the key phrases for me, which is one of the things I find that a huge problem everywhere, which is cargo culting. Can you tell us a bit about that story? Tell us more about cargo culting, and the kind of problems you’ve seen in that.

Manuel Pais: Sure. So, first of all, thanks for having us.

Cargo Culting Company

Listen to this section at 02:26

Manuel Pais: I was just thinking of this organisation I worked for where agile and scrum was really adopted in a way that was called called cargo culting because we’re trying to follow these ceremonies. But in fact, when you looked at the capabilities of the teams and people in the way that when you wanted to do new developments, new systems and new services, you actually still had all these dependencies on different experts. And so the teams were doing the ceremonies, but in fact, they still had all these dependencies between them and between experts. And so one of the things we talk about in our book, Team Topologies, is how can we organise teams and people in a way that they’re are more enabling to others rather than becoming a dependency based on their expertise. So we talk about enabling teams that help other teams’ capabilities. So it’s quite hard for many organisations to think about experts as enablers. They think it makes sense that you look at an expert, someone who is a specialist and think this is the person who can do this work fastest. But then if that person becomes a bottleneck for 10 other teams or 20 teams, then you’re gonna go much slower. That’s the problem that.

Jeffrey: They could get a local optimisation in the sense that this person will be the fastest right now but it doesn’t improve the organisational impact. And so this is really interesting because it sounds like you had this organisation that was doing sort of checkbox agile, you know. Do we have the stand-up? Yes, we all the ceremonies, but they weren’t connected to what’s the outcome that they want to get for being agile.

Manuel Pais: Exactly, both the outcome and in terms of gaining capabilities and understanding. If you want teams to be really autonomous and productive, it’s not just a matter of saying, well, now you’re autonomous, now you’re on your own, because that can be actually worse. It’s OK. What capabilities are you missing and how are you going to get them? And that starts with focussing on the team as a stable kind of unit. First of all. And then over time, how do I build those skills that are missing? How do I manage the dependencies between that team and other teams in a way that is sustainable, I would say is the key word.

###The Technicalities Behind Teams Listen to this section at 04:52

Jeffrey: So you can we talk a little bit more about what you mean by team. And the reason is I think that you and I would probably have different definition of teams, which is great. It’s good to have differences of opinion. I have usually very functional definition, which is for me, a team is a group, people who share a problem. So for me, it’s not about an org chart, but rather a dynamic. It sounds like in your case that you’re talking about sort of sculpting something, you’re trying to shape an organisation. is that right?

Matthew Skelton: In the book for us a ‘team’ is a very, very specific thing, which is a long lived collection of people, in a software context, no more than about nine people. And it turns out that there are some kind of embedded evolutionary social reasons for limiting the size of teams like this. And it relates to trust boundaries. And the data researcher, Robin Dunbar, a few years ago came up with this concept of Dunbar’s number, which is 50, which is roughly the number of people that you might be sort of close friends with on Facebook, because it turns out 150 is the typical maximum size of a village in England in the Doomsday Book, which is written more than a thousand years ago when a census was taken and so, you see that similar kind of numbers at different scales cropping up in lots of Human societal contexts. And it relates to trust boundaries effectively so beyond a certain size, beyond a certain set of sizes, the dynamic of trust changes. And so let’s say when you go beyond 150 people in the group, you start to see ‘us and them’ relationships. You start to see poeple referring to other people as ‘Oh they are not doing things correctly. And we’re the ones who are blocked’.

Jeffrey: Right.

Matthew Skelton: And so there are some organisations who have known about this for a long time. I mean, Roman armies have certain kind of limits on group sizes. More recently, companies like W.L. Gore, the Gore-Tex manufacturer, and yes, when one of the offices reached 150 people, they would open a separate office rather than try and grow the first office because they knew that there was this dynamic, this trust dynamic, started to breakdown.

Squirrel: I’m getting confused because you talked about nine as the other nine is different than a hundred. Help me out.

Matthew Skelton: And it seems like I mean, there’s some debate about how you go about assessing this kind of stuff. But we’re seeing that there’s a kind of onion effect, onion layering of different sort of trust boundaries. Roughly, it seems like these sort of have a x3 multiplier. So there’s one at about 500 one at about 1500 going down. But this one is about 150. It’s about x3 less than 500, if you like. And so on a down to down to five for a very close, very close trust. And why in the software industry, scrum teams or software delivery teams are slightly larger?

Matthew Skelton: I don’t think anyone’s actually answered that question convincingly. But what we do have is empirical evidence, if you like, from organisations that are doing well at software delivery, like Amazon, for example. They’ve got ‘two pizza teams’ and then the size of those teams is about is about nine. And so just kind of empirically, we’re saying that there are dynamics there, which come from human evolution. So for whatever reason, we don’t quite know yet. But in software, we see seems to be about nine, and that seems about the right kind of limit. The key thing there is there’s several key things. One, if you’ve created a team and you’ve managed to get managed to get that team to be high performing, don’t just dissolve it.

Matthew Skelton: If they’ve come to the end of the span of work that they’ve been working on give them more work. If a team is working well, but some organisations which are project based will dissolve that team because the work is finished, ignoring the fact that it’s taken an incredible amount of energy and to create a high performing team like that.

Building Trust in Teams

Listen to this section at 09:02

Manuel Pais: Just to interrupt for a second, but that’s exactly that horror story. That was exactly the problem where they were following agile ceremonies. But then people would get moved around between teams because now you have this urgent need in this other team for this expertise and that doing the whole, you know, the good part of becoming agile team and then working well together because suddenly you were reshuffling everyone based on new dependencies. And that’s where the part about building capabilities and the teams is.

Squirrel: So it’s hard to build trust with you if you’re going to disappear tomorrow.

Jeffrey: And it’s also quite interesting to me hearing you describing this, as you say, stable. You might think, well, we have eight people on our team and then we bring a new person in. Well, that’s only one person. But our experience is that every time you add or remove some from the team, you change the dynamics. It’s actually a kind of new team.

Matthew Skelton: Efectiveley becoming a new team.

Matthew Skelton: I mean, obviously, those people have worked together. Most of those people worked together, but you might well change the dynamics quite considerably. May have added a person who now acts as somebody who questions a lot.

Jeffrey: Yes.

Matthew Skelton: And that could be a good thing or a bad thing,

Jeffrey: Right.

Squirrel: It’s certainly a disruptive thing if the team hasn’t been questioning a lot.

Matthew Skelton: Exactly. Indeed. And so that would definitely change the dynamic considerably. It might be a really good thing for the team to have that disruption and that if if they trust that person is disrupting things for the good of the team. But but they might see that person as being just disruptive in a very negative way. And so you might break the team apart. So I would agree with you that many organisations have not given much thought at all to these kind of social dynamics and the cost, the huge cost potentially of destroying a high performing team by adding or removing people, there are ways to do it. So in the book we mention something called Dynamic Reteaming, which is something that Heidi Helfand mentions. She’s really thought about this, which is really interesting stuff, but it’s very contextualised it’s reteaming. It’s changing teams deliberately in order to grow the organisation, in order to embed new capabilities. And so it’s done very deliberately. It’s not just done in order to kind of manage people.

Jeffrey: Not blindly.

Manuel Pais: And also because, going back to the book, The Mythical Man-Month that talks about, if you add one person, you’re not necessarily getting more capability.

Squirrel: You are often getting less.

Manuel Pais: Yes.

Squirrel: At least in the short term.

Manuel Pais: Yes. So when you’re doing those changes. You should be intentional about them and understand, we’re going to need a period where our productivity might go down. We might have to sort out different ways of working expectations that this person has because of their background, people they’ve worked with before. And maybe in this team it’s a bit different. So we should expect a period of adaptation again. So it’s not a full new team forming, but it’s some disruption that needs to be accounted for.

When Specialists become Bottlenecks

Listen to this section at 12:00

Jeffrey: I’d like to go back to your example that you were describing. I’m curious, because I think a lot of our listeners and I’ve seen this at different companies would say, yes, we definitely have some specialists. We definitely have some people who are more expert, maybe been long sitting in the company and they know their architecture better with many different types of special knowledge. Well, what do we do then? I mean, it’s just a fact. You tell us we shouldn’t be dividing this person amongst multiple teams. But then we have teams that won’t get anything done without this deep knowledge.

Matthew Skelton: So it’s a really, really good question. I think it gets the nub of some of the dynamics that we talk about in the book. Lets say you’ve got someone who’s a specialist in that. So this is a real example from a client that we’re both working with, actually at the moment. You’ve got someone who’s a database specialist and they really understand how to manage databases, and different kinds of technonogies, but they’re currently a bottleneck by having to approve all database changes.

Matthew Skelton: What really should be happening is for this person to be involved in selecting the kind of cloud platform databases that enable the development teams to do things themselves, automate things themselves, also that person to let’s say write some documentation or some tooling to help these teams. write automated database tests, that kind of things are acting as a force multiplier across multiple teams rather than being the person blocking progress. This particular case individual is really looking forward to getting to the point where he can be that kind of force multiplier because he realises that he shouldn’t be in the flow of change.

Jeffrey: Right.

Matthew Skelton: But that has been the traditional approach to that kind of skill set. it is that they must approve all the change because we can’t embed that kind of learning in individual teams. They just doesn’t scale at all. It acts against flow. So it’s going to important for organisations hopefully people read our book will start to realise, yes, we can actually kind of turn this through 90 degrees and say, well, how can we help these individuals? What skills do these specialist need to help them enable other teams? So these specialist might actually need some additional skills around writing documentation, around interacting with teams in a way which is a kind of mentor or tutorial kind of role, they may not have much experience. And maybe they need help in doing that. But the essential areas for them to become hugely valuable, influential precisely because they are actually enabling multiple other teams to deliver more quickly and more effectively.

Jeffrey: It is an interesting example, because I think some of our listeners might have read a book like The Goal, which is the book introduced The Theory of Constraints, and it’s this manufacturing paradigm. And in there, they know they talk about how you respond, what you identify the bottleneck, what you do. But then they are not sure how to make the translation from that manufacturing model where, OK, so we have this piece of equipment, you know, that’s the bottleneck. How do I translate that into the software world? How do I elevate the bottleneck and subordinate the bottleneck? I can’t remember the three steps in there. But this is what you’re describing essentially. You’re saying is take it seriously. You’ve identified the bottleneck. It’s a necessary point of investment. And if I take that further investment, other places other than the bottleneck won’t increase throughput. Is that right?

Squirrel: But getting more developers, if they’re all going to wait on the device.

Matthew Skelton: Exactly. But we’ve got the advantage in this particular case compared to manufacturing, where in this case we can use the subject matter expertise of an expert like this, in this case, the kind DBA type person.

Matthew Skelton: It could be someone in machine learning, it could be someone in infrastructure provisioning. It could be all sorts of things. Security.

Jeffrey: Sure.

Competence vs Expertise

Listen to this section at 15:53

Matthew Skelton: These kind of things where you need deep expertise, but turning them from being from being someone who needs to execute something in a serial fashion before the software goes out the door into a subject matter expert. Who can help enable these multiple other teams to understand this stuff better and or at the same time help let’s say a platform, internal platform, build something which helps these development teams to move more quickly. So if you got some complicated security checks, don’t give it to the security specialist to do every single time. Get them to kind of expose the expertise in a way which allows a platform to build a lot of checks or builds some APIs or build some kind of a capability that enables these development teams to consume that stuff as a service effectively. And so that person has gone from being a bottleneck, into being someone who’s just opened up the possibilities for the organisation to deliver more quickly.

Manuel Pais: The other thing that’s important to mention is in the book we talk about getting fast flow of delivery and that means we want the product teams or development teams to have the necessary capabilities to a certain level of understanding of those capabilities. Doesn’t mean you have to be experts in databases or security, but they need to know enough that they can perform most of the work that they need to do 80 percent, 90 percent of the time. They won’t need to hand over that work to another team or someone else, because that’s where the wait time starts creeping in the delivery. So we’re talking about setting up those teams to have the kind of baseline capabilities around all these different skills so they can go fast. Most of the time there will be occasions where they have a dependency, where they need something so specific that I need my database expert to come in and help me.

Jeffrey: You’re making it more the exception, rather than the day-to-day.

Matthew Skelton: Exactly. Indeed. And when that exception arises, when we realise we do need to actually kind of involve someone else in order to make the particular change, that’s a signal, there’s a capability gap in, let’s say, the platform or capability gap inside our team and then actually give a signal to the organization as a whole to say, how come? Well, how do we bridge in future? How do we avoid the need for this kind of handoff in the future?

Squirrel: And is it these kinds of signals? Is that these kinds of patterns that’s within the book? I’m a mathematician by training, so I’m curious about the topology. Am I going to find lots of graphs that sort of help me understand how to set up the org chart. What am I going to find? It sounds fascinating.

“But We’re Different”

Listen to this section at 18:26

Matthew Skelton: So a key thing we talk about are four different types of team that we really think are the only kind of team types, if you like, that we need in an organization. Modern organization delivering software or software based services, not just software, kind of extends out from that level and three different ways in which teams need to interact. And we believe that- we were kind of surprised, actually, but that there were so few, do we believe. So we’ve yet to find a need for any any more team types in any more kind of interaction.

Jeffrey: This it’s quite a challenge you’re putting out to our listeners.

Matthew Skelton: Indeed, totally.

Jeffrey: Do you think if they come up with a fourth type of interaction or a fifth type of team, you’d be excited?

Matthew Skelton: Well, yeah, kind of. Because it’d be interesting to hear it. But, you know, we did the research. We’ve been out there working with lots of organisations and different kind of contexts. And we-

Jeffrey: ‘But we’re different!’ I mean, you must have heard this many times. ‘We’re different. Our problems aren’t like other people.’

Manuel Pais: I think one of the values from the book is actually having this common lexicon to talk about these things. And there will certainly be situations where actually we’re doing some mix of things and we have this different situation. But at least we can reason about it and say, well, you’re doing this type of interaction you’re facilitating or you are collaborating and doing something else to know that that’s a possibility as well. But at least we have a frame, a way to frame our thinking around these things.

Jeffrey: So we started with, sort of, this problem case of the cargo cult. So now you’ve introduced this sort of tool guide. Do you have a case where you can give a group or organization, you work with you, that they’ve then understood this lexicon and these different options and then use that to really change and get different results. For our listeners to know, like, what where are you trying to get to? What does success look like?

Matthew Skelton: So it was a really good example from the conference this morning. So Adidas, the worldwide sports shoe and sport equipment manufacturer

Jeffrey: You know, just to translate for American listeners, Adidas, Adidas for the rest of the world Adidas.

Matthew Skelton: And so Fernando Cornago and his collegue, presented just this morning on stage about their third transformation of the last few years.

Matthew Skelton: And we know that they’ve used the thinking around kind of teams topologies and some of the early thinking we actually had, that we had before the book was published. To create self-service platform for development teams to make it as easy as possible for those teams to do the right thing, to make sure that they’ve got people who are acting as enablers and so facilitating other teams to be able to work better. And that’s an explicit thing that Fernando talked about this morning. And it’s organisations like that who have really understood the kind of social dynamics at play in software delivery, who are kind of surfacing these kind of explicit, different kind of patterns of behaviour and ways of working for different teams. So the teams inside that platform work in a different way compared to the kind of customer facing teams and naturally, they should do, to an extent. And they understand that their role is to enable what the product teams are doing.

Jeffrey: Right.

Matthew Skelton: And therefore, the platform team is not just going to go out and build an all encompassing, all singing, all dancing, bells and whistles platform like companies used to do in the past.

Jeffrey: Right.

Matthew Skelton: Their remit is to make it safe and easy, for the delivery, these product team to deliver at speed. It’s a different way, perceiving what my role is you, if you like. Yes, I’m still doing a lot of activity, meetings, and monitoring, whatever. But actually, ultimately, my customer is this internal team so the way I therefore interact is is better defined than it has been in the past.

Squirrel: Fantastic. Well, if listeners have enjoyed the pattern, library, if you like, that we’ve been hearing about from Matthew and Manuel, please have a look at Team Topologies, now available, right?

Matthew Skelton: Right.

Squirrel: You can buy it. So we’ll have a link in the show notes, to a place where you can get hold of the book. Also, how would they get in touch with you most effectively? Where’s the best place to go?

Matthew Skelton: Go straight to TeamTopologies.com.

Squirrel: Excellent. Sounds good. So we’ll have a link to that as well. And thanks very much for being on the podcast. And hope it all goes well with book. We also like it when listeners subscribe to to us because Troubleshooting Agile comes out every Wednesday. We have interesting people to talk to, interesting arguments about how to improve your agile team. So please hit the subscribe button in whatever app you might wish to use. And of course, you can find us at TroubleshootingAgile.com and get in touch by email, Twitter, Carrier pigeon, whatever your favourite method is. Excellent. Well, thanks, Jeffrey.

Jeffrey: Thanks, Squirrel.

Squirrel: And thanks, Matthew and Manuel.