Governance for Reducing Complexity

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. For a pleasant change, I am sitting down with somebody relatively close to me. It's just one country away, not many, many hours. I've got the pleasure today of talking with Tony Ponton. Tony and I have known each other for decades.

Tony Ponton: That'll do.

Shane Hastie: But Tony, first of all, welcome. Thanks for taking the time to talk to us today.

Tony Ponton: Oh, it's a brilliant pleasure. I'm really looking forward to it, Shane. You know, I'll always talk to you. Doesn't matter where, when.

Shane Hastie: Thank you. All right. So you and I obviously know each other pretty well, but I suspect most of our audience wouldn't have heard of you. So, who's Tony?

Introductions [00:48]

Tony Ponton: That's fair. I'm Tony Ponton, I'm an executive principal for a consultancy. I like to say with the Agile thing, I've been doing this Agile thing for … I'm in my third decade is how I put it, Shane, rather than saying that I'm old. And I grew up starting the Agile journey in very early world, it was XP before we really even knew what Agile really was. So I've been doing that with enterprises and organizations across the world, and recently, I wrote a book with my co-author, Phil Gadzinski, who couldn't be with us tonight. He's on a houseboat somewhere enjoying himself. So he left me to my own devices. He'll be sorry for that.

Shane Hastie: The book, Govern Agility: Don't Apply Governance to Your Agile, Apply Agility to Your Governance. Bold words.

Tony Ponton: Yes, I guess it goes to the heart of why we wrote the book, really, and we call it Govern Agility rather than Governance Agility or Governance Agile, or whatever you want to call those things, because when we're talking about it, let's just take that first thing as we're talking about it tonight. When we're talking about governance or governing, we're talking about governing the system as a whole. So for the listeners, we're not really just talking about projects and PMOs and those types of things and portfolios. Not that they're not part and parcel, those are very important parts to that, but governing the system as a whole means the whole of the organization. And therefore, that's why we talk about the fact that you don't want to put governance in your Agile and choke the ability, or I call it disenable your ability to use the agility that your organization has by creating complexity.

Shane Hastie: Why does governance create complexity?

Good governance systems should not create complexity [02:33]

Tony Ponton: Well, that's a good question. I'm glad you asked me that, Shane. I could see the cogs turning there. So good governing systems shouldn't create complexity, but they do. And there's a few reasons, and when you read the book, we actually spent a fair piece at the beginning explaining where we see that, where we've seen it, why we've seen it, which places us in the realm of why we wrote the book. A lot of organizations have had governing systems in place for a very long time, and they suffer from what I call organizational detris. It's that buildup of the system on top of the system, on top of the system, because something went wrong. So we did something to stop that. Now we put something to control that, then we put something to control that. In fact, they end up with so many layers of governing throughout their systems from portfolio to enterprise to right down to the teams, people are doing things they don't even know why they're doing, how they're doing it.

And the buzzword at the moment is flow, right? We all know that and we all know what flow is or have been working with it for a very long time. But the reality is the old saying about you can only be as Agile as your most Agile leg. It also goes to the other spaces. What happens is organizations, they go with this goal of being transformation and we're going to transform our organization into a more Agile or a more agility based organization or adaptive, whichever one of those buzzwords you want to use, right?

Shane Hastie: Digital today, isn't it?

Organisations often have contradictory pressures between strategy, governance and operations [03:58]

Tony Ponton: Yes, that's it. There's another one. What they actually end up is transitional, because what they do nine times out of 10 is it's what I call the three-speed economy. You'll hear me talk about it a lot. The three-speed economy is really like this. They usually have their systems of strategy and leadership, and generally most organizations know where that's going. It could be cleaner, it could be neater, it could be better. If they don't, then we've got a whole different conversation.

They then turn to shaping where the systems of work get done, because that's the easy place to start. So they build tribes and cross-functional teams and all the things that we talk about, not that I'm against all of that, that works great. But what they leave behind is the governing systems and the funding systems, and they're usually going in a separate way. And worst-case scenario, your funding is going one way and your governing systems are going the other way. And believe me, I've seen that a number of times as you have. And so essentially what happens is then your ability to enable your agility actually hits what I call the complexity ceiling.

