Working with executives with Peter Lam

Join Murray Robinson and Shane Gibson as they discuss the nuances of agile transformations with management consultant expert, Peter Lam.

We delve deep into:

🔹 The value and effectiveness of consulting playbooks
🔹 The ongoing debate around centralised agile approaches and the disconnect that often exists between executives and workers
🔹 The tendency of organisations to revert back to bureaucracy following significant changes
🔹 The challenges that functional silos pose to achieving agility
🔹 The lessons we can learn from the Victorian government’s COVID response
🔹 How executives can encourage agile transformations by removing organisational roadblocks hindering team progress
🔹 The resistance to agility often seen in those climbing the functional hierarchy
🔹 The potentially stifling effect of an executive emphasis on process in innovative organisations

Join us for this enlightening exploration of agile transformations, packed with expert insights and practical advice.

Read along you will

Murray: In this episode, we interview Peter Lam, a management consultant specializing in fixing agile transformations. We delve into the value of consulting playbooks. The debate around centralized agile approaches and the disconnect between executives and workers. We examine why organizations often revert to bureaucracy after substantial change and the barriers functional silos post to agility. We discuss the Victorian government’s flawed COVID response and how executives can foster agile change by removing organizational blockers to team progress. Finally we explore why those rising within a functional hierarchy often resist agility and how executives emphasis on process can stifle innovative organizations.

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Peter: And I’m Peter Lam.

Murray: Hi Peter. Thanks for coming on today. We wanted to talk to you about working with executives on agile transformations. Why don’t we get you to introduce yourself . So where did you start in your career and how did you get to where you are today?

Peter: Thanks Murray. I was lucky enough to start working with a Big Four consultancy many years ago. And whilst I loved the style and approach, I really struggled with the management team and I was actually looking to exit consulting completely when one of my friends suggested, why don’t you move into this project management caper?

I started as a project controller at a financial institution and then started to run my first project there and it was Lotus Notes development project.

The developer at the time had kids that was older than I was and he said, alright Pete, this is what we’re gonna do. And we basically did what I now know as an iterative approach to build the software. From there, I decided to spend some time working with federal government departments. And then came back to Melbourne working with a number of smaller and mid-size firms with a lot of ex AC Carney people, ex Booz Allen people. And then switched again, around 2010 ish started getting this, hang on, I’ve done this thing they call Waterfall. I remember we used to do this iterative stuff. This was a lot more fun than that. And we started to play with it more extensively. And then around 20 12, 20 13 I was lucky enough to work with someone who pulled together about 30, 40 Agile folks in Melbourne saying, let’s come together, let’s form a business.

Let’s teach everyone about this thing called agile. And it’s where I first learned about complexity theory and things like that. We set up a number of industry conferences, a lot of meetup groups and I’ve been running the Agile Project Management Meetup group in Melbourne since about 2013. 

Murray: What sort of companies are you working with today? 

Peter: Most of the companies I work for would be in the asic top 20 or major government departments you would know by name. 

Murray: and what level do you work in those organizations? 

Peter: It’s really mixed. I, sometimes engage at the project layer. Sometimes it’s boards, they’re subcommittees the CEO and the minus one minus two layer.

Murray: And you focused on doing business agility consulting? 

Peter: Most of it is agile work to do with the business design and the business model side of things. The actual ways of working implementation, if you like, or the technology side at the back end.

Shane: So people at the top of the food chain, people on the boards, people at the C level. What do they call it? Do they use the agile word or do they use something else? Typically? 

Peter: Agile isn’t something that’s first and foremost in a lot of their minds. They call it ways of working because it’s more broad, it’s more compassing and it’s something that resonates more deeply with lots of the executives and leadership teams. I think lots of the executives are interested and fascinated by this idea of agile. If you think about a more traditional environment, you’ve got your cube farms that people sit in, with all these partitions and they’re all gone now and got this stuff on walls and people together and chat. They’re fascinated by that human dynamic and seeing stuff. But whether it was called agile, adaptive ways of working, I don’t think most of them would care as much as you’d expect.

Murray: So the big consulting companies, the big strategy companies are going around town selling agile transformations to big enterprises. What is it that executives looking for? And what is it that the consulting companies are promising to deliver? 

Peter: If I look at a lot of the larger organizations, they actually don’t sell Agile at all. They typically sell projects that allow you to hit the metric that the c e o or leaders are accountable for. So if there’s a cost out initiative, if there’s a speed to market initiatives, any of those, that’s what they sell. Agile is just one of the things that come in as part of that .

Shane: So the execs , care about the outcome and if agile or whatever thing is the term they need to use to achieve that outcome, they’re happy to do it, but they’re not actually buying agile, which is interesting given we often hear agile transformation as being the thing the company’s doing. We don’t hear reduction in cost by using agile ways of working. 

