Episode 123: Making a Viable Organization

A conversation with Matthew Skelton. Founder at Conflux and co-author of Team Topologies: Organizing Business and Technology Teams for Fast Flow.

This article was originally published on?voltagecontrol.com

“Teams might be better able to own things if we adjust the boundaries or might find it really tricky because the cognitive load is too high. So suddenly we’re talking about stuff which is not just technology, it’s about making a viable organization effectively. We’re thinking about viability, the ongoing ownership of different streams of change on an ongoing basis. That’s a healthy conversation to have for any organization to be honest.” — Matthew Skelton

In this episode of Control the Room, I had the pleasure of speaking with Matthew Skelton about his journey in organization dynamics. He starts with reflections on people and cohesion. Later, Matthew shares how he applied software principles to teams. We also discuss simple tips for balancing cognitive load when considering the big picture and getting stuff done. Listen in for thoughts on how to be more intentional in doing organizational work.

Show Highlights

[1:30] How Matthew Got His Start In Organizational Dynamics

[13:44] How To Make Sense Making Organizations

[24:25] Applying Software Principles To Teams

[34:40] How Organizations Can Be Shaped

[42:10] Looking Outward At Relationships

Links | Resources

Matthew on?LinkedIn

Matthew on?Twitter

Team Topologies : Organizing Business and Technology Teams For Fast Flow

About the Guest

Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognized by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com. He is Head of Consulting at Conflux and specializes in Continuous Delivery, operability, and organization dynamics for modern software systems.

About Voltage Control

Voltage Control is a change agency that helps enterprises sustain innovation and teams work better together with custom-designed meetings and workshops, both in-person and virtual. Our master facilitators offer trusted guidance and custom coaching to companies who want to transform ineffective meetings, reignite stalled projects, and cut through assumptions. Based in Austin, Voltage Control designs and leads public and private workshops that range from small meetings to large conference-style gatherings.

Subscribe to Podcast

Engage Control The Room

Voltage Control?on the Web

Contact ?Voltage Control

Full Transcript

Douglas: Welcome to the Control the Room podcast, a series devoted to the exploration of meeting culture, and uncovering cures to the common meeting. Some meetings have tight control, and others are loose. To control the room means achieving outcomes, while striking a balance between imposing and removing structure, asserting and distributing power, leaning in and leaning out, all in the service of having a truly magical meeting. Thanks for listening.

If you’d like to join us live for a session sometime, you can join our weekly Control the Room Facilitation Lab. It’s a free event to meet fellow facilitators and explore new techniques, so you can apply the things you learn in the podcast in real time with other facilitators. Sign up today at voltage control.com/facilitation-lab. If you’d like to learn more about my book, Magical Meetings, you can download the Magical Meetings Quick Start Guide, a free PDF reference with some of the most important pieces of advice from the book. Download a copy today at magicalmeetings.com.

Today, I’m with Matthew Skelton at Conflux, where he is the head of consulting, and specializes in continuous delivery, operability, and organization dynamics for modern software systems. He’s also the co-author of Team Topologies, Organizing Business and Technology Teams for Fast Flow. Welcome to the show, Matthew.

Matthew: It’s great to be here. Thanks for inviting me.

Douglas: Oh, of course. Really excited to have this conversation, because teams and cohesion, and Conway’s Law have been favorite topics of mine for a while, and been a fan of the book. So before we dig in, let’s hear a little bit about how you got your start in helping organizational dynamics?

Matthew: Great. It’s good question. So a long time ago now, in fact it’s more than 10 years ago now, I was working for a company in London. And they were at the beginning of their journey moving to the cloud. So, after traditional data centers and into AWS, and they’re doing quite a lot of revenue. It was relatively small. I think it was about 250 people in that organization, but big enough to show some interesting patterns and things. And at the time, there were some interesting relationship dynamics [inaudible 00:02:14] between the people principally building software and the people principally building the infrastructure and running the software and production. Had a fairly traditional split at the time, so you might call it dev and ops. And obviously looking back historically, the whole DevOps movement was there to try and fix the problems that had arisen in the previous years because of this big split between dev and ops.

And so, that led me to start thinking [inaudible 00:02:41] looking at different possibilities for ways in which the development and the operations teams could work effectively together. Started drawing out some patterns, using Venn diagrams. So, just overlapping circles, thinking okay, at the moment this circle, this group of people over here is very separate from this other group. What happens if we were to work together on a small number of things? So then, you have an overlapping circle if you like. What happens if we had another team involved that was doing something different, and so on. So, using these Venn diagrams of overlapping responsibility to think about more effective ways of working together. And from that exploration came what became known as DevOps topologies.

