Too much de-centralization

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David Sherrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, Peter Madison and Dave Sharrock. What's on the table today?

Great to be here again. And uh I think the topic we're going to focus on is decentralization. It's it's like a foundational assumption or pillar that we bring to the table when we talk about agile. We talk about decentralization, decentralizing decisions. We talk about pushing authority into the teams, having self-organized teams which are somehow decentralized in how they make decisions. And yet, of course, there's a lot more nuance to it than that.

Yeah, this idea of autonomous teams. And and of course, we we want the autonomy in the teams, but a purely autonomous team would be completely independent of the organization. If you were truly autonomous, you wouldn't be operating completely independently of any other outside influence. So so it's not quite what we mean when we say that, for one thing. But uh there's there is a need to understand what we mean when we talk about decentralization. And uh is there a point at which decentralization becomes a bad thing, that too much decentralization is a problem?

Um I always there are so many things which are uh you know too much of one and too little of the other. What is it? It's a pendulum that swings backwards and forwards, right? So centralization becomes a theme or a pattern that organizations chase after and they restructure by centralizing decision-making authorities somehow. And then, of course, the natural tendency is that that goes maybe it's too far in one direction, or just the environment changes, and now we have to move in the other direction. And this is really what we're looking at when we're talking about agile teams. If we go back 20 years, decisions were being centralized much more aggressively, and now obviously that trend has changed. But the reality is now we we we don't want to decentralize everything.

Yeah, because there are certain aspects of this, and then some of the key ones that come to mind are around the various different governance functions. So things like architecture and security and compliance and component parts like this, which are often very dirty words in the the agile space, it seems, but we we need a way to ensure that uh self-organizing teams that are capable of making decisions and understanding have a way of consuming those uh the centralized concepts that we need so that they can apply them in their context. Uh, and so you need that form of centralization of these pieces to to help ensure that the your decentralization has some alignment to it, some kind of consistency.

Well, it's it's interesting because when you think of those those sort of governance roles or architecture, security, a number of different pieces like that, even within quite mature agile organizations, there is almost an expectation to throw away the way things were, standards were set, say architectural standards were set, and allow the teams to reopen conversations perhaps that were really don't need reopening, or it is outside of the scope of the team to be able to make decisions around whatever it might be, tooling or technology stacks, or solutioning, you know, general solutioning principles or where things are going. And I I find that sort of distrust of central control uh to be detrimental to the high performance of the teams. I think there is a reason why architectural decisions are often made centrally or security. A great, great example where you really want to have oversight and governance and sort of control and standards and a direction of how your information security is managed across, let's say, a bank. Uh, this isn't something that we want every team or every part of that organization to be playing with and trying to come up with different ways of solving the same problems.

Yeah, I mean, and a classic example of that is something like identity and identity management. We don't we don't want every team to go out and build its own identity and access system because it when that team moves on to something else or as the product or the services, you've you've now got this isolated island of identity that uh isn't going to be managed and potentially becomes a vulnerability as that uh as time evolves. And that that's a huge hole. I mean, that potentially could be direct access into data, uh, which the organization has no visibility or control over. And and there is that element of that allergic reaction to control, but as an organization, in order to mitigate risk, you you need to have awareness that that exists and that it's occurring. Not to mention all of the time that was spent on building something that could very easily have just uh been consumed as a centralized service. And uh as this is a this is a known pattern. We know how to solve this, we know how this organization solves this, and there are reasons we want to solve it in this way because it incorporates all of these other factors. So uh let's consume that centralized piece that will solve that problem for us and allow us to be able to move faster.

I I think as as you're describing that, and it's a great example, uh, one of the things that would try, maybe the agile kind of uh approach or mindset is trying to mitigate against is mandating how that might be done across an organization. Because I do think where agile teams, they're they're at the coal face, they have a very clear understanding of the particular, in this case, particular problems they have around identity, the needs they have. And there should be a contribution into how the solution is discussed, defined, and eventually you know found, if you know how the problem is discussed and defined, and how the solution is uncovered and defined, that teams have may have something to contribute. And I think there's there's ways to do that rather than centrally defining all the way down how something might happen, because we know that brings of its own problems around fragility and around um maybe not being uh uh responsive to different needs across the organization as well.

Yeah, and it and it's always this balance between the two different pieces, and it a lot of it comes down to uh how and where we want the decisions to be made. Um, what are the things that um are that we're looking and we have to manage from a risk perspective? Uh, because uh those are the kind of the things which will drive that that kind of piece. How do we give uh our decentralized teams an understanding of what it is that we want them to build that build to, what the principles and precepts that we want them to align to, like what sort of architectural concepts we want them to keep in mind as they're as they're building out their solutions so that we we don't end up with um lots of little fragments that won't talk to each other. Um if we so and we see this in the in the organizations that have successfully formed large decentralized organizations, they have very strong discipline around those centralized principles and presets and pieces. It's the it's not that they all the teams operate completely independently each other, they have strong discipline around thou shalt do and operate in these manners, like uh an API-first methodology or something like that. The everything must have an API, it must conform to these standards, etc. etc.