Peter: If you look at some of the larger organizations in Australia that have gone through the Agile transformation and you look through the actual strategy books that are listed as part of the stock exchange, they talk about they need to change the way they work because they’ve changed the number of people that are in the organization. So if you’ve , asked thousands of middle managers and the executives to leave, that creates a void in terms of how your organization works. And therefore, then you have to reinvent the way that you work. Of which Agiles just a useful, very popular marketing term, people thrown into it.

I often talk to agile coaches and teach a lot of Agile coaches, and I say, At the end of the day, if we look back to the early two thousands when, we were all doing things like Prince 2, we didn’t have Prince 2 coaches. We didn’t measure them on your Prince 2 capability. You need to do the days for your practitioner, then we measure you and your ability deliver the phases as planned. And Agile seems to think that the process of agile is more important than the outcome. And I think that’s problematic. 

If you take a step back and you think about where the executives sit; the board of directors in most listed companies are gonna be measured on share price and returns. Agile isn’t part of it. They know that there’s an intrinsic link between happy people and financial returns so they’re trying to keep their people happy, but if you look at places that are technology-centric, so your digital companies and the big ones like Google and Facebook you look at the revenue per head that they generate, it explains why they can spend so much money trying to keep the employees happy. At a more traditional business, you don’t actually have that level of profitability that allows you do that. 

Shane: When we talk about the big strategy firms one of the patterns they have is to remove a large number of middle management people. And obviously that, is one way of reducing the cost for an organization. But also when you take out that middle management layer, then the way the whole organization works becomes broken and they have to reform. We’ve created a way of disrupting the way work’s done, and it’s also part of forcing a way of working changes in those organizations by removing that layer. 

Peter: The consulting language they use is delayering the organization, which talks about span control and influence and there’s heuristics that they apply to help you understand how many people you need to run your business, but if you do dramatically shift the number of managers then of course the teams then have to start to do things differently. And I think in some of the larger companies, agiles an afterthought. We need to reengage how teams make decisions oh, there’s this Agile thing. Here’s, some methods and approaches that are 20, 30 years old that have really proven to work in this type of stuff that, so they just plugged in.

Murray: I have heard that the strategy consultants are going around to executives saying We can use an agile transformation to delayer your organization and get rid of 25% of your managers, and that’ll all go directly to your bottom line. At the same time, you’ll be increasing your speed to market, becoming more innovative, happier people, and therefore your share price is gonna go up. Is that a common way to sell it. 

Peter: I don’t think that’s the way they sell it. I think they look at the metrics that the executives are committed to, which is typically cost out, revenue, up, speed to market, those types of things. And then Agile is just one of the labels they use to do the work they do.

Murray: So in the past they might have said we’re gonna achieve this goal through business process re-engineering or something. Now they’re saying they’re gonna achieve this goal through agile transformation. 

Peter: Before the Agile starts, you’ve got your delayering, you’ve got your, management restructures and then agile then occurs to then help glue the other pieces back together.

Murray: Okay. So often the organization doesn’t really change the way it’s working substantially. They cut a lot of people. They do a restructure into tribes and guilds and that matrix structure. But then the business processes that the organization relies on stays the same largely. In other words, there’s the same amount of work to do to get through the same bureaucracy as there was before. But now there are less managers to do all that bureaucratic work, and there’s some new agile processes added to it. 

Peter: I can say that in some of the larger transformations that I’ve been part of from the agile side, that things are materially different to what they were two years ago, there’s the behaviors that accepted the work, the style, the empowerment, the way decisions are made and things like that. It’s chalk and cheese, two years ago wouldn’t work for them. Two years later you’d actually go, actually, it’s not a bad place. It’s nice people get to do cool things.

Connecting from the team of teams to the organization is where the gap is. And a lot of our coaches, consultants, and people don’t have that expertise in a space between team of teams and the organization.

So finance process is a great example. Annual planning, things like that. Now, the organization needs to do annual planning because it needs to set profitability and expectations to stock markets or to government ministers about what they can and cannot do in the 12 months. So some level of 12 month planning is required. And that’s where the typically finance and strategy people get involved. The challenge is we need to change how that works. At the same time as doing the agile stuff. And I think that’s where, the gap is in a lot of cases.

Shane: Do you see that actually the product people are ahead of the software agilists?

Peter: So I think if you are a product person, your job is to sell to a customer. So your feedback loop is pretty simple. I do stuff, I iterate, the more often I can test with a customer, the more likely I’m gonna build something the customer wants. So agile fits really tightly and easily in that sort of scenario. The revenue goes up, profit goes up, usability goes up, dwell time goes up, whatever those metrics are, that’s quite straightforward. So if you’re not using Agile in that product space, you gotta question what you’re doing. But if you are actually sitting in the heartland of the organization in the heartbeat of the finance team, I need you to hit the number that your project managers commit to hitting. Why? If you overspend your projected amount of money and a number of projects do that, I have to go to the short term money markets to borrow money. To pay my people. And if I do that’s more expensive than you just actually hitting your budget and deferring payment. That’s the game they’re playing. That’s the game they’re awarded on. 

