Team Topologies

Matthew: [00:00:00] Have we exceeded our team cognitive load for the system that we’re working on? And if we have, uh, let’s do something about it.

Jessica: Good morning, it’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Jessica Kerr. The other day, I read the book Team Topologies about how to organize sets of teams for continual flow of value. Today, I’m thrilled to talk with the authors of Team Topologies, Matthew Skelton and Manuel Pais. Welcome to the show.

Manuel: Hi, Jessica. Thanks for having us.

Matthew: Hi, it’s great to be here.

Jessica: Hi. This book has a super DevOps background, right?

Manuel: Yes. It actually started with the DevOps topologies that a lot of people have referenced, which was a blog post by Matthew years ago, and then turned into a catalog.

Matthew: [00:01:05] Back in 2013, I actually wrote a blog post on my personal blog. I wrote it in a rage because at the time, I was like, I was so frustrated with what was happening at the place I was working at the time. There was people on the kind of the dev side of the organization basically and a separate group on the kind of ops side. And it was, they’re finding it very difficult to work out how to work together. And there seemed very little interest in trying to work out an effective way of working. And so I kind of, basically in a rage, I kind of wrote this blog post and came up with a kind of these Venn diagrams with different kinds of overlapping responsibilities or different ways of visualizing how the responsibility of teams. Because at the time, what I had in my head was, come on, let’s just find a way of working. Like, any one of these ways could work really well, but we’re in a bad place where we haven’t got a good way of working at all. And so I kind of wanted to characterize some different ways of working in the kind of IT space in a DevOps context. And then did a few talks and things, and then with Manuel’s help, we kind of expanded it into something a bit more polished on the website at devopstopologies.com.

Manuel: [00:02:23] For me, so I joined the party a little bit later in 2015 when I met Matthew. And for me, it was mostly about everyone talking about DevOps team, and I’m like, what the hell are you calling a DevOps team? And so having that resource was like, okay, here, kind of let’s go one step further and actually think about which other teams do you have. And, you know, DevOps is not about creating a new team called DevOps, so have a look at, you know, what makes sense for your organization and I think that the page, the DevOps topology, says there’s no one, one single right topology, but there are many that are kind of, um, damaging depending on what you’re trying to achieve. Um, so for me, that, that was the key thing about the DevOps topologies, just clarifying what, what types of teams do you have and, you know, what is a DevOps team actually.

Matthew: And so So this website, DevOps Topologies, it became quite well known. There’s quite a lot of organizations around the world that have used it, sometimes acknowledging the source and sometimes not. So sometimes we would see these diagrams and they’re quite clearly our diagrams and people have just lifted them and not kind of acknowledged it, which, you know, I suppose that’s kind of flattery in a way. But anyway, the whole lot is Creative Commons. So it’s free for people to use and send pull requests and all that kind of stuff. Because it seems to really help lots of organisations to kind of think through what they’re doing, how they’re kind of operating their organisation, if you like. So we had, the patterns have been used, those original patterns have been used at Netflix. So Philip Fisher-Ogden, who’s the Director of Engineering at Netflix, he tweeted out a couple of years ago, he tweeted out, you know, thanks for your insightful articulations of DevOps topologies, they inspired many discussions and helped us to think about what model Netflix teams could be using. So that was kind of cool to see, that, you know, an organization like Netflix has found them useful to help them kind of think through how they want to run their teams and so on. And there’s quite lots of other organizations, Condé Nast, the big international publisher, also use them as well. And Crystal Hershon, who’s Director of Engineering, talks about the balanced arguments, looking at the different perspectives between kind of ops teams and dev teams and thinking, looking at this from— looking at this problem, if you like, or this space from multiple perspectives at the same time, rather than just trying to optimize for kind of a dev-centric view or an ops-centric view. So that’s all great. And then we started using these patterns with our kind of consulting and training and things with different organizations around the world. We did some research for a major technology company based in China, And that kind of expanded our thinking. And we did more and more kind of like consulting work and training and investigation with different kinds of contexts to try and validate the pattern or to try and invalidate the patterns, basically. We were looking for ways in which the patterns were kind of wrong somehow, like we do when we’re trying to prove something out. And so we added a few more and we kind of tweaked the wording a little bit in some of the cases. But after a while, we kind of realized that The original kind of DevOps topologies patterns were only really a starting point, because they were very static. They only showed like a point in time, and they showed a kind of big picture pattern that actually wasn’t very realistic across an organization of any interesting size. Because an organization of any interesting size, you have multiple different kinds of interactions happening, multiple different kinds of teams, and kind of setups and things. So, we needed to kind of, we realized we needed to that there was a lot more information that was actually important when thinking about how organisations operate.

