AI, Change Management, and Team Autonomy

In this episode of Definitely Maybe Agile, Peter Maddison and David Sharrock explore how increasing technological capabilities—particularly AI and modern development tools—are changing the landscape of organizational change management. They discuss the implications of newly created capacity, the value of team autonomy, and the importance of balancing efficiency with innovation.

This week´s takeaways:

• Creating capacity through new technologies doesn't mean downsizing teams—it means enabling organizations to address previously neglected but valuable work while maintaining knowledge pipelines.
• Team autonomy is crucial for effective change management—when teams have both direction and freedom to make decisions about their workspace, they can respond more effectively to urgent needs in the system.
• Organizations must recognize and protect "slack time" as a valuable resource rather than inefficiency—this time for maintenance, innovation, and thinking is essential for sustainable systems.

Chapters

• 0:00 Welcome and Change Introduction
• 1:37 AI's Impact on Work Capacity
• 4:03 Refactoring and Technical Debt
• 6:43 Capacity vs. Prioritization Challenges
• 8:25 Two Types of Change: Kaikaku and Kaizen
• 10:27 Autonomy, Slack, and Team Empowerment
• 14:10 Key Takeaways and Closing Thoughts

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today?

Dave: 0:15

I'm really looking forward to this conversation. I think our warm-up for it well led to some interesting comments and points, so let's see what we can have some fun with today.

Peter: 0:25

Yeah, we always say this, that the pre-conversation is usually the exciting bit, where we get to get at it.

Dave: 0:32

Definitely not the exciting bit. This is the exciting bit. Yes, this is the big one. What's the topic.

Peter: 0:38

So the topic is about change, but we're going to see where this conversation takes us, because, really, what we're talking about is we know that change is changing in the sense that organizations need to be able to adapt to change much more rapidly. They need to build the capability of adapting to change much more rapidly. We've talked about it a lot on this show. One of the things that we also see, though, is how does that capacity that gets created, get used, like what are we going to do with it when we get it, and where does it go, and where does it come from? Like, where does it come from? Where does it go? I think the and I think you're you're.

Dave: 1:19

There's some implicit assumptions that we may want to pull out of the bag and just get out on the table, which is that capability for change that we've always talked about, and generally we talk about it in the sort of the way people work and organizations work, and less about the tooling and the technologies that they're using. But in this particular topic, I think you're really trying to hone in on the fact that we're living in a world now where AI is promising that it's going to be able to accelerate the amount of work we can do. They never get prioritized, for whatever reason begin coming into view, Because if you really do have this sort of immensely greater capacity to get things done, then all of a sudden, a lot more things can be up for consideration.

Peter: 2:17

A lot of the things that were difficult to do before, like refactoring large code bases bases or modernizing and removing dependencies to vulnerabilities in the backend systems of your environment. These types of things are large, complex, expensive, add very little business value but are necessary to continue to maintain the environment, but very difficult to prioritize and get to because there's other bigger, shinier objects out there.

Dave: 2:48

There's also a huge assumption that that capacity to be able to dive in and make changes to these systems or replace them is high quality. It costs what it says on the box and not three years down the road when it's tripled or quadrupled in price and all of these other things. So there's an assumption that these new technologies coming in which maybe soon they'll be able to do that really deliver on the promise which I think we've got to kind of clarify that it's not today but it's possibly pretty close.

Peter: 3:22

Yeah, it's coming, and some of the things that they are capable of doing today are here today. There are. There's definitely, um, some wonderful things you can do with, like modern and open rewrite and, uh, other types of tools out there that can, uh, which are not actually ai tools either, which is the use, effectively a graph database to Not even sure it's a graph database, but they use relationships to figure out the parts of the code and refactor it into other code, which is a great and phenomenal way of figuring out how do I move from this code base to that code base, and that really can accelerate things. So, you see, activities that would never really even have been undertaken before. Now come things that we could bring into the sprint and actually start to do and incorporate into our work and actually get the benefits from starting to refactor onto newer code bases and things like that what you're driving towards is we have increased capacity to make these changes to our systems.

Dave: 4:23

We can begin trusting them. Perhaps there's a lot of moving parts, but we're not tied to certain individuals in the organization that have been with us for two decades and know how everything was put together in the past. But there's actually this sort of that. We're losing the dependence on some of these incredibly knowledgeable, experienced people in the organization or the. The bottleneck is less there. There are tools that will will eat into that sort of bottleneck and help us move past it. Therefore, we can do lots more changes. So what's the problem then? It sounds to me like everything's going to get quicker and faster. We're going to do lots of changes.

