#055 - Matthew Skelton - team topologies

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

And I'm Murray Robinson.

I'm Matthew Skelton.

Hi Matthew, thanks for coming on to talk to us today. So we want to talk to you about your book, Team Topologies. Can you start by telling us a bit about who you are and what your background is?

Sure. I'm the co author of Team Topologies along with Manuel Pais. I am founder at a company called Conflux where we help organizations to navigate fast flow. Originally, I started off as a software developer building software for brain imaging machines and then oil and gas industry, and then local and national government and financial institutions. More recently I've been increasingly involved in helping organizations to understand and reason about their internal and external capabilities for building software enriched systems. And that's where I found myself today.

Okay, so what's the problem that you're.

Trying to solve in 2022 when we're recording this podcast? Software is enriching a huge part of our daily lives and certainly it's enriching the services on which we depend. If we go back 20 years, when I started my career, software was a specific thing. You built a piece of software and it sat on a computer and it did a specific thing, whether it was word processing or some counter package or something, and it was very focused in on a particular task. But now software is increasingly pervasive. It's controlling cars, it's controlling your washing machine, and it's interconnected. You get alerts on your phone about spending from your digital bank. This thing, it actually becomes much more all pervasive than it has done in the past. The problem is that many organizations have not actually caught up with the reality of that. Many organizations are still seeing software as a series of projects which have a fixed start and end date, a fixed budget, and we're delivered on time, on budget. That's increasingly not relevant. It hasn't been relevant for a long time, but it's increasingly damaging to software when actually software really in many situations is an ongoing service that needs care and nurturing and attention. It's not a thing which you deliver and then forget about. It's a thing that needs ongoing investment and awareness and, and buy in from people and mental context and all these things, particularly when cloud came along. So from say 2008, when Amazon EC2 was launched, and since then, compute infrastructure is no longer a bottleneck. We can provision this in seconds or milliseconds, even for container fabrics. And the thing that was actually a huge bottleneck for software delivery 15, 20 years ago is no longer there. So organizations can actually build, test release, update new services in a single day or in a few hours. That pace of change, that ability to do that quickly, means that we can have very fast flows of change through the organization to do new things, to update how services are defined and delivered, and so on. And effectively. This new world of fast flow opens up lots of opportunities and also highlights how unsuitable some older practices are. And if we want to take advantage of the opportunities around fast flow, then we need to think about new approaches or revised approaches that actually might look quite different from the past. And what we're doing in Team Topologies is zooming in at the teams and team interaction level, look at how that relates to the architecture of our systems, look at how we might need to adopt some new principles or emphasize different things more because we're able to have a fast flow of change. And so we're talking about team responsibility boundaries, we're talking about architecture, we're talking about how team interactions affect what we build. We're talking about things like team cognitive load, because in the historically, in the past, most organizations didn't really think about the cognitive load they're placing on software and IT teams and so on. It's been described as components or aspects of a new digital operating model. So it's not an operating model in itself, but it provides the bits and pieces and principles to help organizations construct a new digital operating model where software enriches a huge part of the services that organization provides. Whatever they're doing could be retail, it could be manufacturing, it could be banking, whatever. Software is enriching a huge aspect of the services that organization providing. And we can do it, and we can make changes very rapidly. But that means that we need some new operating principles effectively. And Team Topologies is seeking to provide the operating principles at the team level, the middle of the organization.

All right, so what are the common problems with the way that organizations have organized their teams to deliver these software products and services that you see?

So historically, lots of organizations were organized in functional groups. So you might have had a group of software developers, like a department of software people building stuff. I had a separate department of people testing things, separate department of people releasing things, and a separate department of people operating things. That's quite common. Build it, test it, release it, run it. And that was reasonable at one level. It was never the most effective way to do it, but you could understand it. When the speed of change was limited by the speed with which we can provision infrastructure, then it's understandable. That was how some organizations did things. But the handoffs we've got there between those different groups is incredibly ineffective for flow. So one of the worst things you can have in a fast flow context is handoffs between different groups, irrespective of the situation. It's just a fundamental mathematical principle. If you read the book by Donald Reinerson, whose name escapes me, Principles for Product Development Flow. Exactly this one. And it goes through in quite a lot of detail about the way you should absolutely never load up a team, 100% capacity because it's just ineffective in the flow context and so on. But also crucially talks about if we want to have, if you want to have good flow, whatever we're doing, but including in an information context like software delivery, then we need to allow architectures that permit work to flow in small decoupled batches. So the teams themselves need to be loosely coupled and have a sense of end to end responsibility to allow that work to flow. The starting point in team topologies is what we call a stream aligned team. This is a team that has end to end responsibility for a particular flow of change. That might be a user journey, it might be a service, it might be a product, whatever. And that team has got end to end responsibility. There's no handoff to another team before that thing goes live. And so a starting point is really that software needs ongoing care and maintenance. The people who build it are the people who run it. Now, this model has been proven out by organizations like Amazon for nearly 20 years and it has not stopped Amazon from growing to massive scale. AWS particularly, but Amazon in general, it's certainly not hindered them growing to massive scale. If you look at some of the analysis of what Amazon actually does, as they add a new person, they get a new person's worth of effectiveness because of how they've designed the organization. In the senior bodies. We did a bit of reverse engineering of what's actually going on there because Amazon talk about it, but not in terms that we were interested in exploring. Many organizations, by contrast, if you add an extra person, you get maybe a fifth of an extra person in terms of effectiveness, because the organization is scaling in a way which is less and less effective. And so a team to bodies, really what it's really pointing to is actually a series of principles for scaling the build and run of software enriched services. That's what it really is if you unpick it. Because we're keeping things loosely coupled, because we're thinking about the interactions between teams which I can maybe talk about later because we're thinking about cognitive load, which is very human. We're bringing in concepts from domain driven design to help us think about what's the core mission of parts of the organization, what's the supporting mission, and what's a generic thing that we shouldn't be building at all. We're starting from the principle that actually we need to build and nurture and evolve this software using the same people. And therefore we're avoiding these handoffs. We're giving these people in the stream aligned team the context of what's happening in the live environment because they're responsible for it. And so they have the best incentive to build the software in a way which makes it operationally effective. It's not just a case of building it and then oh, we're done now. We don't care how this thing actually runs at scale or runs in production. No, no, no. We want to be able to build this software in a way which makes it operate effectively for the users and customers. And so that's a starting point with avoiding these handoffs that we've seen traditionally a team that has end to end responsibility, but clearly that has a limit which we might talk about as well. You can't keep giving a team like that more and more responsibility. There's some other things that we put in place to deal with that sort of limitation or realization.