Murray: The cost of those interest increases are really not very much compared to the cost of poor outcomes of the projects. It’s quite common for a project to go 50% over time and budget. So those finance people are just focused on their finance KPIs. 

You said that the big gap is between the executives and the team of teams, the program teams. How do we bridge that gap? What are you doing there? 

Peter: I think we need to engage with them on their terms to explain to them how what we do makes their lives better. And if we are introducing a new management paradigm, you’ve gotta have experience in the traditional management paradigm. You’ve gotta be successful in it. And then you have to be able to demonstrate, that’s success in a new organization, which then gets more people to go, oh, that’s pretty cool. Let’s try that and let’s build it out. So you win through incremental delivery, and it’s a step by process where you have to reset expectation about what good looks like.

Murray: One thing that concerns me about the way the strategy consultants implement Agile is that they use a very traditional approach to do it. So it’s hierarchical, top down, secretive, big Bang. We’ll take you through this transformation, we’ll implement your playbook and then we’ll go away. Whereas that is the opposite of an agile approach. An agile approach is involving, engaging, incremental, continually learning. In that big bang transformation approach, there’s no cycle of learning. It’s just we have the answer, pay us, we’ll change your organization, we’ll go away, and then afterwards you’ll see the result. 

Peter: I think we just need to think about how they’re engaged and therefore what they’ve been asked for. So if you think about losing weight. The quickest way to lose weight is to go on the biggest loser. And the way they do that is incredibly structured, incredibly disciplined, almost like pressure cooker to get the exercise up, to get the calorie canning, to get all that kind of stuff so the people drop the weight. 

And sometimes when you are very overweight, you can need that kind of turbocharger pusher to get you across the line, because otherwise it just doesn’t work. However, the key challenge that you then get is that once you’ve lost the weight, a lot of people on biggest losers seem to put the weight back on again because they go back to the old life style old habits and all that kind of stuff. And the pendulum swings back and they end up with a chuck more weight. 

Can you drive massive agile implementations or adoption simply by doing incrementally? To be honest, I think it’s gonna be really hard. You have a whole bunch of middle managers whose job is to optimizing existing process, which is in many regards, optimizing and maintaining status quo, reduction of variation. 

So my job as a X manager is to optimize for this outcome. As in annual planning, my job is to optimize us to hit that. My job is not to measure the value of the customer. My job is optimized for this. So you have all the sub optimization that occurs. It’s gonna be very hard to do an agile transformation incrementally in that scenario. You actually need to sometimes tip over the chess board and start all over again. And that’s where some of these big strategy consultancies set the expectation about what’s happening and therefore help give the momentum to get the ball rolling.

Murray: So I’ve heard consultants who’ve worked with some of these big organizations say that after the mcBain consulting companies have been in and changed everything that the organization is completely broken in the areas where they’ve changed it. Are you suggesting that they’re deliberately breaking the organization to force change or that they actually just broke the organization without realizing what they were doing and then people have to try and fix it afterwards?

Peter: I think all of the above is true. So if you’ve come into the biggest loser camp to lose weight, you’re gonna break a bunch of things to make it happen. And there’s gonna be all these unintended consequences because the complexity that we have in our organization, that when you do such substantial change, you are gonna break things and gonna then patch em up afterwards, 

Murray: Is it that they’re breaking things? Cause they dunno what they’re doing. So they’re adopting a theoretical model. Yes. Their goal is, cut costs by 25% in the management layer by d layering. And we’re going to use Agile to do it. But in fact, if you talk to the strategy consultants, hardly any of them know anything about Agile at all. In fact, most of them are quite young consultants, small number of years out of an M B A. Yet they’re being brought in as agile experts and they had to read a book on the plane to the client site to find out what agile was. Maybe the partner knows what it is. Maybe somebody else in another country wrote a playbook and that’s about it. Apart from that, they don’t really know what they’re talking about at all.

Shane: So if we break that down to two patterns, there’s the idea of d layering, create a hole. Hole makes a change, and therefore you can get some benefit if you do it well. And then there’s a pattern of the business models of those consulting companies, which is partner at a high level with the expertise, bring in the grads to do the work and make the margin on the difference. But the playbooks themselves, are they valuable for an organization or not? 

