Organizational Change Management

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock 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, David Shurik and Peter Madison. So how are you today, Dave? Very good, Peter. You sound like you've you've uh got lots of energy coming into this conversation. Always, always. This is a favorite topic of mine. It's all about change management and organizational change management in particular.

Well, and in particular, agile organizational change management, which I think we would both agree is pretty poor most in most uh situations.

Yes, yeah. I've uh I have not seen a good implementation of it uh in reality. Uh I find that Agile on the on the ends up working on the micro scale. Like it they tend to apply the microscale, they pick a framework, they adopt it on that micro scale. But when it comes to the how do I make sure that I'm bringing people along on that journey with me and that I'm properly sharing knowledge and that we're radiating and making awareness uh in the organization and doing a good job of that communication piece, I I've seen that go wrong or at least poorly on more uh occasions than not.

Well, I think I I think there's a couple of reasons why we don't see good change management around agile introductions of agile DevOps practices, whatever it might be. One of them is the classic problem of technologists being really bad at marketing. Right? We tend to focus on, hey, let's make sure we do this right, but we then don't necessarily tell people why we're doing it, why this is right or it's wrong or not, and and all of that communication piece is not a natural part of what we're doing.

And and we're we're naturally prone to talking about our AWS VPCs and uh the VPNs and all the rest of the uh TLAs that we want to bring into this and all of the mess that that makes, which is just our our our natural way of communicating, which makes perfect sense to us. We know what we're talking about. Uh unfortunately, when we're trying to explain what an awesome thing this is to the rest of the world, the rest of the world's looking at us like we're crazy in our dark robes and cows and etc.

Okay, I'm not gonna dig too far into that one. That feels like we're going in a satanic direction. But but I think one of the things that you we're picking up there is language, right? Change management is not about communicating change in the language that we are used to, but it's communicating change in the language others can understand and are used to using, which is an important sort of takeaway. Uh, there's a the second reason that we often ignore change management, even though we're changing an organization, is I think because it's bottom-up in many situations. It comes out of the teams, behavior changes at an individual level, which then propagate through an organization, which is fantastic, except we do need to start managing, communicating that change to the rest of the organization so they can understand why behaviors are changing, why expectations are shifting and moving in a different way. Have you what would you say is the right way to do that?

I think well, one part of this that I always start with is ensuring that uh, well, you get leadership on board, right? Uh but that I mean, to do how do you go about doing that? Uh well, understanding what are the things that leadership is looking for, what are they being measured against, making sure that when you're starting to bring in change at the bottom, understanding how it's going to impact what those measurements are, and so that you can show and radiate, look, this is what we're doing, why we're doing it, and how it's going to be of benefit to you. This is what you can expect to see. This is how and then communicating that in the language that they understand the world to be in, and helping sort of bridge that gap so that there's a all too often we find that we we've worked out that the teams here are all great, hopefully, and that they've worked out how to work together teams, deliver faster, work out how to um uh adopt these new practices and new behaviors. Um, but that in turn changes the nature of how the organization is operating. And for the people who are looking at the the bigger picture and trying to understand how do I see this organization moving on the longer term, and they're looking at a longer timescale, uh, this could be disruptive to how they're looking at the world and how they're looking at, hey, how do I, it's great that we've got all of this new change going on. It's great that we have all this new capability coming in, but how do I relate that to my world and how do I relate that to what I'm seeing?

So that sounds to me like a case for change management, right? What I struggle with is that when we so what I've seen in many organizations nowadays is organizations recognize agile adoption, modification of, say, practices around DevOps and things like this, whatever that might be, those warrant change management. So what we then find is we get a transformation team pulled together or a change agents, change managers coming in. But the tools that they have at their disposal are geared towards big organizational transformations like re-orgs, change in strategy. And so they they tend to have this sort of what's actually quite a waterfall-based, you know, they'll they'll figure out what the change is, identify what the objective is, communicate that change in terms of those new objectives and things like this. And it's a very big communication effort, which doesn't sit naturally with an iterative approach and an incremental approach to change. An incremental approach to change is much more of a continuous improvement model. And so it I think that one of the challenges that we have is change management as a as a um kind of discipline is out of step with incremental change. It's ideal for big step changes, but it isn't geared up towards incremental changes in an organization.

I'd say that's true. It's where and this is the same, and we've talked about this many times on the show, is around uh ensuring that you've got the cadence of what you're doing is is matched, so you don't have a mismatch between what the cadence occurring at one layer of your organization and the cadence of what's occurring in another layer of your organization. At some point these have to match up, because otherwise you'll find yourself in some situations where uh the leadership will say, well, that isn't doing what I'm expecting it to do, and so you're gonna stop doing this crazy ass stuff that you're doing down there, because I don't want to see any of that. Because that's it's my my report doesn't look the same as it used to look, and so we're going back to the way we used to do it.