You get bound into this complex utterance of all of the governing systems and the funding systems and not thinking of it as a whole. So what we're really looking for when we talk about Govern Agility is having those systems shaping and moving in the same way from your strategic intent to your delivery. And there's that sort of extra piece that connects to it, it's what we call the collaborative connective tissues of the organization. It's the horizontal flow of information plugging into the vertical flow of information, which is the strategic intent to your execution, the execution back to your strategic intent.

And so what we see is that that gets truncated quite regularly as well through the amount of restructures, repoints, realigns, have I got them all? Was that all the terms there? I'm sure there's other ones you can think of for that one. So every time you pull something apart, you actually break your collaborative connective tissues. And usually as that all gets pulled apart, the governing systems don't change either. So they're still applying the same governing systems that they've had in place for X amount of years, and yet they're creating this agility. So I guess that's where we came from when we were thinking about it and looking at organizations and we were seeing this happening at many organizations across the world.

Shane Hastie: Governance exists for good reasons in organizations. How do we, I want to say, sharpen it or make it more effective and avoid some of that complexity?

Governing the system should be part of the everyday work [06:31]

Tony Ponton: Here's the thing, I'm going to say something quite controversial, which I'm sure you're going to enjoy, but I've been in the Agile community as I said, this is my third decade. And I think as agilists, we have been remiss in thinking about the governing systems or governance as a whole. And often it gets pushed to the side as something that we'll get to it or those governance people can go do that thing, but we're going to do our Agile thing. And I've heard that and I've seen that in organizations. So when you talk about sharpening it, well, the first thing is to actually bring it closer to the mix. The governing of the system should be part of your everyday work, not an operational overhead. And the minute it becomes an operational overhead, then you're actually creating bottlenecks that actually choke the daylights out of your system.

The other thing with that is it's looking at it in terms of your governing systems and not just, as I said, not just these checks and balances in the book. We look at it through a set of lenses and we'll talk about those I suppose, the five lenses, which we call the stanchions. We'll talk about those in a minute. So the answer to your question there is you have to design your governing systems to the context of your organization, but to the context of enabling your ability to use your agility. And I think that's the important statement here.

Shane Hastie: So what does that look like in practice? If I'm a large financial institution, subject to Sarbanes-Oxley and various other bits of legislation depending on where we are in the world, we're tasked with looking after other people's money perhaps, and we don't want to take chances with that.

Tony Ponton: Yes. In no way should we, and in no way are we saying you don't have those checks and balances. But there's also the guide rails that allow you to bring it close in person, place, and time is what we talk about, right? Closer to the people that do the work, that know what's happening and are able to make decisions that allow you to expediently understand the risk and make those interventions to the system. And that's what we're talking about is those short sharp cycles that allow you to adapt and change. I've never met anyone in the C space or even program managers who when you say them, wouldn't you like to be able to understand what's happening daily, weekly, fortnightly basis rather than find out a quarter or your steering committee or your CAB or whatever that be that's held once a month that everything has gone to putty, right?

And we all know the watermelon story, everything's green and then it's red. Well, I've taken it a step further. What happens in a lot of these systems is that they drop it on the floor and the red goes everywhere and then it becomes code brown and it hits the fan and then we have an organizational issue. And I think we can all think of organizations who found themselves in that drama, found themselves in the press recently as well. So in no way should you not be doing that. But it's about how do we shorten the cycles that'll allow us to adapt and use the agility and enable the agility and the flow of our organization to have that information so that we're all moving in the same shape and size, if that makes sense.

Shane Hastie: You talk about the five lenses, the five stanchions. What are those five stanchions?

Information flow which allows speedy decision making is the key to effective governance [09:48]

Tony Ponton: Let me start with what is a stanchion? I'm surprised you didn't ask me that, because a lot of people have. Then when we were putting this together, we had some serious debates over what we would call the lenses, whatever it might be. The reason we settle on stanchions, if you look it up, stanchion is a pole that actually you use to hold a structure up and usually those stanchions then fall away.And so we see that as their containers or scaffolding to enable what you're adjusting your agility to.

And there are five key ones of those that we look at that we have distilled out of what we've been doing over the last three decades as the things that will make the change in your agility to allow that adaptability, to allow you to put the Agile in the governance run. So the first of those is sensible transparency, and we use the word sensible, because if you're in an organization, talk about radical transparency.