Manuel: [00:06:19] Part of that is understanding how the relationships between teams and interactions are also dynamic. So, what we were seeing with some clients was that, okay, if this is defined as a static thing, like imagine you have traditional dev and ops teams, and if we say, well, you always need to collaborate for any delivery, and, you know, you’re always expected to be doing things together. That actually sometimes is useful, sometimes it’s not useful, because if there’s a lot of discovery to do, we don’t really know how we’re going to deploy this thing, or it’s a new platform, yes, you know, definitely collaborate and make sure you get feedback as soon as possible. But if it’s something that’s kind of stable, then why do you always have to depend on another team to just do your work, just deploy, or just monitor, whatever it might be. And so that’s what we were seeing with clients, like, okay, this, this is a good type of interaction for this particular problem or need, but later on it might not be the case. So that’s where the DevOps topologies were kind of too static. And then we started thinking about how is this kind of more dynamic in a way that allows the organization to, and the teams to actually sort out by themselves how we need to evolve to achieve whatever we’re trying to achieve.

Jessica: [00:07:45] Yeah, I love the emphasis in the book on not just what are the good patterns, but how do you know which pattern applies, and how do you know when it doesn’t anymore?

Manuel: Yeah.

Matthew: And then this is a really crucial aspect of it that we realized we needed to include, which is, it’s not just, yeah, it’s not just a set of patterns or templates, it’s We wanted to provide a kind of organizational capability for detecting when things have changed and have gone wrong, and then allowing the organization to move on and adapt itself, because that’s ultimately a much more important capability for an organization to be able to adapt in the face of different circumstances than just, oh, we’ve got the right pattern now. That was a kind of a key lightbulb moment, or a key realization for us was, that a lot of these organizations that were having problems were— these organizations were often looking for the perfect kind of team structure, but that doesn’t exist. We need to set ourselves up to change and to detect when our team structure is wrong.

Manuel: [00:08:50] Or they’re looking for, now we’re DevOps, or now we are agile. And in fact, that was not really— yes, was bringing some benefits, but not the kind of life-changing, if you like, for the organization type of—

Jessica: If your transformation’s ever done, your transformation has failed.

Manuel: Yep. Yeah.

Matthew: Yes.

Manuel: Like Mirko Herring says, there’s no end state for your transformation. It’s just becoming able to continuously evolve is the goal.

Jessica: Right. Yeah, like being alive.

Matthew: We added a few extra things in the mix as well. We went back and looked again at the stuff Conway’s Law. So Conway’s Law, this kind of mirroring between the technical and the social aspects of an organization building systems. But actually, if you go back and read, I don’t know whether you’ve read the original 1968 paper. I mean, that is actually, it’s packed full of really key insights. He’s had such good insights, did Mel Conway, back in 1968. I mean, I’d definitely recommend anyone listening just to go ahead and like, actually, this sounds weird, right? But go ahead and read that 1968 paper, and read it properly, actually properly read it. Get a highlighter pen, print it out, get a highlighter pen, or do the highlighter thing in, like, your PDF reader, because there’s so many useful things in there. The one thing that jumped out at me when I read it was that the design of our organization is a constraint on the solution search space. This means that certain kinds of solutions we will never find if our organization is in a particular shape, which is a major problem in terms of innovation, in terms of being able to kind of do new stuff. We’re basically limited, limited in terms of the kind of stuff we can even think about based on the structure of our organization. That’s like proper strategic-level stuff. That’s like, that’s properly, the organization is potentially properly hampered from even finding certain kinds of technical solutions or building certain kinds of systems just because of the shape of the organization.

Jessica: [00:10:59] And that’s not the end of the world. I mean, your organization has to have some sort of structure, unless that structure never changes.

Matthew: Well, unless certain structure never changes, or unless that structure is so far removed from the kind of systems that it should be building, then it’s a problem, because you’ve got this big mismatch between the structure, the communication structure in the organization, and the systems that it’s trying to build, then that organization will always be fighting against Conway’s Law, always spending so much time and effort trying to fight against that mirroring effect, that it’ll be incredibly wasteful. And it certainly won’t discover useful solutions. So that felt like a really important thing.

Manuel: And it’s also related, I think, to if you’re building systems or services where you have many parts, whether that is because of the architecture that’s split into many parts or because of the lifecycle that requires many teams to do different things, then each of those teams has kind of a smaller space to think about the possibilities. And so there’s a tendency to just basically repeat what you’ve done so far. So then we get into the idea of if teams are the means of delivering value and you want those teams to be autonomous and own their services, then they will be— they should have more space to find new solutions and not be so tied to, oh, we only do this thing, or we only do this bit, or we only care about this bit. So I think that’s also one of the reasons why if you have structures that are too inflexible, then you won’t be able to find more innovative solutions or more adequate solutions.