The other common problem I've seen in organizations apart from functional silos is this problem where teams don't have the power to make decisions. So decisions are held and made at the higher level. And so teams have to wait for somebody to allow them to do things or tell them what to do. Do you address that as well?

Yeah, absolutely. It's a very good point. In a fast flow context, the organizations can't afford to be waiting for someone to make a decision. Not on everyday things. It's worth waiting to make a decision before you decide to switch from one cloud provider to another or some major product switch or new market that you're going to find. Wait for a decision on that. But for everyday changes, we're responding to a security incident or we're going to change this checkout flow or whatever it is. Everyday stuff like that. There's absolutely no way that organization can be waiting on someone to take a decision. So what's the alternative? We need to turn those blocking dependencies, blocking checks, into non blocking checks. And a huge chunk of what we're talking about in detailbodies is actually about that and ways of doing that and ways of doing that safely, and principles and terminology that we can build in an organization, that an organization can adopt to help them think through that stuff. So we want to empower these streamlined teams to be able to deploy safely and continuously the speed that's appropriate for them, but without having to wait on other people to make decisions. But that means that things like security compliance, user experience, data validity and so on, all of those quite tricky areas, instead of the decision residing in a team that needs to check everything, because that just doesn't scale when you've got hundreds of teams. There's no way that a security team can possibly have enough context to check security details for all those teams. So what do you do instead? What we need to do is use that expertise in the security team, or the data team, or the UX team, or whatever, turn that expertise and help uplift the capability and awareness inside multiple streamlined teams in the organization. And there's broadly two or three ways to do that. And the first is with using what we call an enabling team, a team of experts that work for a limited period of time, a time bound period of time, with one streamlined team after another to help increase their skills and capabilities and awareness, help them adopt a new tool that helps them to be more secure, for example, or helps them to understand how to do data preparation for machine learning better, whatever it might be. Stuff like this help them to understand some core tenets of user experience so they can build things better. So those experts working as an enabling team, they might work with a streamlined team for three days or couple of weeks, something like this, but then disengaged, so they're not a permanent crutch. There's no permanent dependency there. So that's one pattern we've got. Another pattern is that a team of those experts might end up helping to build a component, if you like, or a subsystem as part of what we call a complicated subsystem team. So it's a group of people with a deep specialism that can help build something which otherwise would be too difficult for streamlined teams to actually build work on themselves. So we're taking away the cognitive load from the streamlined teams by encapsulating that thing somewhere else. But the driver for that encapsulation is team cognitive load and flow. The driver is not, oh, here's a nice bit of technology, we'll put a team around it. It's this technology so awkward and complicated that it will be difficult for a streamlined team to work on that thing themselves. It would Increase their cognitive load, their flow would slow down. And then the final pattern is what we call a platform, which in team topologies terminology is anything, anything that improves flow in streamlined teams by reducing cognitive load. A platform can be as simple as a wiki page with a set of checklists or predefined technology choices or something. Or it could be a piece of technology with some services and things. But again, the point there is if we can embed a set of services around, say, security checks or data preparation, or user experience, experience validation, something like that, then streamlined teams can self serve these capabilities from that platform and therefore retain their independence. So we're not doing away with expertise. What we're doing is we're changing where that expertise sits. Instead of the expertise sitting in a team that is trying to check everything before it goes out, we take that expertise and deploy it into enabling teams, complicated subsystem teams, and platforms so that the streamlined teams can self serve those capabilities. Many organizations have been doing that for a long time. But for some organizations, for perhaps the majority of organizations, that approach feels new.

So you quite often see a security team, for example, which would be an enabling team, perhaps. But what they actually do is they act like the police and they won't get involved early. And getting them involved takes a long time. You've got to fill out all sorts of forms. And then when they do get involved, they generally come on at the end until you've done things wrong, and they're not going to allow you to implement things. So how do we turn them from being this controlling police force or auditor into an enabler?

So usually what's behind the behaviors there is the team's understanding of its goals and incentives. It might not be the actual incentives that the organization has put in place, but it's that team's understanding of what its mission should be. If that team believes that it will be punished or held to account if there's a security incident, then it's not surprising that it wants to get acted as a police force. If instead we change the incentives and make it explicit that their role now is to increase the security awareness inside multiple teams, is to increase flow around security changes. If their responsibility is much more focused on embedding and increasing capability in teams and enhancing flow, then you'll see some behavior changes. From a compliance perspective, there's still some challenges. You need a single point of contact and blah, blah, blah. But you can deal with a good chunk of the challenges around team behavior by changing how we characterize that team's Mission effectively. If the mission is primarily about enabling flow and building capability across teams, then you'll see behavior change.