Sensible Transparency [10:42]

I know the book, I know the thoughts around that and some of the conversations are fantastic, but the words radical transparency strike fear into the heart of CEOs and CIOs anytime you use that. But sensible transparency for us is thinking about what you're going to be transparent about and being transparent about what you can't be. But it's looking at it through the lens of how do we get the transparent flow of information that allows us to make these expedient decisions. And so starting to look at things like using Obeya's, digital Obeya's these days, we've got all of that flow of information.

Setting our systems up, and we'll talk about that, because that's another lens, obviously, but allowing us to have that ability to have the transparency of information that alleviates what we call the bifurcation of information. So usually, people at the top tend to know where they're going and what they know, and the people at the bottom tend to know what's happening with their work, but it's not necessarily a line at the top. And so we've got this split, right?

And what we're trying to do is make sure that as collaborative connective tissues are in place so that we can use that, because the stock in trade of agility, as it was always told to me, is information flow. That's what Agile does. It gives you information flow. You can look at all the other things everybody talks about, but the reality is it gives you information that allows you to make speedy decisions. It allows you to understand progress and it allows you to understand the killers of work, dependencies, risks, etc. So you want to set that transparency. So from the bottom of the organization to the top of the organization and across the organization, you can see that in a transparent way.

And we do that in a sensible way, because obviously you say there's legislative things, some of those things you can't tell people about, but you can be sensible about that and say, "Well, here's X." So it's having that transparent view, a window into the organization. So radiating information from the organization to the organization, is a great saying one of my friends, James McMenamin (shout out) uses.

Conductive Leadership [12:38]

So that's the first one. And then we talk about leadership. So we talk about it in terms of conductive leadership, and that's an interesting turn of phrase. I think a lot of people have asked me about that as well. The reason we talk about conductive leadership is not that I have anything against intent-based leadership or there's so many leaderships I can come up with for you. Servant leadership, please, that's again, as an agilist, I think that's another thing that we as an agilists have done ourselves wrong with. There is no CEO, CIO. There's no leader that I've ever talked to that wants to be called a servant. I mean, I don't pick up after my kids. You're basically innovating that they're going to be servant to the people and do everything for them. And then you have this long-winded discussion about, "Well, we really mean..." So as Agile, I think we haven't done ourselves wrong.

We talk about in terms of conducting, because we found that that was a great analogy to what we're talking about with leadership. We want to change the frame of leadership from the typical command and control. We all know that, right? And when you introduce agility to your organization, by rote it disseminates control. That's what it does, because we're focusing it down into whether the people get closest to the work.

So what that only leaves is command as a lever to pull. And you'll hear, I must, you should, you will, you have to, you've got to. And the minute that starts happening again, then you're disenabling your ability to use the agility in your organization. And in your governing systems, right throughout the organization, you need to look at that in a different leadership style, thinking about how you can be more conductive. And we saw a fantastic video which is attributed in the book of a conductor, and it was a gentleman explaining how the conductor actually manages the orchestra. It's not just a waving stick for fun.

The thing I talk about to people all the time is does the conductor actually play the notes? No. Does he play the instruments? No. But he does help the actual orchestra themselves, put it together in a way that it makes sense and he guides them through the flow of it and he makes interventions. So he does interventions in a different way. If you watch him and next time you're watching him, I'll pick on you, Shane, because you happen to be in the room, but Shane plays a bum note. You get a little double tap from his stick just to let you know you didn't quite get that.

Tony Ponton: Yes, you do it again, you get a very strong stick and he's made an intervention without actually getting stuck in the execution. And I guess that's the bottom line is that we're looking to change that leadership to what we call more conducery, right? You're not in the actual getting stuck in execution, which you see a lot of leadership doing and bringing the ability to make those decisions, intent-based leadership, leading with intent as David Marquet talks about. Setting the guide rails, not guardrails. So I use that turn of phrase when I talk about leadership and guardrails are the last thing that you see on a very steep chasmic road, where you could drive off it.