Matthew: [00:13:02] Yeah. And actually, since we wrote the book, there’s been some interesting academic research that’s come out around flow in biological systems. So, obviously, the subtitle of the book is Organizing Business and Technology Teams for Fast Flow. And it turns out Certainly, some researchers in the biological space are starting to look at flow as one of the most important aspects of living systems. And so actually thinking about organizing an organization to optimize for flow makes it more like a living system. It starts to bring in some of the properties of actual living systems. And so the importance of designing for flow is even bigger than we kind of, than we sort of thought about as we were writing a book. It’s kind of interesting to see some of the really fresh thinking coming out of academia and researchers and things in this space. So this kind of optimization for flow and its counterpart is kind of feedback, because if we’ve got things flowing, we’re actually able to detect things more easily. Just ends up being a really seems to be a really powerful, important kind of driver for effective organizations that are able to then respond quickly. The organization becomes more like an organism, more like a living thing, because we’ve got— because we’ve optimized for flow effect.

Jessica: [00:14:34] In an organization, what is flowing?

Matthew: Primarily, we’ve got a flow of changes to services, to meet some kind of needs.

Jessica: So, changes to software?

Matthew: Well, that’s our focus in the book, because that’s our experience. But actually, so I spent some time doing some work for UK government in 2018. And there, in situations like that, and in other kinds of situations as well, software is only actually a very small part of the end-to-end service, particularly if it’s kind of citizen-facing, or other kinds of services where there’s a physical component. And software is actually only the small bit in the middle. So there is a part in the book where we actually talk about kind of long, kind of bigger services, if you like, where software is only a component. We talk about a service experience team who’s responsible for kind of designing the end-to-end service, working with the software team in the middle to do the softwarey bit, but actually thinking about the end-to-end experience. But yeah, principally we’ve got a kind of, we’re trying to meet a need of either a user or of another system. And a chunk of that is going to be software. And so we’ve got changes to that service kind of flowing down towards the live version of that system, or the live version of that service. That’s the principal thing we’re talking about.

Manuel: [00:16:03] To clarify, I think we’re talking about what is flowing is whatever changes we need to do to meet those business needs. And not— we’re not talking about, you know, flowing, you know, features requests that have been approved down to, to the teams. It’s actually a more kind of experiment-driven approach where, you know, we have this, this goal or this, this need we need to meet, and then allowing the teams to find what’s the right solution and delivering that.

Jessica: It’s a— we’re looking for a flow of changes to outcomes, not like back in the old days. Um, we looked at the flow of parts through a factory, or we looked at— you might look at the flow of, uh, requests for driver’s licenses or whatever if you’re a government office, but you’re looking at the flow of the actual product. And now in modern systems, which include software, the flow isn’t the production. That’s just happening because, especially with software, because computers just do it over and over really fast. The flow is of changes to the flow of the product. Yeah, it’s actually just a very different level of work.

Manuel: [00:17:26] Just as A side note on that, but I think it’s interesting because we know there are also some movements within manufacturing to kind of try to apply ideas from agile. So what they’re trying to do is understanding actually to be innovative in the space where you have physical devices, we can’t, we shouldn’t be any longer also doing everything up front, all the design up front and assume that this is all going to be what the users need. And actually, what some of these ideas are around, actually, you know, prototyping really fast and, and being— having capability to build things yourself, uh, to some extent and validate quickly with your actual users until you get kind of validation that, okay, this looks like this is the right design for our device or whatever it might be. And then, okay, then we can scale and produce at large.

Matthew: [00:18:28] And there’s also, I mean, this is a little bit off topic, but there’s a great, I think it was just a tweet, maybe a talk from John Willis, when he did a factory tour with Toyota recently, and Toyota have a programmable factory. So, hey, John Willis talks about factory as code, where Toyota, obviously originators of kind of lean thinking and all this kind of stuff, now have taken ideas from software and now can reconfigure their car manufacturing plant in code. So we’ve got this interplay of ideas, which is kind of amazing just to see these kind of ideas from software going back into physical manufacturing and enabling all sorts of different stuff. So yes, in that particular case, then What’s flowing down is multi-level. We’ve got cars flowing along the production line, but we’ve also got changes to our assembly line itself flowing down and needing to be tested as code. That’s kind of amazing.

Jessica: Yeah. And then Manuel pointed out that one of the things we get from those fast changes is learning. So, there’s a flow of learning through the system, through our system.