So the way I understood when I read through it is that enabling team is a team of coaches. Their goal is to help the stream aligned teams to get some more skills, some more capability and then once those streamlined teams are self sufficient, get the hell out of dodge and go and help another streamlined team. Is that the idea of the enabling team? They are that upskilling education coaching type group to help somebody else do the work that they used to do.

The enabling team pattern that we've got in the team's project is slightly broader than that, but yes, and that's part of it. The enabling team actually acts as what's called a boundary spanner in organization design because it's working across multiple streamlined teams. It can detect common problems or unusual problems, create that awareness and take that back into the organization. Say 19 out of 25 of these teams have had the same problem around their understanding of machine learning. What can we do? We can hire more machine learning experts, we can send people on training, we can provide some better services from the platform and so on and so on, detecting they're acting as a organizational antenna to detect problems. And that's hugely valuable because otherwise if we don't have that team that is working across multiple other teams, we're going to lose that insight. So that's part of it is to act as a way to detect what capabilities we need and give some options about how we put those capabilities in place. But yeah, some coaching can be useful. Coaching, mentoring are obviously not the same, but getting people to the point where they're able to wear the right hat and adopt the right behaviors at the right time can be really useful. The enabling team definitely does not build stuff for the streamlined teams. Absolutely not. Though people in the enabling teams might be tempted initially to do that because they might be an expert in, I don't know, building or integrating with single sign on systems or something like this, like security personnel. But they must not get involved and do the work for that streamlined team because then who owns that work that's been done. The work should be inside the streamlined team. So sometimes the experts in the enabling teams need to hold themselves back a bit. They need to understand how people learn. And people do not learn by someone else doing the work for them. They learn by doing it themselves, by being led gently with useful questions from a coaching perspective or mentoring perspective to help them realize things themselves. But the focus there is, yeah, keep these streamlined teams as independent and autonomous as possible. But to have that autonomy, you need to have awareness and skills and ability to make sound judgments around security, data, ux, all these tricky things. It's not reasonable to have embedded experts in every single team. That's just not reasonable either. That's an approach that some organizations have taken in the past and it just doesn't scale either. We need to have a more of a dynamic approach to where these capabilities and a dynamic way of assessing how and when we need to enhance capabilities.

So then when I look at complicated subsystem and platform teams, the way I think about it and seems to align the way you've described it is the complicated subsystem or the platform teams are doers. But the complicated subsystem team will parachute into the stream aligned team and build something that's complicated that the specialist skills are needed. As part of that stream aligned team.

The complicated subsystems team is building its own subsystem. There's no parachuting into other teams and doing things for them. That is a defined service or subsystem that they are building on an ongoing basis and looking after it a bit like a product. There's a clear decoupling between these four different types of team all the time.

So then what's the difference between a platform team then? Because they're effectively building a product that the the streamlined teams used as well.

That was a very good question. I'm glad you asked that. What we've realized is that a complicated substance system team is like a tiny platform with just one focus, whereas a platform typically would have multiple other focuses. But it felt useful to actually characterize that out because particularly with the history of previous approaches to software delivery, previous approaches have talked about feature teams and component teams, for example. So a lot of organizations have got the idea of building teams around components. And what we wanted to do is to tie into that by saying sometimes there is value in having a team around what you might call a component or a subsystem. But from our perspective the value is in reducing cognitive load and improving flow and streamline teams. And that should be the decision criteria. From our perspective, that's the decision criteria and it changes a lot about how you decide to do things because otherwise you end up with like thousands of component teams. Because hey, here's a little piece of technology which looks interesting. Yeah, we wanted a way to bridge from that previous way of thinking about team boundaries into a flow centric, flow aligned way of thinking about team boundaries and responsibility and capability so that's why we distinguish it. A complicated subsystem team is like a tiny super focused mini platform.

So the complicated subsystem teams and the platform teams are doing the work. They're building stuff that is used by the stream aligned teams.

Yes.

And that's the difference between them and the enabling team, which is not doing the work right, it's helping the stream aligned teams do the work.

Admin teams are doing hard work for sure, but they're not building stuff. They're not building and owning things on a long term basis. And that's a really important thing.

Okay, so then is it common for whatever the complicated subsystem team builds to get moved into the platform team over time, where the platform team then manage that subsystem as part of the broader platform? Or is that that tend not to happen?

That can happen. It depends on what they're building. If the complicated subsystem team, for example, is building a library component that gets pulled into software at build time, then that can't really be part of a platform in the same sense because it's somewhat isolated anyway. But if that complicated system is like a service that can be called at runtime, then yes, eventually it might get moved into a platform. If there's value in that, if there's value in using the product thinking that a platform is going to have, then that might be a valuable thing to do. It's certainly a thing that we've seen and it certainly makes a lot of sense. And because a complicated system should be operating a bit like a mini platform, then there's always that option.

Could you clarify the three interaction models? I think you've touched on them, but may be good if you could just be specific about them.