So, I wrote a blog post on my personal blog, matthewskelton.net. You can still find it. It gets tons of traffic every month still, even 10 years later, where I’m asking the question, how can we think about effective working together in a DevOps context? We then took these patterns and turned them into a website, devopstopologies.com, which then sort of became the standard way for organizations around the world to think about team effectiveness or team relationships, I guess, in a DevOps context, what was called DevOps then. Now, the word DevOps means something different, but back then it meant ways in which development and operations can work together for more effective software delivery.

So, those DevOps supporters patterns were used by Netflix, they’re used by Conde Nast international, they used by big consultancies like Accenture and so on and so on. And it really helped people to think things through because it provided a set of different anti-patterns and patterns, bad things and good things. It’s not prescriptive, it’s just some suggestions basically. And it’s creative [inaudible 00:04:19], open source. So, people were contributing and trying things out, and blah-blah-blah.

So, that then seemed to be quite useful for people, and it helped me and Manuel Pais who became my co-author on the Team Topologies book. Helped us to think through what’s behind these kind of dynamics. So, the DevOps typologies thing helped us to think through a whole load of other different dimensions, which eventually coalesced into the Team Topologies book. So that’s how Team Topologies sort of came about, if you like. It came through that DevOps topologies set of patterns and originally back through to work I was doing. Later on, Manuel was working with us on a bunch of things too. It came really from our work with real organizations and really thinking this through. But yeah, those DevOps typologies patterns shaped our thinking and shaped the thinking of lots of other organizations as well. Eventually we ended up with the Team Topologies stuff. Although it’s kind of quite a lot different from my early work.

Douglas: It’s really fascinating to me the lineage of DevOps and how a lot of focus on automation and repeatability and even development, having an understanding of kind of what’s flown into production and how that works and making those things programmatic. And yet your work is focused on people and cohesion, which is another component of the problem. But it seems like a lot of the rhetoric and a lot of the things you read out there is really focused on the technology and the systems and how to automate things. So I’d love to hear your thoughts on that.

Matthew: It’s a good call. It’s a really good point, yes, there has been a disappointing tendency I guess over the last few years for people to zoom in on to the technology parts and with Team Topologies book, we were determined to take a sociotechnical approach to it. I mean, there’s a lot to sociotechnical systems and thinking [inaudible 00:06:16], but we’re looking, the short version is we’re expecting to look at the ways in which people and technology interact and you can’t separate one from the other, that there is an interdependency.

There is those kind of cross pollination if you like. There’s an interrelationship between the two and starting from that viewpoint of that we have a sociotechnical context here or problem is vitally important so that we don’t just zoom in on software or hardware or cloud technology, we’re thinking about how this relates to human beings. There’s a wider system that we need to shape and if you build or nurture and the organizations that accept that are increasingly more successful, the organizations that just think it’s about buying technology, then they’re finding it difficult. And there’s a reason for that because the nature of the problem is not just technological.

Douglas: That reminds me of a point you made in the book around fracture planes as well and that being a place to look as far as designing teams and even thinking about change and software or systems. And I think if people are looking purely from a technical standpoint, it limits the fracture planes they may not notice versus the planes that exist because of people. I think there was an example you had in the book around the speed of change, how often the systems are changing and creates a plane of an opportunity.

Matthew: No, indeed. I mean to some extent looking to split responsibility purely around technical boundaries is the last place we should start. I mean we’d normally recommend that as it is definitely one of the fractured planes that we talk about, but it’s certainly not the place to start. The place to start in when you’re looking for boundaries for effective flow is what are the natural flows of change in the organization? What the organization trying to do on an ongoing basis every day? Is it changes to user journeys? Is it updates to a particular kind of service? Is it onboarding new users?

Look at what that organization needs to do naturally and start to have conversations about what is driving those kind of flows of change. We start to talk about language. We start to use techniques like domain-driven design and similar techniques, some of the techniques that we’ve kind of devised and evolved.

Things like independent service heuristics seem to really help get those conversations going, get people to really talk through and increase their awareness of what those natural flows of change are inside the organization. And then start to have conversations about, well what does it mean to actually align teams and whole groups of people to those flow change because the funding might need to change the way in which we conceive of teams might need to change, the implications for team ownership might change. Teams might be better able to own things if we adjust the boundaries or might find it really tricky because the cognitive load is too high. So suddenly we’re talking about stuff which is not just technology, it’s about making a viable organization effectively. We’re thinking about viability, the ongoing ownership of different streams of change on an ongoing basis. That’s a healthy conversation to have for any organization to be honest.