Manuel: [00:19:34] Even more kind of another impressive example. So, Mik Kersten has talked about how he has been to, like, BMW factories. So there are different— it’s not all the same factory lines making different models. It’s some of them are like, okay, this is our, you know, regular production line and we just correct minor problems. And other parts are actually designed to learn actually what is the best way to build this model. So not for the quantity and the throughput, but actually make sure we learn as quickly as possible how the production can be more effective. And then they’ll go and reorganize the line to be as efficient as they can. But it doesn’t start from there. It starts from, we need a space where we deliberately make room to learn and we’re not trying to optimize everything.

Matthew: [00:20:39] I think this dynamic between this understanding that there’s a need to have different configurations for learning and discovery versus high-volume production, if you like, and friction-free production is a really kind of key concept. And it’s something that we effectively talk about in the book, because in the past, For various reasons, a lot of the kind of books that talk about different kinds of teams, and different ways of doing software delivery, and different ways of scaling Agile, and stuff like this, a lot of them have a very kind of factory mentality. We are going to— this is a software factory, and we’re going to push out lots of code. And actually, a lot of them have a kind of one-size-fits-all sort of approach to it, which doesn’t feel right. It seems quite important to understand different kinds of dynamics in the organisation at different times. Sometimes we need to work together to bring 2 different teams together with different expertise and discover something, because that’s what’s needed at that point. But at other times, we actually just want to have a kind of friction-free ability to kind of work on the same kind of stuff with the same kind of dependencies and the same kind of services quite quickly for a long period of time. Other times, we might need some help or advice from some experts or whatever. And so the nature of these interactions should feel different. The nature of what we’re doing is different. So the way in which we kind of interact with other groups should be different. And how that kind of work looks at that point should be different because its purpose is different.

Jessica: [00:22:21] And you give names to these things in the book. What are the 3 patterns you just talked about?

Matthew: Yeah. So, we came up with 3 different kinds of team interaction modes. One is collaboration, but we’re quite specific about what collaboration means. It means working together with one other team for a defined period of time to achieve an outcome.

Jessica: And I love that you point out that collaboration is not the objective. Collaboration needs to be limited.

Matthew: Yes. Because too much collaboration, if 2 teams need to work together for a long period of time to achieve the same thing, and are they really 2 teams? Well, are they really 2 teams? That’s a good question. And do they have the right capabilities? Is something missing? Is there, is there, could they be using an external service to help them do that instead? Are they focused on the right thing? You know, there’s all sorts of problems with that, with collaboration, that goes on and on and on, it’s not necessarily a good thing to have continual collaboration. It’s a signal that something’s missing or in the wrong place or—

Jessica: [00:23:27] Within a team, continual collaboration is expected, right?

Matthew: So, yeah. So when we talk about collaboration, we’re talking about, we take a team as a single kind of unit, if you like, a single thing entity that’s used for delivery of something. So when we talk about collaboration, we’re always talking about like, one team and working with another team.

Jessica: The book is very clear about teams are the units of delivering value, not resources, as you might call humans.

Manuel: Also known as humans. Yeah, we focus a lot on the team. And so, we were saying inside the team, you expect very strong collaboration and trust. And, you know, when you look at high-performing teams, and if you look at State of DevOps report and Accelerate book, it’s all, um, it’s all, you know, that’s, that’s a key aspect, is that the team is, is gelled. And when you see organizations that are, you know, project-based, and, and also a lot of organizations that rely a lot on outsourcing or contracting and, you know, people that come and go, and the teams are essentially never stable. There’s always, you know, we’re creating a team for a project, so there’s a lot of value that is lost, not only in kind of the knowledge around the systems and services that are being developed, but also the gains of having an actual team that can go faster and people know each other. They know what, you know, what are the strong points and the weak points, what, you know, people, um, give importance to. And, and so that all those things and all those kind of human aspects are important to, to get a team that can really perform well. And so when you— if you understand that, and then you should reflect that in the way the organization is structured, the way that people are incentivized, and that focus on the team can have very important implications to how we should go about trying to promote higher performance and better delivery or faster delivery.

Jessica: [00:25:52] So, if teams aren’t collaborating all the time, what are they doing?

Matthew: If 2 teams have been collaborating together, let’s say they’ve worked together in that way, really close collaboration, which might mean, you know, literally sitting at each other’s desks or attending each other’s standups, or at least they’re on video calls, you know, day in, day out for, maybe this happens for 3 weeks, and they’ve now discovered a new way of doing something. Who knows what it is? It doesn’t really matter, but let’s say it’s something about the way that the infrastructure needs to work to enable quicker deployments. If we’ve now got to a point where we’ve discovered how that should work, If we realize that there’s a nice interface, or we can see that there’s probably a nice interface here, a nice API that one team could call and the other team could provide, then if we want that nice API, then Conway’s Law suggests that we should actually not need to talk to each other very much. Because if we don’t need very much machine-to-machine communication, if you like, then there should be less need for team-to-team communication. We should explicitly say, okay, we’re at the point now where we think we’ve worked out what this API should look like. Let’s work together less closely. Let’s actually kind of have a different relationship, different interaction between these 2 teams now. So that, that will, we can start to lean on Conway’s Law to help us work out, to help us make sure that that API is actually nice and clean. Otherwise, the danger, if we continue to collaborate, is that the API becomes less clean.