Good question. One thing we realized as we were working with our customers back in 2015, 2016, 2017, just before we were starting to write the book, is we could see people in different teams getting really confused and really frustrated about having to work with other teams across the industry. There's a real lack of clarity about the purpose of working with another team. And what we wanted to do is to provide the language and set of principles and ways of thinking about when and how we should work with other teams in the context of fast flow, in the context of things like Conway's law, which effectively is talking about the mirroring effect you get with organizational communication and the resulting system architecture. So there's a tendency for a system that gets built, whatever system it is, to reflect the communication paths in the organization. And this has actually been validated across multiple industries, software and jet engine design and car manufacture and a bunch of other things. It's is a tendency. And so we need to be aware of that. And if we have communication between teams that is quite ad hoc and not directed, not deliberate, there's a danger that we also get blurred boundaries between different system components. And if we want fast flow, if you want to be able to change different things very rapidly, those blur boundaries potentially be quite awkward because we might have one particular domain concept actually sitting in a different component. And therefore two teams have to make some changes at the same time in order for that thing to get released. If you're going really slow, slowly, and you only have one deployment per year, fine, you can probably manage that. When we're talking about multiple deployments per day, that thing becomes a real blocker. So we need to have our organization think about flow. We're thinking about where capabilities and concepts sit inside the software so that we can have multiple flows of change. And so ad hoc communication between teams becomes a problem because it works against flow. It works. We're not thinking about Conway's law, we're not thinking about the possible unlikely results of this ad hoc communication. And also fundamentally, if you're having to have 10, 20, 15, 70 teams all collaborating and working together all the time in order to get something out, then that's a huge monolith of effort and dependencies, which again, works against flow, works against real business agility. So what we did is to think what is the smallest number of different interactions you could have between teams that are needed to enable a fast flow approach to software delivery? And what we've defined is three team interaction modes. First is collaboration. But our version of collaboration is very specific. It's two teams working together for a defined period of time to achieve a specific outcome. And that period of time should be days or weeks, not months. The purpose of collaboration, typically is to find where we should put a boundary between those two teams collaborating on something to do is let's work out where we should split this domain, or let's work out how this service should work so that one team can provide and one team can consume it. And why do we care about that? Because boundaries are incredibly important to enable fast flow. If we get the boundary of responsibility in the wrong place, then we're likely to have teams waiting on each other. If we collaborate and find a really good boundary, that means that one team can easily provide something, another team can easily consume it. It gives those teams good autonomy over their different areas, then that's great. The purpose is to find good boundaries for flow. There are a few other things that we might want to collaborate on, but generally speaking, that's what we're aiming for. So we can say, hey, look, we are working together with this other team for the next, say, four days, and we're expecting it to take about four days based on past experience. It's going to feel different, it's going to feel really intense. You're going to be pairing with those strange data science people who don't speak software, they speak data science. But the purpose is to try and understand where this boundary should sit. So it's going to feel weird for four days or whatever it is, a couple of weeks. But don't worry, if we work out what we need to do, then we'll change our interaction mode and hopefully we'll be moving towards something that we call X as a service. One team's providing, one team's consuming something as a service and then it feels nice and straightforward, then it feels independent again, we feel autonomous again. But by defining different ways of interacting, we can set expectations with people inside teams, we can check our roadmaps and things say, well, actually, we are going to need a period of collaboration in a few weeks time whilst we deal with this data preparation service. And therefore we are not going to be delivering during that time, or certainly not delivering as fast as we were. So bake that into the expectations, set the expectations up ahead of time and so we can set expectations saying, hey, it's going to be really intense next week when we do this collaboration with the other team and it'll feel very different, we won't feel autonomous and we'll have to learn this new language and we'll have to remote pair or sit down with data science people. That can really help to avoid the confusion that I talked about before that Manuel and I saw before we wrote the book. That's certainly part of what we wanted to address. Set some expectations with people, what it's going to feel like. There's a third team interaction mode, which is what we call facilitating. And facilitating is the mode that's commonly used by enabling teams, sometimes by other teams too, where we are helping another team to increase its capability, increase its awareness, where we're helping them to build something and increase their capability so that other team can be autonomous. Now, typically speaking, that facilitating mode of interaction is used by enabling teams, sometimes by other teams too. But again, that feels very different. So if I'm working in a streamlined Team, let's say I'm responsible for the order fulfillment process for some retailer. My main focus is building software and thinking about the user journey for that fulfillment process thing and thinking about product codes and product details, whatever. But we now need to start using some machine learning approaches to help us improve what we're doing. I don't know anything about machine learning, let's say. So we're going to bring in the enabling team that has got some machine learning experts in there and they are going to use facilitating interaction mode during the next week. As someone in the streamline team, I'm going to have to expect to learn. I'm going to have to put my ego to one side, I'm going to have to learn, but I'm not going to get someone to do it for me. I have an expert here who's going to, by the way in which they interact with me and my team. They're going to help me learn just enough about machine learning and data preparation and whatever so that me and my team are going to increase our awareness of how to do that thing around machine learning so that facilitating things feels very different. We're not building stuff, but nor are we trying to find a good boundary because there's only one team building anything here, the experts helping us to increase our awareness. Those three different team interaction modes feel very different. But because we can set expectations with people, prepare them for how that's going to feel, we can reduce the frustration, we can make it much more clear the purpose of working together with another team so it becomes like a language and a set of expectations for working together with other teams to achieve something. And it avoids this open ended mashable mushing together of different teams, which then just creates huge flow dependencies.

You've talked about cognitive load a few times. Could you explain what you mean and what the issue is there?