And yeah, well, I'm reminded in um and I think this is a book that we've talked about before, which is Loonshots, which is talking about product innovation. Uh but one of the interesting things that uh the author there brings out is the idea of two very distinct departments or groups, silos, but with a peer-to-peer, a strong peer-to-peer relationship between them. And I think this kind of comes to it when we're talking about things like those centralized versus decentralized. They're two very distinct pieces, but there's a peer-to-peer and a strong peer-to-peer communication between the two of the needs coming from the agile teams, of what their context is and what they specifically need in terms of solutions that are relevant and powerful for them. While at the same time, from a central perspective, there's that sort of span of control and a need for consistency and repeatable um patterns of behavior that are there. But that relationship is a is that it's a strong continual relationship, but also a peer-to-peer relationship. So there's not that imbalance that we often see in heavily centralized functions of that type.

Yeah, I agree. There's this that you've got to have very strong uh communication channels across this. The discussion needs to be such that, hey, we're both in this together, we're both trying to collaborate towards the end goal. There's reasons that we're we're wanting to do things this way. Um let's work together to find out what the best way to solve this problem is in your context, uh, because we need to make sure these things are incorporated. And and I think that is a that is a very critical piece of this.

Maybe if if I wanted, I wanted to pull the conversation away from that sort of architectural standards world that we're probably quite familiar with, or compliance and regulatory world. There's another element around centralization and decentralization that we sometimes forget. And a few years ago, I I hear about it less and less nowadays, but a few years ago, there was that there was a continual talk of ad hocracy, of this sort of end goal of agile teams being this networked organization with with uh very, very few layers of hierarchy in there. And that's the ultimate end, if you like, of a decentralized worldview as you move in that direction, where you end up with a network of interdependent but predominantly autonomous groups working together. And this again raises another aspect, which is the communication cost between decentralized groups. So centralization brings standards, it brings that consistency of how we approach things, but standardization, sorry, centralization uh also allows us to reduce the overhead of communication and agreement between parties. So as we're looking at these different, for example, teams within a particular value stream, we want them to be that there want we want some centralization so certain decisions, certain communication pathways and so on aren't continually revisited, and there's not the overhead on those teams to negotiate every aspect of what's what is going on. Uh, but rather that there's there's the right level of communication that is valuable, that is communicating information or context which is uh germane to that discussion, but not an overhead, which means every single thing is a deep breath. Okay, I'll go and talk to that team and find out how we can get that next step.

Yeah, I'm I'm thinking of uh things like uh domain-driven design here too, like the this idea from an organizational perspective, the boundaries around that you want to draw so that you minimize where those communication lines need to be, because they a lot of the time if you can pull together the parts of the organization that need to communicate a lot more and strengthen the communication there, then you you can simplify some of that to be able to create sort of find a happy median between your decentralization and centralization of the organization. Uh, there are some interesting concepts possibly in there to unpack, but probably when we have a whiteboard in front of us.

But I love the way you've just brought in their systems thinking, which is which is really, I mean, this is the whole piece about centralizing uh centralization and decentralization. It's a tool, if you like. We can look at a system and we can go, maybe we need more centralization around this piece in order to get some certain benefits or to overcome certain weaknesses that we see. And then we're going to need decentralization in another piece. And I think that's that's part of the message here, which is if we see centralization or decentralization as the be-all and end all, we're going to uncover or break a lot of things which are actually working really, really well, or we're going to uh create new unintended consequences, which in the future will mean we need to change a little. But having that sort of systems thinking mindset as we look in, now we can start using it as one of many tools in our toolkit to understand and address that system and the particular challenges that we might be looking at at any given time.

I think that's a very good way of looking at it. It's the I and I I think I naturally default to that to look at the entire system. How is this how is this benefit? How does this serve us? If we're are we doing this for the right reasons, does it still serve? It's uh that looking at the like that in end-to-end system and how do the various parts of it interact in order to deliver what we're trying to deliver. Um I think um I think that was a very good point. Uh there was there was the idea. Sorry. Carry on. I I was I was gonna move into the the uh the idea of some of the the the the concept around decision making and the descent in the centralization and decentralization that uh the because we were we were chatting about that right before the call. The the interesting piece is that in decentralization you uh can end up with problems with communication because um everybody doesn't know who to go and ask because you're too decentralized, and it's there's nowhere to no central point to go and actually get any kind of communication. So decisions take a very long time as a consequence. In centralization, decisions take a very long time, actually two, because you're having to go through the hierarchy to go to the different places, and nobody's willing to make a decision without the sign-off from all the other parties that need to be involved in order to make a decision. So you find in both situations it can be hard to make decisions. So getting to a point where you you're optimizing for decision making is an interesting concept, perhaps.

