Matthew Skelton - Author of Team Topologies

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Matthew Skelton, the author of the book Team Topologies. And we discuss how to build teams focused on a fast flow of change, the impact that team structure has on digital transformation, and how to create lasting change in an organization with incremental improvements over time. All of this right here, right now on the Modern CTO podcast. Here we go.

(Joel Beasley at 00:00:26) This is the Modern CTO podcast. Hello, hello.

(Matthew Skelton at 00:00:39) Hi.

(Joel Beasley at 00:00:40) How are you, my friend?

(Matthew Skelton at 00:00:41) Hi, Joel. Well, thank you. You?

(Joel Beasley at 00:00:43) Good, good. You excited? We're going to do a podcast.

(Matthew Skelton at 00:00:46) It's great.

(Joel Beasley at 00:00:47) Do you have a copy of your book with you?

(Matthew Skelton at 00:00:49) Well, I've got a million copies. It depends whether one's on the desk at hand, but yeah, it's just here.

(Joel Beasley at 00:00:56) Cool. How many editions do you have so far? Just the first one?

(Matthew Skelton at 00:00:59) It's just the first edition. It's only been a year. So normally a second edition would take another couple of years or something to come out. But we've gone into second printing.

(Joel Beasley at 00:01:09) Oh, that's a good sign.

(Matthew Skelton at 00:01:11) We shifted 15,000 copies in the first year, and so they've just printed another 10,000. So that's good.

(Joel Beasley at 00:01:20) Did you go with a publisher or self-publish?

(Matthew Skelton at 00:01:22) No, this is IT Revolution. So, who publishes—it's Gene Kim's outfit. So they publish, you know, Phoenix Project and DevOps Handbook and Accelerate. These books are part of that family.

(Joel Beasley at 00:01:35) Oh, that's like the best family you could be a part of.

(Matthew Skelton at 00:01:38) It's really good. I mean, the titles are all curated, so they all fit really well together.

(Joel Beasley at 00:01:44) Did they approach you, or how did you meet them?

(Matthew Skelton at 00:01:47) There's a kind of combination because we've been kind of circling around in the same space for a while. And then Gene and I were emailing a little bit, and then he invited me to speak at DevOps Enterprise Summit in London 2017. And then on the back of that, we were looking around for a publisher, and we thought, well, why not just try it? What can go wrong? They can only say no, and they might say yes. So we went for it. It was a perfect fit. So it was really good.

(Joel Beasley at 00:02:16) Oh, nice. How long does it take working—I did a book, but I self-published. But from working with the publisher, how long did the process take?

(Matthew Skelton at 00:02:26) It took about eighteen months because it's about six months worth of negotiation and kind of getting everything lined up. And also they've got to slot you into their schedule because certainly pre-pandemic, everything was lined up against, I think, two or three book fairs, physical book fairs. One in Frankfurt, one in—I can't remember. There's one in the U.S. somewhere and one somewhere else. And basically everything was arranged around that. I don't know how it works now because obviously no one's really meeting in public. But anyway, we started writing just over a year before the book was published. So we were writing for about six months, and then it was six months worth of publishing and reviewing and all that kind of stuff. And then it came out in the September.

(Joel Beasley at 00:03:11) Oh, and who is your co-author on it?

(Matthew Skelton at 00:03:13) So it's Manuel Pais. He's a colleague. I've been working with him since 2015. We started working together on—well, actually, he interviewed me for InfoQ magazine, for the InfoQ website, about the original DevOps Topologies website that I put together. And then we worked more on that. And then he started working with us on some client consulting gigs, mostly around build and deployment, continuous delivery, kind of infrastructure automation, that kind of thing. And then we branched out into other areas, you know, team-based team responsibilities and that kind of thing. Kind of came naturally out of the work that we were doing.

(Joel Beasley at 00:03:56) So were you already doing consulting work and then you were seeing these patterns, or—

(Matthew Skelton at 00:04:04) Exactly. And we could read what other people were saying and what other people's experience was and relate that to our own consulting work. So it came out of working directly with people. A lot of the more kind of humanistic stuff in the book comes out of actually experiencing the kind of frustration and confusion that we saw people having inside organizations, not knowing what the team boundary was there, why they were having to interact with this other team, all this kind of stuff. So a lot of that aspect of it came out of directly kind of sitting down and working with people and seeing, listening to what they were saying and seeing that kind of confusion and frustration.

(Joel Beasley at 00:04:46) And what was the most common one?

(Matthew Skelton at 00:04:48) Well, one of the most common things that we wanted to address in part of the book was people often didn't seem to have a strong sense of the remit of their team, what their team was supposed to do. And they also didn't have—in combination, they didn't have a strong sense on many occasions, they didn't have a strong sense of why they were having to work with this other team. And so we wanted to codify some of those aspects in the book to make it much clearer, to give some kind of patterns and some a mental picture of, you know, good ways in which teams could work together or not work together and bad ways in which teams might be interacting. And just to give a bit of clarity around that. And that seems to have been really useful. There's been some very good comments from lots of different organizations saying, actually, the kind of patterns and different team types and interaction modes seem to be really useful for a much more fruitful conversation about purpose and intent of work inside, certainly inside an IT organization for sure. Actually, outside IT as well, it seems to be useful.

(Joel Beasley at 00:06:08) So these—let's stick with the IT stuff because that's where I have experience. Sure. So you were saying that—correct me if I'm wrong. So one of the most common things that you saw people were frustrated about were teams were working together with other teams and they weren't clear on the vision or the purpose or why they were working together.