Peter: Well, I think that most large organizations, will struggle to have the depth and breadth of expertise to drive the transformations or changes that they want. So we know that roughly two thirds of IT projects fail. The earliest stat I could find on project failure for IT projects was early 1980s, and roughly two thirds of IT projects fail. So what we’ve done as an industry has fundamentally failed to change the way we deliver and drive a better outcome. The only thing that makes a bit of a difference is agile, increases probably success by 10 to 15%. What we do know from that is that as experienced project managers, the value of the projects defined in the startup phase. And in almost every circumstance the setup has been done badly. It will only cost you a million bucks to do it 5 million bucks later, it’ll cost you a billion dollars to do, or 200 mil to do the Mikey card and you’re 1.5 billion later. Someone didn’t scope the darn thing out properly, someone didn’t plan it out properly, someone didn’t think through all the implications properly, so getting help in at the start of the piece to set it up seems to make a lot of sense. 

Murray: I’ve read through some of these playbooks because they tend to share them during a transformation, and I’ve read them and I thought, yeah, this is good. This makes a lot of sense. But doing these sort of things in real life, can’t be an academic exercise. You have to try things, see if it works or not, try something else. So I just feel like actually a lot of these playbooks are academic and a lot of people doing it don’t really know whether it works or not. Sometimes it doesn’t. Sometimes they add things in there, which are just bizarre and make the whole thing fail. Like McKinsey wrote a big paper saying that all agile coaches in the community are terrible, except for the ones that have been vetted by McKinsey because they come in with different ideas and we can’t have that. 

Peter: A lot of leaders will go; I’m spending a crap load of money on this. I wanna know what you’re gonna do. And that’s where the playbook comes from. In a lot of cases its a way of showcasing, this is the thinking we’ve done behind it. And in a lot of cases it’s copied and pasted from somewhere else. 

But I think the point that you made Mario , that I like is that, the act of planning is important, but it doesn’t survive contact with the enemy. Once the playbook starts to hit the humans that are having to do the work on the ground, you start to have problems because what works well on paper doesn’t necessarily work with the culture, the skills, the behaviors in that organization .

And I think that’s where there’s absolutely huge opportunity to try and tailor and get it to work for the people that are actually doing the work. And that’s the problem you have with we start with a playbook and we implement the playbook model, as you touched on, it’s a very much a waterfall approach to implementing agile.

Shane: I’ve never worked in one of the big consulting companies, so I can’t visualize what one of these playbooks is. I get the idea of a recipe, and then is a recipe something that needs a skilled chef or not, is always my question.

I did talk to somebody that came out of one of the big four and, she talked about the way they had a set of training material to bring graduates on, upskill them in things, they had a mentor who would actually take them through it. It was treated as a training ground to educate and upskill people with experience. The side effect of course was the pyramid scheme, but is that what a playbook is? Right? Is it is a bunch of material to help people with a quick start?

Peter: Everyone says they’re doing agile. It’s like teenage sex. Everyone’s talking about it. Everyone thinks everyone else is doing, but no one’s actually doing anything about it. 

So they wanna define exactly what it is in this organization and that’s what the playbook comes to, is that if you wanna do X, this is what it looks like. If you wanna do y this is what it looks like. And it’s just a way of trying to consolidate, this is how we think the organization should work after the agile transformation. And when you’re working across larger organizations, it makes sense that there’s a level of commonality across all the teams that you work with. Because the goal is to optimize not for one team, but to optimize for the organization.

Murray: Yeah, I agree. You talked before about how managers understand an organization. It’s about, managing processes to optimize them to reduce cost and reduce variations. So that is thinking of an organization as a factory. Like a Ford factory.

Peter: It’s been the prevalent management paradigm since the 18 hundreds or before. 

Murray: Yeah, but I think Agile is challenging the prevailing management paradigm. Lean does as well. Lean is saying you can improve the process in all sorts of places and it makes no difference at all. You’ve got to improve the process at the bottleneck. Otherwise it doesn’t matter. And agile is saying minimizing variation doesn’t work for innovative work, it doesn’t work for software development. And then there’s a lot of other stuff which is saying that empowered teams of skilled professional people working in cross-functional groups are much more effective than teams working in functional silos in a factory model. So there seems to me to be a really big difference between an agile way of thinking about what works for an organization and the factory model of thinking. Do you agree or not? 

Peter: Hundred percent. A hundred percent. If you look at the way that our organizations are structured, you have all these organizational silos. So you then build expertise in your silo and then eventually go up to manager because you’re an expert in something, you become a manager of people.

And then over time, because you’re good at optimizing this function, you get value out or you reduce cost or something, you get promoted again and again. So you get your functional expertise. That’s the management development model. 

Agile’s trying to upend that and saying, let’s get individually skilled professionals, put ’em together, support and nurture them, and then point ’em at a customer problem, 

It’s quite a different mental model of how an organization works. But you must remember that a lot of the people that have been in the organization’s management roles and leadership roles have been there for 20, 30 years in an existing paradigm, but we’re trying to shift it.

Shane: Yeah, you’re right. When we work with a team I try and move them from roles to skills. We try to reduce the handoffs. So we say, if the team can do the work amongst themselves, let ’em get the work done and, help them where they get stuck.