And and I well, and I but I think what you're identifying there is exactly like like there's the um there's the need to to soften the impact of incremental change because continuous improvement, you you're picking out that idea of a report that suddenly changes. It it we don't really care about change until it hits my desk, my areas of responsibility and the tools and reports and communications and whatever it is. And when it does hit that, I now we've got the inertia of, hey, I liked it the way it was yesterday. So I find you know that and that kind of falling back into the rut that we had. So change management in an incrementally changing environment becomes much more targeted, it needs to tackle the people who are immediately impacted by a change that's just gone into the systems last week, for example. And it also has to very clearly I outline the benefits because again, and I'm just imagining we've worked with a lot of you know vendor systems where we're changing how customers' service is done. And and so there's changes coming in, and those changes are drip feeding in. But we need to we need to make that that uh sort of uh barrier to entry into the new world as smooth as possible, handhole people through that, targeted communications, very clear understanding of what the benefit is, why it's being done, and what the benefit is so that even if um if they you know we all know we've got keyboard shortcuts, things that we can use, we've used that in the way that we're working. Well, when those systems change, how do we help people translate the unconscious ways they've been working into the new world?

Yeah, we we and we see this a lot, um uh and it happens at every layer of the system too. We we um and when you're coming in, uh one of the problems we see the other way when we come in as change agents is that uh we we're told one view of the organization, but we're not necessarily always as close to it to be able to see what the real impact is. So unless we go and look, right, uh our gamble walk of the world, like go and see exactly how exactly are you doing that and find what that keyboard shortcut that the person in operations is doing to get their job done on a daily basis. We can very often find ourselves in a situation where we say, Well, this is easy based on what you've told me, we can move over to this system without a problem. We're just gonna rip out that old stuff and we'll move you right over here, and everyone's gonna be happy. It's like, well, actually, not so much, because what we've re what we've really done is make some huge disruption to the organization. We may have had some unintended consequences of the changes that we're bringing in. Uh, so truly understanding this at every layer and what the impact of that is is is another critical part, I think.

Well, what you're describing there sounds to me a lot like user experience. Yes, right. It's a it's it's exactly that bit, and we keep coming back to this whenever we're looking at these things is uh it comes back to the user, the end user, customer, however we want to think of the people who are consuming whatever the changes are. And and it's so important to understand their environment, their needs, because quite frankly, we're all super busy. We all if we if we see a change, I mean, think of how many times um hardware upgrades or software upgrades on a favorite app, and it's suddenly the way we used to use it before just doesn't make sense and we drop off because we we just don't have the whether it's the time or the desire or the the opportunity to kind of drill in and understand where those changes are. And the only times that we really do that are when we're forced to. If if if you know our healthcare system makes a change and it's the only way we're gonna get healthcare of any sort, then we're going to figure that one out. But that's not a good model. We can't just say we have a monopoly, therefore you have to understand the changes that we have made. I think we need to be much closer to understanding that changes are continuous. This is a mindset shift. And you say when we come in as change agents, sometimes we forget that we are on a conveyor belt of change. We know changes all the time, everywhere around us. And that's where, as a change agent, the environment we tend to sit in, then we go and open the door and step into a room of people who whose environment does not change all the time. It's a it's a very, very different experience. So, you know, it comes back to that user experience to listening, to understanding where their concerns are so that the changes can be put in it framed in a way that they see a benefit.

And I think you bring up a very good point there. This uh this building up the muscle of being used to change, and uh that when we come into an organization, we're very used to change, we're doing it all the time. We're introducing change, we're looking at new ways of working, we're looking at how could we do this better? And we're helping people think through those problems uh and thinking about looking and uh how are you doing things, how could you we help you understand what the next uh outcome might look like and how you might get there. Uh, but we're used to that. We and most people who are coming and doing uh something more consistently on an ongoing basis, um, even though they they probably have a lot of sort of micro changes and challenges and work that they do because it to keep them interested in that work, on on the more macro scale, it's largely the same sets of things they do all the time, and they're not really looking at the system they're working within uh as much as they are just looking at well, how do I how do I handle these pieces of work that I have in front of me today?