Sure. The cognitive load theory is developed by John swaller back in 1988 and it actually relates to situations where an individual is learning. The human brain has got limited capacity in the working memory, so when we're learning things, we can actually only take on new stuff in a sort of limited fashion. When we're building software or running software, we're actually often learning. This is a key challenge of Agile software delivery in general, which is a lot of what we're doing all the time is learning about new things when it's not a factory, as you know this. But a lot of people still have this mental model of software delivery being like building something like a factory. We're building widgets and it's not at all. It's about encoding business intent. That is all that software is. It's literally the encoding of the organization's intention. And so there's a lot of learning to do. So cognitive load comes in into software development and operations all the time. So we need to be aware of it anyway at an individual level. And broadly speaking, there's two or three types of cognitive load. One is intrinsic cognitive load, which is things that effectively we've learned and which sort of which don't get in the way of further learning. There's extraneous cognitive load, which is things that impede that. So we talk about team cognitive learn, not individual cognitive load. We are applying it to a team level because from a team bodies perspective, the team is small grouping for work to happen. We actively recommend not to assign work to individuals. It should be at the team level. So we've got some things that we've learned which help us to do things quicker. We've got some things which distract and things that we really should be focused on from a domain perspective.

That's the theory of it. But you're talking about minimizing cognitive load.

No, so we're talking about minimizing extraneous cognitive load.

So that would be like maximizing focus.

So effectively it's about maximizing focus, you could say, or maximizing cognitive space available for the main domain focus of that team. So yeah, if you hear me talking about minimizing cognitive load, it's a shorthand for minimizing extraneous cognitive load. The stuff that is actually getting in the way of us being able to properly own and think about this domain that we're working in. Because that cognitive has to go somewhere. If we remove it from a streamlined team, it's going to go somewhere else. It's going to go into a complicated subsystem team or maybe into a platform or somewhere else. It doesn't magically just be. We can also train people, increase the skills, have a skills uplift in the streamlined team and that can deal with the cognitive load aspect. Because if there's something which it feels like extraneous, it's really difficult to use this programming language or this tool. We can train people, then that cognitive load turns into intrinsic. So there's multiple different ways of dealing with cognitive load. But ultimately what we're trying to do is for any given team, so for any given team, building something. So for the streamlined teams, for the complicated subsystem teams and the platform teams, we're looking to maximize the available headspace for working in the domain which they're supposed to be working in, because that then means that we can have faster flow.

And are you trying to minimize dependencies between teams as well?

It's a good question. Yes and no. So lots of organizations seem to confuse different kinds of dependencies in a software context. There's compile time dependencies, dependencies that we pull in as a library when we're building the software. Now those dependencies need managing and so on, and there's. There's some challenges around that, but fundamentally it doesn't really affect flow very much. There's runtime dependencies. So this particular service or application over here calls out to another service, whether it's internal or external. So that's a dependency. At runtime, that service might be down and therefore our part of the system can't complete the order processing. Whatever, fine, so that's another dependency. But there's also dependencies in time as teams are building things. So if team A is working on something and in order for them to deliver that thing, they need another team to update the database. So there's an extra field in it. So that's like a temporal dependency, a dependency in time that the organization has allowed to happen. And that kind of dependency is the worst kind of dependency that you can have in place.

Okay, so dependency is okay if it's controlled, if it's quick, if it's like a platform or a service that's being provided and there's minimal delays in absorbing it.

You need build time and runtime dependencies because there's no way that one team can build everything. If you avoided all build and runtime dependencies, then that team would have to build the data center in order to run the equipment. They'd have to build the chips to run the software. That makes no sense at all, literally. I mean, there are dependencies all the way down.

Yes.

So we have to be realistic about what dependencies we mean. And the dependencies that are the most difficult from a flow perspective are those that introduce delays in time. And so organizations end up coupling together multiple teams, saying, oh, we promised this feature, that means we need to update the database, but the database update happens by another team and they're really busy. It's like this tangled mess of dependencies in time. And that is definitely an aspect that we think teams project helps avoid. And it helps it because we're thinking more about flow. So the responsibilities that teams have should be end to end. So if there's a team that needs to deal with order tracking. Maybe it needs its own database. That's one example of the principles from Fast Flow which feel very strange to people coming from another background or set of principles. Twenty years ago you had one database and everything went in the single database. That was it. That's because those databases were incredibly expensive and very difficult to manage. Now there's no reason for that thing at all. We can have multiple databases, we can make the updates asynchronous using message queues and similar technologies. And so we can keep the responsibility of teams substantially separate. So it helps with that temporal dependency thing because we don't need to wait on another team. We've got the end to end responsibility for the vast majority of stuff that we need to work on is within our remit and UI industry.

So a lot of the concepts that you're using here seem quite similar to the principles of microservices architecture. Things like decoupling, single responsibility, bounded context encapsulation, transparency, decentralization. Did you get some inspiration from there?

I think the inspiration for the microservices approach and the team's body stuff comes from the same place originally, which is around decoupling and independent deployability and responsibilities and so on. But from a team topologies perspective, the services that a team builds should be no bigger than the available cognitive load for that team.

And we're talking small teams too, aren't we? Not giant teams.