Peter: 5:02

So where we start to see the problem is when people say, well, if I've managed to create all of this capacity, I can fire all these people, or I'll just keep the senior people and I'll get rid of all the junior people, and now I don't have a pipeline of junior people who are going to become senior people.

Peter: 5:18

So my problems may not occur today, but it is going to occur a little bit down the road. And so we're in a piece here where the promise better come true if that's the path you're going to take, because if it doesn't, you are, in a few years, going to be in a lot of hurt, which you're not going to have anybody who understands anything about your systems, and all your senior people will retire. So there's a function here which I always, from an operational perspective, have taken, as we've never had enough capacity in the system to get everything done that we need to do, and there's always far fewer people on the engineering side who are trying to keep up with all of the requests, and they never have enough people or capacity to do it. If you can become a force multiplier for that capacity, then it's not a case of, hey, I can now do it with less people, although arguably you could. But if you do it with less people you're not really helping the situation. You're still not going to be able to get to all of the work.

Dave: 6:18

Right, yeah, but I I mean this is, I think, part of the conversation we were having earlier on. When you say get to all of the work, I think there's. I really this is an area I really struggle with, because the reality is we'll never get to all the work. There are always things that we're not going to get to. And the fact that we have capacity. You could also argue that if there are things of sufficient value, then I can find capacity. I mean, that's effectively how companies invest to go and bring third parties in or recruit to meet a certain demand, and they bring that in because there's a return there that is outsized for their market. But anything that isn't outsized for them, like like above the hurdle rate that an organization has, should they change?

Peter: 7:04

those things, yeah, that there's. That's where we come into things like the prioritization of, like, the work. Is it something that we should be looking at next? Is it something that we could put to one side? But there is always a set of work that well, if we had capacity, it'd be nice to get to, so that stuff is the stuff that can then start to get done and which does benefit the system but can be harder to justify and harder to prioritize, because those bigger, shinier objects, that, and which we naturally because we only have this amount of capacity available to us is what gets prioritized for the right reasons.

Dave: 7:41

And is this not that you're describing two types of change? Right? You're describing the change, which is big step changes where there's very clear benefit in a change. So we're going to double down, invest in this. It's a huge step change, right? Kaikaku, I think, in in lean terms.

Dave: 8:02

And then there's the other one, which is continuous minor modifications, which is kaizen again, which is this more you know, and and what I like, and I think the the thing that happens when we think of change in these two ways is that the kaizen piece used to you used to just be able to kind of leave things and hopefully it would keep going because things weren't changing around it, right? Um, that's why, you know, many people who listen to this show probably still remember using xp, not because they're old enough to remember when xp was created, but more because it hung around for so long because it was just it did what it needed to do and the the pace of change around it was not so much that we had to drop off of it really quickly, whereas nowadays, I think that pace of change is is more of a, like it's a nearly straight up, or it's just it's. It's very, very rapid, which means the ability to continuously make small modifications and improvements to our systems. We need to devolve that into the teams.

Peter: 9:06

We need to take it out of the hands of some sort of executive prioritization function and give the sort of ownership of that into the teams, because they are the ones who can see which parts of the system possibly with help from tools, but they'll see which parts of the system need the urgent care yeah, and I think that's a very good point, and that I mean this is we were talking about this recently when we were talking about the okrs as a mechanism to do that to to help enable the teams to understand like what direction to start to go in and help to think about how do we know that we are going in the right direction and using that as a mechanism to create that autonomy.

Peter: 9:44

And I think this all ties together in exactly as you're describing, that we need to create that function, that capability of being able to change at the levels of the organization, so that we're able to take on and start to make not just the big change but small, incremental changes as well, and continually looking at that, continually making sure that we have that capability, understanding that there's there's a piece there, that there is always things to be done.

Dave: 10:18

We'll never get to all of it, and also that the decision as to what to do next needs to be in as close to where that coalface is, wherever people are working. And I think there's a tendency and I certainly have bumped into this in organizations where we're in a place where everybody wants everyone, to all the teams, to be efficient. Therefore, in order to be efficient, they have to work on things that we agree with as being a high priority and by giving over control to decide where some of that capacity gets used is viewed as inefficient, is viewed as inefficient and therefore we have to stay in control, and that's actually removing the capability of those teams to be able to respond to what they're seeing in an informed way.