Have you worked for organizations where they have actually broken down some of the functional silos and actually restructured effectively their way of working, their processes. Have they gone to that level or are they really just focusing on that de layering?

Peter: I’ve seen organizations do both. Rarely at the same time. There is only so much change the organization can tolerate before it breaks. If you’ve been working in this existing paradigm that I’m a developer, I’m an auditor and I’ve worked in this silo for 20 or 30 years, you’ve gotta unpick that and then shunt it, and then try and open the doors and let fly. It’s a tough shift. If you look at a large organization and you tap Joe Schmo, Product Owner on the shoulder and say, which customer are you supporting? And how does what you do connect you to the customer? In most cases, most of ’em can’t tell you. So you have to start agile in silos before you start connecting them across into collections of teams that drive customer value.

Murray: I think that this factory mindset is the reason why a lot of these agile transformations fail. People come in like us and talk about all this agile stuff and we help some teams do really well, but then senior management are trying to turn what we’ve done back into what they’re used to.

So they’re saying, we need a centralized agile management team that centralizes all the agile ways of working and defines exactly how to do a standup and exactly how to do a retrospective. And has a whole lot of complicated ways of working, built into Jira that the team can’t change.

So in Agile, there’s this idea that the team reflects. And adapts continuously their way of working and what they’re working on. Whereas in a bureaucratic factory model, the team is disempowered. All of that is removed from them because the business processes and the business model are defined and controlled centrally. So those two things seem to be at odds with each other. 

Peter: So does a centralized agile management office make sense? If you’re optimizing for one team, hell no. If I’m optimizing for a thousand teams, actually yeah, it does matter. Do I care that you use Jira, Rally or whatever the digital product you wanna use? I’m not really. Do I care about the ability to aggregate the work so I can at least have an argument with someone about what’s going on. So to get that information, will I force you to put in certain data across the business? Yeah, I will. Simply because it’s not about one team here, it’s about getting a thousand teams or more to step to the right, if that’s what’s the right thing for the business. My gut feel says that if you have enough of a common added approach, you have an ability to have that conversation with your finance team, with your risk team, with the compliance team, and they can make the macro changes and policy setting changes you need to create more space. Is that where you wanna stop? Absolutely not, you wanna get to the point when the processes and the engines that drive your business allow your teams to move like that flotilla of little ships rather than the Titanic. But you’re not gonna get there in one step, all those things take time to unpick and to change and to make work.

Murray: So how do you work with procurement and finance to allow this sort of thing to happen? Because I find that procurement are often the drivers of traditional ways of working because they are insisting that you engage with all your partners on a fixed price, fixed scope. Which simply doesn’t work for software development or product development . We want to have new ways of working with procurement and with finance and often they just say no. So what do you do to bring them on board?

Peter: We need to be clear about what procurement are driven by. A lot of larger organizations they’re measured on cost reduction, and risk. So if someone puts in a proposal for a hundred bucks, if they can negotiate it to 80 bucks, or they do a statement of work and they get three providers come in and they go, choose the lowest one, in their mind, they’ve gone out with what they know. They’ve come back and chosen the cheapest supplier. They do the quality checks on the organization. They’ve actually done their job, why do they wanna fix price stuff? Because then there’s not just an open-ended ticket. There’s a, you will deliver X by that date. That is it. That’s our contract. If you want to change it, let’s have a conversation about it. 

Murray: Well, the Agile way would be fixed team, fixed time, fixed cost, variable scope with a goal, which seems to make procurement people’s heads explode.

Peter: Absolutely. Because they’d always start with, what are you gonna do? 

Murray: You do know the objective and you do know broadly what you wanna do. But what you’re saying is that we expect that we are gonna learn a lot about the requirements and the solution design as we go. In fact, we know for sure that the requirements and solution design that we’ve defined upfront are not gonna be what we implement. Maybe it’ll be 70% if we’re lucky, but that’s the starting point and so therefore we have to optimize for change and learning, not for this false sense of security upfront.

Peter: But that sense of security is what lots of the leaders are looking for, Because they need to know what is gonna be done by when, so they can announce the benefits, the savings, where the market’s going, what drops, what hasn’t dropped, all that kind of good stuff. 

Murray: But they don’t actually know. They’re just pretending that they know. 

Peter: That might be the case, but for whatever reason, the expectation on the leaders of today are to have a very clear crystal ball to know what profit they’re gonna deliver in 12 months time. 

Murray: Yeah. but what I just said isn’t contradicting that because I’m saying that if you did it with an agile way, you would say, here’s the things we wanna do. Let’s get some ideas on the size of this, and we’ll put an envelope around it, and a goal. But we’ll expect the details will change. There’ll be a lot of negotiation and shifting scope within this envelope.