Douglas: Yeah, it makes me think of a point you made in the book around when organizations map to existing architectures or if we’re thinking about beyond software, maybe existing systems or existing ways of doing things. If they’re mapping too closely to that, they might have this artificial sense of flow, but it’s not a fast flow.

Matthew: Yeah, it could be. I mean, there are some contexts where fast flow is not needed. In fact, I actually pulled together something on GitHub recently for exactly this reason. What did I call it? I called it slow flow.

Douglas: Interesting.

Matthew: There’s a repository on my GitHub. If you search for slow flow, you’ll find it. And this is some context where fast flow might not be suitable. So research and development, possibly, R&D things like policy formation, you don’t want to be going too quickly on that. Artistic creativity, possibly things like palliative care, so end of life care for human beings in medical context, but actually the number of cases where fast flow is not needed [inaudible 00:10:34] relatively small and in most organizations what we’re seeing sort of business context certainly is we need to get things done quickly in a sustainable way. And how do we do that without creating a kind of big mess of software? But if the stuff we’re doing is software enriched, the service we’re providing is software enriched. So the entire service might encompass other things.

It might encompass some physical aspects. You might have to go to a registry office or something to apply for something, you might get something delivered at the end of the day, the end to end service is bigger than just the software, but software is enriching it somehow. It’s making it more capable or whatnot. If the software in the mix there, we have to think about the things like cognitive load of the teams that are using and building these systems and running the systems. We have to think about dependencies. If we’re going quickly, we cannot have inflight dependencies on other teams because that’s going to slow things down.

So that means we have to shift responsibility boundaries and that means that cognitive load is being shifted across the organization and we need to think about kind of technologies we’re using and when and where, when to retire some things, when to retire other things. In the context of going rapidly [inaudible 00:11:51] this fast flow of change. The decision criteria that we need to be using inside an organization look actually quite different from the decision criteria they might have used 15, 20 years ago when many of the [inaudible 00:12:05] the current execs were learning their trade, if you like. Well we’re at business school or rising through the ranks, whatever. And so modern principle, fast flow [inaudible 00:12:15] things like we allow some duplication.

We’re not looking to optimize down the cost of licenses. We’re happy for there to be some duplicate licenses and things like this for software, [inaudible 00:12:28] consuming. Bunch of these things like this, we don’t have a single central database. Things like this seem crazy ideas to people who grew up with a different set of constraints when technology was really expensive, when licenses were really expensive, when things took a long time to get into production for software. All of those things kind of made sense.

We’re in a different world now with cloud type systems and with all the automation that you mentioned before, whether it’s come through the last 10, 15 years through DevOps and things, we can take different decisions, we can optimize for different things and if we’re optimizing for fast flow, we need to take a different set of decisions along with it or different set of decision criteria to help us choose what to do and to look for when things are healthy or unhealthy. And it’s quite unfamiliar for lots of people. Lots of people find it kind of weird because it is weird compared to the slow situation from before. So people need some help with it effectively to get to grips with this new way of thinking.

Douglas: Absolutely. It also makes, what you’re saying makes me think a little bit about the self-similar teams pieces, which on the surface to some might seem redundant or disorganized, but I think the trade off that you get from the autonomy of being able to make decisions and take action can be pretty liberating.

Matthew: Yeah, the traditional command and control thing that came out of Taylorism from the 1920s or whenever it was, I mean it probably didn’t even work very well then for factories where you had management separate from the workers and all this sort of stuff. There’s a lot of politics and class based stuff going on there. If you’re in a physical factory, it’s probably quite a good thing for workers to notice when something that’s being produced is not being produced accurately rather than just aligning machines to run and the managers have told them to produce 10 million widgets in a week.

If the workers noticed something, it would actually be more effective for them to actually be able to, like we see with Toyota for example, pull the [inaudible 00:14:25] cord and say something’s wrong here. But certainly in the case of knowledge work and software is form of knowledge work.

Because ultimately software is just… If you think about modern business software, modern business software is purely the encoding of organizational intent. That is all it is. Yes, when you’re working with some firmware and hardware devices, you are getting the sensor data and pushing it into RAM and storing in disk and it feels a bit more techy when we’re working this. In the context of most software is written for larger organizations, it’s about encoding intent, it’s knowledge work. We need to think about the words and the meaning and the concepts behind what we’re doing. In this kind of context here, we need to have localized autonomy, localized awareness, need to use the eyes and ears and senses of everyone who’s involved to give us additional context, need to turn the organization into something like a sense making or sensing organization that has a huge degree of situational awareness both for the what’s happening inside the organization and what’s happening outside.

