Subscribe
Share
Share
Embed
Exploring how humans connect and get stuff done together, with Dan Hammond and Pia Lee from Squadify.
We need groups of humans to help navigate the world of opportunities and challenges, but we don't always work together effectively. This podcast tackles questions such as "What makes a rockstar team?" "How can we work from anywhere?" "What part does connection play in today's world?"
You'll also hear the thoughts and views of those who are running and leading teams across the world.
[00:00:00] Dan: Let's face it, if you're a senior leader, the thing that keeps you awake at night is asking yourself how to make your organization more productive. The classic way to do this is to focus on the people in the organization. How do you make them more engaged and productive? But is this looking at things the wrong way? Is the actual key to delivering value, how you structure your teams?
[00:00:20] Dan: Our guest in this episode of We, not Me, is Matthew Skelton, author of Team Topologies, who will help us to take a more effective approach to achieving organizational performance by taking a proven approach to building a team of teams.
[00:00:38] Dan: Hello and welcome back to We Not Be the podcast where we explore how humans connect to get stuff done together. I'm Dan Hammond
[00:00:45] Pia: And I am Peter Lee,
[00:00:46] Dan: and happy New year Pierre. This is our first episode of 2025.
[00:00:50] Pia: 2025, A glorious year ahead of us.
[00:00:54] Dan: Magnificent. Magnificent. And now, um, uh, I was looking back to the sort of advent period and, um, thinking about, because I gave a talk To the technology community in my local city leads, um, in Agile Yorkshire. Um, and I gave this talk about, um, small teams. I, I came up with this amusing, festive title about the two Christmas pudding rule.
[00:01:18] Dan: Talked about the elves working in small teams and, um. But yeah, there's a little bit of, um, and a really good fun exploring the science behind why people should work in small teams, which was really good fun, including the famous Ringman Effect and social loafing. Um, which I think I first learned from you back in the day about, um, the sort of experiments that that.
[00:01:41] Pia: the, the depleted effect of having extra people
[00:01:44] Dan: Depleted. Exactly, exactly right. So that when you have three people pulling on a rope, it's basically the same as 2.5 people who are on their own. It is not great. Um, so small teams is where it's at. And actually I referred to, um, our guest today in that talk because, um, having small teams also helps you to sort of focus your efforts on a single smaller goal.
[00:02:07] Dan: And, um, and, but our guest today, uh, Matthew Skelton has done. A lot of work on, um, how you organize teams in organizations, um, to get fast flow, to get fastest possible result out to the user and deliver value as fast as possible. And, um, sort of those smaller teams sort of, um, support that. But um, yeah, we have a really interesting, talk by someone who is really a leader in their field and an author on this stuff. So, um, let's get over and, uh, have a listen to Matthew now.
[00:02:43] Pia: And a really warm welcome to Matthew Skelton. Hi Matt.
[00:02:47] Matthew: Hi. Good to be here.
[00:02:48] Pia: So, um, we've got a lot to learn today. but first, you, you can't go. It's a bit like monopoly. Do not pass, go until you've gone into the chambers to have a question asked. So, um, we'll see what color that. Hammond has chosen for your, whether it's easy, medium, or tough.
[00:03:08] Dan: I have an, um, average average difficulty card for you. Um, and it's, it is the biggest risk I've ever taken is
[00:03:16] Matthew: so the, the, the, the way I would would've answered this, uh, about a year and a half ago would be, oh, I learned how to ride a motorbike and, or things like that, or I, I, um, got up on stage, a massive, uh, auditorium in London and performed some music as part of an ensemble or stuff like that.
[00:03:35] Matthew: But actually, to be honest, um, I've been doing some work on myself. Over the last 18 months or so, and the biggest risk ultimately is the biggest risk I've taken, and to be honest, I'm still taking, I suppose, is to actually get to know myself way better and to connect through to what's really important and to go beyond some like, uh, I dunno, personal fears and things like that and, and really try and connect not just to myself, but to other people too.
[00:04:05] Pia: and, and dare I say, and your English doing this, this is quite an extraordinary feat.
[00:04:09] Matthew: Hey, very good.
[00:04:11] Dan: It's probably a first. Uh,
[00:04:13] Pia: Oh, you are the only person who in the UK who has gone on embarked on this journey. Matt, if you don't mind telling me, what, what prompted you to, to start that journey?
[00:04:24] Matthew: few things, it came, things came to a bit of a head. came to a bit of a crisis point a couple of years ago, um, personally and professionally. Um, it was exacerbated actually by the, by the kind of popularity of, of, uh, the teen Topologies book, which we probably talk about in a minute. Um, because effectively it was sort of, I guess, unexpectedly successful. we've sold like 170,000 copies now. It make, basically makes it not best selling technically, but it makes it extremely well selling and, and, and so on and so on.
[00:04:51] Pia: best selling.
[00:04:53] Matthew: But like what it exposed was that I wasn't ready for, um, leadership, I guess, and I wasn't ready for, um, building a company. I wasn't ready to be an entrepreneur.
[00:05:06] Matthew: And so lots of stuff came together and it was, it was quite difficult. So I've been spending basically the last two years kind of working through that. It's still, it's a journey, right? It is always a journey like you've never done with it. But, um, I'm in a much better place than I was, uh, two years ago for sure.
[00:05:21] Pia: Good on you. Good on you. I think, I think, full marks for, really getting into, stuck into understanding yourself. 'cause I mean, my quip about being English, it, it was not really part of the curriculum for an English life
[00:05:33] Dan: no. If anything, it's how to avoid that. It's, if anything, here's here are ways of deviating around that particular Yeah, exactly.
[00:05:41] Matthew: So the interesting thing for me has been actually having gone through that process myself, or I've been, I'm still going through it. it's really obvious now the extent to which, um, so many organizations refuse. To know themselves effectively in a similar sort of way in a, in a, in an equivalent sort of way.
[00:05:58] Matthew: They refuse to do like the self-reflection or to, to be realistic about what their strengths and capabilities and so on and so on, on what even like the mission and purpose of the organization is. It's just like, Hey, do more stuff. Do more stuff, like do this thing, sell this thing, whatever. Rather than actually really taking the time to become more self-aware.
[00:06:14] Matthew: I can see that with, with this, with this new lens now. And, and that's the lack of self-awareness in organizations is a, is probab, I dunno, probably the biggest blocker to those organizations being successful ultimately because they're, whatever they're fighting against themselves or they're, they're, um, they're just not realistic about a whole bunch of things.
[00:06:33] Matthew: Um, they haven't to find the mission, they haven to defined where they want to get to really as an organization and so on and so on. So that's. That's a perspective which I wouldn't, could have, couldn't see before. I can now. Now I can't not see it. Like it's really, really obvious when I go into organizations.
[00:06:48] Pia: I can't not see it. I can't
[00:06:50] Dan: I got can I not say it? No, I have to say it. Yeah. Um, and well Congratulations, Matthew. It's, um, it's a thing, uh, joking aside, that is often avoided and, um, yeah, wonderful to, wonderful to hear, but I cannot, um, I'm sure our listener won't forgive me if I let your mention of getting up on stage performing in front of a huge group of people without just digging, turning that one over. What, what happened there?
[00:07:14] Matthew: Oh, this is really funny. Um, so I used to do a lot of, uh, singing in choirs. I still really enjoy it, but I've not been doing it for a couple of years. I've actually switched to the trumpet for a while, which is a entirely separate story, but completely amazing. So, yeah, Excellent choice so I played a jazz band and a concert band and thing.
[00:07:30] Matthew: Anyway, so that's all that. But I used to do a lot of, uh, singing in choirs and there was one time when I was, uh, invited to sing with, uh, London Philharmonic Choir, one of the, one of the best amateur choirs in, certainly in the uk, but arguably probably in, in Europe. I guess. They, they do, they're really, really good.
[00:07:46] Matthew: And we ended up, um, singing in the Royal Albert Hall. In London and, um, huge, huge space. Absolutely enormous. It's where the problems, the BBC problems are absolutely enormous space. probably overwhelming for some folks if you've not been there before.
[00:08:00] Matthew: Anyway, I've been a few times already. Anyway, we were on the stage singing a, a big, uh, piece of music for those of who are classical music lovers. It was Beethoven's Ninth, so huge, huge chorusy bit, um, towards the end. The conductor at the time was, uh, Yehudi Menen, the very famous violinist. He was quite old.
[00:08:19] Matthew: Um, and thi this is in no way to to, to disparage his, his talent. But like his, he, I think it's fair to say he was first and foremost a violinist and then only kind of secondarily a conductor and it getting quite old. And he knew the music very well. And at one point, effectively. He sort of stopped conducting the orchestra and started kind of, like doing the motions for playing the violin.
[00:08:44] Matthew: So like he was putting it, it was almost like he was pretending to play the violin, so he wasn't actually conducting, he was sort of like, just just bowing a violin with his arms, kinda like miming. And so basically the leader of the orchestra, the first, the, the, the head violinist had to kind of stand up and wave the bow around to keep things together.
[00:08:59] Dan: So they, they switched, switched, switched roles.
[00:09:02] Matthew: Switched roles. It was really, it was kind of really funny, like everything worked because, 'cause the orchestra was extremely good and the choir was extremely good and everyone, um, had a lot of, goodwill to, towards a whole ensemble thing. But it was, it was fascinating to see it. And I guess that that kind of ensemble experience.
[00:09:17] Matthew: Coming together and, and working as a, as a real ensemble was, I think it's probably influenced me, not, not just that one experience, but the experience of singing in lots of choirs and orchestras and, and, and, and jazz ensembles and things. I think that's influenced me way more, I guess, than I realized. And it, it, it, there's a way of being and a way of, contributing.
[00:09:37] Matthew: In a group setting like that, particularly when it's a performance, particularly when people are paying to see it that many people maybe haven't experienced. Like you actually have to, sort yourself out basically like, like and, and, and pull your weight in that
[00:09:50] Matthew: situation. cause you're literally on stage. I think that probably has influenced some of the. I dunno, assumptions and thinking that I've got definitely, uh, around, um, ways of working in organizations for sure.
[00:10:01] Dan: Well, one of our very first podcasts in this, um, uh, the We Not Me use was, um, with a jazz musician from Sydney and for the, um, Conservatorium. And he talks about, um, jazz being, expressing your individuality without subverting the purpose. Um, and it's quite an interesting sort of balance that, isn't it, how you express yourself, but that actually is the group, the, the whole that's most important.
[00:10:25] Dan: So yes. Well, as a fellow trumpeter, um, sounding like I'm already. You thinking, I, I, I probably can't reach your Dizzy Heights, but I know exactly what you're talking about. Um, but the, um, Matthew, talk, rewind us a little bit. That's a fascinating piece around your recent life winds back a little bit. Where did, where did, how did you get to this point? Give us a bio in a box.
[00:10:43] Matthew: When I was at school, I assumed I would actually do music. To be honest, that's, that was the direction of travel. And then I had a, a sort of a change of heart for various seasons and ended up enrolling on a course at the University of Reading in the south of England. Uh, um, computer science and cybernetics, uh, cybernetics being the science of systems, um, and that kind of thing.
[00:11:03] Matthew: I ended up then going to the University of Oxford to do a degree, a master's degree in neuroscience. So basically brain science, like how the brain works and then, and, and so on and so on. um, so that gave me a, an additional perspective in terms of quite complicated processing, I guess information processing.
[00:11:18] Matthew: I then got my, well, went into being a software engineer. Actually my first job was building software for brain imaging machine, so using some of my like master's awareness of, of, of, um, of how brains work, but then built building software for that and so on. And then ended up just kind of, um, getting more into the, into the detail of, of larger and larger scale software engineering. Ended up in London, did some work for, organizations like London Stock Exchange and Lloyds of London and some big, uh, pharmaceutical companies and telecoms and blah, blah, blah.
[00:11:47] Matthew: And then I then went to work for. a travel retail company based in London. And there I was build and deployment architect, uh, one of two. So we were working very closely right in the middle of the engineering part of the organization, the technology part of the organization, they're in the process of moving away from traditional data centers towards Amazon at the time. and like many organizations in that kind of space, and to be honest, let many organizations still today, there's some tension in terms of ways of working between the people building the code and the people who are then operating some of the systems.
[00:12:17] Matthew: And so it's a way of working through the options of, of development and operations working best together. I ended up doing a blog post exploring different patterns and just thinking about like, here's, here's some, ways of working that are clearly bad, like just not effective. Here's some ways of working more effective and just exploring it and trying to explore the different options. And we did a few workshops around that. With some early customers and which was really helpful in financial services and technology, telecoms a bunch of other places where, where it start. They used the early version of these sort of patterns.
[00:12:48] Matthew: Now, these patterns are then picked up by organizations that included Netflix and Conde na, international big publishing house consultancy like Accenture. Uh, and a whole lot of other organizations picked up these patterns and, and they became quite well used for helping organizations think through what options they've got.
[00:13:05] Matthew: We ourselves did a bunch of consulting with a whole lot of different companies in the uk, big, telecoms company based in China and a whole lot of other places. So we were sort of refined our understanding of what's needed. What companies that were, were, were asking for and finding useful. And eventually as we were working through these different options, we got in contact with Gene Kim from IT Revolution. So the author of the, uh, Phoenix Projects dev, uh, DevOps handbook or the co-author of, of, of these kind of books. And he, he said to me, and, and Manuel, who is who I'd been working with for a while, my co-author, Manuel p said, look guys, how about we publish your book? Why don't you write a book on this stuff? And I'm like, let's sort of codify or coalesce our awareness and, and practical experience and understanding of our own work, but also the work that, so the examples that, um, some industry leading organizations have been showing as well, and try and sort of reverse engineer some of the principles behind things like Amazon AWS two pizza team,
[00:14:09] Matthew: like. Two pizza team. It's kind of cute, but look what's actually behind there. Well, what's behind there at one level is trust. So we, if we've got a small group of people who've got high trust, we can make decisions very quickly. We could keep the context of what we're building because the thing that we're building is within the remit of what, say a group of eight people can, can look after.
[00:14:28] Matthew: So therefore it's always, it's always something that we know how it works rather than trying to tackle something that's too big, and so on and so on. So we try to reverse engineer all of this kind of stuff, bring in some other sociotechnical aspects like Conway's Law, um, but also then some innovations.
[00:14:43] Matthew: So like, yes, we, we put some names to some teams, um, but crucially things like. Introducing the idea of team cognitive load, uh, as a design principle, as an architectural principle. Um, then I think it's fair to say that's, we, we didn't invent it, but we elevated the importance of thinking about cognitive or mental load on the team.
[00:15:04] Matthew: And then things like the team interaction modes to think about how different teams interact and making that a very specific thing. Uh, so collaboration, x as a service and facilitating. So that teams have got a language to navigate complexity and navigate changes in their environment, changes in in technology, changes in business requirements, changes in in, um, compliance, whatever. There's always changes happening, like how do we navigate that and, and work more effectively together?
[00:15:32] Matthew: Manuel and I, when we were writing the book, we probably underestimated the gap between the organizations that we knew about from our research and for working with them or even working inside them, the organizations that we knew about that were setting really good examples. AWS, Netflix, Etsy, these kind of organizations and your typical enterprise, which effectively was really, was operating on really, really, really different lines. ' cause you, you, you, the leading organizations, as we know from the state of DevOps reports, the high performing organizations have got a, uh, got a more generative culture if you go by the Western, uh, organizational typologies, generative culture, um.
[00:16:12] Matthew: Where, people are, are, are happy to speak up and where we're expected to change things and we're expecting to, to have multiple different opinions and, and perspectives and so on. And we're moving towards a, uh, something that, that's sort of continuously improving and so on. Whereas most organizations are stuck in, are kind of bureaucratic or even a kind of dysfunctional sort of, Way of working, very command and control, very much about power of, of, of individual leaders, blah, blah, blah. And that stuff just isn't effective. But the gap, I think, I guess was, was, was way bigger.
[00:16:39] Matthew: And team priorities, I suppose is a way of, I guess we, uh, thinking about myself, I think I probably wanted to nudge organizations towards being more generative. But the gap, I suppose, is. Bigger than I realized. And so if, if we'd been maybe more, well thinking about the next book, I guess what I would be thinking about is like how to set expectations may be a bit better and contextualize things so the organization can say, well, actually yes, we want some of that, some of those good outcomes that come from a generative culture and fast flow and the rest of it. But oh yeah, it's actually gonna take us 3, 5, 10, 15 years to get there. It's not just like a three week or three month exercise.
[00:17:18] Dan: So, um, we're talking about organizations. I, this is obviously a very applicable topic for so many people, um, organizations getting stuff done fast and right, I guess is, is what, uh, what people wanna do or in, in some way that's useful to the user.
[00:17:31] Dan: Could you, what, what. Could you talk a bit more about that? What's what, um, particularly what slows that down? I mean, what's, what are the, what are the problems that you are solving here?
[00:17:41] Matthew: So when we're, particularly when we're talking about, um, software, but also knowledge work in general, there's a lot of people who think it should just be really straightforward and simple. Oh, I just need this thing doing. Just do it. Um, and those people tend generally to be on the kind of business side, on the sales or marketing or product side, let's say.
[00:17:59] Matthew: Um, and often don't take the time to understand the details of what they're really asking for. so. In some cases, some people in that kind of space find it almost offensive to have to understand the details of technology or the details of, of how this stuff needs to work. And so they, they, they don't want to, uh, they don't want to take, take the time to, to really get to grips with this system of work that, that an organization really is and to, to work with it.
[00:18:27] Matthew: Um, and often that's, that's a significant part of the problem, the way in which the work works, the way which, which work has been set up. It's incredibly ineffective. There's lots of dependencies between multiple different teams. Um, there's an idea that, oh, we have to build all this stuff in one big block and deploy it all together.
[00:18:42] Matthew: or even the way in which the organization has been designed has been designed by, for example, the HR department or by people without any awareness of things like flow, without any awareness of things like domain boundaries and the meaning and semantics of the work. All of these things need to come together if we're gonna have an effective, very rapid way of delivering value.
[00:19:01] Matthew: If you wanna go slowly, then have your organization designed by HR or by some managers or whatever who don't really know the details. But if you want to go rapidly, there's all of these different like sociotechnical aspects that we need to bring into play, and we can make that work. It's been proven plenty of times, but if you ignore the sociotechnical aspects, then that's where things tend to slow down.
[00:19:20] Dan: So just diving in on that particular topic of dependencies, um, it's, it's, it's interesting because if we think about the work that we've done in organizations, in a way sort of. This is looking at this in a new way because what a lot of work we used to do back in the day was sort of help these sort of teams or silos even, which isn't quite the same thing, but people to sort of work out those interdependencies and, and collaborate more. But you are, but you are seeing dependencies as part of that problem actually, aren't you?
[00:19:53] Matthew: So one of the things we recommend in the team support book is, or we, we advocate for or talk about in the team support book is that that collaborate more is actually, is the wrong thing to do. and it sounds counterintuitive because people go, oh, we need to collaborate more. We'll get more stuff done.
[00:20:04] Matthew: Well, up to a point, yes, but actually unbounded collaboration just leads to a tangled mess and you can't do anything. So what we actually need to do. Is to find effective boundaries for flow. And those effective boundaries typically are domain boundaries. So demand boundaries defined by the meaning of what we're working on.
[00:20:19] Matthew: So if you've got a concept of like in an organization, if you're selling something, you might have an order, but that the word order might mean three different things inside the organization, depending on who's who you're talking to and which part of the process you're talking about. If you've got three different meanings for the word order, you've got three different.
[00:20:33] Matthew: Debate or sub debate or something like this. I mean, that's a very, a gross simplification, but that's the kind of thing we're talking about. So it's the semantics of, of the concepts we're trying to represent. And typically that's a good starting point for, for good boundaries, for flow. We're keeping things separate.
[00:20:44] Matthew: That should be separate. We're deliberately keeping things separate. We're deliberately looking for opportunities to not bring things together. And that sounds very counterintuitive to people, but if we get the, those boundaries aligned to flow or value. So if they're, if they're effective boundaries for flow, then things can work really, really well.
[00:21:00] Matthew: And so actually to some extent, less collaboration is good, or at least we have to be very mindful about where that collaboration happens. And from a team quality perspective, the collaboration is there mostly to find an and refine boundaries for flow. Like we're trying to get a new API in place, or we're trying to like adjust our responsibility boundaries for something, whatever.
[00:21:20] Matthew: That's when we might collaborate to try and discover something, discover an approach which is gonna be better for flow. Um, so some of these ideas are actually counterintuitive when we have to go very quickly.
[00:21:29] Dan: And if, if we sort of slightly de agonize that, um, or bring it down to sort of plain English, we're talking about setting up teams, sort of teams of teams if you like, you know, in the organization. But the, those teams are chosen, who is in that team and what do they do are deliberately chosen to be quite autonomous, autonomous, independent, that they stick within their sort of, when you talk about boundaries, their sort of area of responsibility or something like that so that they can do their whole job without waiting for someone. Another team is that, um, oversimplifying
[00:22:05] Matthew: that's the starting point. So we, we asked the question, what would it take for a single small team of up to about eight people, eight or nine people? What would it take for that team to be able to do the vast majority of the work on a particular flow of value themselves? That's it. That's the starting point.
[00:22:19] Matthew: Because the reason why we want a single team is there's no handoffs. Handoffs are a real blockage of flow, a real killer for flow. So we start with that premise. What would we need? We need a mix of skills. Um, why, why do we, why do we care about such a small team? Is to, to maximize trust inside the team and therefore they can make decisions very quickly.
[00:22:34] Matthew: And so if they can make decisions very quickly, then they can effectively steward and look after a particular service or product or user journey or something by themselves. But then we have to ask a whole lot of other things as well. Well, how much, how much work do they do? What, what's the depth of the, the technology stack or the, the, The knowledge stack effectively, if you're talking about stuff that's outside of it. So in say, a medical context or an education context, what's the depth of that knowledge stack? What stuff should they not need to care about and work backwards from there? And that's, that's effectively the starting point for, for teen bodies.
[00:23:04] Matthew: What would it take for a small team to be able to own and deliver, own or, or steward and look after an ongoing service or product or used journey for and, and evolve that safely? Effectively over the course of months or years because that's the nature of the kind of of services that we've got in place these days.
[00:23:21] Pia: So it sounds a little bit like the task is actually really dictating the flow and the connection is about the delivery of the task. There's not a human element. There's nothing warm and fuzzy about any of this.
[00:23:34] Matthew: So I, I think there's a very human element. So at the heart of Teen Topologies is, is empathy for the people working. There is a real deep connection to the humane to make the work humane because part of, uh, what we saw working in organizations was, was, um, a kind of inhumane ways of working where people were piled on, were asked to do more and more and more work.
[00:23:55] Matthew: They were, they, no one was thinking about the depth of the stack. No one was thinking about the cognitive load. No one was thinking about the onca experience and so on and so, so, I would say that the heart, tea body is very much a caring for, for the human experience, but this is not about it being warm and fuzzy.
[00:24:09] Matthew: This is about it being effective. So we're, we're here to, to do a job, we're here to deliver business value or organizational value if we're in public sector or something. and this is not about the warm and fuzzies. This is about, this is about people stepping up and doing a really good job, in the context of a, of, of a team.
[00:24:26] Matthew: If we adopt these principles and terminology and, and so on as we're designing the organization, then we get a humane, effective organization as well, if you like. That's what, that's what will, that's what will come of it. And this is what people say when, when we're adopted, the teen support principles, they say, yeah, it's People really appreciate the, the language and clarity and the sense of, um, the sense of empowerment to be able to detect when things are going wrong. That's one of the things that team's language and patterns are providing.
[00:24:54] Dan: I, I, this is the penny has just dropped for me lately, uh, about this, which is, um, which is sort of this obvious notion of the organization wants to deliver things. What you do is you start with that flow, and then you build your team structures around that flow instead of what we often see, which is we've got a team structure. How do you make them work better to flow?
[00:25:16] Matthew: But, but, and, but that's the interesting thing. Like we, I I, I completely agree with you and, and actually the, the penny kind of dropped for me after writing the book and after we've been working with organizations for a while, which is that many, many organizations don't really understand their value flows.
[00:25:31] Matthew: they're not thought a bit like, thought a bit like that. They've thought of, we need to sell some stuff. We've got these contracts we need to fulfill. Let's just get this stuff out the door. But they're not really thinking about where the value is for the customer necessarily or the user.
[00:25:41] Matthew: They're not really thinking about what these different flows are and how they relate and how they support each other, or like an ecosystem of value. Effectively. They're not thinking about it in those terms. They're sort of thinking about it in, we've got a lot of people, how can we get some stuff out the door? And there's a, it's a big shift.
[00:25:55] Dan: and even if you take the next step, which is to say, okay, we are not gonna be functionally driven or whatever, we're gonna have teams of teams delivering things that then it's still not start, it's still starting with a team structure. And getting them to flow. It's not that full actually sort of flow-based design. I, I, I guess, um.
[00:26:15] Dan: So Matthew, can you illustrate this with a, sort of, with an example where have you seen this, um, when have you seen a, uh, someone adopt this even in a small way that has had a, had a, an impact?
[00:26:26] Matthew: Well, fundamentally, teen Topologies is really just an opinionated encoding of all the learning from DevOps and cloud. Since 2008. It's not anything special, particularly, it's, it's 'cause we, Manuel and I were working in that space, continuous delivery, DevOps and things. Uh, way back, I gave my first talk at DevOps days conference in 2010.
[00:26:46] Matthew: So I was there not from the very beginning, but pretty early on. and so we'd been living in that space right as we, we'd internalize all of the stuff about flow and feedback loops and uh, autonomy and so on and so on. Teach parties effectively is, Opinionated sort of distillation of practice that was already in existence.
[00:27:02] Matthew: So places like Netflix and Amazon, AWS and Etsy and a lot of these places like this have been demonstrating these kind of ways of working. Not exactly like change properties, but very, very similar. And so what we tried to do is reverse engineer some of the principles and, and patterns that were, that under, were underneath some of these organizations you hear about. Amazon, two pizza teams. What does that mean? It's not about the pizza, right? It's about trust. It's about well-defined boundaries. Um, yeah. it's about well-defined boundaries. It's, it's about, it's about, actually at Amazon, it's about, um, ways of working that actually result in a. super linear scaling.
[00:27:36] Matthew: In other words, as they add more people, they get increased effectiveness, whereas most organizations, when they add people, they get, they get less than one person's, um, worth of effectiveness out. So it's, there's, there's some fundamental things that are, that are sitting underneath these kind of ways of working.
[00:27:51] Matthew: so if we're saying like, where have these kind of approaches been seen? You can look in the state of DevOps report 2021, which says, I, I'm, I'm paraphrasing something like, um. Uh, high performing organizations, are generally adopt topologies principles, something like this. So that was the state of report from 2021, you know, multiple thousands of people surveyed.
[00:28:10] Matthew: There, there's a really nice case study on the Teen Topologies website from, uh, from a company called Uswitch. They're basic in the uk they do consumer, um, like utility switching, like broadband switching or mobile phone switching, that kind of thing. And a bunch of other things. I think insurance comparison and things now. Anyway, Uswitch has been at the forefront of kind of practices and things like that for quite a while. And, uh, back in, I think 2015, they started to, um, they, they were really starting to gain market traction. And the story takes 'em through, uh, takes us through, their evolution. they had, they started with like the, with three independent teams working on, on three completely different areas, and over time their cognitive load in those teams increased and increased to the point where the organization realized they need, or the CTO Paul Ingles realized they needed to introduce something to manage that cognitive load.
[00:28:58] Matthew: And that turned out to be a platform, a technology platform, which, which helped basically, but the way in which they made those decisions. It itself was informed by teams, apologies. And when we learned from them in, in, in, in, in return. And, uh, and that's why there's a case study on the website. But anyway, the, the key, the key point there is they were thinking about keeping these teams independent, but then managing that cognitive load on the teams and then introducing, uh, platforms in a way, what we call a platform, which is just a construct which reduces cognitive load and improves flow.
[00:29:29] Matthew: Um, see it like an innovation engine effectively. So introducing platforms in a way which was non-compulsory, so teams could choose to adopt those platforms. The, the, the platform people had to effectively market their internal platform to the internal teams, the, the, the, the streamlined teams. And then after, I think it was about two years, they persuaded all of the streamlines teams to use that platform because it was so good and it, and that the nature of that dynamic.
[00:29:54] Matthew: We're keeping the discipline not to force teams to use an internal central platform is so important and the whole case study's worth, worth looking at. If you go to team support.com/yoUswitch, you'll, you'll find it there. But like, it's a really good example of, of decisions that were made with really good understanding with, with a, with a strong empathy for the teams involved, keeping them autonomous, but giving them choices with the result that it significantly, Improved the, the, the experience and life for all the people involved and helped to, to kind of accelerate what they're doing and, and reduce waste and.
[00:30:25] Dan: So. is, are there any, it sounds, sounds really well accepted. Are there any contrary voices? Is there anyone who sort of says, actually, I've read the book and I'm not convinced, or, uh, there's this, this is not, this is not right for some reason, even on the margins. Is, is there any, is there any sort of an alternative school of thought, I guess?
[00:30:45] Matthew: Yeah, there are some alternative skills of thoughts, um, schools of thought. Um, the main one really comes from a place where people, people are looking to, well, two things really. There's a group of people who. Are concerned that very small teams with, with ongoing strong stewardship or ownership of, of, of systems creates for a fragmented experience and a fragmented kind of value proposition, blah, blah, blah.
[00:31:10] Matthew: And I've got some sympathy for that. But the reality is if we want to go quickly, we can't, we cannot have great big bundles of things that are being deployed together. It just, it just doesn't work. We have to be able to deploy a fine grain, a more fine grain frequency and allow the value to emerge. As and when the different pieces of the puzzle are actually there ready.
[00:31:28] Matthew: So that, that, um, that drive towards bigger chunks of value effectively is for me feels like a pre-cloud, a pre DevOps kind of way of thinking. Because back then there was no, you had to release a piece of software in, in one big block, like desktop software or what have you. It had to be pulled together in a single thing.
[00:31:47] Matthew: You couldn't do the, the intermediate deployments, whereas now we can. So that kind of thinking for me feels like it's, I don't know, pre. Like a 1990s, 2000 kind of way of thinking. And there's another kind of group of people who for some reason find the, when, when you peel back what they're saying.
[00:32:04] Matthew: They really are trying to optimize for the developer. I. Interest or excitement about what's going on in, in the code. So allow developers to move across the code base and, and kind of work on whatever they fancy, which kind of sounds appealing. And it sounds kind of cute and fluffy and things, but, and, and to some extent it might be fine.
[00:32:21] Matthew: Like there are ways of, there are certain kind of knowledge work where that kind of approach might be okay. For example, if you're tidying up after, uh, it's, it's Halloween when we're recording this, right? So if you're tidying up after a kid's Halloween party, There's no, no ongoing implication of how you tidy up.
[00:32:36] Matthew: Like you tidy up, you're done. It's finished. Whereas when we're building long-lived services for things like a pension or bank account or for whatever it is, healthcare, there is an implication for, for the changes we make today, have an implication on how it, how we're able to change things tomorrow, and so on and so on. And. I strongly believe it's very important that we take that into account.
[00:32:55] Matthew: So the incentives that we've got for writing code today need to be, need to include how that is going to evolve in the future, how we're gonna support it when it goes down at the 2:00 AM, and so on and so on. And so this idea of like, so this, this kind of, um, liberty of multiple different people roaming all of the code base and, and kind of picking what they work on feels kind of naive to me in this context.
[00:33:17] Dan: And possibly depends on that your, your organizational objectives. But if, if you think that's sort of way to engage people, but it sounds like it would slow the flow in your experience.
[00:33:28] Matthew: So it's, it slows the flow in the sense that, people. Certainly my experience will end up making decisions which are not, which are, don't have enough context, they don't have the context of how that code base needs to evolve and has evolved in, in the past. People make changes to get a feature in, get it out the door, and then effectively they, they've reduced the health of that code base.
[00:33:46] Matthew: Now, it, it definitely, it definitely happens in, in software development. I suspect, although I haven't done the research, I suspect it happens in other kind of, I, uh, other kind of knowledge work too. So if people don't have a continuous, like, uh, stewardship of a particular kind of domain or particular area in knowledge work, whether it's healthcare or it's education or it's something else, then there's a danger that that context is lost and therefore then outcomes are not as good.
[00:34:10] Matthew: And in some cases, like in in, in medical care, we know that handoffs. lead to higher rates of death. I mean, this is, this is life and death at that point. Whereas in software, it's, it's usually not high life and death. And in education say it's not really about life and death, it's about the quality of the, I don't know, the university course we're creating or something like that.
[00:34:29] Matthew: But there is this real sense in which a lack of continuity there. if, if we're just optimizing for the experience of people who, who want to be creating new stuff, that to me feels, yeah, it feels a bit naive to me.
[00:34:41] Pia: And what's been the impact for the, the leader of the team or, or are these self-managed teams? So, so what's the experience for them with the accountability of the team and for the outputs? Like what have you noticed there?
[00:34:56] Matthew: So I think what, what we'd expect to see and what we, what the organizations that are really, um, working well in this kind of space, what they do is we should get, we should expect to get to a point where the manager doesn't have to manage the team members, I mean it feels like a very taylorist approach where you've got to have a manager, like dictating to the workers what they do.
[00:35:17] Matthew: Like we get to the point where the team is substantially self-managing. We've got responsible adults, they're actually engaged, they're working on things together. We've, we've taken the time to build that team and we've taken the time to have that team develop this, the sense of teamwork working together, the manager.
[00:35:34] Matthew: At that point, the job is more about managing impediments, like unblocking impediments. I mean, that, that's what the scrum master role was in, in, in software development. But it's turned into something else now. But like the manager can be looking at what the impeded, what impediments the team's got. Like are the team boundaries still effective?
[00:35:52] Matthew: Maybe we need to like look at where the team is, is blocked on things where they're waiting. Do we need to upskill? Do we need to have a period of kind of facilitation from, um, from an enabling team to help us get over this particular hurdle. It's, it's more about, it should be more about unblocking flow.
[00:36:09] Matthew: And to be honest, that's, that's the role that any kind of manager should have across a whole organization, including at one level, the CEO, the CEO. She, at one level should be asking the question, how can I unblock flow across the organization? What do I need to do in order to do that? How can I empower people across the organization to.
[00:36:26] Matthew: To do their best, given that we understand our value flows and so on and so on. What is, what is impeding, um, that value flow? And it might be a mixture of things, skills, and it might be the way we've got things set up and it might be, who knows, like some processes that, that are legacy and so on and so on.
[00:36:41] Matthew: But that kind of manager role turns into turns from Commander Control dictating what we do, or at least, uh, pushing people to do certain things into. Setting the environment, like, uh, tweaking the environment and looking for blockers to flow, looking for impediments and, and removing them.
[00:36:58] Dan: It's, um, yeah, it's quite a shift that I think as well, isn't it, for a lot of people's mindsets. Um, Matthew, can I just, um, sort of take a slight diversion Whenev, when I first came across your book, the, um, people strongly recommend it. The next thing they said was, and um, and do you know about Conway's Law?
[00:37:15] Dan: Now? I dunno. Um, I don't know why these things have got connected, but as we're talking about organizational design, I found that to be a really interesting concept. Um, and it's sort of slightly, can you talk about that in the context of what it is and what the con in, in, what's the meaning of the context of team topologies?
[00:37:31] Matthew: So Conway's Law is the name that's given to an observation from Mel Conway in a, in a scientific paper he published in, in 1968. Uh, he'd worked on all kind of systems, I think from the US Navy. I. Two big early, uh, computer systems, I think from IBM and places like that. And he'd observed how, uh, how products get built.
[00:37:52] Matthew: And the, the, the title of the article that he wrote was How Do Committees Invent? And in there he was kind of laid a, laid out his, his, his observations, including the observation that effectively the, The shape of the communication pathways in the organization sort of dictates the shape of the eventual product, and it was a kind of off the cuff observation to an extent.
[00:38:13] Matthew: Anyway. More recently, there's been some research into this, in automotive industry, in in jet engine manufacture, in software and a bunch of other places. And the evidence is there to say that when we're building, certainly when we're building kind of engineery type things, like software, like, like these kind of systems, then that relationship seems to hold the communication pathways in the organization effectively mirror the, the product architecture and vice versa.
[00:38:37] Matthew: So we've got like a, What's called a homomorphic force. It's something that tries to keep things the same, and there's lots of reasons for that because like communication pathways effectively about information flow and so on and so on. There's, there's, there's reasons behind it, but the, the long and short of it is that if we don't consider.
[00:38:53] Matthew: The shape of the organization that we're, that we're designing and, and building in terms of the communication pathways. It's not about the org chart, it's about the communication pathways. If we don't consider what those communication pathways are, are doing, then we're accidentally reshaping the product, or we're making, we might be making it harder to build the product or services that we want.
[00:39:11] Matthew: So if we want to make our lives way easier, then we need to take Conway's law into account and think about the interactions and communication pathways between the different teams. And that's then reflected in, in the teams bodies book,
[00:39:22] Dan: It's really interesting. There's sort of, it's very much about the flow and the output you want, and you've got to be really wary of the organization you create because it, it sort of imprints itself. I think it's, it is
[00:39:33] Matthew: It's, it's something that really makes a difference when we're going very quickly. Like if we were going really slowly, then you can probably just nudge it and, and we wouldn't, I mean, it'd still be more painful than it would need to be. But if we're, as we're going very, very rapidly as it becomes possible to deploy hundreds of times a day, particularly with like agentic ai.
[00:39:53] Matthew: Which are, you know, generative AI creating software applications, something like this. We're deploying thousands or even, you know, hundreds of thousands of times a day. Small changes the software systems. Then the shape of those responsibility boundaries, whether it's human teams or whether it's a Gentech ai.
[00:40:08] Matthew: Is gonna have an impact on the, the, the maintainability, the evolvability of these services, and how well they actually represent the concepts that we're, that we're trying to, that we're trying to, um, encode. And so that then becomes a real like, strategic challenge for organizations because potentially these organizations are accidentally making it really hard for themselves to, to work with digital services,
[00:40:30] Pia: So Matthew, we talked quite a lot about decoupling and I guess there's always a, a challenge there around fragmentation. What's the process then of, of ensuring that doesn't happen and bringing it together? I think, I think that, I think we turned that as diffusion. Could you, can you tell us a bit more about what that involves?
[00:40:48] Matthew: Sure. So if we're gonna go quickly, if you're gonna have fast flow of value, which is what we need in many or most organizations, uh, these days, certainly if you're offering kind of business services, then we need to have decoupling of teams and architecture for fast flow. That's the only way we get to that point. We need to decouple along, say domain boundaries or along, um, compliance boundaries or performance boundaries. A a bunch of other boundaries in the teams bodies book we call these fractured planes. So fine. So we've, we've got an architecture for flow. We've got teams, processes, even, even money decoupled along these different flow boundaries.
[00:41:22] Matthew: Brilliant. All great. the, the challenge then is that, or the real, the danger is that some organizations would take that too far and then have effectively lots and lots of little, you might call 'em flow-based silos, all working independently, not really talking to each other. In fact, we ended up, we did some work with an organization where they had sort of got down that they got themselves into a sticky position in, in, in that space where.
[00:41:44] Matthew: Like the team, the development manager or the team leader was saying to people in their team, no, don't go and talk to people from the other team because just focus on your own work and that's not a good place to be. And so what we need in the context of, so we've decoupled for fast flow, but what we need in addition is diffusion of.
[00:42:02] Matthew: Learning trust engagement across the organization. So we bring together some kind of loose alignment. Loose alignment. The, so we we're not, we're not locking everything together. We're not saying, you must think like this, or you must do all of this stuff exactly the same time. But we've got some kind of loose alignment across the organization.
[00:42:17] Matthew: So we've got an awareness of how we're going to use ChatGPT. We've got an awareness of how we're going to use, uh, machine learning. We've got an awareness of how we're going to use Edge rather than cloud, and so on and so on. and that diffusion of learning needs to come through community activities.
[00:42:33] Matthew: So weekly, lunch and Learns, talks, um, public blog posts, internal conferences. community based ways of defining, uh, standards for doing software or for doing data or whatever it is, and so on and so on. So generally making sure there's a focus on building trust and engagement and alignment in a community centric way, uh, with people coming together.
[00:42:55] Matthew: Where possible for food and actually meeting each other, say in the office. Um, if it's not possible, then we, we, we do that remotely, but there's some element of, of in person at some point during the year, uh, for, for, for organizations that are, are doing this effectively so that it is worth having a budget to pay for people to all come to a single place and get to know each other.
[00:43:15] Matthew: because without that, Diffusion of awareness and diffusion of, of knowledge across the organization. We end up with, with lots of little silos. So There's two dimensions. There's the, there's the, there's a decoupling dimension, decoupling for flow, really important. That's the architecture part, but then there's the diffusion of knowledge part, which it needs to be more diffuse. It can't be, it can't we, we can't get that alignment through working together because we're working on multiple different things. Each, we, each team is working on something separate, let's say.
[00:43:42] Matthew: So we don't get the opportunity necessarily to, to, to learn from each other when we're doing the work. So we learn from each other separately using, yeah, like I said, internal conferences and uh, lunchtime talks and a bunch of other things like this. It's then bring people to together slightly outside of the context of their daily work, but we're still learning from each other.
[00:44:00] Pia: that makes that very clear, but. There's a, there's a complexity to this and there's quite a lot to understand. So for our listeners embarking on this or thinking about how they can make the first steps, What would your suggestion be about, about how to do that when they're considering, flow of work, their people, and optimizing? What would you suggest.
[00:44:23] Matthew: So like always the, the right thing to do is to start small. Like don't try and reorganize the entire organization. That makes no sense. We start small, we'd find an end-to-end flow of value that we want to explore to start with, and we see how we can actually make that happen. so that's in terms of the flow of our, so we, we, we work out, well, let's just try this thing.
[00:44:41] Matthew: We've got a single team of nine people. They've got a mixture of skills. We think they should be able to deal with this end-to-end user experience or this particular, product or service, they should be able to build it themselves. Let's try it out and see what impediments there are, rinse and repeat, learn from that, and then start on a second flow of value and so on and so on.
[00:44:57] Matthew: And over time we're learning and, and adapting based on, on what we're seeing. But at the same time, clearly what we need is the diffusion part as well. So as part of this, we need to be then setting up some lunchtime learning sessions and sharing, and people get the permission. We need to get permission to have a public blog, technical blog, like sharing what we're doing as we're, uh, adopting flow-based approaches like change properties.
[00:45:21] Matthew: It's, it's the two dimensions we need to have at the same time. Um, and then over time we'll be increasing our awareness, publishing that out or, or, or showcasing what we're doing across the organization so people can. Can learn what's happening and understand why. And over time then we've, we, we've, we've built the organizational muscles to be able to do this effectively. it has to be a, an approach where we're expecting to learn and expecting to adapt rather than just a big bang. We've changed everything in one go.
[00:45:48] Dan: That makes, that makes a lot of sense, Matthew. It's, it's, it's, um, But, uh, final question for you, Matthew, is, is always about a media recommendation. So could be anything, what's Pepper bee,
[00:45:59] Matthew: Peppa Pig?
[00:46:00] Dan: uh, is strongly recommended. No. But, um, yeah. What, what, um, what has entertained or educated you or
[00:46:08] Matthew: So I actually recommend three things 'cause I'm not gonna make a single choice. Right? So the th two books and one film, the, the first book is called, uh, Empowered Agile Transformation, and it's by Alex, Alex Stokes, who's based in Australia. I had the fortune, I had the good fortune to, um, to meet her in person.
[00:46:24] Matthew: She came to the UK recently and she and I did a workshop together in Manchester, and it was amazing. I learned a huge amount from Alex. And we basically did a mashup between the Teen Paul book and, and, and Power Agile Transformation Superbook. Go and read it, um, and particularly go and use it in, in combination with the Teen Topologies book to help you think through how you actually do the transformation in your, in your organization.
[00:46:45] Matthew: The second book is, Architecture Modernization by Nick Tune, and it's an amazing book. Like it's really, it really, uh, goes into the detail of how to think about creating architectures for flow. Uh, uh, lots of references to team topologies and domain driven design and water mapping, and a bunch of these techniques. Really, really valuable practical guidance on like, how to do this stuff, how to reshape architecture for flow, which is, which is what we need. This is, we need to make the architectures of, of the systems that we're building, the architecture of the organization needs to be something that where we can, we can adapt and change it, and we're making changes on, on a daily basis. Super book.
[00:47:18] Matthew: Um, the third thing, the third thing I recommend weirdly, is, um, is Frozen. Two, the movie.
[00:47:27] Pia: You see,
[00:47:27] Dan: two. Okay.
[00:47:29] Pia: knew it was gonna happen.
[00:47:30] Matthew: Bear with me. Bear with me because. Uh, it turns out, so I actually did a talk about this, like, um, how to Fail with Team Topologies and I used loads of quotations, direct quotations from Frozen two to do this.
[00:47:42] Matthew: So this is a Disney movie and it's got, um, a, an ice queen princess with magical powers and they go on a journey and they, they save the day, but there's so many quotations in there about transformation. There's so many quotations in there about, Kind of change and, self-awareness, I guess.
[00:48:01] Matthew: Things like this is actually really funny. Like, I literally like got the, got the text directly from the film copy, pasted it into the slides, and it fits really, really well. Um, so actually weirdly, even, even if you don't have a, you don't know a small child or whatever who likes, who likes kind of Disney movies like that, it's actually quite funny to watch it in terms of the sort of quotations that that. Pop out that relate directly to like organizational transformation
[00:48:25] Dan: Great record and once, so once you've read the fir, once you've read the two books, you can reward yourself with a, with frozen two. But yeah, brilliant. A great way to end. Matthew, thank you for talking us through this, topic, which is so important, has some complexity to it obviously. So some real, as you say, requires uh, some, some real diving in to think about it.
[00:48:45] Dan: But having, um, attended one of your workshops and started reading your book, I think you make it all quite simple there. So thank you for talking it through and um, for being with us today on we, not me
[00:48:55] Matthew: Great to be here. Thank you. Thank you for the questions
[00:48:59] Pia: I think Matthew's got a fascinating way of looking at this, and I mean, uh, clearly a very intelligent chap and yeah, and it's, this is quite a technical way of actually looking at the interactions. You can see that quite a systemic view of the way that he sees how teams interact. And then this concept of sort of decoupling.
[00:49:19] Pia: What are, what are things that you need to pull apart? Um, and then the diffuse, what are the things in order to make sure that we don't build on natural silos or lose information? So, really, quite interesting concepts. And I guess they also would vary according to the personalities you have in teams. I, it could work really well. Potentially in more technical type TE teams, but maybe less so. That might be a little harder ' cause it might be a bit more freewheeling
[00:49:48] Dan: Yes, I think yes. That's a good point actually. I know, um, uh, Matthew sort of used this in multiple types of organization, but I'm sure it does depend on that. But I, I, I, I, I had that rather embarrassing, epiphany during this conversation, which was that we, that we want organizations to deliver things rapidly, but we actually.
[00:50:10] Dan: Don't organize ourselves For that, we put an organization together and say, okay, now how, now let's make this organization deliver. Instead of saying, we need to deliver these things. How do we organ, how do we structure ourselves to deliver? So for example, anything with a sort of, with si big silos or functions.
[00:50:30] Dan: And that hasn't really been built with fast flow in mind with delivery. It's been built with, um, functional expertise and the sort of older models. I mean, as I say, it. It. I've worked in this field helping organizations doing this like you have for many, many years, but it's never really occurred to me that we're just do doing it totally backwards.
[00:50:51] Dan: And uh, Matthew's really got a good point, I think here. Um, the other one that struck me, that's really, I think so. Um, important now is what Matthew, talks about in the, in, in, um, cognitive load. The cognitive load of teams. And I've had a few conversations with people about that recently 'cause it's really sparked an interest for me.
[00:51:12] Dan: And I think, you know, you and I work with quite a lot of teams helping them to, and we use it ourselves to use agile and a lot of that is about reducing cognitive load. So not sort of be loaded by all the things you could do, but there are so many. Um, pressures on teams now, sort of inputs that can really overwhelm and confuse you in, in what, where you want to go.
[00:51:33] Dan: So again, being really deliberate in teams about what are we working on, what aren't we working on? What are we paying attention to? Um, and in this case, as much as possible, reducing the scope of the team so that you, you know, just by your design so that you're not trying to do too many things and. Just wrapping up the point, but the, when I see teams with very large numbers of people, they've got a lot of objectives as well.
[00:52:01] Dan: They've sort of mushed them together, sort of loosely saying, oh yeah, well, they can do all those things and actually this is really convincing. Yeah. Do you know what I mean? And break that. The load of that it looks. Sort of efficient 'cause they've only got one manager. Great. It's not efficient because the working of that is just, it's almost unworkable actually to, to, to try to create a team out of 18, 20 people.
[00:52:24] Pia: Because the complexity plays a part, um, it becomes overwhelm and then you then start falling into the trap of people feeling like they don't trust people or there's breakdowns in communication. So, you know that, that, that that overload doesn't set you up for success. Whereas in, you know, it, it is, it, it is that whole prioritization of focus. What are the big rocks that you need to, to work on first and what, and how do they drive, drive the activity?
[00:52:52] Dan: No. Absolutely. And I actually, in doing my research for the, um, presentation, they were saying that a lot of sports teams are small, and if they're bigger, they tend to break out into mini teams. So you've got forwards and backs, and they operate actually even on the field quite separately in some ways.
[00:53:08] Dan: Not always, but they, they have this sort of, they actually. Have that decoupling essentially on, on the field. So yeah, it's great. I think this is a really thought provoking thing for any organizational development person. CEOs, c hr, chief, HR officers, anyone really who's, who's got more than about five people in their organization to think how you're gonna do this.
[00:53:28] Dan: So, um, a really. Um, stimulating conversation. Lots of links in the, in the show notes today, um, for everyone to feast on, but that is the, that is it for this episode. Um, we, not Me, is supported by Squadify. Squadify helps any team to build engagement and to drive performance. You can find show notes as I just mentioned, where you are listening, and also at squadify.net. If you've enjoyed the show, please do share the love and recommend it to your friends. We, not Me, is produced by Mark Steadman. Thank you so much for listening. It's goodbye from me.
[00:53:56] Pia: And it's goodbye from me.