Jessica: [00:27:27] So you’re listening to the technology and using that to give yourself advice on how the social half of the system should work, the team structure.

Matthew: And both ways around, the same as well. So listening to the social interactions and saying, does that match with what the technical interaction should be like? And it’s a kind of circular thing, really, which is what Conway’s Law kind of tells us.

Manuel: Because it’s also like, you don’t know, you’re not always going to get it right. When is the right time to expose something as a service and say, well, now our interaction is more decoupled? Because maybe you got it wrong, maybe it’s, it was too early and you need to, um, and you actually need to go back and collaborate a bit more again. Um, and so You know, if we’re talking about kind of services provided by some, some kind of platform, then you also need to be aware of, you know, different teams might come from different backgrounds. So what works for one team, and we could say, well, this is enough for one team, might not be adequate for the second team or the third team because maybe they’re coming from a different starting point or they don’t have as much experience with infrastructure automation or deployments, whatever it might be. And so it’s kind of, again, kind of continuous evolution and sensing when the expected interactions are causing problems. So actually, we thought this was stable enough and clear enough to be X as a service, but the teams are always coming back to us asking for help. How do I use this? And so that’s a sign that actually we need to work out a better interface, we need to perhaps improve our documentation, and so on, so that those teams can be again more autonomous and use the services rather than depend on us to help them.

Jessica: [00:29:24] In this example, the team started out in collaboration mode, they found a nice breaking point with a good API, and so they moved into an as-a-service interaction?

Manuel: Yeah.

Matthew: That’s right.

Jessica: And then when that got fuzzy, they moved back into collaboration.

Matthew: Exactly. So we’ve got this kind of, this dynamic where we’re, you know, if we’re using— so collaboration is great for discovering new stuff, new patterns, new ways of doing things, but it has a higher cognitive overhead, and it’s probably slower overall to deliver things. If we found a nice interface or nice API, that we can kind of consume or provide as a service, then potentially, if that’s a good API, we’re actually able to kind of use that and deliver stuff really quickly using that. But there’s always a possibility that the API needs evolving, and we’ve got it in the wrong place, and so on. So we might need to actually kind of have a different sort of relationship with that team for that particular kind of API, if you like. So we’re always kind of thinking, well, what’s the right kind of relationship to have at this point? Bearing in mind Conway’s Law, because that Conway’s Law, like, too much collaboration is going to tend to blur the boundary of that kind of component. And we’re also thinking about what we’re trying to achieve. So, being much more conscious about the kind of interactions that teams are having with other teams inside the organisation to make the purpose much clearer, and to help us detect when we’ve got boundaries wrong, or we’ve got responsibilities wrong, or there are missing capabilities. Inside teams or inside the organization as a whole. And we’ve got, we’ve got this third interaction mode called facilitation. This is where we’ve got one team kind of helping another team to increase their knowledge or awareness or capability, or helping, helping to understand, let’s say, why another team is finding something difficult. So typically, we might have a team of experts. So one specific example I had with a client recently was they’re moving from Oracle database to Postgres database. So they had a team of experts there who were acting in a kind of facilitating way with some of the kind of product teams. In the book, we call them stream-aligned teams. So this group of experts was acting in this kind of facilitating way with with the Stream Align team to help them move, in this case, move database. So the people who are doing that facilitating interaction are not, they’re not doing the work. They’re not doing the work to move from Oracle to Postgres in this case, they are helping another team to do it.

Jessica: [00:32:04] And by providing the knowledge that’s needed, and at the same time transferring that knowledge to the team.

Matthew: Well, so it’s not just about knowledge transfer. This is a key thing that it’s also about the people that are in that facilitating interaction, listening for signals, looking for things that might be missing. So, if they’ve worked with 3 different teams that all have the same problem, is there— perhaps there is something missing in the toolset, perhaps there’s something fundamentally missing in terms of the set of skills that we’ve got in the organisation, perhaps, you know, something else is kind of not working. And actually, we can We can, if we’re listening for that, we can detect a problem there early and do something about it, rather than just going ahead and kind of doing the work on behalf of 17 different teams. At some point, we’re going to say, something’s missing here, or something’s wrong. Let’s step back and think perhaps this could be better provided as an API by a platform, for example. And so it allows the organisation to kind of self-steer and correct its kind of organisational behaviour much sooner, than if we’re just kind of going ahead and building something on behalf of everyone else.