If you think about all the stuff that’s changing now, we’ve got Russia invading Ukraine, destabilization in lots of other regions. We’ve got oil and gas prices causing havoc, we’ve got climate change, a whole bunch of geo-political stuff in the UK, this was Brexit, but we’ve now there’s additional kind of disruption and things with other trade and so on. All of the stuff is actually connected and it’s not going to get any better in the foreseeable future. It’s going to get, if you like, more destabilizing. We’ve had COVID, all of these things mean that organizations need to be able to adapt and respond rapidly, particularly to the external changes. Suddenly one day we’ve got a trade deal, next day we’ve not. One day the won currency was worth twice another currency, the next day it’s completely devalued and we need to be able to respond to this stuff that we’re in a period of extreme change.

And to be able to respond in these contexts, we need to be able to rely on the senses of people who are in the organization, in individuals and in teams particularly. So we need to provide ways in which teams have a language, a grammar, a vocabulary if you like, for helping them to sense what’s going on and helping them to communicate to other people in the organization about what’s going on. This idea of team, of a shared language is something that lots of people have said if they found valuable about team topologies. Excuse me, a shared language for the types of team, different purpose, different focus, but also the shared language for the three team interaction modes, collaboration [inaudible 00:17:17] service and facilitating. And that shared language just helps, seems to help teams and organizations to have a much more structured and useful conversation, which is really great to hear. [inaudible 00:17:29] what we had hopes for by putting that stuff together. So it’s great to hear that’s helping.

Douglas: That’s really great. And I wanted to come back to something we talked in the pre-show chat about, which was how a lot of the work you’ve done came out of software systems and certainly Conway’s Law plays a big role in some of the foundational pieces of what y’all built and that’s talking about software architectures, systems that are built and yeah, it’s clear that this stuff applies in lots of other situations, lots of other types of companies. And I recall that you were saying that you’ve seen healthcare organizations and trauma teams be really successful with this stuff.

Matthew: This is amazing. So in over kind of the last year or so, I’ve seen several people, particularly in the UK. So in the UK we have a national health service, the NHS. And so the vast majority of medical care in the UK is provided through that. And so there’s a amazing ability to learn practices across lots of different hospitals and parts of the country and sharing data and so on and so on. And it’s really helpful for making progress really quickly. Anyhow, we’ve had people who, literally, they’re doctors or they’re surgeons or they’re head of clinical practice or they’re head of this entire department or what have you, entire region, health region saying, coming on Twitter or LinkedIn saying “hey, yep, we’ve been using Team Topologies for in a clinical context, nothing to do with software. We might need to have a team with mixed skills inside it.”

So for example, if you’ve got someone who’s got COVID and they’re in, say, a vehicle crash, like a car crash or something and they’ve got some trauma, you actually need a mixture of skills that you can’t just have a surgeon, you need someone who understands COVID response and someone who understands what’s needed for surgery. It’s a complicated situation. And so you need a mixed team of people in there. You’re going to need a anesthetist, a surgeon, nurses, other people who understand how to make all this stuff work. They need to be able to have high trust, they need to be able to make decisions in real time without referring to someone else. They can’t pass that patient onto someone else. They need to deal with the whole end-to-end trauma situation right then and there. And that might be ongoing for let’s say 10, 24 hours, something like this until they’re stabilized.

And in that context, in particular, cognitive load comes into play, team cognitive load comes into play because that group of people to have high trust, for them to be able to trust each other well enough to be able work well, you need to limit the number of people in that team. It needs to be limited to about eight or nine people and [inaudible 00:20:16] human, there’s anthropological reason for that that go back millions of years. We can’t really change much about it. So you can only have about eight people in that team. There’s a whole load of stuff that they will not be able to keep in their head. And so how do you deal with that? Well, from a Team Topologies perspective, we’ve got the idea of a platform and a platform is not a piece of technology. A platform from a Team Topologies perspective is something which accelerates flow and ownership in what we call a stream-aligned team by reducing cognitive load.

So a platform can be literally a checklist on a clipboard. If that checklist on a clipboard is helping that team to own that situation and achieve flow inside their context by reducing cognitive load because they can just refer to that checklist that is acting kind of like a platform. It’s a very different way of thinking about the word platform compared to IT. But it works in both cases. And we’ve got idea concepts of enabling team, a group of experts who helps to uplift the skills inside these stream-aligned teams and so on. And it turns out that these concepts map really well, particularly into healthcare.

It was really interesting to do a Google phrase search, I can’t remember what it’s called. You look back in history and see when phrases were being searched for. Turns out that the phrase team cognitive load started to be used around about 2018, which coincides with when I started to use that basically when we were starting to write the book and so on.