Yeah, we're talking small teams. In order to have the highest trust possible, we want teams of no more than about eight people. With around eight people you get very high trust. And with very high trust you can make decisions very quickly and therefore have the trust within the team that we can deploy this change and it's not going to cause the problem. That's why that team size is in place. It's a very human centric thing. Some of the drive for microservices five, ten years ago was around really small services. And it's very technically driven teams. Broad is much more driven the team level and thinking about socio technical aspects, the relationship between groups of people and the technology. From our perspective it doesn't really make sense to say, oh, the service should be 10 lines long or 100 lines long or something like this, or should fit on the same page. And it's more about if a team builds something and if that team can understand that service well enough to be able to build and operate it effectively, then it doesn't matter how many lines of code you've got for that service, if they're able to build and run it effectively themselves, then that's a good outcome. At the point where whatever they're doing becomes too complicated for them. If they've got 100 microservices because they've been told that microservice should be no more than 10 lines long, and suddenly they've got an operational nightmare, that's not a good architecture for them. Our focus is on the team and what the team needs and what the team can do. And that seems to result in better heuristics, certainly from our point of view.

Just to go off on a tangent, so a little while ago I read a book called Data Mesh. They talk about socio technical. And then I started reading your book and then used the word socio technical. Where did that term come from?

Oh, it goes back to 1960s, 50s at least. Some of it comes out of the work with people like Norbert Wiener. The cyberneticist is decades old. It's the idea that the organization of people and the organization of the thing that we're working on are interrelated. You can't separate them. And for too long most organizations have ignored the interrelationship between people and technology. Certainly when building software, organizations have basically been pretending to themselves that you can build whatever technology you want without having to think about about the people or the organizational relationships, which is clearly not possible. You've got need to think about the interrelationship of people, the things that we're working on and building, and the external environment and how these things interrelate becomes more of an ecosystem. It's weird and scary for lots of people because it feels very strange to have to think about these things together.

I would call this organizational design, which management consultants generally do for the purposes of getting rid of people to cut costs. But you're talking about a different type of organization design because generally when organization design is done, it assumes that silos are good and you get economies of scale with silos and that you want command and control and centralized control of things and you want lots of policies and procedures. So it's an old bureaucratic type of organization design. Basically you'll get management consultants in and they'll recommend whatever the modern bureaucracy design is. Whereas this is quite a different type of organization design to me.

Yeah, being inclined to agree, a lot of the organization design stuff doesn't take into account any aspects of things like Conway's law. So the socio technical mirroring, which is from my perspective, very strange because that's been demonstrated in multiple different industries and so on. There are some more progressive or modern or better aware organization design principles emerging around autonomy and around networked organizations. So small cells of the organization working together in a way that's more loosely coupled and so on. Things like sociocracy and so on are interesting to explore, but these are all very, very strange and unfamiliar to lots of organizations. Sure. One of the things that we wanted to provide with Team Topologies is a way to be able to adopt some of this stuff incrementally. So, for example, teams can start using the team interaction modes tomorrow and just explore it and see what happens. And then we might then decide to adopt the four team types and see what happens there, or start to move towards that and incrementally adopt some of these different ways of working. It doesn't have to be like a big bang, huge great thing, incrementally improve our service boundaries or the ways of finding good team boundaries for flow and things, incrementally adjust the size of the services we're working on and so on. And that felt quite important to provide routes for organizations to be able to adopt things bit by bit rather than big bang.

So I wanted to ask you about how I might get started with this approach. Let's say I've come in to work with a large team of, say 100 people, and they're having a lot of problems delivering a product or a service that they're supposed to be building. And there's all sorts of dependencies on other teams and blockers all over the place. How would I start? How would I go about applying this approach?

We've got loads of material on the Team Topologies website. So if you go to teamtopodies.com there's a whole bunch of material on there. We've got videos, we've got talks, we've got a lot of free templates and patterns, most of which are Creative Commons share alike. So free to use with attribution. We've obviously got the books. So there's the original Team Topologies book. There's also a newer book called Remote Team Interactions Workbook, which is effectively updating or adding on some ideas around remote work that's been brought on by the pandemic. But we've got a load of learning materials on there and in particular we've got some infographics. So we've got a couple of infographics. One is Team Topologies in a nutshell, which takes you through the core concepts. And another is getting started with team Topologies. So some ways of thinking through how to adopt some of the ideas, as I said, incrementally. If you go to teamtopologies.com infographics, you'll find those there.

So would I start by trying to identify stream aligned teams even if they don't exist, some part of a product that a team would build that's going to deliver value to a customer. And that makes sense from a cognitive load point of view because it's about basically the same sort of thing. Is that where I'd start?

That can work. We've definitely worked with some organizations do exactly that. And we've got some tools and techniques for helping to find good team boundaries. They're called independent service heuristics, which is a long word. It's a technique that we develop which is inspired by aspects of domain driven design that is a little bit more easy to get started with, a bit more pragmatic and it gets people talking, gets people talking about the feasibility of different domain boundaries and so on. And seems to work really well for getting multiple different people from all across the organization to talk about what it would look like to have multiple flows of change across the organization. So yes, that can be a good starting point. We definitely have seen some organizations that have started with that. Clearly a good starting point is going to be to read the book or watch some videos that we've got online. It's good to be realistic about the types of team that are in place as well. If an organization is creating and destroying teams on a three month basis, then that's probably a place to start as well. Don't do that. Be looking for long lived stable teams. Team members can change, but the team itself is going to remain in place for as long as the service that it builds is in place. And start to think about are there anything that needs to change from the organization's perspective to help that long lived team concept to take root.

So we moving away from projects with this model?

Exactly, we're definitely moving away from projects for sure. Projects have a place. If there is something which has a very defined start and end date and no ongoing operational or customer impact, then a project is ideal. But most software these days has an ongoing customer and operational impact. So we shouldn't use projects.