(Matthew Skelton at 00:06:29) Yeah, that's right. That's one of the things. And if you think about it, if you've ever been in a situation where you've been asked to work together with another team, that can sometimes be very rewarding, can really work well. Sometimes it can be very frustrating. And often that's because the boundaries are not really well thought out and the intent of that working together, that collaboration, is not really specified. And it kind of just drifts into an ongoing kind of, "Oh, it's really painful to work with this other team," rather than using that pain as a signal which says, "Okay, this collaboration is not working. Why is it not working? Have we got the boundaries wrong? Have we got insufficient capability inside one or both teams? Or should we actually now be expecting to provide or consume something across a kind of API boundary at this point?" And so starting to think about how team interactions relate to the software architecture because of Conway's Law and so on, mirroring sociotechnical mirroring. So actually, it becomes—turning awkward team interactions into signals to tell us something about the organization, capabilities, architecture, boundaries, flow, this kind of thing. So it becomes much more powerful if we've got this language and this stuff in our head. And it's not particularly complicated, but it just means that we potentially avoid quite a lot of frustration and stagnation by actually then turning that kind of inside out and saying, "This is telling us something important about the organization. So let's do something about it."

(Joel Beasley at 00:07:58) Yeah. And that is—yeah. When I heard about your book first, I was giving a talk and people were asking me—I guess the talk, this is pre-COVID—people were asking me about team structures. They're saying, "Oh, you know, my team's structured this way." And then we hear about, like, you know, Netflix has their team structured this way and Spotify has their teams and they have all these, you know, nice words and structures around how they do it. And they were saying, like, "What's the perfect structure? Like, how do you do it?" And I was talking with them about the structure of the team relating to the need of the business. And that was the shortest summary of my answer, was paying attention to what the needs are in the marketplace, and then that will create the needs of structure for your team. And someone mentioned after that, they're like, "Oh yeah, that reminds me of Team Topologies. It's like my favorite book. Like, have you read that?" And I was like, "No, I haven't." And so then I went and got it, and I was like, "Oh, this is—you are super in tune with teams and understanding the structures." And there's a lot more nuance. But my question is, when people ask you, like, "What's the perfect way to structure your team?" How do you answer that when you're giving talks?

(Matthew Skelton at 00:09:17) The perfect way to structure an organization to deliver software is one that is adaptable and evolves. And therefore, there is no one diagram that will capture that. Our book starts from the premise of needing a fast flow of change. If your organization does not need a fast flow of change, then a lot of the stuff in the book is not going to be relevant. There is some stuff which is going to be relevant for sure. But if you're not interested in a fast flow of change, then that's fine. You'll look at some other book to tell you. But to be honest, these days, anyone building software systems, if you're not moving quickly, if you don't have a fast flow of change, you'll probably be out of business very quickly. So certainly for most IT organizations, we're expecting a fast flow of change. So that's our starting point. So for a fast flow of change, what we want is no handoffs. No handoffs at all between writing the code or committing the code to version control and then flowing that code down to production. We want no handoffs at all. So if we have no handoffs, we need a mix of skills inside the team with all kind of different capabilities. It varies depending on what we're trying to achieve. But typically that involves people who can write code, people who can test code, people who understand infrastructure and metrics, people who understand kind of product management, and so on. So there's a mix of skills. There's an upper bound on the size of a team, and this is just social anthropology and so on. This is something we've inherited as human beings from millions of years of evolution. It's about eight people. Some organizations can actually run with groups of about up to fifteen that sort of work still quite closely together. But beyond about fifteen, there's a kind of trust boundary which means that you can't move as quickly. So if you want to optimize for a nice fast flow of change, you have to limit the size of these groups, these teams. And then there's a limit on the cognitive load inside that team because you can't keep adding people and retain a fast flow. So there's therefore limits to the size of the system that a team like that can actually understand and properly own. And so that immediately starts to then have an effect on the kind of software architectures that we'd like you to build. It sort of implies heading moving towards loosely coupled independent smallish services or applications. It might not be called microservices because that's coming at it from a very technical angle, but it shares some concepts from the kind of microservices world. And then so you've got multiple loosely coupled independent teams matching their architecture, loosely coupled applications and services. But then we need some other kind of teams to kind of support that because we've got a limit on the cognitive load that we can take on. We can't build the entire stack. At some point, there's a layer below which that team is not going to be able to deal with. It might be—and it depends what you're working on. But at some point you'll hit a level which is, "This is too complicated. We don't have enough time to deal with, you know, infrastructure or networks or hardware or firmware or electronics." Or you'll hit a layer at some point which is, "Okay, we need to define this as our platform on which we build." So then you have a platform underneath of some description. So the perfect team structure, it depends on the context. But if you're looking for fast flow of change, you need to minimize handoffs. And if you've got multiple streams of change, you need to make sure those different teams are loosely coupled, just like the architecture will be. So that points to something that's kind of an ideal, if you like. I wouldn't call it perfect, but it points to kind of an ideal that's derived from these principles that we just talked about in terms of fast flow and cognitive load and the size of teams and that kind of thing.

(Joel Beasley at 00:13:00) I love the cognitive load concept because it's something that, you know, the moment you say it, you just as a human, you instinctively know that that's true and you kind of build this map in your mind of how that works. And so this concept of, you know, the number—the maximum number of people and mixing in our anthropology—that's pretty smart. Can you help me better understand, when you're saying fast flow of change, that's like—means quick changes. Like, to deliver. Like, is that what we're talking about with fast flow of change?