Manuel: [00:33:20] Okay.

Jessica: So, we’ve got the 3 interaction modes, the collaboration, the as-a-service, and the facilitation. And then you have how many different kinds of teams that are involved in these?

Manuel: So, there are 4 fundamental topologies. We talk about stream-aligned teams, which, you know, some people call them product teams or cross-functional teams. So, essentially, We’re talking about cross-functional team that owns end-to-end delivery and runtime of a service.

Jessica: And this is where the flow of changes to services happens, right?

Manuel: Yeah, yeah. So they’re kind of the heartbeat, if you like, of delivering those, those changes to that the business or, or whoever needs. Those are kind of core, and then we have 3 other fundamental topologies that are in place to help the stream teams reduce their cognitive load. So we talk about platform teams that provide services like we were talking just now, whatever kind of services that are helpful for the teams to use in, in this kind of autonomous way as much as possible, whether that be deployments, infrastructure provisioning, monitoring, or more business-focused services around data, whatever it might be.

Jessica: [00:34:44] Is this what people call a DevOps team?

Manuel: In some organizations, perhaps. And then we have enabling teams, which are typically the ones doing the facilitation that Matthew was talking about. They might be, in some cases, they’re more short-lived if it’s a very specific area that they’re helping the stream teams with, like, like that example of migration between database technologies. And in other cases, might be more long-lived around some capabilities like, let’s say, continuous delivery, something like that. And then we have complicated subsystem teams, which we strongly discourage, but we had to acknowledge that Sometimes for very specific types of algorithms or even some very niche technology that you— there are very few specialists, or is something that is too, too complicated that requires basically a full-time team to understand and own it and be able to make changes, then you want a team around that, which might actually just be providing a subsystem to one other, to another stream team, but it still makes sense from a cognitive load perspective that, you know, we cannot ask one team to own this complicated subsystem and all the other bits of the kind of more end-user-focused part of the service.

Jessica: [00:36:13] You’ve mentioned cognitive load a couple times, and that’s one of my favorite things in this book, is how you talk about The limitation of a team is cognitive load. It’s not resources. It’s not pizza.

Manuel: Although pizza is a very appealing way to talk about it. Okay. So we start from the point of view that, um, you know, the idea of 2-pizza teams actually, well, it depends on the size of pizza, but it makes sense, uh, when you look at, uh, things like actual research around the human brain size and the capacity of humans to have close relationships with other people. And so there’s Robin Dunbar, he’s an anthropologist, so he did a lot of research and he came up with Dunbar’s numbers, or people called it Dunbar’s numbers. And so there’s a limit between 5 and 15, which is how many deep trust relationships we can have at any moment in our lives. So that seems to fit in that kind of the usual number of team members for agile teams and delivery teams, you know, around 7 plus minus 2. But then cognitive load comes in into, you know, if we have that limitation on the size of the team, how much are they able to take on without degrading their capability of responding to change and responding to problems as well, and fixing problems.

Jessica: [00:37:49] And that’s— How much they’re able to take on, does that mean feature requests?

Matthew: Well, so if that team has got to be, is going to properly own the change in the software systems that they’re building, if they’re going to actually be able to understand it, and to be able to diagnose it properly and to be able to make sensible decisions about trade-offs in terms of security versus speed or other kind of trade-offs in terms of operability or the complexity of how the deployments work, all sorts of things like this. If that team is going to truly own that service and keep it viable, then they have to understand it. Not everyone on the team might not understand every single aspect, but the team as a whole, as a unit, needs to understand that service well enough from for the team to be able to own it. And so effectively what we’re saying is that, so one of the things that the kind of Amazon AWS 2-pizza team enforced back in 2002, or whenever it was, when Jeff Bezos came up with that, one of the things that effectively enforced, even though they don’t talk about it, is a limit on the size of those systems that those different teams build. And it’s in the interest of that team, if that team is going to own that system, then they will make sure that the system never gets too complicated for them to understand. So therefore, by implication, there’s a limit on the cognitive load that the team, that team needs to work with to actually properly own that system. They’ll always keep it kind of understandable, if you like.

Jessica: [00:39:29] So there’s another underlying assumption here. We’ve got that the team is is the unit that delivers value. And we’ve got the part that the team owns a piece of software, that there’s not like one blob of software and 10 teams making various changes to it. There’s ownership there.