Yeah. You also talked quite a few times about skill and I'm wondering how important is competency in this approach? What if you have a lot of novices? If you think about there's a competency model that goes novice, beginner, competent, proficient, expert. And I have seen that as you go from beginner to expert, you get a 10 times increase in outcomes either because they enabled the team or they are just able to do more themselves. Can we do this with a whole lot of people that are beginners and novices?

Yeah, for sure. You're going to need some people who are aware of the underlying principles and things. So there might be novices at their craft or their discipline, whether it's building software, whether it's who knows what, whether it's data science or something else. But of course you're going to need some people who can guide this that can be where external expertise is useful, particularly if it's applied as an enabling team. With our customers, we act as an external enabling team. So we're using the team's body's principles and ideas to help us actually do the work with our customers. Precisely because enabling team is going to be temporary, the interactions are going to be temporary and we don't want to be. The organization should not be dependent on that external expertise for a long period of time. It's precisely there to build up capability and awareness within these teams. So it's an ideal model. Ideal way to get external expertise into an organization is as an enabling team.

Just related to that. It's very common these days for organizations to outsource quite a lot of their core software development or maybe they're testing or something like that to another company that's doing it in a developing country. Because the day rate is 20 or 30% of local costs. How does that fit in or work or would you recommend it or not?

With this approach, outsourcing of testing is the most stupid thing an organization can ever do. It's the most fundamentally the most stupid thing ever. Like just don't do it. You can use techniques and awareness from things like domain driven design to think about where we need to invest our skills inside the organization. And if an organization is doing any useful innovation, then we need to have skills and capabilities around the core aspect of the business, probably the supporting aspects of the business too. Because sometimes we need to build some stuff that's not directly related to our unique mission but is difficult to outsource. Everything else we should pull in from outside, but as a service. So DDD has got concepts of core domain and supporting domain and then generic and the core and supporting definitely needs to be inside the organization. Why would you not? Why would you allow a supplier to gain a competitive awareness about a domain so that they can go off of that to someone else? That makes absolutely no sense from a business strategy point of View. You need to have that awareness inside the organization so that you're able to then develop and build and hold that IP unique capabilities or differentiated capabilities inside the organization. It makes no sense to do anything else. But when it's driven by like cost accounting and day rates and things, it looks good on paper. From a financial model that is based on counting cows from 2, 300 years ago. Of course this stuff is going to look weird if we're using a financial accounting model that is basically designed for cows and not designed for ongoing services. The organizations that are really switched on would never outsource core unsupporting capabilities. It would make absolutely no business sense that would indicate an organization that is on the way to becoming irrelevant.

But I think the key is the point you made there, which is the competitive capabilities versus commodity. So as you mentioned, we're not going to build our own chips, we're probably not going to build our own data centers. So we will use a provider who as a platform effectively, but that still allows us to use the platform team type. We can say they're a platform team that are providing something and the way we interact with them is the same as if it was an internal platform team.

Yeah, absolutely. So we would definitely still expect to see all the full team types inside the organization. It just allows the organization to focus on things that are more value add. So instead of building low level infrastructure type services, we can focus on value add services which might be some enrichment of data or some better way of deploying something or whatever. We'd always be doing that effectively. We'd always be looking at what the industry is doing. The industry is moving really quickly and we're having to evolve our internal capabilities so that we never building stuff which we could pull in as a generic service from outside.

Yeah, that's exactly what Simon Wardley was saying with his Wardley maps that things tend to move to commodities. So why build your own data center or Amazon web service when your one's not going to provide you enough differentiation to make it worthwhile? I think we should go to summaries. Shane, what do you got? All right.

Yeah. The problem that we're trying to solve is this idea of organizations that are structured by function. That example you used of build, test release and run being separate teams. And the problem with that is we have a massive amount of handoffs. So we want to make the flow better. And the way we do that is by reducing the handoffs. I like that comment you made about when we add a new person to the Team, we typically get 20% of an uplift in capability or effort and really what we should be aiming for is 100%. So how can we optimize the flow of the way we work so when a new person turns in, we get full value out of the effort that they have available? I originally thought, when I. When you hear the word team topology, you think organizational structure, you hear the way teams are structured and the way they work together. But fundamentally what you've got is a way of working. You've adopted a whole lot of DevOps practices, there's a whole lot of practices that teams use that you have built into team topology. So for me it's more a way of working than just an organizational hierarchy or approach to the way you structure teams.

I think that's fair. Yeah, I think that's fair.

I work in with data teams primarily and a lot of the issues that we have with data teams are the same ones we have with software teams. There's been a bunch of patterns that we've been using with those teams that we've had some success with. The other thing I liked is the fact that it provides a shared language, the idea that there is clear definition of what a streamed aligned team is versus an enabling team. So that clear language enables more than one person to use the language in the same way. I find that really valuable. We had Jorgen on with the UNFIX stuff and I can see a lot of alignment with the way he described the way UNFIX works, with the way you described the idea of those enabling teams and streamlined teams. So there's shared patterns coming out.

That's not surprising at all because we're coming from some very similar perspectives in terms of autonomy and flow and that thing. Yeah, it's not surprising at all.

And also Jurgen does credit team topologies as part of the things he's doing.

Which is great because I'm a great fan of people taking patterns and iterating them or putting them together in different ways that provide value in a certain context. And the other thing I like is it solves a scaling problem. So from my point of view, if you can start off with one stream aligned team, a team of eight, and start doing some work, and as you need to scale, you start bringing in these other team types. You figure out when you need an enabling team, when you need your complicated subsystem, when you need your platform teams, it enables us to scale out in a way that is very different to some of the other scaling frameworks.