Peter: When you have fixed quarterly earnings reports, you need to drive, and that goes from board down, the CEO, down, the cfo, down to the procurement. They’re gonna be really deliberate saying, what are you gonna give me and when are you gonna give it to me by, and it’s on that basis of gonna buy. 

Murray: Yeah. I understand that. I’ve done business cases. If you keep that at a high level, it’s fine. It’s just that what happens in projects is that people start at the high level and they first thing project managers do is turn the objective into an 800 page requirement specification, and then try and insist that you do that and only that, and then find, oh, actually we have to do something different, or it’s all gonna fail. 

Shane: We can do budgeting at a high level, that’s probably good behavior. But we’ve got some people that do dumb behavior, which is, gimme the line item of, which quarter are you gonna deliver that micro feature in your sprint. So I think we can do some dumb things or we can do some things well, and it’s the same within procurement and budgeting.

Murray: It’s got to do with how quickly you recognize that you’ve made a mistake and correct it. So let’s say the Victorian government’s Covid response where they put everybody in their hotels. They started getting told almost immediately that the air from one sick person’s room was going into another person’s room who wasn’t sick cause of the air conditioning system. They got told by nurses that the security guards weren’t following the infection prevention protocols and were fraternizing with guests. And that they weren’t able to take patient’s medical records or get them assistance. That all came out in the public inquiry on it.

And you know what? The government was super fast at getting that set up, which is great, but then they strongly resisted the feedback and they strongly resisted doing anything about it. So in an agile world, I would say we recognize that we all make mistakes all of the time, and the key is to learn and respond quickly. And what I see in big bureaucratic organizations is that they just learn and respond very slowly. 

Shane: So there was a retrospective on what went well and what didn’t go well, but had they actually changed their way of working, had they said when the next pandemic hits they gonna change what they do, or are they gonna go and use the same playbook? If you’re in a large organization and you are trying to change the way your organization changes, are you actually just doing the retros with no feedback loop after that to actually change the way you work?

Peter: The challenge you have in a lot of corporates is that adding a thousand teams, hundreds of them won’t directly interact with the customer. The advantage that product people have is that agile is almost a given because their feedback is so quick, particularly with online products. They can iterate so fast because they get really genuine feedback. Whereas if you sit in the heart of a corporate land it’s very hard for you to show the value you’ve delivered to the organization and the needle you’ve moved.? I believe that once you start to show people the value that they deliver they’re sensible, they’re smart, they’re good at what they do, they’re gonna just start to optimize to drive towards the metrics. 

Murray: There’s a lot of very smart people in senior management in these big organizations. I don’t doubt that. They tend to be very focused on their own position in the hierarchy, the power and status they have, and whether they’re achieving their own objectives though. So there’s a lot of optimization around what’s good for me and my department. 

Peter: Yeah, and someone in their wisdom has set the KPIs and objectives for them to drive this outcome for the business. And they’re doing exactly what they should be doing, which is driving towards their outcomes. Now, if you want to change the recognition, then that’s a different conversation, and that’s something we should absolutely do as part of the shift. 

Murray: Okay, so the big consulting company has been in, they’ve implemented this and they’ve gone away. On paper there’s been a lot of big benefits and big changes, but there’s a lot of things broken and a lot of people reverting back to old behavior. How do you fix things? How do you make it work?

Peter: It’s just talking to people and actually starting to understand the intent, the model, where they are at this point in time, the challenges they’re facing. It’s about understanding the culture of the people, what’s happened, and then being able to find what is the single constraint I need to change that would make life better for everyone. And it’s about hunting for that lever, and the levers aren’t always where you expect them to be.

Murray: Can you give us an example of one of those blocking decisions or implementations that you recognized was the core thing that was holding them up? 

Peter: So working with a large program of work and they’d been doing PI planning for quite some time and they had some inherent problems stopping the program from working. In, this case, it’s testing environments. Lots of large companies don’t like testing environments cuz they’re expensive. And all I simply did was actually having the team at the end of day one say, these are the problems and saying you leaders have to present back to everyone the next day what are you gonna do about these problems? And they thought about it. We got some actions. The next day one of the leaders she stepped in, said you told us these things, I am going to do this. And the crowd literally started clapping. Cause yeah, finally someone’s gonna do something about it. And this idea of the leaders supporting and unblocking their teams started to become real. 

Murray: I’ve seen before in big enterprises of the types that you work with, that if you go in and work with, a hundred people in a digital team and you do a retrospective to help them find out what’s blocking them, that you’ll find out a lot of things that their managers have caused or are refusing to talk about. A lot of things that their management could unblock but are not because for some reason it’s politically sensitive or it’s an outcome of a decision that they personally made. So yeah, I think the most important thing management can do for their teams and team of teams is to support them by helping them work out what’s blocking them, and then going and removing the blockers that are outside the team’s control. 

