# Why Do So Many Business Transformations Flop?: transcript Automatic transcript of the published podcast audio. Recognition errors are possible. Speakers are unlabeled; do not attribute a passage to Yuval or a guest without checking the audio. Episode: https://yuvalyeret.com/scaling-ai-podcast/why-do-so-many-business-transformations-flop/ Source RSS GUID: substack:post:169673329 Source: published Riverside RSS audio enclosure Transcription: faster-whisper base.en, English ## Transcript [00:00:01] Let's get real for a minute. Most transformations flop. [00:00:05] It's not because people are lazy or allergic to change. It's because the whole thing is usually forced from them. [00:00:11] Welcome to Scaling with Agility. I'm Yvall Yerax. I'm a management consultant, has been helping people [00:00:20] navigate transformations, whether it's agile product or AI for information recently. [00:00:27] I've seen way too often [00:00:29] organic pilots that create an island of transformation that works great, [00:00:34] but then someone declares, we're going to scale this and it becomes an imposed mandate. [00:00:42] The result is way too often or almost predictably resistance, [00:00:49] box checking, and a whole lot of transformation theater where nothing meaningful changes. [00:00:55] You might see vanity indicators like people trained and certified and you know I've been part [00:01:02] of that in the past. It's an optimal life training and certifying people and helping people [00:01:09] install tool templates like Jira rolling out a shiny new framework, but when you stretch the surface, [00:01:20] it's the same old organization. If we look for an example at the typical agile transformation, [00:01:28] you would have things that are cold stories, but there are actual technical slices that [00:01:36] teams use to manage their work and they still prefer to do everything that they need in a certain [00:01:42] area before they go up for air. You might see people called product owners, but it's actually [00:01:49] engineers and project managers that have been told you are now the product owner, but at best, [00:01:55] they own technical solutions and integrations, not customer outcomes. You need these people [00:02:00] in training workshops and they have a lot of good questions around we're not really empowered to [00:02:08] own a customer centric outcome. We can't really make a change in a product that our customers, [00:02:15] even internal customers care about. These people are really frustrated with the guidance that we're [00:02:21] trying to give that. What's happening here is that this organization, because it's mandated to [00:02:31] transform it a pace. People just slap on the new names, the new framework, [00:02:40] call it scrum, call it safe, call it whatever, as lipstick on a pig and hope it will improve some. [00:02:49] Or through some magic, they won't have as many dependencies and the spoilery is this approach [00:02:56] doesn't change much. In a this point, the leaders start to think that this whole transformation [00:03:03] is a sham that edge only is a sham that they eyes a sham that lean is a sham whatever and the search [00:03:09] for the next big big begins. Here's what I've found. Sustainable change doesn't come from [00:03:17] mandates. Maybe faster change comes from mandates, but it's not sustainable. Sustainable change comes [00:03:24] from treating transformation like an internal market. Instead of inflicting change, you invite [00:03:31] leaders and their teams to adopt new ways of working. You're trying to sell it to them. Think about [00:03:37] Jeffrey Moore's crossing the cousin approach. There will be early adopters. There will be laggards. [00:03:45] You will have these people in the organization. There would be people that will jump to try [00:03:50] your new approach. Typically, by the way, those are the dried in the pilot and made it work despite the [00:03:56] fact that it wasn't fully ready yet. When you take the thing that worked for these people and [00:04:04] copy and paste it to people that are the mainstream in your organization, that are looking for working [00:04:12] solutions. They don't want to find everything on their own. When you apply the solutions from the [00:04:19] early adopters to the mainstream, things don't work that well. And when you try to accelerate, [00:04:25] when you try to inflict this change, then it's even worse for these people. They're forced to use a [00:04:32] solution that's not working well for them. Whenever in mind gauge, we stopped enforcing these frameworks [00:04:42] and started showing teams how these practices could actually help. When we help them through a [00:04:49] wide conversation, why might this be useful? How might it be useful? When's the right timing for it? [00:04:55] How might we adopt it to our needs? When I started dealing or coached a transformation team to deal [00:05:03] with each different group in the organization, like I work with a new client. I cannot force a new client [00:05:11] to do something. All I can do is help them steer, help them navigate through what is it that we might [00:05:17] want to do. When we started to have these conversations internally, adoption took hold, [00:05:24] because teams started to apply practices and patterns that resonated for them. The day [00:05:34] had the agency around using it, you might think about it as treating the digital journey with the [00:05:41] agility or treating any sort of transformation. Empowering people, orienting around outcomes, [00:05:51] not rituals, giving people the optionality to figure out their own ways, aligning on the principles, [00:06:02] what does success look like, but not forcing people to use a certain set of practices. [00:06:13] So here are some principles to think about if you're tired of this [00:06:18] transformation theater that's so common around us. Focusing on outcomes, not rituals, talk about [00:06:26] outcomes, lead through outcomes, interest people in outcomes, not the rituals. The rituals might be [00:06:32] useful, but they're not why you're doing some. And don't do it as a ritual, do it because it's useful. [00:06:42] Even the language of rituals is creating the wrong mindset. [00:06:50] You want to consider whether it's useful for you and do it if it's useful and be better and better [00:06:58] at it build consistency and reps around it if it's useful, not because somebody told you it's useful. [00:07:07] You want to really think about how to organize around value. The fastest path to apply [00:07:13] in agile transformation is to just paste it on the legacy org chart, but that typically doesn't [00:07:21] allow you to deliver value, just reinforces dependencies and creates the need for more and more structure. [00:07:29] So if you have scaled up organization with a lot of teams, the pattern that you might [00:07:37] want to start with is to descale in order to create an environment where you [00:07:43] bring together real product teams, teams that are able to deliver value, give them the decision [00:07:49] rights that they need, the resources that they need, then give them the context, the intent, the [00:07:56] clarity on what is their purpose, what are they focused on. And that's where outcomes comes into play. [00:08:06] Structure your risky, high potential investments like experiments. [00:08:12] That's core to agility, but every transformation is risky. It has high potential, but it also has [00:08:20] risk of, is this the right thing for us? Are we thinking about it the right way? [00:08:25] So, structure your transformation as an experiment. What's the hypothesis? [00:08:33] What's the risk, its assumption in this hypothesis? How are we going to discover? [00:08:41] And you might say we've done a pilot and the pilot has proven that this works. [00:08:49] Now we're going to roll it out. But again, that's falling to go back to the [00:08:56] desirability challenge. It was maybe desirable by a small group, probably early adopters or people [00:09:06] at a very, very tough problem. You probably still need to validate that this change is desirable for [00:09:15] others. And the way to test desirability is not forced people to do this. It's too marketed to them, [00:09:23] to sell it to them, not forced. In an upcoming episode, we'll go upstream to identify one of the root [00:09:31] causes of this transformation's theater. But until then, you can ask yourself, [00:09:36] are you running a transformation or just putting on show? If you're curious to explore an alternative [00:09:44] approach, you can check out my scaling with agility free email course. Thank you for listening in [00:09:50] today. I hope you'll join me again for the next episode of this scaling with agility podcast. Bye for [00:09:57] now.