(Matthew Skelton at 00:13:30) Yeah. So fast flow of change may come from lots of different places. We're innovating very quickly, or we need multiple new features to be logged, so we need to fix bugs very quickly, or we need to be able to respond to security incidents like zero-day vulnerabilities, this kind of thing. We need to be able to understand what we need to build or change in software, and we need to be able to deliver that very quickly. So obviously underneath we've got lots of tooling, like continuous delivery, deployment pipelines, that kind of thing, infrastructure automation, whole lot of good practices like test-driven development and so on. All of that, to be honest, a lot of that stuff in our book is just taken as a given because that really is table stakes in 2020. I mean, there's loads of organizations who aren't doing it, but all those kind of engineering practices are really kind of—you've got to have those in place. But yeah, we're talking about being able to respond quickly to business needs or customer needs depending on your starting point. But to be able to make certainly make software changes, change to our software systems very rapidly and flow those changes down towards production and have them running and working in production and meeting user needs as rapidly as possible with the shortest lead time as possible.

(Joel Beasley at 00:14:41) And then can you—that was a really good explanation. And I'm just trying, by the way, I'm just trying to wrap my head around some of these things to make sure that we're on the same page. And can you give me a description of what you meant by you want to minimize handoff? Like, what's a handoff?

(Matthew Skelton at 00:14:56) That's a good question. So handoff—traditionally, we might have had separate teams for, let's say, development and then testing and then release, and then operating it in the live environment. So there you've got four different teams: dev, test, release, and operations. And between each of those teams, there's a handoff. So dev hands that work off to test, test hands it to release, release hands it to operations.

(Matthew Skelton at 00:15:23) So at each one of those points is a handoff, and what we're trying to do is remove those handoffs. Because in any kind of flow-based system, as soon as you have a handoff in place, it severely limits the ability of that work to be moved rapidly towards the destination. So that's why we're removing these—what some people call silos—these separate groups. And we've got an obsession with making sure there's none of these handoffs in the flow of change from the request to make that change through to it being in the live environment. That's a single team that owns that entire journey of change.

(Matthew Skelton at 00:15:59) And it strongly affects the kind of architecture and things that we'd want to build.

(Joel Beasley at 00:16:04) I mean, I fully agree. To be honest with you, I've never worked in a team that was siloed. So me, personally, just I guess the nature of my experience. But I could imagine, you know, when I hear—I've got friends that work at all different sizes of companies. And when I hear the amount of red tape that sometimes exists in their flow, I really am like, how do they get anything done?

(Joel Beasley at 00:16:28) Right? But the teams that can structure like that, I mean, that just—I think what happened is there was an older way of doing things, and I just missed out on that. And because I started with a small team, just being a software developer and then building, adding engineers around me, I just did it in a way that I thought was most efficient and logical.

(Matthew Skelton at 00:16:47) Yeah. I mean, there were some good reasons for lots of handoffs in the past, arguably. The technologies of the time, of the 1990s, were not as programmable as they are now. I mean, some of that stuff existed, but there wasn't this kind of API-first approach to lots of software and particularly to infrastructure. I mean, now if you think about cloud infrastructure, it's all programmable.

(Matthew Skelton at 00:17:09) There's APIs for Amazon and for Azure and Google Cloud and whatever. This stuff is software, effectively, or at least there's a software paradigm you use to create things and interact with infrastructure, all the way down to networking and all sorts of other things these days. So certainly a lot of stuff has been made easier through infrastructure automation. But also in the past, there wasn't such fierce competition in terms of getting things to market so quickly. Things were packaged on CD-ROMs, so there was always a kind of production delay, whereas now you can ship new features into production multiple times a day into your live environment if you're running a SaaS product.

(Matthew Skelton at 00:17:46) So the nature of products has also changed in the last, certainly the last fifteen years, but arguably shorter than that—certainly the last ten years. And so that's really accelerated. Well, that's increased the need to be able to deliver things rapidly. And so that's causing organizations with these handoffs in place to seem very, very sluggish. And so the organizations with no handoffs at all for different parts of their systems are way out ahead in terms of speed—very much quicker and able to respond much more rapidly and nimbly to different market conditions or to, you know, pandemics, able to change how to do things and build new features or capabilities into the software very, very quickly.

(Joel Beasley at 00:18:35) That's actually a really interesting take on it because, you know, one topic I get to talk with a lot of different people about is digital transformation. And this is the first time I've connected team topologies, team structures, to having a massive impact—at least perceived impact—on digital transformation.

(Matthew Skelton at 00:18:57) So it's an interesting point. We're doing quite a lot of work with lots of different organizations, different parts of the world at the moment. It's a bit of a nightmare for my calendar to try to work out which time zone I'm in when I'm talking to a client. But anyway, that's a separate challenge. What's interesting about—what seems to be interesting and valuable about Team Topologies, talking to our clients and talking to other people who've used it, is it's not simply a restructuring.

(Matthew Skelton at 00:19:24) It's not just another organization design. Because of the principles that we've got in the book—and there's a whole host of them—it's helping organizations to rethink their, at least rethink their technology strategy. But also in many cases, actually help to rethink their business strategy or help to think how well technology aligns to their business strategy and pushing out into business subject matter experts and trying to get more clarity about the key aspects of the business domain, for example. Because we want to align teams typically to slices or segments of the business domain. And so then having that conversation actually makes our teams more responsive because we better understand what the business domain is, and we're now going to align our teams to those things. And so suddenly we're able to actually—we've reset our thinking, and we're now thinking in additional dimensions, if you like, about cognitive load, about flow, about these other things.

(Matthew Skelton at 00:20:25) And we're now able to much better serve the needs of the organization in terms of technology delivery. It's not just a kind of new team structure or organization design. It's this rethinking about how technology can serve, can meet the business need, can serve the business need, because we've got—we're thinking about these other things as well. That seems to be a key part of why it's valuable.