So writing the book during 2018, it got published in 2019, team cognitive load. So the concept of cognitive load applied to a team starts to appear around that. In IT. Interestingly, it starts to appear in clinical research at the same time. 2018 there’s an explosion of academic papers and clinical trial and other things talking about team cognitive load in a clinical context. So independently in IT and in clinical and medical contexts, a need for thinking about team cognitive load came roughly about the same time, which is super interesting for me. I don’t know what’s going on there, but there’s this shared awareness in two completely different disciplines that we need to think about team cognitive load.

It is probably because we need to bring different skills together and work together and those kind of stuff. But it was really interesting to see it.

Douglas: Yeah, I was going to jump in there. The cross-functional nature of both those situations and the contextual awareness that’s required. I think similar in maybe sports teams, trying to think of these types of organizations that have these similar constructs because you go into other industries or other types of companies and maybe that’s not as prevalent, but certainly when you think about when someone’s in an ER, they’re having to function pretty cohesively.

Matthew: I mean during the pandemic response in the UK, there was a particular point in time, it was around booking vaccinations online and things like this. When there’s a need for medical professionals like the professor of medicine at a hospital or something like this, these people were getting involved directly with software teams because they need it to have that cross experience pollination or awareness to be able to build the vaccination booking [inaudible 00:23:30] system in the right way. And they were using the Team Topologies ideas to help them think about that, think about ways of talking about expertise. Should we put this expertise inside this team directly? Should we use the expertise as an enabling team? Should we actually build [inaudible 00:23:45] platform? And then that language helped them to actually deliver that vaccine response, which is oh absolutely amazing. I’m completely blown away by that, to hear that kind of story.

Douglas: Yeah, pretty amazing to see that happening. And it makes me wonder with the book coming out in 2019 and the onslaught of coronavirus coming mainly in late 2019, 2020, I’m curious, did anything shift as far as your understanding or the types of questions and concerns you were getting from folks as they moved more into virtual and work from home and maybe even just the stress of all the things that were happening?

Matthew: [inaudible 00:24:27] good question. So the short answer is yes, no. Because it turns out that a huge chunk of the vast majority of the patterns and principles in Team Topologies is actually applied both in an in-person working context and hybrid and remote because the principles are sort of universal in the sense that we’re applying really sound software engineering practices to teams. That’s effectively what we’re doing. So the software engineering practices that we already know work are things like clear APIs, so that’s the application programming interface, a clear, bit like a plug in a socket, a clear interface, does it fit, does it work? Things like loose coupling, things like local autonomy and these kind of principles have been known to work in software contexts since the 1960s. There’s nothing new there. The software context has enabled us to iterate very rapidly and find the fundamental principles that enable things like fast flow and high scaling and things like this.

And they’ve been refined over decades, basically, particularly in the last 20 years since we’ve had better software tools and eventually cloud and things. But there are always specific things in the Team Topologies book that are not relevant in a remote work context. So there’s a little diagram and a section on how teams might sit together in a physical office, which is super cool and it is really great to see, but it’s obviously not relevant directly in the remote work context where everyone’s at home. What we ended up doing is pulling together a kind of appendix to the team topologies book, so some ideas and principles for what we’ve called remote team interactions. And so we publish this through the same publisher as the Team Topologies book. It’s called Remote Team Interactions Workbook.

It’s quite short, it’s 65 pages long, but it kind of provides some suggestions and patterns and ways of talking about working together in a remote context using the team topologies ideas, but making it more specifically focused on remote work. But we are pleased with basically that pretty much everything was still relevant. It’s just we had to call out or emphasize certain additional things in that workbook.

Douglas: I wanted to come back to the cognitive load point that you made and specifically something I was thinking about there, which is there’s definitely a trend in the workplace where people were wanting to feel more connected, they’re wanting to understand the higher purpose more, the big picture and cognitive load is about constraining what they have to know about and think about so that they can focus on the job at hand. How do you balance the need for the bigger picture, more information with also the need to constrain what people have to think about so that they’re not overwhelmed with all the things.

Matthew: It’s a nice question and actually some people have, it’s quite a subtle connection, but made that point before because if you think about historically with Taylorism, there’d be one person whose job was to fix this widget into this part of the machine and then pass it on to the next person and so on. And definitely, that’s a bad thing, let me make that clear. When we’re writing the Team Topologies book, we wanted to make sure we are trying help make work more humane, more interesting for human beings. Now part of the way it gets more interesting in a typical team topologies inspired organization is that we’ve got end to end responsibility for a particular service. So we’re focused on user needs or something that our customers need to have done and we’ve got end to end responsibility, which means we’re thinking about all the aspects of that service then that come together to meet those needs.