Peter: Yep. And the more data you build on what those things are, the easier it is for your leadership team to go, oh look, I need to do this. I need to make an investment this cuz this will change my metrics by X, Y, or Z. 

Murray: All right, Shane, I feel we should go to summaries. So do you wanna kick us off? 

Shane: I like the point that you made that people and agile teams seem to be happier and typically the outcomes of the organization are achieved when teams are happier. But we’ve gotta remember that the executives, the boards, they’re measured on share price and returns. Google and the fang type companies have more money to spend on making people happier and changing the way they work, whereas traditional organizations don’t. 

I love that term delayering the organization. I can see de layering has some interesting side effects. If you create a hole, the organism will reform itself and fill the hole. So by delayering the organization, you’re effectively making such a big brutal change that the organization has to change the way it’s working. Cuz it has no choice. I thought that was an interesting pattern. 

I like this idea that. We focus on teams and teams of teams but we don’t focus on that linkage between the team of teams and the organization. 

And I love that idea about weight loss. We want to change the way we are working, like we want to change the way we are living. And can we do that incrementally? Yeah. If we really do change the way we live. But often we do short term projects, we go on a diet. I’m gonna cut out all carbs for a while and then I’m gonna go eat fries because I love fries. It’s quite a good analogy. 

I thought the brutal statement that, the failure rate of IT projects many years ago was horrible. The failure rate of it projects now really isn’t much different. 

Murray: If you go and look at the research, it is better, particularly if you do small agile projects. The giant transformation projects are still as unsuccessful as they always have been. 

Shane: It’s better. But I’d really love to see the numbers of our return on the amount of money we’ve spent on changing the way we work. And the other one that, that you said it was just gold is how do you get a thousand teams to step to the right. That is a scaling problem. 

And so the last one for me is the advantages product people have is they have a direct connection to their customer. And therefore they have the ability to leverage that feedback loop quickly.

And so actually how many people at a board level or a C level have you worked with that actually go and talk to customers on a regular basis and see how the organization is impacting their most important asset? 

Peter: Some CEOs are renowned for calling their own organization and getting on hold and working through the process and trying to see, how that works. Some of the CEOs starts almost every town hall in conversations. I was talking to Mary, I was talking to John, I was talking, he or she, it is a customer, a small business, large business, whatever, and starts to frame that conversation. I think a lot of the senior leaders and boards wouldn’t talk to customers directly, but they would also have endorsed things like setting up product owners for lots of teams who they expect to talk to customers and their teams. And how many of those product owners actually talk to customers. Someone I know did a survey in an organization and one product manager hadn’t spoken to a customer for seven years or something. It was amazing.

Shane: All right. Murray, what do you got? 

Murray: Okay. So the core thing I wanted to focus on is the gap between executives and the teams doing the work and the customers. In my experience in these big organizations, there is a huge gap because there are so many levels.

If you are part of a program team that’s trying to deliver something, you are often being asked to do things that go against the objectives that you’ve been given. Because some executive has made a decision that you have to do something in a certain way without understanding what the impact is on people on the ground doing the work. So it’s very common for executives to be really out of touch with customers and with the people doing the work, and very resistant to hearing from them that the decisions they’ve made are having negative consequences and that they need to be changed.

They don’t want to do that cuz they’re living in a rarefied atmosphere where they’re listening to other executives and they’re listening to consultants and people trying to sell them things who are telling them that they’ve made the right choices. This gap is what drives a lot of the problems. 

When people are doing agile transformations at the executive level maybe the plans are quite good but when it comes to implementation, the plan does not survive contact with reality .

This is where I think an approach like mission Command is very valuable. There’s this idea coming out of NATO and the US military that it is inevitable that the plan won’t survive contact with the enemy. And so therefore, the role of a leader is to focus on objectives, helping their subordinate plan, providing them with the support they need, and then empowering them to make their own decisions once they engage with the situation.

And I don’t think we see much of this in executive teams. I think that there’s a still a lot of micromanagement and just follow the plan. Follow the plan. Follow the plan. Even if it’s not working. If it’s not working, what we’re gonna do is change the reports. 

And more fundamentally than that, there’s a real class system in organizations where the executives think, and the workers do. And you’ve got a lot of really intelligent workers now. You have all these engineers and software developers who understand a lot about the systemic problems in the organization and the impact of local optimizations. Agile and lean came out of that professional engineering community . But this class system is continuing. This bureaucracy is continuing and this factory model, I think is continuing in these agile transformations, and that’s what’s making them fail.

Peter: Certainly the mission command is a model that the Germans had in the World Wars that NATO’s reusing. So, this idea about leadership being about direction and intent and then leading the planning up to the team to do the work. And I think people would suggest that Ukrainians using that incredibly effectively to fight against a more traditional sort of command and control approach. Most people aren’t taught how to delegate but that’s how delegation is supposed to work, is we delegate the outcome, not just a task. 