(Joel Beasley at 00:20:48) Yeah. One of my favorite books back here is Principles by Ray Dalio. And it sounds like you've got some pretty great principles inside of Team Topologies. Like, I get it. It's not like an instruction, like step-by-step, here's how to organize the team, but it includes a lot of these principles. And I think just the beginning, what you said about optimizing for fast flow, reducing handoff—that right there is just well said. It's just a valuable piece of the puzzle. Now for you personally, as one of the authors, what was your favorite chapter in the book?

(Matthew Skelton at 00:21:27) That's a good question.

(Joel Beasley at 00:21:28) Yeah. Feel free to open up the index. I would need to do the same thing with my book.

(Matthew Skelton at 00:21:36) That is a really interesting question. I think the chapter which actually ends up—I think the chapter which is probably—well, certainly Part Three of the book has the content which is probably most novel. And probably Chapter Seven, where we're talking about the team interaction modes, is the one which I think is, out of any of the chapters, probably helped the most. Actually, the cognitive load aspect—the chapters on cognitive load—have definitely helped a lot of people. But we didn't invent cognitive load or the concept of team cognitive load.

(Matthew Skelton at 00:22:15) That's all out there. The team interaction modes is something that we did put together that was new and seems to have really helped. There's a really interesting case study that we came across from a company, a retailer in the UK. And they actually said that the product managers really valued the team interaction modes because it actually helped them to plan out their product roadmap and make sure they were lining up the teams at the right point in time so they could deliver stuff and set the expectation from the teams that these things are going to happen and it was going to feel like this. It's going to feel like you're switching from collaboration to consuming something as a service. And so it actually helped the teams to—you know, setting some expectations beforehand.

(Matthew Skelton at 00:22:51) And that was a really interesting take that, actually, the product managers found some aspects of the book that actually were super helpful for them to manage the multiple different product streams. So at the moment, that chapter is my, I guess, probably my favorite. In a few months, it might be different. We'll see.

(Joel Beasley at 00:23:08) So that was Chapter Seven, Team Interaction Modes. Is that what you said?

(Matthew Skelton at 00:23:13) It's Chapter Seven on team interaction modes, yeah.

(Joel Beasley at 00:23:19) Nice. So I was reading that, one of the chapters, about four different types of teams: complicated subsystem, enabling, platform, stream-aligned. Can you break those down for me a little bit?

(Matthew Skelton at 00:23:32) Yeah. So our starting point is a stream-aligned team. This is the cross-functional team that has end-to-end responsibility for delivery of a flow of change for one particular part of the business domain, usually. So we use techniques like domain-driven design and similar things to identify these boundaries for these teams. But once we've got those in place, that team will be substantially autonomous.

(Matthew Skelton at 00:23:53) They'll be able to deliver changes basically by itself. They will have dependencies on other things like infrastructure and marketing platforms and stuff like this, but there won't be any—they won't need to wait on anyone to do something as they're making that change flow towards production because they can just consume the APIs. So that's our starting point. And if you can get by in your organization, if you can survive with only the stream-aligned teams in place, then that's a really good situation. Typically speaking, once you get to a certain size, like, who knows, thirty, fifty technologists inside the organization, typically that's when you start to expect some sort of platform to emerge, just because there's many commonalities, and these teams would end up duplicating a whole lot of stuff, which would be better served by being carefully curated and managed as a product in the platform.

(Matthew Skelton at 00:24:45) And certainly as you get to that kind of size, it's useful to have some experts who end up enabling some of these stream-aligned teams to do some more specialist things, like adopt new technology or move, upgrade from one technology to another, or to learn how to use a new technique, something like this. Might be around data privacy, for example, which is a quite specialist thing, or something about credit card payments, whatever. So something that's specialist. And so you typically have this one or more enabling teams helping, on a time-limited basis, helping the stream-aligned teams to do something over a fixed period of time. And then we've got a complicated subsystem team type, which is only really necessary if you have some really complicated processing that's happening in part of the system, like complicated maths or vector matrix type calculations going on.

(Matthew Skelton at 00:25:40) Generally speaking, if you can avoid having a complicated subsystem, then you should avoid it. But really, these three supporting team types—the enabling team, the complicated subsystem team, and the platform team—their primary purpose is to reduce cognitive load on the stream-aligned team. That is really the starting point for those other three teams. If they are not reducing cognitive load on the stream-aligned teams, then they're not fulfilling their purpose. There are some secondary things that these other teams can provide, but our starting point is the lens, if you like, through which we look is the starting point is that these three team types—the primary thing they do should be reduce cognitive load on the stream-aligned teams.

(Matthew Skelton at 00:26:15) They shouldn't certainly be adding cognitive load by making it difficult to integrate with the platform, for example, which is often the case from platforms of the past, right?

(Joel Beasley at 00:26:29) That's funny. So when your customers—how are they finding you? What's the problem they're experiencing, and what's their life like when they decide they need—because, like, for some background, do you have this book and it helped your consulting business? Now your consulting business is growing. You help companies do this, structure teams.

(Joel Beasley at 00:26:48) But, you know, what causes your customers to make that call and reach out to you?

(Matthew Skelton at 00:26:52) Good question. So we do a lot of speaking, lots of different events. So I guess we end up being quite well-known through that. The publishers, IT Revolution, are very, very good at what they do. Amazing editors, amazing publicity people and so on. And so word gets round, and they do things like, you know, online, massive-scale ask-me-anything sessions, AMAs, and all kinds of articles and stuff like this. So we've been helped a huge amount through IT Revolution. But both Manuel and I have got a background in hands-on software engineering. And before—so we've been talking about, well, the patterns that are the precursor to Team Topologies is called DevOps Topologies.

