Matthew Skelton joins host Giovanni Asproni to talk about team topologies—an approach to organizing teams for fast flow of value. The episode starts with a description of the underlying principles before exploring the approach in more detail. From there, they discuss when to consider implementing the approach; keys to a successful implementation; and some common mistakes to avoid. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 628: Hans Dockter on Developer Productivity
- SE Radio 554: Adam Tornhill on Behavioral Code Analysis
- SE Radio 543: Jon Smart on Patterns and Anti-Patterns for Successful Software Delivery in Enterprises
- SE Radio 524: Abi Noda on Developer Experience
- SE Radio 462: Felienne on the Programmers Brain
- SE Radio 317: Travis Kimmel on Measuring Software Engineering Productivity
- SE Radio 247: Andrew Phillips on DevOps
- SE Radio 226: Eric Evans on Domain-Driven Design at 10 Years
Articles and Resources
- Team Topologies
- Book: Team Topologies
- Book: The Programmer’s Brain
- Book: Dynamic Reteaming
- Conway’s Law
- Cognitive Load
- Domain-driven design
- Wardley Mapping
- Team Topologies: Five Years of Transforming Organizations
- What Is Psychological Safety?
- Teamperature cognitive model
- Matthew Skelton’s website
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni, and today I will be discussing team topologies with Matthew Skelton. Matthew is a leader in modern organizational dynamics for fast flow drawing on team topologies and adapt together to support organizations with transformation towards a sustainable fast flow of value. He’s the co-author of the book, Team Topologies and CEO of Conflux and Team Topologies. Matthew, welcome to the Software Engineering Radio show. Is there anything I missed that you need to add?
Matthew Skelton 00:00:49 That all sounds good. It’s good to be here. Thanks Giovannie, it’s good to be talking to you again.
Giovanni Asproni 00:00:53 Yes, thank you for being here. Now well let’s start with team topologies. So the first question obviously has to be what is team topologies?
Matthew Skelton 00:01:03 Team topologies is, I think it’s fair to say, the leading approach to organizing for a fast flow-of-value team of teams; organizations is the focus and it came out of the IT space, but really it’s actually applicable to all knowledge work. So far this is what we found out about, we can explore this a little bit later, but because of the way in that team topologies book, it didn’t really zoom into particular technologies. It turns out that the approach is actually really suitable for thinking about all kinds of knowledge work, not just sort of software delivery and IT, but other things as well. So you could really see team topologies as an approach to knowledge work where we are using technology to enhance our capabilities as humans to do knowledge work really effectively at scale.
Giovanni Asproni 00:01:51 Okay. Now I know that the model is based on four team types and three interaction modes. Can you briefly describe them to us?
Matthew Skelton 00:02:00 Yeah, but I don’t think that’s the best place to start. So that’s how we talk about it in the book, but actually there’s a danger if you start with just types of team and interaction modes that people really take a very shallow reading of team topologies. They just see it in terms of structure, in terms of renaming some teams. So it’s actually important to go a step backwards and look at what’s behind the principles underneath team topologies. The principles really are, we’re trying to get to a position where we’ve got a fast flow value out towards the user and we are going to have multiple separate flows of value because we’re trying to go quickly. So we are deliberately decoupling these flows. We’re not trying to bring them all together and coordinate them. So some large-scale software delivery Agile frameworks try to coordinate everything together.
Matthew Skelton 00:02:43 But we’re deliberately de-coordinating in order to get fast flow, we need to be mindful of team size because we want to have high trust so we can go quickly. So then the size of the team is quite small, that’s involved. We take the team as the smallest unit of delivery, by the way. We don’t go down into individuals when we’re thinking about the roles and responsibilities. We need to think about a cognitive load or mental load on that team because they’re going to be building and running a service, a single kind of stream of value that’s useful to a user. They’re going to be building and running that thing on an ongoing basis. And to be able to look after something like that with all the different aspects that you need to think about in terms of building and running something, we’ve got to be mindful of the cognitive load that we’re placing people under because otherwise they, they just won’t be able to support it properly.
Matthew Skelton 00:03:27 We’ve got to think about the kind of system and organizational architectures that work really well for flow. We’re going to have multiple fast flows of value. Then there’s only a certain small number of kind of architectures that actually work well. We’ve got to be mindful of what’s called Conway’s Law, which is like a mirroring between the organizational communication pathways and the likely architecture that results from that. And this has been, it’s a tendency, it’s a kind of force that’s at play if you. We can’t choose to work against it, but it’s going to be more difficult if we work against that what’s called homomorphic force. So we’ve got to be mindful that that the shape of our organization communication pathways, is likely to influence the kind of systems that we end up building. We need to be mindful that any digital technology we introduced now is likely to be obsolete in five years, three years, 18 months. So the way in which we think about introducing technology and using technology needs to expect it to disappear within a very short space of time, which is quite extreme compared to how technology was used in previous decades.
Giovanni Asproni 00:04:25 So you are suggesting teams to actually plan for that as well, plan for the fact that technologies are going to change is one of the themes.
Matthew Skelton 00:04:35 We have to, because this is where organizations get into a fix. They expect they’ll introduce new technology; they’ll get 10 years’ worth of life out of it. It’s not like that anymore. We might introduce a technology to give us an 18-month advantage, and then beyond 18 months that technology might start to act like a drag. And we need to be expecting to replace that technology with something that we’re just getting from a Cloud provider. So team topologies provide the underlying fundamental kind of mindset and dynamics that allow us to have true like business agility to organizational agility in the context of technology changing very rapidly and in the context where we’ve got the techniques and practices where we can deliver software changes hundreds of times every day. And that’s table stakes to be honest, for many organizations to be able to do that, decent person control, continuous delivery practices, kind of Agile practices and smallish teams and so on and so on. This stuff has been as you know, practiced for decades. Not in every organization, but in many organizations.
Giovanni Asproni 00:05:30 If I understand correctly, it’s like all these principles and practices are the fundamental things more than the things that sometimes teams tend to focus on, like the team types and the interaction modes. Am I correct in stating this?
Matthew Skelton 00:05:43 Sort of yes. I mean in the sense that team topologies, but we’ll dive into the details in a minute, but team topologies came out of all of the practices and awareness around the DevOps movement that started back in about 2008, which was sparked really by the availability of kind of infrastructure automation, configuration automation and Cloud that would, could have emerged round about 2006, 2007, 2008. So suddenly there was new practices available, suddenly IT infrastructure was no longer the bottleneck. And suddenly we had this coalescing of practices like continuous delivery, which the book came out in 2010, newer tooling that allowed us to do, for example, application logging at scale with quite high fidelity and so on and so on. A bunch of tooling came out in this kind of space, which suddenly gave technologists way better and much greater variety of options for going quickly.
Matthew Skelton 00:06:35 So anyway, the one way of looking at team topologies is really, it’s an opinionated expression of core DevOps principles when DevOps is really the original meaning of the word DevOps, which is effective Development and Operations teams working together, not just the very shrunken version of DevOps, which some people refer to, which is just kind of dealing with build and deployment pipelines or dealing with Kubernetes infrastructure or whatever that version, which is what DevOps tends to be these days. But back 10 years ago, it really meant this whole approach to getting IT delivery, working really effectively. So it came out of all that stuff. So team support use at one level is really just a natural expression of what you would get if you put a few constraints in place. We need to have fast flow, we need to think about Cognitive Load, we need to have a team-based approach, we need teams to be small so we’ve got high trust and can go quickly.
Matthew Skelton 00:07:24 We need to think about Conway’s Law, we need to have a language for navigating this stuff. We need to make sure that we’re detecting opportunities for improvement across the organization on a regular basis, rather than just having lots of small teams all siloed and so on and so on. If you take all of those constraints and apply them in the context of sort of modern software and IT delivery, you will get something team topologies out. It’s not just coming out of nowhere. It’s a natural consequence of having these kinds of operating constraints in place. So we weren’t just inventing a whole lot of stuff. This is the techniques in that we talk about in antibodies had already been used by some companies for like 10 years effectively. But we put particular terminology, we put particular spin on it, if you like or we put a particular opinionated view of what was kind of already happening in the industry based on sub companies.
Matthew Skelton 00:08:14 The more advanced companies like Netflix and some of the teams in Amazon AWS and a few other places like this, some of them are in the book and we said, look, let’s try and reverse engineer what’s going on here. Why did Amazon talk about two pizza teams? What’s going on? It sounds funny, right? Two pizzas, ha ha, blah, blah. What size pizza is it? Is it an Italian pizza or is it an American pizza? All that stuff, right? But clearly underneath there is something really important. And the thing that was, that we reverse engineered effectively underneath that two pizza team thing was the trust that you get from a team that is relatively small and therefore you can go really quickly, and you can have autonomy. Combine that with the really important design principle from Jeff Bezos back in, I think it was even 2001 or 2002 or something where he said something ìevery interface must be externalizableî.
Matthew Skelton 00:09:00 So in other words, every kind of API or thing that you build, you need to treat as if you are going to expose it to the internet, effectively expose it to external customers because that makes Furling incredibly powerful scaling technique for systems and for the organization itself. And so we took things that and tried to recast it in language that was kind of independent of any one particular organization and put it into a form that was suitable for kind of typical organizations that we’d come across. Typical banks, typical retailers, typical logistics companies, typical pharmaceutical companies, any kind of company basically manufacturer, whatever, typical government department and so on and so on. We tried to find language that was accessible, approachable. We tried to come up with patterns and terminology and diagramming style in particular. The diagram style was really important for us.
Matthew Skelton 00:09:46 We tried to pull together these things in a way which was accessible to technologists and to non-technologists. One of the things that I’ve been doing in my career for a long, long time is bridging the gap. Often, it’s a chasm between technology and people outside of technology explaining how this stuff works and why. And that’s one of the things that we’ve seen with the team topologies book is people who are non-technologists, they might be head of strategy, they might be CEO, they might be COO, who can read the book and go, I get this. It’s explained in a way which is not condescending, doesn’t require me to understand too much about technology and so on.
Giovanni Asproni 00:10:23 Can I ask you a question because before when you said that we team topologies, you try to, you said desynchronized teams, am I using the correct term? I think you said desynchronized. Instead of synchronizing and now I find this intriguing. It’s, what do you mean with that? With de synchronizing maybe can you give us also a real-life example from some project you worked on?
Matthew Skelton 00:10:42 Yes. So there is a kind of common sense, there’s a natural tendency for organizations. I think people and organizations as a whole to want to try and synchronize the work of multiple teams, for some reason. There’s a belief that the synchronization of that work is needed in order to get the right value out at the right time and so on and so on. The problem is synchronization doesn’t scale and the more synchronization you do, the worse the problem gets. And we see this in large organizations where they’ve got big programs of work and you’ve got hundreds of teams all kind of working on something and the amount of effort that goes into synchronizing that work, bringing it all together, integrating it, planning and trying to get this thing built in time for this other team to use it. And then that team’s waiting on another team and so on and so on.
Matthew Skelton 00:11:31 If you actually do the calculation on this, the amounts of money that organizations are spending just having teams waiting on each other is millions and millions of dollars every year. It’s absolutely madness. And yet it’s the kind of so-called common sense. It’s not actually good sense, it’s just a sense that is, there is accepted wisdom if you like, turns out there’s another way to do it and the other way to do it is to deliberately desynchronize. So keep think have a limit on the number of teams or the number of people in a kind of synchronization unit if you like and keep that extremely small. So maybe you limit the synchronization to just two or three teams. That’s what’s that like? That’s, it might be eight or 15 or 24 people and say okay, we can try and synchronize between a couple or maybe three teams but much bigger than that.
Matthew Skelton 00:12:16 Let’s deliberately de-synchronize it. Let’s deliberately not try and bring that together and use modern techniques like feature flags and a bunch of other things so that we’ll deliver something into life first that at some point later something else will pop into live and then maybe a couple of weeks later something else will arrive in the live environment and then we get the value. But by deliberately desynchronizing and using these kinds of techniques, we actually get the value sooner because that value will appear in production sooner than if we try to synchronize it altogether.
Giovanni Asproni 00:12:43 Can you give us now maybe briefly a real life example from a particular system or project you worked on? To help our listeners create some mental models of how things may work in practice. Brief you don’t need to describe the entire project.
Matthew Skelton 00:12:59 This is how Netflix has run for decades effectively this is how the entire of Amazon AWS runs. Amazon AWS, you’re not actually permitted to insist that another team changes their API within a given timeframe. That’s how they’ve managed to scale so big. In fact, if you look at the way that Amazon AWS scales, when they add a new employee, they get more than one employee’s worth of value out of that new person effectively because of how the scaling works. Whereas most organizations, when they add a new person, they get about 0.85 or even less worth of employee value out of that person because most organizations are not operating on the same scaling laws. So the best examples are already there from organizations doing this kind of thing. They’re huge and they’re delivering huge amounts of value. But it seems mysterious, mysterious to be organizations outside of that way of working because it’s so counterintuitive.
Giovanni Asproni 00:13:50 What kind of organizations, this team topologies approach is suitable for, startups, small projects, big projects involving how many teams. Is there a sweet spot and are there any situations where you would actually recommend something else?
Matthew Skelton 00:14:04 That’s a great question. So I think the sweet spot is actually quite a large spot if you like. But it’s crucially for organizations that genuinely want to empower their people, want genuinely want to empower teams, genuinely want to make the organization a more humane and effective place and it’s not a good fit for organizations or for leaders that actually want to exert strong control, command and control kind of ways of working. So if you are do command and control, then do command and control, tell people what to do, accept that your organization can be very slow, accept that it’s going to be very annoying and painful and people are going to want to leave and accept that the organization will probably fail at some point. If that’s what you want to do, then go for that. But if you genuinely want to have an organization that’s actually effective and humane and nimble and has outsized performance and gets way more value out of the employees than the competitors, then approaches team properties are actually an extremely good fit.
Giovanni Asproni 00:15:02 And so does it work, say in small startups, startups that, let’s say five 10 people in total because they are just starting, does it work also in this very small-scale kind of projects?
Matthew Skelton 00:15:14 If you’ve got very small number of people, then you probably don’t see really the effects of Conway’s Law and the effects of some of the scaling effects that you would get outside larger organizational sizes. So if you’ve only got say 10 people, you could probably get away with just kind of not really defining the boundaries so strongly because you’re still exploring kind of what you’re doing and what the market fit is and so on and so on. But as you head towards, I don’t know, maybe 15 people, you probably need to start thinking about where to put some boundaries for Cognitive Load boundaries, for flow boundaries for scaling this kind of thing. Because if you don’t then you’re in danger of growing the thing too big and then it becomes actually too difficult to manage. So we did some work a long time ago back in 2015 with a startup in video advertising, so you might not believe it, but back then, this is based in the UK back then, sorry, not video advertising, it was TV advertising, television advertising.
Matthew Skelton 00:16:14 So national broadcast in the UL. And back then adverts for broadcast television were produced, recorded, they were burned onto a DBD and they were put on a courier, a motorcycle courier and moved from one side of London to the other and that was the quickest way to do the delivery and that’s what the startup was trying to address and successfully did. It was bought by, I can’t remember, a VC or something later. And so what they did is to do all this via Amazon AWS in the Cloud and back then 2015 or something, they were the first solution to Cloud-based advertising review and approval for the world I think certainly for the UK market. And we were helping them when they were around about kind of 15 people and we saw some early problems starting to arise because they weren’t really thinking about cognitive load, they weren’t really thinking about kind of skills differentiation and so on and so on or we help them to think about it effectively.
Matthew Skelton 00:17:06 We help them to think through, well look, you’re getting to the point where there’s actually too much to think about for this one group of people. You need to differentiate the skills a bit and maybe start to think about providing what we end up calling a platform and maybe start to think about something that’s a bit more complicated. So take away the cognitive load for that complicated thing to a smaller group of people so that other people can focus on the end customer experience and so on and so on. So we started to test out some of the team topologies ideas early on, but we started to see these problems emerge as I said, when there was a roundabout 15 to 20 people in the startup.
Giovanni Asproni 00:17:40 Are there any kind of things where actually team topologies is not necessarily applicable? I’m talking about situations where there is a small team trying to discover something in domain, fleshing out information they are not quite sure about what they’re doing. So there is a lot of experimentation, prototyping, discovery or maybe in some companies now, and there is a lot of data, there are data analytics teams and that are not necessarily featured, well feature teams or stream aligned teams, or complicated sub-teams. Basically what I mean are there types of teams that actually are a bit outside the team topologies framework, but then they need to interact with teams within that framework?
Matthew Skelton 00:18:20 Great question. So we thought that maybe R&D, Research and Development, was one area where some of the team topologies approaches might not work, but we were told that we were wrong by the global head of an R&D division in a big global pharmaceutical company. And he was, no, no, these definitely applied, these definitely applied R&D. So we’re okay fine, we’ll take your word for it. So if you think about it, if we are doing exploration, if we’re doing analytics, if we’re working on a product or a service or a user journey or something this with software or with where we’re enabled by software, we’ve got a core mission or ideally, we’ve got a core mission, we understand who we’re delivering that value to. We’ve got a value consumer effectively of other work that we’re doing and there’s an amount of stuff that gets in the way of that value delivery.
Matthew Skelton 00:19:15 And so we’ve got a sense of a stream of value, a value stream. It’s sometimes easier to feel like it’s a stream of value, but even with research and development, even with kind of discovery and noodling around and experimentation, there’s still a sense in which we’ve got a value stream because the value is in the lessons that we’re learning and we’re delivering that value to some sort of stakeholder who’s paying for that work to be done. And for those discoveries to happen, there’s always an amount of stuff which is a distraction. There’s amount of stuff which causes effectively friction around that work. And we’ll always hit some snags which relates to areas of expertise that we just don’t have in the team. And that’s why the team parties approach works across all knowledge work effectively. This is what we’ve discovered. We didn’t design it that way, but actually what we ended up doing when we were writing the book and thinking through the patterns is providing a framework or an approach to knowledge work, to navigating knowledge work, technology assisted knowledge work I should say. So team parties really an approach to highly effective technology assisted knowledge work at pace, at speed.
Giovanni Asproni 00:20:22 So maybe you can give us more details about the structures the team structures, communications among them.
Matthew Skelton 00:20:28 So team topologies we start with, to be honest, we start with a massive assumption and I’ve mentioned it already, and this massive assumption is that the organization understands its value streams. And this is, this turns out to be basically mostly not true. Most organizations need a lot of help in understanding their value streams, which is fine. We’re here to help. The teams I’ve built over the last few years are super impressive and we’ve been doing lots of interesting work with lots of organizations. So let’s say we get to the point where we start to understand some of the value streams, at least perhaps we’re doing a pilot project and where we’ve got, I don’t know, five or six teams involved. So we start with this idea of, here’s a stream of value, we want to have the fastest flow of value inside the value stream in order to do that.
Matthew Skelton 00:21:11 We do not want any handoffs from one team to another. We can’t possibly have one team that does a bit of work and then hands off to another team that does a bit more work and then hands off to another team. Because if you’ve studied anything around queuing theory and stuff that and process control, then handoffs absolutely kill flow. So how do we get to the point where we’ve got end-to-end value flow for that particular part of the value stream? We need to have a team that owns the end-to-end thing. We can’t have a handoff from one team to another. So that’s our starting point. And what that’s what we call a stream aligned team. They’re aligned to the stream of value. We deliberately chose a word that is not too opinionated. It’s a little bit kind of neutral.
Matthew Skelton 00:21:47 That’s why it’s called stream aligned team. It’s just aligning to the stream of value. It’s not a product team, it’s not a feature team, it’s not anything else this. Because those words mean all kinds of different things in different places. And crucially stream aligned team, it’s aligned to the stream of value that works in all kinds of knowledge work as well, which is very convenient. So that’s a starting point. And the team in this case is about up to about eight people now for most organizations, that’s very small. It’s a very small number of people in that group. Interestingly, I was talking to someone at a conference in Hamburg last week and he said, Matthew, eight or nine people is a huge team for me. I get by with three or four people. But anyway, so he’s in a world where he’s really used to really, small teams.
Matthew Skelton 00:22:26 But anyway, up to about eight people is because that number of people, we still get a very high degree of trust, but we’ve got quite a broad range of skills. So inside a team like that, we’ve got a mixture of different skills sometimes called cross-functional, sometimes it’s called multi-functional, multi-skilled. We deliberately bring in different perspectives so that we can go very quickly. Sometimes inside a team that we might have like an expert or a compliance specialist or a legal, even a lawyer inside a team that. Maybe if we need to go very, very, quickly and understand the context for making decisions and for building these services and running these services so that team’s got everything it needs to deliver value independently 90% of the time. That’s our starting point. So, and ideally we’d have multiple independent streams of value with these streamlined teams, multiple streamlined teams.
Matthew Skelton 00:23:16 If we could get away with having a hundred streamlined teams in the organization providing a hundred different value flows, that would be where we start. Like if we could get away with that, then that’d be brilliant. But in reality, the reality is a bit messier. In reality, if you take one of those or several of these streamlined teams, if they’re fully independent, then over time they’re dealing with more and more things. They’re dealing with data, they’re dealing with security, they’re dealing with generative AI, they’re dealing with infrastructure, they’re dealing with reporting audits, a whole bunch of stuff like this. And over time those extra things don’t really relate to their core mission. If their core mission is focused on applying for a credit card or ordering a pizza or doing a specific kind of drug discovery or whatever the mission of that team is, whatever the value that they’re supposed to be delivering is all these extra things then start to slow them down effectively.
Matthew Skelton 00:24:16 They start to be a distraction. They start to eat into the cognitive capacity of the collective team. And so we need some approaches that help to encourage an ongoing fast flow value in that streamlined team. How can we do that? Well, one way is by dealing with some of those aspects like security, audit, compliance, whatever, that are not really related to the core mission. How can we do that? There are multiple different ways and there’s three different types of team that we talk about in the team support book that help with that. So the, the second team type is called enabling team. An enabling team is a team of experts that can help to uplift the capability in the streamlined team. So these might be experts in legal compliance or biosciences research or credit card data regulations or something. And that team of experts can come in and help the streamlined team for a small period of time, maybe a few days, a few weeks, until the streamlined team’s capability is uplifted, until the streamlined team understands how to deal with that aspect better and they can then bake that into their everyday processes.
Giovanni Asproni 00:25:20 The enabling team helps the streamlined team to acquire skills they don’t have.
Matthew Skelton 00:25:25 Exactly. That’s one of the things they do. Exactly. Okay. That’s one of the things they do. The enabling team might also though, because the enabling team might also detect that 17 out of 20 teams all have the same problem. They all find this particular piece of technology very difficult or this particular aspect of regulation very difficult to work with because they’re working across multiple different streamlines teams in the organization. So they’re, the enabling team acts like a boundary spanner in organizational design terminology. They’re detecting this stuff, they’re actually like a sensing mechanism across the organization and then they can go, if 17 out of 20 teams are all having the same problem, maybe we need to do something about it. So then they can say, well, we’ve detected the fact that there’s an opportunity for enhancing that capability across the organization, not just sort of solving the same problem time and time again.
Matthew Skelton 00:26:10 What do we do? Well, we can do whole organization training. We can, buy a new tool. We can maybe hire some people and put them into every team if we need to. We don’t have to, but that could be one option. Or maybe we build or enhance the experience of using that particular technology or that particular thing. How can we build it? Well, that’s where the other two types of teams come in, one of which is called a complicated subsystem team, where we’re taking a very specific part of the work inside streamlined teams, which is really complicated. It might be an algorithmic thing, a video processing algorithm. It might be data preparation for generative AI. It might be something that’s just not realistic to expect people in the streamlined team to be able to take that kind of mental load. And we take it out into a complicated subsystem team. But the reason we take it out into that separate team is because we’re dealing with the cognitive load to enable a streamlined team to go more quickly,
Giovanni Asproni 00:27:09 How do you decide to create this kind of complicated subsystem team? So what are the signals in a streamlined team that they need this kind of help?
Matthew Skelton 00:27:20 That’s a good question. So the signals are that streamlined team is basically just struggling with that particular specific aspect of technology, that specific library or component or algorithm or concept or whatever. And we’ve tried to uplift their skills using an enabling team and that just hasn’t worked. It’s just way the enabling team really can’t provide the uplift that’s needed. We’ve sent them on training. Still the streamlined team is just saying, look, this is just way too complicated. You need, you need people who’ve got PhDs or, a research background in physics or astrophysics or nuclear physics or something. You need to get these kinds of people involved in here who really understand the, the complicated mathematics. And so then we can go, ah, okay, it’s one of those things, let’s break it out as a separate.
Giovanni Asproni 00:27:59 Have you got an example from a real situation you have been involved in this to make this kind of decision?
Matthew Skelton 00:28:06 Well, yeah, so that video processing, the TV advert startup, they talked about before, there’s one particular part of their system that was video encoding.
Matthew Skelton 00:28:16 And they didn’t actually write the algorithm, but it was a software itself that was running on a particular kind of operating system and so on and so on. It was quite awkward to manage, and it was out of the experience of most people in the team to work with. And so actually made much more sense to kind of hide the details of that inside what we now call a complicated subsystem to enable the, the other people to focus on the user experience better. And by doing that, it got better flow. They could have better pretension to detail to the experience of the approval process for the adverts rather than having to think about the details of configuring and running and operating this what was effectively a complicated subsystem for video and coding and decoding.
Giovanni Asproni 00:28:53 So all these seems to be also revolving around the cognitive load concept, kind of people that have to know things and they don’t necessarily know everything. So you mentioned cognitive load already a few times, so it’s quite a central concept in the team topologies, but how do we define that in a, let’s say, relatively accurate way? So what is it when we talk, because intuitively it seems to be lots of stuff, things that make us tired to think about, I don’t know, but how do we define this?
Matthew Skelton 00:29:22 That’s a good point. So in the anthropology book we, we use a definition from Australian psychologist John Sweller who defined it in the 1988. I think it’s fair to say there’s some debate about around the sort of the applicability and validity of the John Sweller view of cognitive load, the different ways of interpreting it. And in fact we’ve been working with Dr. Laura Vice who’s got PhD in organizational psychology and she’s been helping us to sort of come up with a more rounded approach to cognitive load, which takes into account a bunch of other extra kind of dimensions around the workplace, around the additional distractions that people have got in the workplace and so on and so on and so on. And that’s been encoded into a tool that is now out of beta. So it’s actually available for general release called Teamperature, a bit temperature, but we’re taking the temperature of the team, so the kind of teamperature it go to teamperature.com, you’ll find that and we’ve run that successfully with a bank in Europe and with telecom’s provider in Europe as well.
Matthew Skelton 00:30:25 And they’ve been running with that for the best part of the year. I believe it’s my colleague Manuel Pa who runs that side of things. But we’ve been working with them very closely and has had some really, really useful results in terms of looking for detecting high cognitive load, detecting the change in cognitive load over time because it might change depending on the kind of the time of year. If you’ve got Black Friday sales and stuff this for a retailer, then the cognitive load probably goes up because there’s a load of other things to think about and so on and so on. So we’re exploring that very much at the moment. And in the second major bodies book, which we’ve started planning now, we will have an updated kind of expression or updated view of our intent around cognitive load that came out in the first book.
Matthew Skelton 00:31:06 I think our intent was absolutely sound to really think about the human kind of what it’s like to be human and knowledge work. I think the intent to bring that in and to be realistic about that was really important because to be honest, if we’re overloading people, they can’t possibly do good work, they can’t possibly look after these systems in effective way. It’s just, it doesn’t make any sense. So let’s be realistic about it. Clearly, we can use technology to take away some of that extraneous cognitive load. Some of the cognitive load, which just isn’t very interesting. Let’s use Gen AI, let’s use Cloud, let’s use whatever technologies to help with that. But that just means that those human beings can now focus on something that’s more mission centric, which is great, which is where we want to be.
Matthew Skelton 00:31:43 And there’s that cycle always kind of is always changing because technology’s always changing, but we’re always trying to get into a position where we’re balancing the amount of cognitive load with fast flow, with the amount of flow. If we squeeze down the cognitive load too much, if we just give people a tiny amount of things to do, the slice is probably too thin, we’re probably not getting enough value. If we expand the value stack, if you, or the amount of cognitive load is too much, then people are probably slowed down. So is it always a constant tension between cognitive load and fast flow, which is nice because it gets interesting then.
Giovanni Asproni 00:32:17 How do you get the right balance there? How do you measure cognitive load to decide what the right balance is? How do you do that?
Matthew Skelton 00:32:24 Well, so the, the teamperature tool is our offering for how to, how to measure cognitive load and it includes lots of different variables basically. And it needs to be done on an ongoing basis effectively. I think there’s probably going to emerge, well we already starting to see emerging some tools that sort of automatically detect aspects of cognitive load, not everything but aspects of it by looking at the messages in Slack for example, or Chat by looking at things cyclomatic complexity or other measures of code complexity and things this and mapping that to teams. So there’s tools like code scene that get involved in that, which is amazing and other kind of tools this which are using kind of telemetry and organizational signals to give us some clues into where cognitive load might be higher than others. And that just helps us pinpoint and start an investigation.
Giovanni Asproni 00:33:11 Okay, that’s interesting. So it’s a kind of looking at various aspects, both technical in the code base, the shape and non-technical in terms of the people interaction, what they say on messages on Slack and the things they talk about and things they may be struggling with and somehow come up with a measure to decide this team actually needs help.
Matthew Skelton 00:33:31 There’s tooling ways to do it and we’re actually working with an interesting startup that’s in this space that, that is using gen AI to do sentiment analysis at scale and we’re working with them to see how we can incorporate that into our consulting offering. But it’s a signal, the tools is one important part of it, but we also need to focus on the psychological safety and the culture of the organization that enables people to speak up. Because if people are afraid, no amount of tooling is really going to help. We need to be getting into a position where people are empowered and feel safe enough to be able to say, look, this thing over here just is a nightmare. We can’t work with it at all. We need to have a conversation about this. We need to improve the user experience of working with this thing over here.
Matthew Skelton 00:34:09 They need to know, they’re not going to get shouted down for, for raising that. That’s why I said before that team’s project is definitely suitable for organizations that truly want to empower people but is not suitable for situations where the leaders or the whoever managers execs really want to impose command of control definitely say that. It needs these kinds of generative approaches to running organizations need fundamentally start with a foundation of psychological safety to enable people to actually operate well. We should probably mention the fourth type of team that that’s in the book. In the book we actually called it a platform team. It actually wrong. That’s the only mistake in the book really that’s the only …
Giovanni Asproni 00:34:50 Are you coming out with a rat out the book to correct that?
Matthew Skelton 00:34:53 We might do, we might do, it should really say platform grouping because it’s not a separate team type.
Giovanni Asproni 00:35:00 Ah, that’s interesting. So can you expand on this? What do you mean with this?
Matthew Skelton 00:35:03 In our world a team is a group of up to about eight people. So very high trust and multiple different skills and so on. Whereas the platform concept is actually more like a grouping of teams. We expect to see inside a platform, inside a kind of platform boundary. We expect to see multiple different types of teams in a large organization. I mean if it’s a tiny organization of 15-20 people then you might have a just a single platform team, but as soon as you get to beyond, I don’t know, 30 people, then you’re going to have multiple different teams that operate inside a given platform.
Giovanni Asproni 00:35:38 Let’s see if I understand this correctly. So it’s like we can think about some team that is dealing with maybe creating some, I don’t know, abstractions on top of some AWS things, I don’t know, configure databases in a specific way. So when the teams need that they have everything done for them. But then we can think about, I don’t know, security team people that are experts in security aspects and do some other stuff that requires a different still platform level but a different kind of special skill and things along these lines or am I missing?
Matthew Skelton 00:36:09 So yes, but to be honest, a lot of organizations talk about a lot of IT departments and things that have used enterprise talk about a Cloud platform, which is great. So that group provides kind of abstractions and simplifications around the use of Cloud. Typical inside most enterprises you’ve got multiple different Cloud providers, just have your tech technology providers, so you need some kind of simplification and abstractions around it, but inside there you’ve got multiple different teams working on different things. What are the value streams? What are the value consumers for the different things you’re working on? It’s not just about a blob of technology. If you basically need to look at the value that that group of people is providing and to whom are we providing it? We’re providing it to other internal teams. Okay, great. Understand their needs. What’s the user experience or sometimes called developer experience, what’s the roadmap? How’s it all work together, how are you going to work out? What comes next? It’s just product management.
Giovanni Asproni 00:37:00 I don’t know if it is correct, but sounds like it streamlines things all the way down since exactly a kind of pattern there. Also the platform grouping is actually some streamlined teams where the customers in this case and that use that need the value delivered are actually the streamlined teams that provide value to the end customers.
Matthew Skelton 00:37:21 Exactly, exactly. It’s the famous Terry Pratchett quotation, right? Turtles all the way down.
Giovanni Asproni 00:37:26 Yeah, it seems to be similar to that.
Matthew Skelton 00:37:29 You know, it’s either streamlined teams all the way down or you might argue it is platforms or platform groupings all the way down because underneath that internal platform grouping, there’s really, there’ll be a platform which is a Cloud provider or some other kind of technology provider and it’s the same pattern inside there. Obviously if you zoom into AWS or Google or Microsoft, guess what, you see some teams that are focused on particular streams of value, call them streamlined teams and they were, they’re busy working on some stuff too. It go keeps going all the way down, all the way down to the operating system. You’ve got different teams working on different aspects of Red Hat, Linux or Windows or whatever it is and so on. And same all the way down to the embedded software. You’ve got different teams working on different streams of value inside there.
Matthew Skelton 00:38:10 So it’s a very fractal approach, fractal self-similar approach. You can zoom in, zoom out, which is really good because you can, it fits very well with worldly mapping, strategic awareness and approaches core domain charts and kind of domain driven design because you’ve got nice, bounded context from DDD. So we could apply the bounded context inside a platform grouping, but then we don’t always want to think about all those contexts so we can zoom out and just think about contexts which sit outside of that platform grouping. So it really helps with navigating all the way across the whole organization because we can use these techniques, the same techniques we can use across the entire knowledge work organization.
Giovanni Asproni 00:38:47 I see. And one last question before we start talking about how to get started with, team topologies. Say if in an organization people want to implement them, how they should start, but before that. Now with team topologies, you mentioned this also today, there is an emphasis on fast flow. Yeah. Which I would say that looks productivity in a sense, but how does that affect other qualities of the system, you know quality of the code and performances? Anything else? I mean is this fast flow going to happen at the expense of other system qualities or maybe not?
Matthew Skelton 00:39:25 Let me relate a story. So it’s possible to take the fast flow thing to the extreme and to over index to really focus on just individual fast flow of value inside little teams or little departments without that stuff being coordinated, but crucially without it being related to each other. We actually did some work with an organization a few years ago where they were, they were actually pretty good knowing what their value streams were, and their customers were. And they had platforms in place. They had enabling teams in place based on team topologies and so on or influenced by it. But they had some strange incentives, and this was about, I don’t know what why these things were in place. But anyway, you had a development manager saying to their team, don’t talk to people from the other team next to you.
Matthew Skelton 00:40:10 Don’t talk to people from that team over there. Your time is my time, it’s precious. I want you to focus on just this product. And so they ended up with it is madness, it’s complete madness. They had, effectively they had, whatever it was 70 teams, but they were completely independent. They were acting like mini agencies, mini digital agencies, 80 digital agencies inside the organization. But they weren’t talking to each other, they weren’t sharing anything and so on. That was an example of this kind of approach taken in a direction that we kind of didn’t expect and would never recommend. And actually that approach could of is reflected in some of the criticism of teen properties that we’ve seen over the last five years. People say that this leads to fragmented value and blah blah, blah. And yes, of course, if you take this to the extreme and don’t think about the organizational culture and learning aspects and a bunch of these things, and of course you’re going to end up with something that looks very strange.
Giovanni Asproni 00:41:06 Okay. Before going to the implementing team topologist, just I want to see if I understand something because at the beginning when I ask about the team types and communication interaction modes, you said, well, it’s not a good point to start because this seems to be where everybody focuses. And then it went to the principle. So it is what you said now, one of the reasons why you don’t want to start with the particular elements of team structures, interaction modes, and instead emphasize the principles is just to help people avoid focusing too much say on the mechanics without really understanding what the underlying reasons are.
Matthew Skelton 00:41:40 Exactly. The team types look really easy. We’ll just copy paste them without thinking about the reasons for that. And the reasons are really important, the reasons why we create a platform grouping or the reasons why we create complicated subsequent team and so on. All that stuff is driven by flow and cognitive load and it’s driven in a very specific way. And it’s not just a, we’ve seen examples where the HR department or the people department has designed the organization using these kind of teams without any awareness of cognitive load or flow or sense of value streams and that’s at best it’s misinformed and at worst it’s actually counterproductive for the organization because you’ve got the boundaries in the wrong place.
Giovanni Asproni 00:42:16 Okay. Now let’s talk about how to get started with this. Let’s say we have an organization that they want to, let’s say, improve their team structures and the way they deliver value, and they look into team topologies. Yeah. How should they get started? Because I see also in in the book itself, you state that organizations at different stages of technical and cultural maturity will find different team structures to be effective. Yeah. So how an organization should get started. Maybe you can also tell us how they can find where they stand with the respect to organizational maturity in the for that.
Matthew Skelton 00:42:53 So there’s a nice phrase that Jon Smart from Sooner, Safer Happier Users, so Sooner Safer, Happier is a book that came out I think the year after Team Bodies by the same publisher, IT Revolution by the way, which is an amazing publishing house and it’s great to be part of that family, pretty much any book from IT Revolution is something that I buy personally and read, and I basically recommend everyone else to do as well. So Jon Smart from Sooner, Safer, Happier, he talks about Elephant Carpaccio. So how do you eat an elephant? You slice it very, very thinly. And so the way you would start in any of these approaches, we’re talking about end-to-end value delivery. So where we start is we find an end-to-end stream of value that we can work with straight away. Basically that’s our starting point. So it might be called a pilot project, it might be called, hopefully not the word project, but pilot.
Matthew Skelton 00:43:42 We’re going to pilot this with one particular area. So for example, we’re doing some work in a European bank at the moment, it’s one of the smaller European banks, which is actually quite convenient because it’s easier to get things done. They’re not so huge. And let’s say there is opportunity to differentiate that bank’s offering in the marketplace by making it really, really easy. Not just easy, but a really good experience to apply for a loan or apply for a mortgage, something like this. And we say, okay, well that’s actually quite a useful kind of end-to-end sort of value stream. There’s going to be ongoing differentiation, ongoing work to improve this experience over the next 18 months. Maybe longer, right? So actually we’ve got a clear customer for the value, which is the person who wants the loan, we understand their needs well or we can do the work to understand their needs and what we need from them.
Matthew Skelton 00:44:36 And we can pull together a streamlined team. Let’s say it’s eight people that can work on this thing. That’s where we’ll start anyway. Maybe eventually it’s a couple of teams or three teams or something. But to start with, let’s say assume it’s just one team, what would it take just to need one team of eight people? We’ll use particular technologies that are easier to work with so that we can just keep it to a single team. So we might use low code or we might use the particular languages that are more amenable to really focus on innovation around that. Applying for a loan user journey. And then we say, okay, that’s fine. What about things like security Cloud, infrastructure data, a bunch of other things. What’s the minimum we need in place to enable that streamlined team to do its job?
Matthew Skelton 00:45:18 Let’s work it out. Let’s work backwards from having that team in place. What else are they going to need? What else we could explore over time? But as they’re working on these things, as they get their deployment pipelines in place, as they get their Cloud infrastructure in place, we’re looking to see what’s slowing them down, what’s taking their time away from that end-to-end value delivery, which is focused on applying for a loan. And we say, okay, it looks like this aspect of Cloud infrastructure is causing a problem. This is really slowing things down. Can we find a sensible boundary and provide some of those things as a service from what we’re going to call a platform or platform grouping in teams’ quality terminology. So we are only putting in these other constructs to support that flow value by reducing cognitive load. And we are using that pilot to explore the language we’re using to explore the different team types, to explore the different dynamics when we bring in an enabling team, when the enabling team disengages and goes off somewhere else. Explore how we talk about the value that we’re getting, how we talk about the experience of working in that way, how we do showcasing, how we do a whole bunch of other things this. And we use that pilot to learn how we’re going to do this and what kind of things we need and what kind of what’s the experience and so on and so on. And then we find another opportunity to do it. Maybe this time it’s not applying for a loan, maybe this time it’s something different.
Giovanni Asproni 00:46:36 So it’s really, you go one thing at that time and somehow you defend the slice of your elephant carpaccio in this way.
Matthew Skelton 00:46:42 Exactly. So over time, build up more and more slices of elephant carpaccio, basically thin slices, learning as we go and deliberately sharing that learning across the organization and over time creating a bit of friendly, FOMO friendly fear of missing out, engagement basically. It shouldn’t, it’s not about the fear, but it’s about, oh that’s really looks really cool. I want to be involved with that. What would it take? And building the momentum and excitement over time, but crucially making sure we learn
Giovanni Asproni 00:47:06 A bit of PR to interest the others to into the approach.
Matthew Skelton 00:47:10 Curiosity. Yeah, curiosity. Curiosity around missing out. What’s that? Curiosity around, it’s that kind of thing. People want people to be curious and interested in what’s going on and try and see the value. But crucially getting to that end to state from the very beginning. I did some work in the UK government a few years ago and there’d been some suppliers working in there for multiple years and they still hadn’t deployed anything to production. They’d already been working there for; I think it was three or four years. Not a single line of code had been deployed to production in that time. That’s the place where it needs to start on day one. You build your deployment pipeline, it goes into production, you deploy a text file, and you say, okay, let’s work backwards. Let’s get audit trail in place. Let us get the logging in place, let’s get the approval gates in place that enable that stuff to happen even though it’s just a text file. Because once we’ve got all of that trust and awareness about how we’re going to do this, then we can go really, really quickly.
Giovanni Asproni 00:48:01 I can imagine those situations you’ve been the teams working three, four years without deploying anything. Then you go there and deploy something, whatever it is, the motivation starts to increase because it’s, oh, finally we are actually achieving something.
Matthew Skelton 00:48:14 But we try and do that from day one. Absolutely, we do what’s necessary. I mean that’s part of what my companies do. We do the work with real people and talk people through it to get to the point where we can have that elephant carpaccio because we’ve done the kind of trailblazing we’ve solved the hard problems around technology deployment, pipelines, approval gates, authorization, security, compliance, all that kind of stuff to enable us to get end-to-end deployment from day one. And then over time we’re going to build up what the application does. And yes, we might deliberately, effectively hide the application from the outside world, but we are doing the full end-to-end deployment from as close to day one as possible, ideally from day one. And working in that way then becomes so eye-opening for the stakeholders. Because they can say, wow, the speed of delivery here is just incredible. We’ve managed to get this thing out of there and it’s compliant and it’s, we’ve got an audit trail for it, the auditor’s happy with it and why do we not work this way with everything?
Giovanni Asproni 00:49:13 Are there any common challenges or pitfalls that team encounter when implementing a team topologies approach? Things that you see again and again frequent problems.
Matthew Skelton 00:49:24 First of all, if you think about it, teach project is basically an opinionated version of what the industry is. Collective wisdom around DevOps and Cloud and these practices. It’s an extension of the original Agile software delivery. But clearly, when the original Agile manifesto was created, there was nothing like Cloud, you couldn’t deliver to a global audience on multiple times a day basis. That just wasn’t a thing. The original Agile manifesto was all around desktop software and so on. So although Agile practices are essential, they’re not enough for modern software delivery. So yeah, so a one level team support is not necessarily a special thing. It’s not different from sort of collective wisdom around the industry over the last 20 years. Really. It’s an opinionated version of that. So part of my answer is really around what are the ways in which organizations fail to apply collective wisdom around engineer software engineering.
Matthew Skelton 00:50:17 And so it’s quite common. And that’s the same for everywhere, right? The organizations don’t take the time to understand what’s going on underneath. They don’t understand what’s really, even if you just at the original Agile practices, they don’t really understand what’s going on in terms of some of the team practices things, what’s going on in ensemble programming, what’s really going on in terms of retrospective and things like that. Some of these things just become ceremonies that like then lose all their underlying meaning because the organization hasn’t taken the time to embed that true awareness of the value. And so they end up becoming sort of meaningless. And that’s one of the things that we’ve seen with teams’ bodies. We’ve seen organizations take a very thin or very shallow understanding of team parties.
Matthew Skelton 00:51:00 They just look at 14 types and some interaction modes. They don’t really understand the interaction modes. We’ve not talked about them today, but they still go, oh, I don’t really understand that stuff. It’s not about structure. They see 14 types and then they just go, well that’s it. Basically three weeks we’ll be done. And literally we’re on a workshop with a retailer in North America, the CEO had read the book and in the middle of the workshop he was, okay, this sounds great. We’ll be done in three weeks. Then we all laughed and then there was this really awkward pause where we realized that he actually meant it. Because he really just thought it was about renaming a few teams and then we’re done. He hadn’t internalized the massive changes it implies, which isÖ
Giovanni Asproni 00:51:36 It’s the typical thing. I want to change everything without really changing anything of, sometimes without trying anything.
Matthew Skelton 00:51:40 Exactly. Because the implication of teams’ topologies, the implication of fast flow in general. I mean the implication of the original Agile really, but anyway is we’re reorienting everything to value stream approaches and that includes the architecture, that includes the funding, that includes the processes. That includes if you’re working in a big organization that includes the external procurement, the procurement boundaries you’re using when you are procuring software from external suppliers need to be flow aligned. If you don’t do that then you don’t have any flow. So, there’s a huge implication if you want a flow-based way of working, which is super effective and super humane. If you get there, you’ve got to change quite a lot.
Giovanni Asproni 00:52:18 So you have to change lots of things, not simply the names of the teams or not some random teams.
Matthew Skelton 00:52:22 A few things we should have put a health warning. We should have put a warning on the Team Bodies book, which said warning the implications of working this way are way bigger than you probably imagined.
Giovanni Asproni 00:52:31 You’ve got an opportunity because you said you’re working on the next book about it, you can put it in the next book. Actually you should do that maybe in the cover. One last question about implementation. So team topologies are not supposed to be static. The organization evolves, their needs evolve. Maybe, the value evolves, there could be changes of direction. So how can an organization keep the teams aligned with the changes of value streams and flows? How can an organization do that?
Matthew Skelton 00:53:01 There’s some really nice techniques in particular, there’s a dynamic reteaming from Heidi Health Fund, which provides patterns for reshaping and changing the composition of teams in a way that keeps the teams healthy. So you’re not just pulling people out of teams and throwing them into another team or cutting a team off after a few weeks or a few months. There’s a way of changing teams, which is way healthier than most organizations of practice. That’s pretty useful.
Giovanni Asproni 00:53:27 I would imagine that these practices have an element that is incrementally maybe, iterative. You’re not going to say, okay guys, from now on, this is the new shape of the organization. It’s a sudden change from one day to another. Imagine that is something that you can do in steps somehow.
Matthew Skelton 00:53:43 Exactly. And that’s exactly what the team interaction modes are there to help define. So collaboration and X as a service and facilitation the interaction modes effectively set expectations about what it feels like to work with another team, or another set of teams. So we’re leaning on the emotional aspect of people in the organization saying, well, setting those kinds of expectations and then allowing people to detect when actually, to be honest, it feels we’re expecting to just consume this thing as a service from an API, but actually we are having to email or message people all the time about this thing. It doesn’t feel very service like. Use it as a signal to say, okay, the service boundary used to be good, now it’s not.
Giovanni Asproni 00:54:22 Yeah, I see. So any kind of friction that is kind of not normal for some probably it’s difficult to define it very precisely, but something that they look that are more awkward than what they should be are signals.
Matthew Skelton 00:54:35 It’s a signal for us to have a conversation. It’s a placeholder, guess what, it’s a placeholder for a conversation, right? It’s that kind of mentality. We are looking for things that tell us, let’s regroup, let’s rethink this thing. No one’s blaming anyone. The boundary we put in place 18 months ago was good at the time. The technology’s moved on, the domain’s moved on, the regulations moved on. We need to shift where the responsibility lies so that we got sensible amount of cognitive load and we’ve got better flow and let’s just have a conversation. Okay, let’s have a conversation no one’s, it gets out of that kind of blame game. Blame trap.
Giovanni Asproni 00:55:08 Yeah. Okay. Well thank you very much. I think we’re now approaching the end of our conversation. So I think he helped us to do actually quite a good job I think of introducing team topologies. I think our listeners will have a, let’s say a better introduction. Lots of things to think about if they want to use this approach. Is there anything that we missed that you’d like to mention?
Matthew Skelton 00:55:33 So just a couple of things. We’ve got a growing worldwide partner program with Team Topologies, which is proving increasingly successful and useful around the world. And if you’re interested in joining that let us know, there’s opportunities for organizations and opportunities for individuals as Team Topologies advocates. And if you are interested in the aspect of active knowledge diffusion that I mentioned before where we’re running conferences and engaging people and increasing alignment, then get in touch with me and my company. Conflux as well, we can help on that. If you want to get in contact with me, I’m at MatthewSkelton.com. That’s the easiest place to find me.
Giovanni Asproni 00:56:10 We’ll put some information in the links of this episode. So, thank you Matthew for coming to the show. It’s been quite a pleasure. I really enjoyed the conversation. And this is Giovanni Asproni for Software Engineering Radio. Thank you for listening.
[End of Audio]