Peter: 11:04

Yeah, exactly, and I and I think, um, I mean it's the, it's the daniel peak, the pink piece, right, it's the autonomy, mastery purpose, the understanding like what is it that I I need to get done? What's most important, how can I start to work on that? And I think the capabilities that we start to see enabled in organizations make it easier to get some of these done.

Dave: 11:26

I know Jump in on that, because I think there's something a little bit more to it than that which directly conflicts with this drive that so many organizations have towards efficiency, which we touched on right at the beginning and we've touched on a number of times and that is that one of the things that we actually want to give to those teams is slack in their work, commitment, which looks like inefficiency because it looks like blocks of time, however you want to think of it, but a chunk of time or capacity that that team is not committed to strategic endeavors, whatever it might be, but is actually using to maintain and sustain the environments that they're in. However it's not, it sometimes gets squeezed out.

Peter: 12:12

Sometimes Okay, nearly always gets squeezed out, or at least viewed as a cost, viewed as a problem yes, yeah, and it can be very hard to protect that and because, uh, it's not necessarily seen as the valuable piece, even though it is incredibly valuable. And I do wonder, actually, if the introduction of the new capabilities and tooling that we're seeing, which allows people to much more rapidly prototype and investigate and look and potentially solve problems, if that might actually make that slack time look more valuable.

Dave: 12:52

Yeah, I think there's something I mean that's maybe a future conversation around really where some of these new technologies come in, because it touches on, if I'm not valuable creating the code because it's being created, where does that value come in? How am I contributing to the overall movement moving forward, the organization, the business, the value being created by the business, the value being created by the business and I think you're absolutely right, that slack, slash, sort of I don't know if it's discretionary time, but time that we don't quite know what to be doing, in that one is really powerful yeah, well, I mean even we've talked about this recently too the the concept that you need time to think, and we very rarely are given time to think in a fast-paced environment, so that in itself creates risk in the system.

Peter: 13:43

If we're constantly just switching from one task to the next task and we never have time to sit back and think about what it is that we're doing, mistakes will happen, it's just guaranteed. So we need time to breathe and to get up and to think through what the problem is and how we should approach it, and if we don't have that, then it becomes much more difficult to get some of these problems solved.

Dave: 14:07

I feel like we should try and wrap. I think we've had this really interesting winding conversation. I'm just wondering how we pull a few nuggets out of this.

Peter: 14:16

I'm just wondering how we pull a few nuggets out of this. Yeah, so I think there's a piece around. Don't assume because you've created capacity in the system, that that capacity isn't immediately going to get consumed and used for other activities in the system. The system will do what the system is going to do and if you create capacity in the system, people will find a use for it by creating sufficient autonomy for the teams in the system. People will find a use for it by creating sufficient autonomy for the teams in the system. Then they will find good uses for that. So if you set up the system well, so that teams have an understanding of what it is that they are working towards, then once you give them capacity and capabilities to start to work on those things and the autonomy to do so, then really good things will start to happen and the recognition when they do that as well.

Peter: 15:05

So these are, I think, very key points that I think we need to think through. So that would be a point that I would pull out of that. I think it kind of brings a lot of the different threads together that we've been talking about. I think another key point is that the piece around capacity as something that we need to manage within the system is best managed by the people who are figuring out what it is. They need to do so by giving them the autonomy to know how they're going to spend that time, by using mechanisms like OKRs or some mechanism to help keep them on track to where it is you want to go. That is, I think, a very valuable way of looking at that.

Dave: 15:53

And I think I'd add to that comment you just made at the end there, to say that it isn't 100% of the capacity is somehow discretionary and handed over to the team. There's plenty of direction that can be provided about the sort of significant features, products, whatever it might be that need working on. However, it's almost like this I always think of this as there's a cost of ownership piece. Always think of this as there's a cost of ownership piece. If I have a team working, I have to give them time to clean up their workspace, to fix something which is creaking and needs attention before it becomes the point where everything is fragile and it breaks. And too many times we try to control literally every hour of the team's time availability or every ounce of their capacity, instead of recognizing that there's a certain proportion of their capacity. That they're effectively is is part of the deal. They should have that to be able to sustain, maintain, innovate around the product that they're working on.

Peter: 16:54

I think that sums it up nicely. So with that, till next time, peter, as always Till next time. And thank you to our listeners as always, and you can reach us Feedack at feedback@ definitelymaybeagile. com and look forward to hearing. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.