(Matthew Skelton at 00:27:40) We've been talking about those since 2013. So what's that? Seven years now. And between that time and now, we are both speaking about engineering practices as well. So we are inside organizations doing stuff like automation and deployment pipeline creation and looking at team boundaries and looking at team practices and things.

(Matthew Skelton at 00:28:03) And I think that's a key aspect of why people like to come to us. We're coming at this organization dynamics space from the perspective of really being in the middle of building and running software systems. We're not coming at it from an organization design or an HR viewpoint or a management viewpoint. We're coming at it from a strongly technical background. And I think that really helps.

(Matthew Skelton at 00:28:28) We deliberately use some of that terminology in the book. We talk about a team API, which is—so API, application programming interface. So that's obviously how we describe how we interact with a bit of software. And we've taken that term and made it into something which sounds much more relating to humans. And that's deliberate because we're trying to bring that terminology into how we think about teams and think about the organization.

(Matthew Skelton at 00:28:52) So I've—and certainly this combination of strong awareness around software engineering and delivery practices, operations practices as well, and telemetry and metrics and infrastructure, and also then awareness of this kind of sociotechnical aspect of software development delivery that we talk about in Team Topologies book. I think this combination seems to be very valuable. Because without the strong technical background, just talking about how you arrange teams feels potentially a little bit empty. So certainly there's many cases where what we end up doing for our clients is working on the shape and responsibility of teams and the dynamics between teams, and also working on technical foundations as well.

(Joel Beasley at 00:29:41) What—sorry.

(Matthew Skelton at 00:29:43) No. Go for it.

(Joel Beasley at 00:29:44) Oh, I was curious, what's the size? What's the size of your normal customers when they're reaching out to you?

(Matthew Skelton at 00:29:52) Whole host of sizes. Anything from roundabout forty, fifty people, smallish, through to some of our customers have got 10,000 employees, so quite large. I don't have the revenue figures off the top of my head, but I mean, you can extrapolate from that—from low millions into billions is what—so quite a range. And obviously, we're often just working in one area of a larger organization, typically as a pilot. And then we often look to try and expand that out into other parts of that same organization.

Matthew Skelton at 00:30:30: There's only a particular—you can't try and tackle too much at the same time effectively. A key aspect of the Team Topologies approach is we're not trying to do a big bang change. We're trying to do an incremental evolutionary change because that's how we instill the right kind of thinking and principles into the organization to help it evolve into the future. It's not just a one-off, "Hey, one big change, then we're done."

Matthew Skelton at 00:30:59: It's, no, it's much more about let's embed the principles so that we're always thinking about changing the shape of the organization to meet the internal and external business context.

Joel Beasley at 00:31:11: I'm glad you clarified that, because at the beginning of the interview when we were talking, the way that you were using "fast flow change"—to me, in companies that want this, for some reason my brain was connecting that to, like, if you want change right now and you want massive organizational change, read this book. So that's not the case. We want small, fast—that's why I had you clarify in my follow-up what fast flow changes were. And I think some of the other listeners are probably on that path too.

Joel Beasley at 00:31:42: So you want small, incremental, evolutionary-style changes within a subset of the organization and then expand that out if it's a larger one. Or if it's a smaller one, they only have 30 or 40 people, just begin implementing the principles. Is that accurate?

Matthew Skelton at 00:31:59: Yeah, something like that. Yeah. I mean, we're certainly—anyone who's offering to change an organization very, very rapidly in a short space of time is either a magician or selling snake oil or something. And, yeah, the approach is very much not about one massive change. That big bang approach, it can work in some very, very specific contexts, but it needs really strong CEO-level buy-in and that kind of urgency of vision and execution right from the top. When we're talking about something which is a bit more normal, if you like, a normal situation, then we need to help organizations to be—whether you use Team Topologies or whether you use something else, I mean, organizations need to be able to change on an ongoing basis. The idea of a big reorg every three or five years is just crippling so many organizations because it doesn't take into account a huge number of the different dimensions that need to be thought about. And so by adopting something like Team Topologies or a similar kind of evolutionary, incremental approach, that kind of listening for change and adapting the organization to these changing circumstances just becomes part of what the organization does.

Matthew Skelton at 00:33:17: It's a much more sustainable approach. It's much less destructive.

Joel Beasley at 00:33:21: Yeah. So when we were talking earlier about, you know, "Oh, should we do pods or tribes?" You sort of bring up this concept of, you know, what terminology do you have? I'm just trying to think about in the future how I'm going to redirect people to Team Topologies after having spoken with you, because, you know, this is just for me—it's very exciting to have this conversation, right?

Joel Beasley at 00:33:45: Because I'm learning a whole lot. But, yeah, redirecting them—I think the most powerful thing that you've done is created a framework for language. You put words to the organizations that existed within a company, but people couldn't articulate them. And with this new language, you can now look at your existing organization with fresh eyes and better understand your team's bottlenecks, low-hanging fruit for optimization.

Matthew Skelton at 00:34:13: This is certainly what a lot of people say. They really value the kind of pattern language, like a language for talking about things that seems to have really empowered lots of organizations. So you're not obsessed with the Spotify model, exactly what they say or whatever. There's lots of good things in there, but it was a snapshot in time. You're not obsessed about a two-pizza team like they have at Amazon.

