This week's episode of Definitely, Maybe Agile uncovers how can we make the change stick. We explore why some people are more apt to change their minds than others, and what strategies can help us keep moving forward when it feels like there is no other option.
This week takeaways:
- Are leadership built-in?
- Hidden agendas
- Start small and keep it simple
References in this episode:
Leaders Eat Last- https://www.goodreads.com/book/show/16144853-leaders-eat-last
We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com
New episodes released every Thursday to challenge your thinking and inspire action.
Listen and subscribe:
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 episode of Definitely Maybe Agile with your hosts, Dave Sharuk and Peter Madison. So, what do we have on the cards for today, Dave?
DaveGreat to talk to you again, Peter. I think a really interesting topic here. We talk about change all the time. We talk about how we're trying to help organizations adjust how they work. We've not really talked about how to get those changes to stick. What's the kind of stickiness element that we can bring into shifting behaviors in an organization?
PeterYeah, I think this is an important one because we often talk about this and we talk about how we're going to introduce change into an organization. And we talk about it because it's the right thing to do, and everybody's going to buy into this, and they're instantly their mindset's going to change and they're going to operate in this new manner, and they're going to follow all of these new wonderful ways of working because it's the right thing to do. But I have, and I'm sure you have many times seen where we we come in, we introduce a change and try things, and it sticks for a little bit, and then people fall back into their old ways of doing things.
DaveYeah, I mean the reality is the change that we're talking about here is not a process change. It's not, you know, leave your dishes on the left instead of on the right, and things like this. But it's actually people change. It's helping the the intuitive responses that we've all learned to deliver in and to certain situations in an organization. We're wanting to change those intuitive responses. And those are challenging. That's that there's a lot of subconscious, there's a lot of individual uh um behaviors that we're kind of battling against, and cultural shifts and norms that we have to battle against. So I think that's one of the the kind of leading uh um uh challenges of change in today's sort of organization is that it's a lot more cultural and behavioral change than how we do business change.
PeterYeah, and that uh that brings us to the whole unlearning, right? It's uh we we talk about this. I I see it a lot in the agile space, especially. It's this this idea we have to unlearn. There's that great video of the the guy who teaches himself how to ride a bike that uh where the handlebars go backwards, and uh yeah, that's uh we've probably put that into the comments. But that but it it is that it's something that you're it's so ingrained to where you are, it is possible to unlearn these things, but it takes effort and it takes work and it takes concentration. You really gotta focus on it.
DaveAnd I I always love that example because what's interesting there is of course, this is where we bring in feedback loops because the and and anybody who's ever gone on one of those bikes where the the you know the handlebars are skewed, you know, uh uh pulled together in a different way. And when you turn right, you actually turn left. The nice thing about it is you get immediate feedback. So the minute you try and turn right, you actually turn left. So you can learn and unlearn the behavior and learn them. And part of that is driven by that feedback loop, which brings us into organizations where how do you create those changes so that the feedback loop is visible, clean, and easy for people in that organization to see.
PeterYeah, and then this is gonna get us into a couple of interesting pieces too, because uh one when even when you set up that feedback loop, if what's being measured about is potentially negatively impacted by the change that you're making, just naturally, because as you go through experiments, as you're learning, as you're seeing which ways you could go, uh as you're learning to ride the bike, it's like you're gonna fall off a few times. Then uh during that time, if you're still tracking against those old metrics and those old metrics start going in a different direction than you they were before, you might say, okay, we're gonna stop all of this, we're not gonna do that anymore, because that's obviously a bad idea without taking the step back to look at like, well, yeah, where where are we actually trying to get to? What are the outcomes we're actually looking for? Absolutely.
DaveYeah. It's it's the there's there's feedback loops upon feedback loops. So if even within the team, we're we recognize that when we turn right, the the bike is turning to the left, and so we're learning and we're falling, but we're getting better at it. If there's another feedback loop that looks, for example, at how many times you fall over and says that the more often you fall, the more you know, negatively that's viewed in an organization. So that's often those, you know, as you go up in an organization, the different whether it's KPIs or OKRs or whatever might be looked at, but they're now looking in a different way, those incentives where they're not aligned create conflict and pressure. And there's now a power dynamic, which incentives are listened to, which incentives, which which metrics are more important than the other one.
PeterSo when approaching a problem like that, where would you suggest people start?
DaveI I I think the first thing, and the the there's that sort of sitting down around a table to say how are we going to change? One of the biggest uh uh sort of mistakes I think we often see is that trying to change too much at once. There's a feeling, a number of different things. One is we know all the working parts, let's just change all of these working parts, and somehow this new beast, this new machine that we pull together is going to work in the way that we expect it to. But it doesn't work like that. It's not a machine, it's organic, it's people, and it doesn't work in a way that we picture it in our head. But another driver is often speed. We there's an urgency, we have to make the change. So we can't possibly make small changes, we have to make big changes. And there's a a misunderstanding or a misrepresentation that if we make lots of big changes or a lot of change, we'll somehow get there quicker. Whereas actually, very often it's the tiny, small changes which will guide you and and very rapidly sort of build up momentum. A little bit like a snowball rolling down a hill builds up momentum and builds up bulk. We're making small changes that add on top of one another and add on top of one another and very quickly outdo a sort of a big change mindset.
PeterYeah, I think there's some fancy uh Japanese words for that for some another topic, yeah.
DaveYes, kaizen over Kaikaku, right?
PeterSo uh so yeah, I mean if when we're uh when we're looking at this, making sure we're doing small changes, uh there, but there's still other things that can start to stop changes. And I I know that you'll have seen this too, where there's um sort of there's other things going on in the organization that you're not necessarily aware of, and your changes are um having an impact on something that may be outside of the scope of what you're definitely aware of, and there's some other hidden agenda that uh and if you're not aware of that, that can also derail change as you're bringing it in. So understanding and getting people aligned to what that is, and uh overcommunicating the change as much as you possibly can to help people uh come along saying, hey, we're we're doing this, we're all bought in, right?
DaveIt's i i I it's the unintended consequences, right? So we make a small change, and this this is one of the reasons why small change is better than large change, because the small change creates small unintended consequences, large changes create larger unintended consequences, and those unintended consequences are often the things that actually derail your change effort. I'm always wrecking like realizing as we discuss something like this how complexity and the thinking behind complexity really comes to the fore. And this is something that I think is a huge, uh hugely underrated in understanding change. If you look at complex environments, they're dynamic, they're moving all the time. So we need to make a small change because we don't know where the environment will be in the future. So there's a couple of things that you start looking at in complex worlds. One is that small change, the other one is focusing on these unintended consequences, which means not just over-communicating, but extending your feedback networks. Where are you getting information from above and beyond where you may normally get it, to look for those signals, the weak signals that say here's an unintended consequence in a completely different part of the organization, customer service or operations or wherever it might be, that we need that is a consequence of what we're doing. We need to be aware of. So, again, from a complexity standpoint, we're broadening out our information networks, getting information from as wide a range as possible. And then the other bit is the constraints, is reducing it. And I jokingly call this the keep it small, stupid, right? That constrain the change to something that you can really view and understand, because as soon as it gets too much bigger than that, is going to be a totally different uh scenario.
PeterYeah, and then uh and exactly the the piece if you don't have that uh network and you can't feed it back, if the change gets bigger, you're more likely to encounter unintended consequences. You're more likely to find things that are going to derail it, and other constraints in the system just simply because of the breadth of what you're impacting in the organization.
DaveAnd it's, I mean, in in organizations, that we're talking about this in terms of complexity, but in an organization's if we if you kind of redo the wording there, what we're really talking about is leaders and their involvement or not involvement in the change. So when it's a small, you can get buy-in from a small number of leaders, and we can probably validate that buy-in is really there, and so that we're we're getting that feedback and we're controlling that. The other interesting thing is leaders and and many people in organizations are highly incentivized by structures within that organization, like KPIs, you know, annual performance reviews, OKRs, whatever they might be. And they're often quite difficult, they're opaque to many of the players in that organization. So if that change is small, you're looking at it, you can at least interact with the leaders, validate their commitment and buy-in. As you make that change larger, the likelihood is much more that you're going to encroach on misaligned incentives because you're your your kind of center of mass is growing or is moving.
PeterYeah, and you're impacting more parts of the organization. You're uh you're looking at more different services, more different areas, more different pieces, and and as a consequence, bringing in a lot of those different opinions about the way things should be going or what those outcomes should be. And all of those are going to start to impact what it is that uh you're looking at. Uh so so when we when we look at all of that, we've talked about a lot of what the the the negative impacts are, the things that actually impact it. So, how do we actually go about making sure it sticks? Which is where we started.
DaveWell, I it's an interesting one because I I as we're talking about this, and I've got a few notes here, I'm thinking about being results driven, but I'm pulled back to that very original comment about the bicycle. One of the the reasons that that is such a fun kind of you know, booth or whatever it is, exercise that you get at fun fairs or or parties or wherever it is where somebody brings along the bike that's the wrong way around, is this rapid feedback. And not only that, but as you get the hang of it, if anybody's taken a little bit more time and starts getting the hang of moving the handlebars in a different direction, you now start getting that positive feedback loop, which uh again from Simon Sinek and his you know Leaders Eat Last uh book, which has some fantastic uh information there about just some of the physiological drivers behind these changes. That's that sort of dopamine cycle that starts coming in. And I I think that's uh and again an underrated piece. It's it's built into the Scrum framework, maybe accidentally, maybe on purpose, but this continual drip feed of that that dopamine hit of getting things finished. Well, in the same way, any change that we do has to be visible. The results have to be there so that we feel better, we get happier and more comfortable, and we're getting this continual physical response of positive change that's happening there.
PeterAnd well, as with uh any habit system, we want to make the uh we want to be positively rewarded for the good things that we consider good, and we want to be negatively uh penalized for the things we consider bad. And in order to help you.
DaveYeah, I think it's more of the positive reinforcement, less of the uh the whip and the stick in reinforcement, perhaps.
PeterBut these these yeah, these ways in um in which we look at systems, but but there's there's a different element there too, in that uh if there's positive reinforcement for the negative behavior, and and by negative behavior, I mean that sounds horrible, but if um the practices that we had before that uh we were looking to change are ones for which we still have a positive reinforcement from the whatever feedback loop is in there, like how we're compensated, how we reward, how we're praised, how we uh tell uh somebody that yes, you did a great job uh putting out fire and uh saving the day and all these pieces. Then what we're really doing is we're reinforcing the negative behavior that we don't want. So we're and we're also, if we've tried to make a change to that, we're also making the change which that we're trying to introduce less likely to stick as a consequence of this.
DaveI'm uh reminded as you're talking about that, Peter, of things simple things like um rewarding individuals, the employee of the month fallacy, right? So we pull out that individual and say, this individual has been really helpful, that they've done this, this, and this, they whatever it might be. And at the same time, we're trying to shift to a team mindset, collaborative team environment. Well, that is produces that sort of peculiar mismatch of expectation. On the one hand, maybe I'm driven to try and get that employee of the month recognition. On the other hand, I'm supposed to be committed to a collaborative team where there is no one kingmaker or queen maker within that situation, but there is a team that's all pulling in the same way.
PeterAnd uh, and I think that brings us back to uh alignment, which is probably something fairly useful on a bike that doesn't turn the right way. Uh the trying to make sure it goes in the straight, straight line. Uh so the I think, yeah, I think we've touched uh touched on a number of things. So uh how do we start to sum all of this up as what actions people can take so that when they're introducing change, it will stick in their organization.
DaveI there's a lot here, right? So uh as I'm trying to sort of distill some of the things that we've talked about, I think one of the first pieces is small change trumps big change. I mean, lots and lots of repeated small changes will allow you to learn and get better. We all know the benefits of that. Yet the tendency is when we look at any sort of organizational shift, we sit down and we plan the entire piece. And I think the the idea of small changes really is is a huge, you know, if you can put that on the wall or on your virtual backdrop and just try and figure out what that will look like is really powerful. I think uh a second piece is is understanding the power of feedback loops. We didn't really touch on that, but the great uh metaphor that you brought in with the bike is that works because of the feedback loops. And you know, designing any sort of change that has some sort of feedback loops that rewards that behavior that allows us to feel good about moving forward and making progress, I think is incredibly powerful.
PeterI think uh I think the other part is there is building on that, that those feedback loops need to extend uh beyond the the work that's there to the rest of the organization too, and that the leadership is bought into what the impact of those are, and that you're not having sets of incentives which potentially will uh change that behavior. So then it becomes very hard to let things stick because you're making changes to something which is going to look bad on a report that the leader is looking at, uh, because you haven't uh you haven't acclimatized them to the what is happening and what that change, uh the impact of that change will be and what it is they're gonna see. So that those are kind of very important pieces. And I I really like the way you described it as uh extending your your feedback network out and uh so that you've got a uh a better understanding of like what that network of consequences is as you start to introduce these small changes.
DaveAnd I I think the the uh as a consequence of that, if you like, one of the things that always strikes me, and I'm reminded of whenever we're working with organizations to adopt change and so on, is the amount of effort to change those those key experiences, those key touch points, and the amount of effort to whether it's the the phrasing used by leaders when they come and give feedback, or whether it's as you mentioned, the reports and how data is reported, how the information is communicated, and whether you're trying to replace some of it. But there's these little nuanced pieces. Uh, and rather than focus on how a practice changes, it's more about looking around the side to see how it's communicated out, what the information, because it's a people change, we're very, very responsive to the comments that people make, how the changes are recognized within the organization. And I think we're we don't spend enough time understanding what that is and tweaking that.
PeterAnd I would definitely agree. Um, with that, I think that wraps up our time for today. And so it's uh as always, it's a fantastic uh talking with you, Dave. I I love these conversations. And uh if anybody wishes to get a hold of us and provide any feedback, they can do at uh feedback@ definitely maybeagile.com. And we look forward to talking to you uh next time. Yeah, thank you. Perfect. Thanks again, Peter. 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.