And so because we’re working with people with a range of skills, we don’t just have a single set of skills to do that. We typically need multiple set of skills so that in itself makes it kind of broader, makes it more interesting. We’re learning new things. Jon smart who wrote the book Sooner, Safer, Happier, also published by IT Revolution Press talks about skills being kind of comb-shaped. So we hear about T-shaped skills, we hear about pie-shaped skills, like the numeral pie, also hear about comb shape skills where you’ve got actually quite a few different specialisms, some of which may be stronger than others, sometimes called broken-comb, kind of skill profile. Anyway, the point is we’re expecting to support people in developing multiple different sets of skills.

You might start out as a software engineer, but you’ll develop skills in testing, you’ll develop skills in user experience and they won’t be all as strong, but that’s the expectation that actually you’ll learn from your colleagues and then be able to support them doing their thing and so on, when you’re working together with them in the same team.

So that’s one aspect of this kind of end to end responsibility that usually makes it more interesting. We do see a slightly bigger picture. But you’re absolutely right, there’s a need to limit the stuff that we’re thinking about and some things we want to sort of hide away and to make it so people don’t have to think about that stuff. One approach that some organizations have been doing for a while, but we can formalize it with Team Topologies, is to think about rotations between different teams. So you might be in a stream-aligned team, focused on a particular customer journey. If it’s an online shop, it might be part of the checkout, if it’s whatever, I don’t know if it’s booking vaccinations, then it’s about making sure that you’ve got your validation code at the end so that you can actually turn up and get scanned and you get your vaccination, whatever.

You’ve got that entering journey. But maybe you stay in there for the year, two years, three years and you actually fancy a different perspective. So then maybe it’s an opportunity to move into, let’s say, a platform where you’re using the same skills but you’re focused on a different type of technology so you can increase your awareness and expertise from a different perspective. Or maybe you decide that you actually, you’ve developed some expertise and you want to try out working in an enabling team. So a group of experts with a particular focus, let’s say user experience, you really like the user experience aspect. You decide that you’re actually going to use your expertise in that area to work across multiple teams. So with team topology, with the Team Topologies team types and team interaction [inaudible 00:31:15], there are ways for people to explore different aspects of the bigger picture if you like, but in a way which is not destructive, in a way which is actually very healthy for the organization, rather than just dipping in and out of things and having your fingers in lots of pies, which is one way to do it before.

I’m sure the listeners will probably think of people, maybe themselves, I mean I know I’ve done it in the past where you just decide to kind of get involved in everything because it’s kind of cool, interesting. There are more sort of structured and healthy ways that we can talk about doing that with these patterns I guess.

Douglas: Yeah, the rotations is a fascinating concept and mostly you’ll see in organizations where it’s some executive program or maybe it’s some graduate student recently hired and they take a batch of folks around and rotate them through different departments. I don’t think enough companies offer that as a way for just any worker to stretch their wings and try new things. And people complain about retention all the time. It’s like, wow, you keep it a lot more interesting if this is almost like they’re changing jobs in a way.

Matthew: And the nice thing about Team Topologies, the fact that it applies at multiple different levels. I think you mentioned before, the way it applies in a fractal way, in a self similar way across different organization is, so if you’re going from a customer, if you got external customers and you started working in a team that focus on external customers, well the way in which you work inside that team is essentially identical to the way in which you would work if you were working inside a data platform. It’s the same set of techniques, it’s just your domain focus is slightly different or substantially different. But the way in which you talk about that work and interacting with other teams is essentially the same. So you got people from across the organization using the same working techniques, but then maybe changing their area domain focus as needed or as they want.

So I think it’s quite powerful in that respect. It provides that kind of context. Historically, if you think about it, people certainly in IT on the software development side use a whole bunch of techniques called things like Agile and DevOps and blah blah, blah. People in infrastructure or IT operations use a whole completely different set of principles iTell and whatnot. And they were basically mutually incompatible, but with approaches which are self similar across all parts of this, the organization like Team Topologies, then we don’t have that barrier. So there’s many more opportunities, I think, for learning different aspects of how the big picture work.

Douglas: Yeah, they don’t to. They kind os just can lean on some familiarity because they’ve already learned it. That makes sense. Which it brings up another topic, which is something that we see a ton, and I think it came up in your book as well, which is the dreaded reorg. So I don’t know how often our clients and customers are going through a reorg or dealing with the aftermath [inaudible 00:34:10] a reorg. And it seems like it’s just this strange cycle that’s happening. And if you really look at high performing teams, there’s this constant trust building and evolution that’s happening and all that gets really disrupted if you’re constantly ripping people apart and reassembling them in weird ways. So I’m just curious how reorgs have shown up in your work and if you have any thoughts on how to avoid them.