Exactly. But the scaling is driven by two criteria. This is what I realized since writing the book. The first is, does it improve flow? And second, does it reduce extraneous team cognitive load? And just using those two principles, that helps us to work out whether we need to add an aiming team or a platform or a new platform service or a complicated subsystem. And that's what should drive those things. And of course we can then reassess later. And if the extraneous conflict load has gone away or that the technology's moved on, maybe we remove some team, we don't need it anymore because the technology evolved. So it is super helpful for a different way of thinking about team purpose and interactions and what we need inside our organization.

Yeah, definitely. Because sometimes people have this fallacy that adding an extra person to the team makes the team go faster. They tend to add them right at the end of their project when they need to deliver 80% of the functionality in the last 20%. And we know that as soon as you add another person, you get your 20% problem. In fact, it's worse because the rest of the team now have to upskill them and onboard them and cover them and it's worse. So that idea of incrementally scaling out, right, do it in small steps, prove it works, and then you're ready to go to the next step. Often people say to me, okay, if we don't use safe, how do we actually, how do we start off with a hundred teams to do some development? And my answer is, you don't. You're crazy. Start off small and build up the scale and to the point that it works. And picking up on your point, sometimes you go, look, we've done an experiment, we've scaled out a little bit more and it didn't work. We need to pull back and figure out what went wrong. And so again, this idea of those four team types for me gives me a good shared language of saying, where can we experiment? We can experiment with a platform team. Is it working? Are they serving the stream aligned teams in a way that makes their lives easier? We're getting better flow. No. Okay, something's wrong, so let's look at what was wrong and let's fix that before we carry on and do more of it.

We're embedding that awareness inside the teams. That's the crucial thing. We're giving the teams the awareness to think about interaction modes, to think about service boundaries and things, and to empower them to do something about it or to at least initiate the conversation. And that's something which you don't see typically in some of the larger scaling frameworks. I think it's better.

Yep. And last thing for me is now I have a link to where Socio Technical came from. So thank you for that. Murray, what do you got?

I think the old organizations you talked about are bureaucracies and bureaucracy was good for a while and it's just not effective anymore. It's like a dinosaur compared to the fast moving digital predators on the plane. And yet people are very confused about how to organize constantly when we're doing agile with people. Managers are always wanting to get agile and DevOps to fit within the existing bureaucratic team organization structure and approach. How do I apply agile in my test silo? And people are very confused, I think, about how to scale this modern way of working. And what you've done is provide a lot of clarity around it and you've given people a shared language that they can use that empowers them to be able to have these discussions amongst themselves rather than to have it imposed on them from above. Because this sort of stuff is normally done by executives and management consultants and who are imposing it on people in a big bang transformation. And this is a much better way of organizing and scaling in my opinion. And it gives some very clear patterns and language to talk about it. That's what I really like about it. And just to remind people so the four fundamental team types are streamlined teams, enabling teams, complicated subsystem teams, and platform teams. And the three interaction types between teams are collaboration, service provision and facilitation. And from that you can design and improve the way that you're working together to become more efficient and effective. And this is pretty much what I do when I go in to help organizations that are struggling to deliver software or product or a program. But this just makes it a lot clearer and gives me more patterns to think about. So I find it very valuable from that point of view. I'd also like to say that I don't think there's any reason why this should only be applied to technology teams. This makes complete sense for your entire organization design.

So that's what we increasingly hearing from lots of people we know, people applying IT to legal departments, to marketing, sales, IT support, customer support. There was someone on Twitter recently from the Health Service in the uk she wants to apply to clinical settings, pure clinical settings. So no software at all. These are doctors and nurses and surgeons and anesthetists and things in hospitals. Because she could see the value of using that terminology because in a Clinical setting, hospital setting, cognitive load is a real problem. You've got specialists, you've got people who need to deliver end to end care for a patient who's come in with particular trauma. That you need all those people, all that expertise together until they're in a stable condition and improving or whatever. So we've got people coming to us saying you need to apply this outside of it, which is great. And that's what we've started to work on now is looking for these examples. We're not totally surprised that it seems to work outside of it. We kept it to an IT context for the book just because that's what we're familiar with and we could definitely talk about with confidence. But yes, we're starting to see teacher bodies being applied outside of it, which is great.

This area of organizational design and structuring has always been a dark art, kept hidden away in locked rooms by management consulting companies. It is, in fact, I've been told by a partner their core competency. So the fact that you've exposed it and made it public and open source and you're teaching people to understand it and do it themselves is quite powerful and revolutionary and I really appreciate it.

That's good to hear. Thank you.

We've got a few references that people should go and have a look at. There's team topologies.com infographics, there's an implementation model and Getting started approach there too. And you provide us a couple other links that we can share with people. Are there any other places that people should go to read about what you're doing? Do you have a blog, a medium or is it all on Team Topologies?

So on the Team Topologies website, there are some case studies as well of organizations who have been using it to give you some inspiration and some ideas about like how they've used the patterns and ideas to help them improve things. So that's a good place to go.

And does your company provide training or services to help people implement this?

Yes, we provide an expanding range of services and options with a small but growing partner network as well.

Great.

So if you're looking for some very focused help on adopting these principles and related principles around fast flow in general, then just get in touch.

All right, thank you very much for coming on.

It's great. Thank you for inviting me. It's good chat.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.

Sa.