And you're living in New Zealand, Shane, you know what I'm saying, right? By the time you hit those, that's your last resort. What we want to do is more think about it in terms of the new cars with the fantastic lane control that I always switch off, because it drives me nuts. But anyway, it pulls you back into line. It just course-corrects, makes that adjustment and it gives you the guide rails of where you need to go.

So we're talking about setting those guide rails, leading with intent, being more conducery in the terms of leadership, using the transparency. So of course these things are all interlinked and using the transparency to help you make those decisions as leaders expediently. So that's that piece of the puzzle.

Patterns of Work [16:15]

And of course then we talk about the patterns of work and systems of work, right? And essentially you have to actually think about how you set your systems of work up to enable your ability to use your agility.

You need to set your systems of work up so they enable flow, but they also produce the flow of information, transparency and enable the leadership to be able to be part of that system so that they can understand what's happening as well. So it's moving the entire system of work and thinking about how it works in conjunction rather than being truncated in that original example I gave you about the three speed economy, if you like.

Data-Driven Reasoning [16:53]

I'm being careful, because I know I could go forever on each of these, there's chapters and chapters in the book. And of course, then that brings you to data-driven reasoning. So here's the thing, when we were looking at the data piece of it and we came up with data-driven decisions, and then it was data-driven reasoning and the reason we settled on it in the way that we did was because the words out there at the moment, everybody's heard it, data-driven reasoning, they don't hear that much. What they hear is data-driven decisions. They hear data-driven intent. Well, you can have intent and you can have decisions, but the reality is you actually have to have the data that allows you to reason and it allows you to use that data in a way that allows you to actually reason in terms of introspecting it, understanding it, creating insights, improving, being able to make speedy decisions and reasoning.

And you've got smart people, your hire smart people, right? So if you just sit on the data and use the data to make your decisions, then you're literally taking smarts out of it as well. And when you think about it, when you think about that in terms of AI coming for us as well, this reasoning factor, it's going to give you a plethora of data and information back in speed, but you actually have to think about reasoning, if that makes sense.

Humanity as the Cornerstone [18:07]

So they all got to be working in concert as well. So what we talk about it is that if one is out of kilter with the other, then your organization is out of kilter and your governing systems are out of kilter and you find yourself in a complexity hole. That brings us to the middle or the cornerstone as we call it, and this should strike to every good agilists heart is humanity is the cornerstone. And the reason we say that is because quite often in terms of governing and governance and governing the system, it becomes a very transactional, mechanistic kind of system.

And the reality is you actually have a blip in the radar and that's the humans, the ghost in the machines, I talk about it, right? Humans will do human things and humans will make human decisions. So you need to actually enable the humanity in it and enable the people. We talk about trust, but verify, which is an old proverb, came out of the Reagan. We're going to trust you to do X, but we will verify. So the governing system should be more around verification of than actually the management of and the micromanagement of and grinding your people to a halt, because you're actually so governance based around what they're doing and how they're doing it within the organization rather than thinking about how you can leverage the actual people themselves.

And we talk about that aligns with all of the other stanchions that we talked about, because the reality is you want to bring it close in person, place, and time. Your governing systems need to be closest to where the people are who do the work at the time the work gets done, because that will allow you to make those expedient decisions. That'll allow you to create flow and that will allow you to manage the risks, the dependencies, issues, all of those things that we talk about when we talk about governance and funding and those types of things. Obviously, I'm giving you a whistle-stop of it there's a lot more depth to that, but hopefully that was a quick explanation, Shane.

Shane Hastie: Yes. So let's bring this really practical. I think of our audience, many of them are technical influencers. They're not able to change the structure of the organization, but they're sitting down trying to get work done on a day by day basis. Why should they keep?

Why this matters for technologists [20:18]

Tony Ponton: Because the reality of it is that these are the things that are stopping them from getting their work done on a day-to-day basis or slowing their ability to make the work down. Or they're in a situation where they're so beholding to the decision-making matrixes that have been put in place, that they're actually disenabled in terms of their unhappiness around the work as well. And I talked to them, I was one of these people. I started off in enterprise and I remember those situations where I was just going, "Why are we doing this? Why are we doing this?" You would become almost disenabled to go, "Oh, well just going to do it, because I got to do it and I'll do it, but I'll do it in the most minimal way that I have to." And so I think that's why they should care because if they don't, then the system itself will continue. If you push hard enough on the system, the system itself will push back.