Matthew: For sure. And the reorg is driven by lots of different things, but often it’s driven by a new leader. Comes in and wants to stamp her authority or his authority, or the organization tried out local autonomy and it didn’t work. So now they’re going back to centralized everything, but that’s not going to work either because they’re fundamentally missing some really important aspects of how organizations actually need to work and how work needs to flow and this kind of stuff. So you get these reorgs that are, by the time the reorg is finished and the dust has settled, that particular leader’s gone. The VP has disappeared or the CTO has gone. And I mean I’ve seen this in person, I’ve lived through these and it gets into this really, really toxic cycle and it affects retention, it affects hiring and all sorts of things. Maybe our hope is naive.

We do have a hope, but maybe it’s naive that because Team Topologies has helped to introduce some much more fundamental principles and decision criteria for understanding how the organization should be shaped or can be shaped if you want to achieve fast flow, then the kind of reorgs that happened in the past that were driven by Ernst & Young, KPMG and [inaudible 00:35:44] and whoever saying, oh, try this, try that, try [inaudible 00:35:46]. Well, those kind of reorgs don’t make sense unless you’re doing it with a very particular intent.

Unless it’s aware of Conway’s Law, for example, this socio-technical mirroring that occurs between the communication path and the organization and the likely architecture of the thing that you’re working on, thing that you’re building. If it’s not aware of those things, then people can call it out and say, This is nonsense, why are you doing this? This is going to work against what we need to do. So we’re hoping… is a bit early days [inaudible 00:36:18], but we’re hoping that Team Topologies provides people with the language and the insight to question and challenge a random reorganization that’s just coming for no particular useful reason. We’ll see.

Douglas: Well, I certainly hope that’s the case because many organizations would do much better if they could avoid such things.

Matthew: I mean fundamentally Team Topologies, our aim is to try and help people be more intentional about the work that they’re doing, about the way the work is structured, where the teams interact, more intentional in general, and it’s that intentionality which hopefully produces some better results for organizations.

Douglas: You mentioned domain-driven design a little bit earlier and I wanted to throw this out because I know a lot of facilitators listen to the show and this would be an area that they might not know much about and could be another tool their research for their tool belt. And I think there are two specific things you called out in the book. One was event storming and the other was context mapping. wondering if you could just share a little light for those who haven’t heard about those things and how they might even just start [inaudible 00:37:29] playing around with those tools.

Matthew: Sure. So bit of history first, I guess. [inaudible 00:37:34] sort of emerged from a book in, I think, probably is in 2003, 2004 by Eric Evans. Now if you think about it, back in 2003, 2004, we didn’t have cloud infrastructure at all. The way in which software was developed and shipped was still relatively slow at that point. The software was still being shipped on CD ROMs and DVDs at that point and so on and so on. So the context was quite different from today. The interesting thing of course is that these ideas are now, we’re now able to apply them at speed.

We’re now able to use things like cloud computing to enable us to take advantage of principles around kind of domain centric design and things and separation concerns and use. And we’re not hampered by the slow speed of change in the kind of infrastructure space, which is great. It’s a good place to be. Domain design, the way I see it, is it’s focused on untangling concepts at a business level, business domain level. Domain [inaudible 00:38:46] design is really focused on language, the language that people use every day to talk about the problems they’re trying to solve. And it really zooms into listen to and look at the language and find the different things that happen from the perspective of domain experts and other people.

And fundamentally, if concepts in the organization are tangled up, if we see concepts tangled together, meshed together, then the software that we are going to write is also going to be tangled and meshed together. So domain [inaudible 00:39:19] look is they’re trying to untangle these concepts precisely so that we can separate them out. And then what we apply on top of the traditional DDD concepts is ideas around fast flow. Because when we need to have very rapid flows of change, then we need to find boundaries that work for flow as well as work conceptually. So originally a lot of the workers in DDD was on the conceptual stuff because fast flow wasn’t a thing. The software took a long time to ship. With fast flow possible and normal, based on principles like continuous delivery and automation and so on, when we’re thinking about boundaries using techniques like from DDD, we also need to think about what boundaries can actually work in a fast flow context.