And they shouldn't be looking, shouldn't be looking at that system, they should be looking directly at what their their kind of perspective is and what they need out of that system. It's a little bit like if I think about um many of us have cars now with four-wheel drive, and yet we never need four-wheel drive until we do need four-wheel drive. And then our perspective on four-wheel drive changes really, really fast, because then you find out if you've got cheap, nasty four-wheel drive or real, um uh, you know, real four-wheel drive or towing, you know. Many many SUVs nowadays have some sort of a towing connection. If you've never towed anything, it doesn't mean anything. We don't need to worry about it. But if you tow a boat out every weekend, because that's what you and your family do, um, then you learn all about that perspective. So it's very much driven by the that user's experience and what they need to do with what's going on.

And uh so how do we go from a world where we we have these these large change processes where we know we need better communication to one where we help the organization adopt that more incremental approach to changes and change communication and awareness uh as we bring in uh agile practices, as agile practices come into the bottom of the organization.

Um, maybe to start with, the first thing that strikes me is we need change management because I think we started our conversation saying a lot of, and we certainly I've seen this many times, a lot of agile transformations, because they kind of come in over here, not everywhere, and they're not necessarily nowadays, they're more and more they are top-down, but they weren't always. Then there's this perception that you didn't need change management, and I think the starting point, 0.1, is you need change management. We have to recognize that. Um, the second point is the big broad change management communications, where it's only it's going in at, say, a town hall, and you know, the next quarter this and this and this will happen is important for big transformational shifts in strategy and so on. But that's not the change management we're talking about. The change management we're talking about, that micro changes that are continually happening, has to be targeted. We've got to figure out who's directly impacted and go deal with that very, very quickly and early. We've got to um help them understand what the long-term objective is. There has to be, as Cotta will talk about, that sense of urgency, a burning platform conversation piece. So we know why something is changing, whatever that might be. And um we we have to understand that user's experience so that we're not simply ignoring those sort of subconscious keyboard shortcuts and the way that people have found of working with things that makes their life tolerable wherever it is, makes the work that they're doing um something that they they feel is works well for them. So then that leads us to the whole like um small changes that are clear clear benefits. And again, I think of Cotter's work, and that's the you know, go find the low-hanging fruit. At the end of the day, if you're gonna change somebody's system, solve a problem for them.

Go back to them, yeah, spot and then solve that problem, fan the flames, spark, grow it, build the community around that, and then and that's how you start to grow that change.

I I I love that idea of just building that community around it. What you're you know that change is successful when the people that you're working with are propagating that change themselves. Yes, right? So, how do you get that? Low-hanging fruit, make sure you understand their environment, listen to them, and and and don't just ignore and say, we know better. This system is better. Well, that's not necessarily the way. This way of working is better. And I think in in agile circles, we sometimes forget that because we know how different agile teams, when they work together really well, what a significant difference it is. But nowadays, I think there's many, many people who've had experience on agile teams which aren't those ones that we know about, which aren't high-performing teams. They're kind of just performing teams the way they were before. So the the kind of shiny side of the change is dull down, is diluted because there's not that expectation that we could that was implicit before.

Yes, yeah, and then what that looks like, and how are you going to translate that into the organization so that it can be more broadly adopted. So I think with that, we're we're coming to the end of our time here. Uh, and I think there's quite a few good points we could pull up. What what would be your top three points from what we've uh discussed today?

Um I think number one, you need to handle change management. Like, don't ignore it. Stop ignoring it however you want to think of that. Number two is targeted. It's not big, big change, it's targeted change. Figure out who's going to be impacted by the change. Make sure we understand what that impact will be and make sure it's a low-hanging fruit. It's something that they'll thank you for, right? And it's solving a problem that they have.

Yeah, and uh, I think I will double down on your uh communicate, communicate, communicate piece. It's the we however I think John Smart put this very well in uh in the SSH book. It's like uh you you however much you think you need to communicate, triple that, and then it still won't be enough. You making sure that you understand that uh the because I in all the organizations I think I've worked in, uh the feedback from uh staff has always been, well, you don't communicate enough. And you're like, really? But how could we possibly communicate more? Well, the answer is, well, you need to communicate more, and you're and it might not just be you need to communicate more, you might need to communicate in different ways and provide different forms and different ways to engage with the material, different ways of understanding how will this impact me? What is it, what is the impact to me as a consequence of doing this? It's not to your point, it's not enough to stand up at the town hall on a quarterly basis and say, all of this wonderful stuff is coming in to you in the next quarter, and uh and that's that there needs to be more. That's not gonna radiate with everybody.

One one thing I wanted to pick up is just as an add-on, a a finding or a realization I've come to in this conversation is the importance of understanding the experience of the users and embedding that into any sort of change work and change management process. I think that's very important.

So, with that, we'll wrap up for today. And uh, if you would like to reach out to us, we're always happy to have a conversation. You can get us at feedback at definitelymabeagile.com. And we look forward to next time. Thank you, Dave. Always a pleasure, Peter. Till next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.