Shane Hastie: So if I am in that technical influencer, team lead, maybe middle to senior manager in a technology part of an organization, how can I influence bringing these ideas in?

How to influence bringing in new ideas [21:21]

Tony Ponton: The way that you can do that is start to make small change anytime. It goes back to asking the questions that will help people see the light, I suppose is the question. Or I could make a shameless plug and say, "Bring me in," but I won't go there. But the reality is making small changes that allow the organization to see those changes. Somebody asked me the other day in an interview that I was in was, what are the three things that you tend to ask?

And it's the same thing I say to those leaders, can you see your single demand view? Do you understand all of the work that's coming at you or when it's coming at you? Do you understand your demand versus your capacity versus your ability to deliver? Not only can you, but can the people above you and the people above those. And I hate to do the above, above, because that's sort of like, all right, well let's just face it, that's how it works, right?

But the reality of that is so you can start to make some changes and start to make those things visible and the light bulb start popping on. So I've worked with teams when we was thinking about these things where I've gone, "Well, how can we make some change here?" So we started making the capacity very, very clear versus the demand versus the work that was coming at them versus the in progress and making them very, very transparent against their ability to create flow.

Because immediately you start to see that thing, people start to ask the right questions. So then that is a catalyst of the conversation. And we talk about it, you want to do this in a very principled way. You don't want to just go at it ad hoc, because the other thing that I see people just run into it and that's the dangerous thing as well.

So we in no way say that you should just throw all the cards up in the air and do that. If you're thinking about it in a very principled way of thinking about how you can make some of those changes, well let's decide what we're going to decide. What are those relevant activities? What are the phases we need to apply that decision into? And then go, "Okay, well if we know what that is, then decide how to decide." Let's make an effort here to govern the actual logic, not the decision itself.

So think about that, design your mechanisms to ensure that the logic is very consistent, very clear, very transparent. Transparency comes in again, so I always talk about you want clarity and you want consistency, that's really important. And then decide who decides. Who can decide on these things. Set up these decision-making frameworks and allow the decision to be made as close, in person, close in time as I was talking about.

I was in with an organization some time ago, very governmental organization is what we'll say. And that particular government definitely has the hierarchy of X. And there are some very good reasons to your point before where they hold certain decisions. And when we were in that particular conversation, someone said, "Well, I can't do that, because he has to make all the decisions." And he actually turned around and said, "Well, you know what? I do have to make that decision, but you can make those decisions and you can bring the information back to me so I can help you make that decision."

And so all of a sudden that changed the frame of reference. So decide who decides, and then big thing is decide when to decide. We should make them at the most appropriate times. We want to make the short cycle decision and we also want to make not too late, not too soon. So again, I like to give you organizational context around it.

Working with an organization one stage where they basically couldn't get anything through the flow, because their organization's steering committee only met once every two months and then they had to prepare a 965-page document of x, x, x, x, x, x, x. And they were filling this stuff out and nobody knew why they were filling it out. When we sat down with the actual steer co and said, "Well, can we shift it to the left? Can we make this shorter cycle and do they need to fill..." And they were going, "We don't even read that stuff."

So I think that's a really important thing that you do, and that's why we talk about making your governance a really seamless integration, make it part of the everyday flow of work. And these middle leaders that you're talking about, they have the ability to do that. They don't want to make it an operational overhead, but how do we make that part of what we do in our flow?

Shane Hastie: A lot of good ideas.

Tony Ponton: I'm an ideas man, I always said that, Shane.

Shane Hastie: If people want to continue the conversation, where do they find you?

Tony Ponton: You can find me and Phil Gadzinski on LinkedIn. And you'll find a Govern Agility page on LinkedIn as well. But we're always happy to talk, reach out to us, please. We're happy to have those conversations, because we only touched the tip of the iceberg today.

Shane Hastie: Indeed. Tony, as always, it's a pleasure talking. Thanks so much for taking the time to talk to us today.

Tony Ponton: Shane Hastie, it has been an absolute pleasure as always.

Mentioned:

• Tony Ponton on LinkedIn
• Book: Govern Agility