So there’s a kind of additional thing going on there, but techniques like event storming where we’re trying to surface all the different things that happen, basically events using domain experts and engineers together in a room, mapping that stuff out, which helps to find where the boundaries are. It helps to find where there’s ambiguity around the language and actually that helps us to find where the boundaries are, can really help. It helps to bridge what is sometimes a gap between, if you like, engineering and business, if you like. People who either got the money or they’ve got the domain awareness. Now we’ve actually been looking at using additional technique called independent service heuristics. It’s a bit of a mouthful, but if you search for that online then you’ll find some details as inspired by domain-driven design and uses some similar techniques and again, is a way to bring together people from different disciplines to be able to co-create and co-agree, to co-discuss what will be good approaches to domain boundaries and therefore good approaches to team boundaries and things.

So you actually getting people together to evolve the organization, evolve the team responsibilities in a way which is viable, which deals with cognitive load and so on, and gets people bought in. And it becomes really powerful kind of technique for getting people involved and becoming aware of the kind of things they need to be looking out for the go, going back to that sensing thing, helping people to sense what’s needed inside the organization. It’s a really interesting technique and powerful technique for doing that. It’s been nice to see that evolve over the last few years.

Douglas: Yeah, that’s super cool. It’s almost making me imagine a world where organizations have dedicated teams or identify folks to meet regularly, have these conversations to make sure they’re kind of shepherding how the organization grows and evolves.

Matthew: For sure. And the traditional role of let’s say agile coach, valuable for sure, but the traditional focus of an agile coach was inside a single team or inside multiple teams. And actually we need to start to look outwards as well and to look at the relationships between teams and the capabilities we’ve got in teams and things like boundaries for flow. This is also a role potentially for people who traditionally were managing aspects of work in an organization, whether it’s software where it’s something else, instead of trying to manage dependencies, let’s try and look instead for whether our boundaries are good for flow and whether we’ve got any blockers in place. If we can instead focus on removing blockers and finding good boundaries of flow, we don’t need to manage the work so much.

So it’s almost like that’s another example of where fast flow needs to refocus existing skills and provide opportunities for people to do new stuff effectively, but to use their kind of existing skills, but in a different way. Yeah, so for sure we’ve seen examples with customers where the pool of the community of agile coaches was hugely effective in helping to spread these ideas around flow and boundaries and core Team Topologies ideas and so on. I think there’s a real opportunity, particularly for people with this kind of coaching experience of some description, but also manages to refocus their attention and use their skills in a way which enables autonomy and flow and viable team and system boundaries effectively.

Douglas: Yeah, it makes me think to use the Team Topologies language, it makes me think about the enabling teams and how organizations are really good at erecting silos and there’s huge opportunity for some group in the organization or individuals that float around and just bridge silos in interesting ways. Say, oh wait, let me plug this into that. You need to hear about this. And who’s bouncing around like a little pinball figuring out where the gaps are.

Matthew: Yeah, for sure. And in organizational design terminology, that’s called boundary spanning. So anyone listening who gets then you recognize the need for boundary spanners and the value that they bring and the enabling team in team sport is effectively a boundary spanning role because we’re working across multiple teams. We’re not building anything ourselves where the interactions are temporary. We’re detecting a bunch of stuff that’s happening across [inaudible 00:44:40] of teams and we can then have a conversation with the right people saying this is a problem, or we don’t have enough skills of that type across all of these teams or something similar. Absolutely, yeah.

Douglas: Awesome. Well, we’re running short on time, so I want to make sure leave you an opportunity to leave our listeners with a final thought.

Matthew: I think the thing I would suggest is to think about ways in which you can, what the implications will be of limiting team cognitive load in teams that you’ve got. What would the implication be? What would the implication be of having end to end responsibility for a particular service that’s quite a responsibility and you might need to know a lot of stuff, so what would you need to make that true and what would you need in order to have no handoffs at all from start to finish of working on a service? So no waiting for another team to do something because these are things which really enable fast flow. Fast flow effectively, in this context, ultimately enables real business agility, the ability to switch around and change things and adapt to these increasing kind of changes and threats from the outside world. So really think about those kind of concepts and what would be needed to achieve those kind of things.

Like no handoffs, no waiting for another team during the period where we’re building something or we’re making some changes. But also then the need to think about limiting cognitive load. And I mean, the secret basically is in the team’s [inaudible 00:46:20] book you’ll find some suggestion for what that looks like, but it could be interesting to start from those kind of principles and then work backwards. If you work backwards from those principles, you effectively do what we did and the team’s quality stuff emerges from there or something like it will emerge from those first principles.

Douglas: Amazing. Well, thank you Matthew. It’s been a pleasure chatting and hope to chat with you again soon.

Matthew: Thank you, Douglas, really appreciate it.

Douglas: Thanks for joining me for another episode of Control the Room. Don’t forget to subscribe to receive updates when new episodes are released. If you want to know more, head over to our blog where I post weekly articles and resources about radical inclusion team health and working better voltagecontrol.com.