Why Do So Many Business Transformations Flop?

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/why-do-so-many-business-transformations-flop/transcript.md ## Published episode notes In this solo episode of Scaling With Agility, Yuval Yeret pulls back the curtain on why so many agile, digital, and business transformations, more generally, fail. Instead of doubling down on top-down mandates and theater, Yuval explores how to foster meaningful change by treating transformation as an internal market. From empowering teams to structuring change as experiments, this episode offers a different take on achieving real organizational agility for leaders tired of check-the-box change and looking to drive outcomes that stick. "You don't scale transformation by copying and pasting. You do it by treating it like a product, by validating its desirability and iterating." "Empower teams with agency and context. Don't dictate rituals; align around outcomes." "Sustainable change doesn’t come from mandates, it comes from treating transformation like an internal market." "Focus on outcomes, not rituals. Do it because it’s useful, not because it’s prescribed." "Real Transformation isn’t a rollout. It’s an invitation. An experiment. A conversation." "When you force a solution that’s not ready for the mainstream, you kill its credibility." "Ask yourself: Are you running a transformation… or just putting on a show?" Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As a Product/Scaling/Agility-focused consultant, SAFe Fellow, and Professional Scrum Trainer, he guides organizations away from process theater toward true product-oriented agility. He’s helped R&D, BioTech, Marketing, and Strategic teams evolve how they work and win. 🔗 Follow Yuval on LinkedIn Check out Yuval’s Insights on Scaling w/ Agility Why Do So Many Business Transformations Flop? – https://yuvalyeret.com/blog/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. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.