Matthew Skelton at 00:34:35: Yeah. Well, for a start, the size of pizza varies between countries and people's appetite varies. But anyway, apart from that, you know, it doesn't get down to the—it doesn't immediately talk about the dynamics behind it. And so, yeah, by coming with some language, which—we worked quite hard on the language. We tried to make it as useful as possible.

Matthew Skelton at 00:34:59: So we avoided the word "product team" for the stream-aligned team because, actually, in some of the situations that we worked—for example, in manufacturing—a product is a physical thing. Products these days, you know, physical products now have got embedded software and connection to the cloud and everything. But still, in manufacturing, the product is a physical thing. So you can't call it a product team because a product team is the team that will get disbanded in five years after that physical product is no longer being sold. Whereas what we want is a team that is going to own the software aspect of that thing on an ongoing basis.

Matthew Skelton at 00:35:32: So we were looking around for—that's an example of why we ended up using the word "stream." We also wanted to emphasize a sense of flow. So that's why we ended up with the word "stream," stream-aligned. And some of the other terminology as well, we were quite careful to avoid certain words and things to not get the wrong impression. Like "complicated subsystem," for example—it's kind of a horrible word in some respects. It's a bit of a mouthful. But we avoided the word "complex" because if you look at the language from frameworks like Cynefin and other frameworks that deal with complex adaptive systems, the word "complex" has a very specific meaning. And the kind of stuff that we're—the kind of things that people are building inside that kind of logic and mathematics is not complex. It's complicated in that terminology. So we were quite careful to make sure the terminology we use works well with complementary frameworks around the edge.

Joel Beasley at 00:36:36: I like that you were clear on that, because I have found that many people will use the words interchangeably. And one day, I think—seven or eight years ago, I think I watched a TED talk on complex versus complicated, and they dove deep into the differences. But I'm going to check real quick with you to make sure I remember it correctly. It was "complex" was more like a pattern emerging, like a fractal nature or maybe like a flower, right? And then "complicated" was more disjointed and less repeatable. Is that wrong?

Matthew Skelton at 00:37:14: Maybe. So in the terminology from something like Cynefin, then complicated is still amenable to reductive analysis, but it needs more experience to do so. Whereas complex has emergent behavior coming from multiple independent actors. So complex is the one where if you've got some situation which is complex in that terminology, then you can't analyze it. You have to sense and respond to what's going on.

Matthew Skelton at 00:37:46: So in that specific—so for example, a modern cloud-based software system of a decent scale is going to be complex because there are multiple independent actors, and you can't predict all the different interactions between them. So that's why you end up needing techniques like chaos engineering and SRE and things, because strange behavior appears in these kinds of systems just because of the number of actors and the unpredictability. Whereas if you're building an image processing kernel, then it's still really involved, but it's entirely predictable in its behavior. Given a certain set of inputs, it's entirely predictable. And so that's why we—that's the example of why we chose "complicated" for that type of team, complicated subsystem.

Matthew Skelton at 00:38:39: Because they are working on something which is actually predictable. It's just really involved and needs lots of experience and awareness and things.

Joel Beasley at 00:38:46: Yeah. That was a way better explanation. I love it. Who did you mention that was? I want to write that down.

Matthew Skelton at 00:38:52: Cynefin is the framework. It looks like—let me spell it out for you. It's actually a Welsh word. It was invented by Dave Snowden, who is Welsh. So Cynefin is C-Y-N-E-F-I-N.

Joel Beasley at 00:39:09: All right. Thank you for spelling that, because I put a K there in my notes. Yeah. Oh, this is good. So how did you—walk me through a little bit about you personally. Like, when did you first start interacting with technology and you knew, "Hey, I kind of like this"?

Matthew Skelton at 00:39:28: I guess, at any kind of interesting scale, probably around about the early '90s, I think, when we got a PC at home. And so I was tinkering around on that, doing various bits and pieces. So kind of early Internet dial-up Internet access, like 28K modem or something, whatever it was at that time. And then I went off to university to study computer science and cybernetics. So it was a nice blend of, you know, programming, practical programming, plus kind of computer theory, and also then building stuff.

Matthew Skelton at 00:40:07: So building robots and learning about systems, control systems effectively. And I think that was actually quite useful as a perspective. My background isn't just around, say, programming in Java. I've got the cybernetic or control systems awareness as well, which is super useful. I mean, we bring in a little bit of that stuff into the Team Topologies book.

Matthew Skelton at 00:40:36: Because for me, it's embedded in how I think about stuff in terms of feedback loops and so on. But it's clear to me, having spoken to lots of people in organizations, that they're not even aware of the principles of fairly straightforward control systems. Like a central heating system is a control system, and there's a feedback loop in there, and there's a lag and so on. Or a control system like how a steam engine works, for example. How steam engines were able to kind of power the Industrial Revolution because of the kind of control system they had that were self-correcting. This kind of thing.

Matthew Skelton at 00:41:18: There's some basic lack of awareness of how some of these things work and how, therefore, some people's mental model of an organization and what we're doing is very far from where it would be useful. People just think, "Oh, we just need to deliver some software and forget about it," rather than having an expectation that what we're delivering is probably wrong. And therefore, we need to sense for when it's wrong, feed that back into the organization, correct what we're doing, improve it, and move forward. It's a very different mentality, kind of, conceptually. Those two ways of thinking are very, very different.

Matthew Skelton at 00:42:01: So, yeah. And that was super useful. And then I went on to do various roles in different organizations. Did some network engineering. I then built some software. I wrote some software for brain imaging machines, MRI brain scanners, and then some local government websites, and then into financial services and other things. And eventually ended up sitting in the middle of the IT organization doing build and deployment, infrastructure automation, that kind of thing, which gives you real insight into the dynamics of software delivery. And, yeah, the last few years I've been consulting and helping organizations with a combination of engineering practices, both at the software delivery side and at the operations engineering side, and then increasingly helping organizations to think about the shape of their teams and interactions in what's now become a Team Topologies approach.