Matthew: There’s ownership there, and that’s a really important dynamic, because without that ownership, the complexity will will inevitably bloat and rapidly become too difficult for almost anyone to understand at all. So you’ve got an interesting kind of enabling constraint, which is an upper limit on the kind of complexity of a chunk of the system that is sort of team-sized, a team-size limit on the kind of complexity Which is a really weird starting point for thinking about how the size of different bits of software systems, but that’s the kind of implication. Because we’ve got a sociotechnical system here, actually, we can use that upper limit to kind of create a kind of sensible upper bound on the complexity of small chunks. Oh, like a useful constraint? Yeah, it’s a useful constraint on the complexity of chunks of the system.

Jessica: [00:40:53] Okay. Now, you said something. You said that if If the team has ownership, and the team has limited cognitive load, then the team will make sure the system never gets more complicated than they can… I’ve not seen that in practice. I mean, I’ve totally been on teams, and we created software systems that were way more complex than we could understand anymore.

Matthew: So, I think this is the thing which we can elevate now to be something that should be an explicit goal. Which is, let’s always ask ourselves, have we exceeded our team cognitive load for the system that we’re working on? And if we have, let’s do something about it. Let’s make sure, you know, let’s detect it. Let’s reflect on that. That’s actually something we’re working on at the moment, is ways to assess team cognitive load in practice. Because that’s one of the questions that’s come out of the training and kind of consulting we’ve been doing, been doing recently.

Manuel: [00:41:54] Actually, we have a case study in the book where, um, actually a couple of case studies where effectively the team themselves realized, uh, the system or, uh, the responsibilities have grown way over what we are able to, to do with the sense of actually having some mastery and some autonomy. Because sometimes you also can create kind of monsters where it’s, you know, it’s, it’s too big, and then you actually end up being at the mercy almost of this software where you’re just running around trying to fix something here, fix something there, make a small change. But we have case studies where the teams themselves or some people on the team realized this is what was happening and they decided to split the team and do a bit of re-architecting of that piece of software in order to be able for the smaller teams to go faster on, on different parts of the, of the software while understanding that it’s not comp— they’re not completely independent because this was one single system or service before, uh, that we’ve split. And so there will always be some dependencies and some work that requires collaboration between the 2 smaller teams, but let’s say 80% of the time, something like that, we can actually work more independently than with a big team trying to do all this different stuff. Because then that really can take a toll on the individual’s feeling of autonomy and of kind of a shared purpose.

Jessica: [00:43:36] So, in that case, are you describing like 2 teams splitting into— or one team splitting into 2 teams that are collaborating? With the intention of moving toward a side-by-side kind of as a service operation?

Matthew: So it could be as a service or it could actually be side-by-side paired. So there does seem to be one of these kind of dumbbells numbers limits around about 15 people. So there are very few sports teams that are more than— that have more than 15 people in it. If you think about it, I’ve not found one yet. I mean, there may be a sport that has that, but very few. And again, there’s a kind of anthropological reason for that, which is that there seems to be a limit of around about 15 people in terms of the number of people we can have a kind of secondary level of trust with. And so actually, quite a few organizations have talked about situations where they’ve actually been able to run with a pair of teams working on slightly different but related things and still maintaining quite a high degree of trust. But actually, that model doesn’t seem to scale well to 3 teams, for example, because there’s now too many people. That’s kind of, as it happens, that’s another kind of important kind of lesson from the book. And there’s lots of references in the book to the original material, but what works at a certain scale doesn’t work at a slightly larger scale. There’s these kind of trust boundaries, which actually make the dynamics a little bit different. And that’s kind of an important thing that organizations are going to need to get to grips with, which just because it works at this particular scale down here, doesn’t mean that you can assume that you can just make the same model work at 8 teams or 25 teams. There’s some different dynamics as the number of people reach different numbers.

Jessica: [00:45:21] Yes. I loved the bit where you point out that as a company grows from 5 people, and then crosses the boundary of 15, and then crosses 50, and then crosses 150, you have to re-architect the social organization of that to reflect the new needs. And that implies that you have to re-architect the software.

Matthew: You’re absolutely right. And it implies a need for— the nice thing is, with the kind of Dunbar’s numbers heuristics, we can sort of anticipate when we’re gonna need to re-architect, because we can look at our growth trajectory as a company in terms of the number of people we have, And in terms of where those boundaries currently are, and say, well, actually, based on this growth trajectory, we’re going to expect to need to re-architect it to look a little bit like this, with these kinds of number of segments, and these kinds of number of different services, or different kinds of subdomains, or whatever, in 18 months’ time. So actually, with these heuristics, we’re actually able to predict some architectural changes that are going to be needed, or at least start to prepare the ground for that, which Which feels much more useful than this very reactive re-architecting that often happens in lots of organizations.

Jessica: [00:46:37] Right, you can plan for it. And you’ve managed to provide some sort of evidence or answer to the eternal question of how big should a microservice be? The answer being, what is the cognitive load capacity of one team of 7 plus or minus 2.