I think the other point that you touched upon was around the executives outta touch. We need to recognize the pressure cooker that executives are in. I looked at someone’s diary yesterday and he had 13 meetings he was expected to have. They get allocated 15 minute slots or 25 minute slots and it’s just relentlessly, conversation after conversation. And they don’t actually have time to take a step back to reflect and to change how things potentially could work.

Murray: Yeah, I understand that. And the executive ranks are often gladiatorial political combat on a daily basis. It can be really tough. Your enemies are really hard to distinguish you’re all operating in that rarefied world where perception is reality.

I don’t underestimate how difficult it is, but it’s also the system that we’ve set up. I think if the executives are much clearer about objectives and outcomes, delegate more, focus on cross-functional teams, those organizations would get better results. And we know that because organizations like Spotify are doing really well, and Facebook, Google they’re all doing versions of Agile, even though they don’t always talk about it. And they’re doing really well. 

Peter: But remember Murray, everyone in those organizations, very few of them have progressed through the traditional hierarchal siloed structure. If you ask a young person today, you got a business idea, how gonna test it? Oh, I’ll put on Instagram and I’ll Snapchat, and I’ll see what they say. When I get enough orders, I’ll then order it. It’s incredible how fast they do it, because that’s how they’ve been brought up. 

But if you’ve spent 20 years in a larger organization, you had the financial rewards, the status rewards, the multiple investment properties and they’re going I’ve got 20 years of experience that says, I know what I’m doing. I’ve got all the financial status. If I bunker down for another , 18 months, I can retire. Why would I gamble on a change?

Murray: I understand that. I think agile is such a different way of working if you do it properly, that it’s probably very threatening to a lot of people’s status in the hierarchy.

Peter: I did leadership training for a bank at one stage, and everyone in this release , who managed over 200 people had to come along from my one day hear from Pete conversation. And one of the people actually said, so we go, agile what happens next? What do you mean? As a leader, do I just walk around and say, Hey, I’m looking for, impediments. Point me at an impedement to solve for you. Is that my job now? And the sense of dislocation that they had was so great. I said what do you normally do? It’s like this conversation. I normally talk to people. I coach, I provide support. I’ve been a banker for 25 years. I know this. I’m helping them do this. I’m gonna call customers. No. You gotta delegate toys to your team and go what do I do? What’s happened to me now. And you could see this sort of loss that they had was incredible. 

Murray: Particularly when the consultants have got a, objective of taking out three layers and you might be one of those layers.

Shane: We’ve had this thing come through that organizations pre 2000, are built on hierarchies. They have a certain way of working and it’s incredibly hard to change them. 

Murray: You are in the startup world. What happens if you get a banker with 30 years experience as an executive, come to help get engaged in the startup. They’re just gonna ruin it with process. 

Shane: Yeah. I listened to an interesting podcast the other day about when you start to become a scale up. How many companies bring in somebody who’s good at scaling at moving you from this to this because they’ve done it before and they know the playbook. And how many of them have their team intrinsically learned how to do that the hard way? And actually, do you end up being a better company if you use either of those techniques or those patterns? 

Peter: The third one, which is what we’re seeing through the recent economic downturn that’s gone through all the tech companies. A lot of the tech companies in Melbourne and Australia have hired people from big companies who are now implementing process. And this is what we used to do. This is what good looks like. And you’re seeing massive churns through all these startups as they’re try and impose more traditional methods of working. 

So that’s the third sort of option. One is that you get someone that’s done it before to advise. You try and, trial by fire. And the third option is hire someone in that fundamentally tries to make your startup organization look like a bank, a post office, a utility, or something like that.

Murray: Trying to make your hundred person fast growing, innovative startup look like a bank is just gonna kill it very quickly. 

Peter: But that’s what’s happening right now. They’re all gangly teenagers. Is the phrase that I heard yesterday and therefore we need to put more processes in place.

Murray: There’s been some fear sweeping through the startup community because interest rates have gone up, funding’s become more expensive, and seen Silicon Valley, they’ve been firing people.

Peter, how can people hear more about what you think or read your writing or your blogs?

Peter: So, the easiest way to connect with me is on LinkedIn. So it’s Peter Lam. I’m one of the few people that doesn’t actually have a profile picture anymore.

Murray: Yeah. And do you, write? 

Peter: Not as much as I should. I generally run meetups, that’s why I spend most of my time. So the Agile project management meetup in at Melbourne is the one that I run every third Tuesday of every month. Generally physical. Trying to build this human connection in Melbourne again. Join the group. We do the odd online meetup too, just to try and, support and connect with our members who are interstate and overseas.

Murray: Yep. All right. Good one. Thanks for coming on. We appreciate it.

Peter: Thank you gentlemen.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact Murray Evolve dot cove. That’s evolve with a zero. Thanks for listening.