Joel Beasley at 00:42:59: Yeah. The way you were describing the control systems and assuming it doesn't work and looping the feedback back in—that reminds me of Elon Musk when I hear him talk about companies and business in general, because he takes the approach that the business is not going to work and we're just going to reduce our probability of failure and increase our probability of success. And I've heard a couple people talking like that, and they all seem to be—now that I'm connecting some dots right now—they seem to be people that have experience in industrial or some sort of physical manufacturing. So you think some of the principles are coming from there?

Matthew Skelton at 00:43:43: Could be. It could be. But that's also possibly because that's where these control principles were first sort of discovered. I mean, or first we were first able to work on them and evolve how those control systems work. I mean, these kinds of systems are everywhere in reality, but, you know, in the atmosphere of planets, in parts of how the body works, arguably, and so on. But, yeah, it's certainly from a business perspective, that people who have done an MBA or a business degree or have come through as a salesperson and now they're the head of sales or marketing or whatever, that way of thinking of making sure we've got a rapid feedback loop from the live system, if you like, from the live environment, rapid feedback loop so we can course correct—that's very alien to a lot of people who haven't come through an engineering-type background. You can see with Elon Musk with the SpaceX rockets—I think they've been going about ten years or something, maybe longer.

Matthew Skelton at 00:44:51: And the early rockets, they fell over. They exploded. And then they lifted one meter off the ground, and then they exploded. And then they lifted ten meters off the ground, and then exploded. And everyone was like, "Look at that, it's so rubbish." But then they lifted 30 meters off the ground and didn't explode. And then, and so on and so on. And then they could settle back down on the launch pad. And so there's this mentality of we're not going to get it right first time. And if you start with that mentality, if you start with the mentality of we are exploring the space rather than we're going to build it right first time, if you start with the mentality of we need to explore this space and learn, it sets you up in a very different way and sets you up for success in this kind of space where we're exploring the technology, we're exploring product and so on. Essentially, for success, compared to assuming that we're going to get it right first time.

Joel Beasley at 00:45:41: I like that. Very smart person. Do you go by Matt or Matthew, by the way?

Matthew Skelton at 00:45:45: Matthew.

Joel Beasley at 00:45:46: Okay. I want to make sure that we do the intro correctly and promote it all properly. So names are very important.

Matthew Skelton at 00:45:55: I tried Matt for about six weeks, and it didn't work.

Joel Beasley at 00:45:58: No? It's just too frustrating, you know?

Matthew Skelton at 00:46:00: I don't know. It just didn't work.

Joel Beasley at 00:46:04: So, you know, I'm curious—do you consider yourself an entrepreneur?

Matthew Skelton at 00:46:09: Not particularly. Although there's people around me who would say, "Definitely Matthew is." Yeah. I guess some of the stuff we're doing now is of that nature, trying to push the boundaries on different things. I guess a lot of what I'm doing at the moment is fairly entrepreneurial. We've got a few things in progress right now, some relating to Team Topologies, some around sort of related things that are—yeah, something like entrepreneurialism.

Joel Beasley at 00:46:45: I could guess. I hope you're building some sort of SaaS app to help you manage team structures. That would be pretty cool.

(Matthew Skelton at 00:46:50) We're actually working—so we're not actually working directly on that. If I had time, it'd be great. We're actually working with a couple of really interesting partner organizations doing some very similar things in this space. There's some really great, really great software available now that is coming out at kind of just the right time, if you like, to help organizations get really good insights into the relationship between teams, their interactions, and the code that they're writing. So it's a very interesting space, and the next few years, I think, is going to be some really interesting stuff that comes out here.

(Matthew Skelton at 00:47:26) Really powerful. Organizations that adopt tools like this are going to have a huge advantage.

(Joel Beasley at 00:47:32) Yeah. There was a couple that I've—I don't know if this is exactly what you're talking about, but there was like, and maybe Jake can help me type in there, but there was a company called, like, Pinpoint that's, like, helping developers measure their work and work together. And there's just a couple different softwares out there that were doing some things that I had never seen before until, like, the past year, year or two.

(Matthew Skelton at 00:47:56) I've not heard of Pinpoint.

(Joel Beasley at 00:47:58) Pinpoint. And then, Get Clear is another one of them.

(Matthew Skelton at 00:48:04) Okay.

(Joel Beasley at 00:48:04) And Get Prime is probably the most popular because they sold to one of the larger education companies.

(Matthew Skelton at 00:48:10) Mm-hmm.

(Joel Beasley at 00:48:10) That does, like, online videos. But I think those three are, like, the main ones in that space.

(Matthew Skelton at 00:48:16) So the two companies that we've been talking to, one is called CodeScene. And it's written by, or led by someone called Adam Tornhill, who's written two books on the relationship between, kind of, code and humans, or how you can actually use insights into version control history to gain additional insights into all sorts of things, including you can predict where bugs will occur by looking at your version control history, which is kind of cool because now you don't need to guess. You can just say bugs are pretty much likely to occur in this area here. But all sorts of other things, too.