Or it I I I I have a note in my uh a little note here uh uh with the word revolutionaries in it, because that's exactly the problem revolutionaries have is if you have a completely decentralized base of revolutionaries, how they talk to one another is one of the biggest challenges they have, right? Um, which is I I just always brings a smile as I'm thinking about this because we don't normally think of revolutionaries being part of the agile mindset, perhaps nowadays. Um, that that idea of uh the balance between the two and how to uh how to get the right amount of centralization or decentralization is really interesting because one of the things that we end up spending time on quite early on when we're introducing agile in the context of say organizational change is decision making. And I'm always quite um I find that many organizations, many leaders and managers don't have a clear understanding that decision making isn't some sort of skill that we come in and we can make decisions or we can't make decisions, but is something where we have to understand there are decisions which are which are unanimous decisions that need everybody's agreement. There are decisions which are democratically selected, there are decisions where specialists, where experts are going to make those decisions. So there's a huge range of different types of decisions that we're making at any given time as we go through creating a new product or uh enhancing what's there or chasing particular line of business and all of the challenges that go with that. So that whole concept of understanding decision making in the context of how to make the best decisions. To your point earlier about speed, how do you make the decisions at the right speed? How do we manage the risk of those decisions so that we don't make decisions that kind of go increase the risk profile of what we're trying to do or decrease it or whatever it might be?

Yeah, I think uh I think that's a good point around it's the it's also one of the first questions I ask when I go into organizations and uh we're looking at uh the looking at how they do delivery. How do you actually create new products? How do you and one of the first things I ask is, well, how do you make decisions? Like it's because we it where does that come from? Like what who who signs off these, how would you actually make these decisions? Um quickly followed up by like, well, how do you actually make money?

But uh very true, very true. Now, what about it's we're kind of coming to the close there. What are the sort of the the characteristics of any centralization or decentralization conversation you might have? What are you looking to um what do you expect to change as you move from centralized to decentralized or decentralized to centralized? What is the the benefit of that shift?

So in in a in a completely in an organization that's maybe gone too far into decentralization, where there are a number of problems that come up from the the lack of consistency in how things delivered. You end up with lots of pieces of things which um not at nobody's in the organization is sure what it is they have or where they are or how they talk to each other. And that causes a number of concerns and problems from a risk perspective, um, especially and because, hey, how do if I don't know what I have, then how can I ensure that I'm properly protecting it and like and a lot of other problems like that. Uh as not to mention how do I get these things to talk to each other properly? Do I end up um spending a lot of time reworking because I try to integrate things and they don't integrate because they were never designed to. So and and uh so trying to from that introduce some idea which the organization will naturally be quite resistant to as well, because they're often those very autonomous teams are very resistant to any kind of uh sort of centralized advice at this point, too. So even trying to introduce any kind of consistency can be very difficult in that very decentralized organization. And then so finding the right way to do that, finding the right language, the right thing to do, so bring it back to and we don't want to bring it all the way back to centralization, but we do want to ensure that we've got enough consistency and pieces in place to that we're satisfying the organizational needs uh for governance, that we're bringing the right pieces in, uh, and that we're not breaking all the really wonderful great things that come with that level of decentralization in terms of innovation and the ability to adapt and to deliver. And we are allowing uh them to still be able to act as autonomously as possible, but start to introduce some of the centralized um value that comes with being able to have a centralized place to to operate from and ease the decision-making complexity.

That's a great point, yeah. So, in closing, two or three things that we might take away from this. If I get I just wanted so you're describing there some really interesting points just around the the sort of consistency, that risk management, the standards, the need for standards that come in. We also talked a little bit about the overhead of communication or agreement, reaching agreement between you know incredibly decentralized groups, then there's an overhead to agree where things, you know, that communication and contracting in the world of ad hoc. And as you move towards more centralization, there's obviously less of that overhead because communication effectively can be broadcast or mandated. But there's a balance there. We want to get the right level, we don't want to end up with a burden or an overhead or mandates and communications which are basically ignored or worked around. I think the other thing that we just picked up that was is worth us just bearing in mind and putting a pin in is the whole context of decision making. Because the more we look at the role of leaders and managers, and I think is is the understanding of how decisions are made in organizations has a huge impact, as it does for centralization or decentralization, of course.

I like that. I think it's I think it's a very good summary of all the various pieces we've covered. And I I love the conversation, it's a great topic. I think we could probably talk about this for much, much longer, but uh I know we have to wrap up. So uh uh thank you again, Dave. It's uh it's always a pleasure. Uh if anybody wants to send us uh any feedback or there's topics they want to talk about or they're interested in being on the podcast, then send us an email at feedback at definitely maybeagile.com, and we look forward to talking to you next time. Look forward to it. Till next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Madison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.