Matthew: Yeah, exactly. Because if that team wants to create 100 microservices and they’re happy with it, and they’ve got a nice fancy microservice fabric that does all this stuff for them and allows them great observability, if they want to do that, that’s great. If they’re happy and they’re able to deal with it, cool. If they prefer to create 1 or 2 services to deal with that, but they can still deploy them nice and quickly, and they can still deal with how the software is architected, Again, that’s fine because it’s about kind of team-level ownership and limiting the kind of complexity and size of bits of software. So it’s no bigger than that team can handle.

Manuel: I like to use a beer analogy for that. If I want to drink a liter of beer, I don’t care if it comes in a bottle of 1 liter or 3 small bottles of 33 centiliters. I still want to drink a liter of beer.

Matthew: [00:47:52] I don’t want to go. I don’t want a gallon.

Manuel: And then what I want to worry about is if I don’t want to get sick or intoxicated, then I probably shouldn’t drink in, you know, 10 minutes or 20 minutes a little beer. I need to drink over 3 hours or 4 hours. So thinking about my, you know, capacity to, to deal with that, um, what’s, what’s, uh, that intake of, of how much I can, uh, intake without degrading in my system or the team’s system.

Jessica: You know, I could ask a lot more questions, and I’m sure our listeners have a lot more questions, which is great because they should all go out and buy the book. But in the interest of time, I want to wrap up this episode. Is there anything in particular that each of y’all want to make sure to get in?

Manuel: I think something that has been— well, the book has gotten really nice feedback and seems to strike a chord with a lot of people and organizations. And like, like you were talking about cognitive load as kind of just having terminology that people can use to talk about certain problems and talk about, you know, why it’s, it’s not microservices versus monoliths, but actually the team’s capacity to, to deal with, with the software that they’re responsible for, um, and other things, you know, the the topologies and interaction modes. So people have— some organizations have really taken that just as a starting point to discuss, you know, how are we organized, having a kind of lens on our organizational capabilities rather than it being something too reactive or saying, well, we need to move to Kubernetes and now we need to hire 10 people, or what, you know, this is not really kind of helping have this broader view of what types of teams do we have, how are they interacting, what do we need to move towards. And so I think that has been very insightful to get that feedback that the book and the terms and the way things are described has helped a lot of people just talk about problems and talk about organizational capabilities.

Matthew: [00:50:10] I mean, we’ve been kind of blown away really by the response to the book. It’s been really great. So, we’re super happy to be part of the IT Revolution Books family, along with Accelerate and Phoenix Project and Project to Product and these kind of books, because Gene Kim does it and his colleagues do a really good job in bringing together the kind of really complementary viewpoints. I think it’s fair to say we’re still learning. We’re still learning. We’re consulting and training with lots of different organizations, multiple governments in different parts of the world. Many different kind of banks, insurance companies, product companies, software gaming companies. I mean, at this point, it’s kind of— it starts to become easier to say which companies are not using it compared to which companies are using it. But yeah, we’re still learning. We’re kind of developing some new materials at the moment. We’ve got some collaborations with some really interesting companies to try and kind of expand on some of the ideas. We just yesterday, today, we’ve released a couple of repositories on GitHub for helping to kind of flesh out some of the ideas in the book and make them more useful for people. So, you know, this is a kind of work in progress, if you like. So we’ve obviously published the book, which collected the ideas and made some terminology kind of more useful and so on. But we’re still working through some of the ideas and implications and It’s great to see people using the ideas and kind of running with them and developing new ways of kind of bringing together, for example, Wardley maps and some more strategic stuff together with some of the Team Topologies ideas and seeing the— seeing a kind of cross-pollination of different ideas come out. So that’s been really great. So we’re kind of super excited to kind of be developing the ideas further at the moment.

Jessica: [00:52:04] So, as people want to follow along with you, as you continue to develop the ideas, where can they find that?

Matthew: So, just head to team-topologies.com. And we’ve got a newsletter there, and we’ve got a Twitter account, which is very active, and we’re on LinkedIn as well.

Jessica: People can also head over to arresteddevops.com/team-topologies for this episode’s show notes. We’ll have links to all the references and a summary of the episode. Visit arresteddevops.com/itunes and leave us a review in the iTunes store. If you want to help other people find the podcast, spread the flow of learning. Thank you so much, Manuel and Matthew, for joining us today.

Manuel: Thanks for having us. It was a pleasure.

Matthew: It’s been great. Thank you.

Jessica: I’m Jessica Kerr, also known as Jessitron.

Manuel: And this has been Arrested DevOps.

Jessica: Remember, there’s always DevOps in the banana stand.