(Matthew Skelton at 00:48:49) You can infer internal boundaries in the architecture from looking just at the Git history. You can look at some team relationships, all sorts of things like this. That's really, really interesting. Working on that at the moment with a client in North America. And there's another company based in Australia called Teamform. They've just changed their name. They're called Teamform. They're doing kind of all sorts of things, but one of the things they offer is around helping organizations to assess the current relationship between multiple teams and therefore get a sense of whether those relationships are helpful towards the architecture we want to build, or whether those relationships are actually likely to be working against the kind of architecture we want to build, thinking about Conway's Law, that kind of thing. That's pretty interesting. Some really cool stuff coming out. It's early days, but some really, really interesting tooling coming out.

(Joel Beasley at 00:49:42) Yeah. There's some, you know, legitimate uses for these tools. Like, I hear a lot of people at the large organizations trying to find, like, experts within the organization on specific topics. And my first thought was, why don't you just do code analysis and see what type of features people write, see what type of systems they have experience with? Because the way that they do it without looking at code analysis is they'll have, like, an internal company profile and they'll put tags, you know, whenever they update their tags, and that's like one way to do it.

(Joel Beasley at 00:50:16) But if I'm sitting here and I'm like, okay, we need to find out who the smartest person in our company is with authentication. Like, show us that person. There's no technical reason why we wouldn't be able to do that with the skills we have out there today.

(Matthew Skelton at 00:50:32) Yeah. Yeah. That's—I think there could be all kinds of tooling in this space over the next few years as, particularly, and it'll be accelerated with the remote-first way we're working. You know, there's companies that have just sold their offices and never planned to go back or really downsized. And so actually, you don't have any direct eye-to-eye visibility of the team, so it'll be derived from, you know, interactions in different online tools.

(Matthew Skelton at 00:51:01) So in this space, this kind of tool—there'll be more and more of this kind of tool.

(Joel Beasley at 00:51:07) Yeah. No. Thank you for bringing up CodeScene and Teamform. I'm going to check them out. And by the way, I have an enormous amount of respect for you for your ability to grow your company beyond yourself. Right? Because I see so many consultants out there that it's just like one or two people just doing it, and you've been able to, like, build a team and grow it. And that's, like, one of the hardest things to do.

(Matthew Skelton at 00:51:32) Yeah. It's—I mean, I'm fortunate because I ran a company. Well, I was the technical director of a small software company in London for just over five years. So I had some early experience in kind of the dynamics that are at play there. So building partner relationships, doing all the kind of new business stuff with clients and so on.

(Matthew Skelton at 00:51:54) So that was—and also, a lot of the work we did there was for high-profile brands. So I got—it's like in my DNA now, kind of like, don't mess with the brand. Don't mess with the brand. Pixel perfect. All of this kind of stuff, which a lot of software folks don't necessarily have unless they've been at the, you know, really the front end of software development.

(Matthew Skelton at 00:52:17) So I had an eye for some of that kind of branding and how things look as well.

(Joel Beasley at 00:52:24) Yeah. I like your font. I like your logo and your design.

(Matthew Skelton at 00:52:28) Yeah. Yeah. That was good. So we've got strong—small but growing and strong—partner relationships. That's one of the things we're doing right now, actually, partly because, partly because we've been really successful.

(Matthew Skelton at 00:52:42) It's a nice kind of success to have where you have no time, basically, because you're too busy working. So one of the things we're doing now is building out our partner network and getting opportunities for partners to deliver some, certainly some of the training, probably some of the consulting and other offerings that we've got as well.

(Joel Beasley at 00:53:01) That's exciting. I think you'll do very well. Is there—we're approaching our hard stop time here. So is there anything else that we want to get out there? Any call to action?

(Joel Beasley at 00:53:11) We'll put your information in the show notes. People can reach out and buy the book and learn more.

(Matthew Skelton at 00:53:17) Yeah. So if you want to learn more, just go to teamtopologies.com. There's a whole set of information on there. We're putting more kind of background information, slides, videos, getting started guides. We've got a load of stuff on GitHub as well.

(Matthew Skelton at 00:53:30) So free templates, you know, send us a pull request. It's all, well, technically, it's sort of like open source. It's Creative Commons because at the moment, most of that stuff is text, not code. Anyway, it's on GitHub. So just github.com/teamtopologies.

(Matthew Skelton at 00:53:44) You'll find all that stuff there. We are working—we're working on some new material as well. So if you just sign up to the newsletter, you'll find the details. We have got training, plenty of it. It's all remote-first. Lots of different flavors of training, from a kind of quick introduction—two hours—through to a full day's worth of kind of platform-focused training.

(Matthew Skelton at 00:54:08) And we've also got a two-day course covering all the key concepts in Team Topologies. So if you're interested in any of that, just head to teamtopologies.com, and you'll find the contact details there.

(Joel Beasley at 00:54:20) Oh, excellent. So if they want to do a course to go through these principles and these concepts to talk with you, it's like it's a remote course, and they can go to your website. Cool.

(Matthew Skelton at 00:54:29) Yeah. And we've—the training used to be in person, but we've obviously took the last few months to really reshape how we do things. And to be honest, I think the online training is actually now better than it used to be in person for various reasons. The tooling is really nice now. So I think the attendee experience consistently is good for people.

(Matthew Skelton at 00:54:47) They really appreciate how we've done the course, how we deliver the course, and the kind of exercises and mix of things that we do in the sessions. It seems to be good.

(Joel Beasley at 00:54:57) Excellent. Well, thank you so much, my friend. This has been an absolute pleasure.

(Matthew Skelton at 00:55:01) Thank you very much. It's been great to be here.

(Joel Beasley at 00:55:03) Talk soon, buddy.

(Matthew Skelton at 00:55:04) Thanks, everyone. Cheers. Bye-bye. Cheers.

(Joel Beasley at 00:55:09) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.