Why the Pivot? Tracing the Line from Scaling Agility to AI Impact

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-the-pivot-tracing-the-line-from-scaling-agility-to-ai-impact/transcript.md ## Published episode notes In this special episode, host Yuval Yeret flips the script with guest Philip Morgan, an expert on positioning and point of view. They discuss the recent rebranding of the podcast and dive deep into the striking parallels between historical Agile Theater and the emerging risks of AI Theater. Discover why measuring raw activity, like tokens consumed or lines of code written, is a trap, and how organizations can shift toward measuring tangible business outcomes and flow efficiency. You'll also learn about Unreasonable Agility and what happens when R&D goes on the offense. Chapters 00:08 The Agile Shift in AI and Podcast Rebranding 01:07 Philip Morgan's Background in Positioning 02:36 Yuval's Role as a Plumber for Engineering Pipelines 06:53 How Pain and Opportunity Drive Change (Gillette & Biotech Examples) 15:51 Introspective and Compound Engineering 17:08 Exploring AI Theater vs. Agile Theater 21:44 Shifting Bottlenecks: From Coding to Code Review and Adoption 28:04 The Trap of Vanity Metrics and Token Maxing 33:26 Moving from Output to Outcomes and Business Impact 40:50 Breaking the Status Quo and Resisting AI Mandates 56:21 Unreasonable Agility: Taking R&D on the Offense Notable Quotes "If you want to succeed with it, find somebody who talks about the principles, who understands it in depth, who can make changes while still being aligned to the spirit." - Yuval Yeret "People will find a way to use AI without really getting any value. They will find a way to generate a lot of activity, but not really create any change in the impact." - Yuval Yeret "There's a sense in which it seems like Agile was sort of waiting for AI." - Philip Morgan Ready to stop measuring tokens and start measuring real business outcomes? Reach out to Yuval at yuvalyeret.com or yuval@yeretagility.com to discuss how to build unreasonable agility into your organization. About PhilipPhilip Morgan is a positioning and point-of-view expert who helps independent service providers thrive by leveraging effective market positioning. He is the author of multiple books on the topic and shares his insights freely at ⁠philipmorgan.net⁠.Scaling AI: From Activity to Impact , yuvalyeret.com The Scaling w/ Agility Newsletter – yuvalyeret.com/insights Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/ Agility Might Have Been Waiting for AI – https://yuvalyeret.com/blog/agility-might-have-been-waiting-for-ai ## 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-the-pivot-tracing-the-line-from-scaling-agility-to-ai-impact/ Source RSS GUID: bd32805d-76c6-45a1-ae81-2bc7e17774c1 Source: published Riverside RSS audio enclosure Transcription: faster-whisper base.en, English ## Transcript [00:00:00] AI is forcing everyone to be very agile about who they are, what they do, [00:00:04] what impact can they make, and how they're perceived. [00:00:08] Hi, I'm Yvall Yerit, and today on the Scaling AI from Activity2 Impact show, [00:00:12] we have a special episode for you. You might have noticed that I recently rebranded the podcast [00:00:18] from Scaling with Agility to Scaling AI from Activity2 Impact. [00:00:22] And today we'll talk about that. I've recently been having fascinating conversations with [00:00:28] Philip Morgan. Philip is an expert on positioning and point of view, [00:00:32] and I invited Philip to the podcast to chat with me about this shift. Welcome, Philip. [00:00:38] For my listeners who don't know who you are, can you share a little bit about yourself and your work? [00:00:44] Yeah, thank you. You've all glad to be here. Most of my public work has been about positioning [00:00:49] and point of view. So I've become a marketer. I used to be sort of a tech guy back when [00:00:56] servers were, like Unix was nothing, and everything was Windows servers and novel servers like that [00:01:04] era. And I've gotten into marketing work, became very interested in how positioning and point of view [00:01:09] work. So I've published some books on those topics. All that stuff now is available for free on my [00:01:15] website, Philip Morgan.net, just one Allen Philip. So I'm someone who really wants people out there in [00:01:21] the market who are independent service providers, like yourself, you've all to make things better [00:01:28] for themselves by taking advantage of these tools that I think of them as tools positioning [00:01:33] and point of view. So that's about as brief as I can make it. That's who I am. And that's what I do. [00:01:39] Cool. All right. So let's dive in. [00:01:42] Okay. So some list that I'm going to be interviewing you, you've all, and some listeners, [00:01:47] I'll promote this to folks that follow me on LinkedIn, that kind of thing. So there's a chance [00:01:52] that some folks will be hearing about you for the first time. Who are you? [00:01:59] So I often say that I'm a plumber, and not because that's maybe it is the future, the profitable [00:02:07] future for us knowledge workers when AGI is here. But no, I found myself over the years, [00:02:15] whether it was in the Israeli Air Force back in the 90s or [00:02:21] leading engineering teams, building engineering systems or over the last almost 20 years at this [00:02:29] point, helping leaders improve flow in their engineering pipelines and eventually outside [00:02:38] of engineering and marketing sales throughout the organization. It's like plumbing. It's [00:02:43] sometimes things are stuck. Sometimes there's a bottleneck. Sometimes there's a very [00:02:52] ugliness on the floor that you need to clean up. And whatever the context I come and help organizations, [00:03:01] and I do that much better than I do real plumbing. And that's because I don't do real plumbing that [00:03:07] well. And specifically, if you look at the tools that I use as a plumber, [00:03:14] those are tools like agile, flow, Kanban. And most of the time, I help organizations apply [00:03:22] these techniques in spaces where they haven't been used before. So kind of on the frontier, [00:03:29] whether that's using agile techniques to design and launch razors at Gillette, their flagship launch [00:03:38] a couple of years ago with a Super Bowl ad was designed using agile techniques across commercial [00:03:47] R&D manufacturing. That's one example. Other example is organizations that were using AI before [00:03:56] gen AI and machine learning to engineer essentially beneficial viruses. That's the layman's version [00:04:05] of what they talk about. I don't understand the details of what they're doing with cap seats, [00:04:10] but it's about tech firm that is trying to improve flow of research and discovery and commercialization [00:04:19] and involves people in the lab, outside of the lab, in the wet lab, in the dry lab, in GNA, [00:04:27] all of them trying to work better together to achieve success and impact and grow the company. [00:04:35] So it's different places, not the usual places where the bite of book approach doesn't work. [00:04:40] That's kind of what I've been doing and writing about for my years. [00:04:44] I go into these interviews with a rough sort of high level plan of what we might talk about, [00:04:51] and then you say things and I'm like, that is so interesting and I get a little bit pulled off [00:04:56] my plan. So here's that happening. You're agile, Philip. That's the nice spin on it. Thank you. [00:05:03] I think some people so agile at this point is such a such a note, it's like such an institution, [00:05:09] if you will, that that's probably the reason a lot of organizations adopt it and you're talking [00:05:16] about cases where that's not the reason it's adopted. It's not adopted because, well, that's just the [00:05:21] thing you do or we want to have the agile brand stamped on this department or this initiative or [00:05:27] whatever. And so I'm curious, in cases like that, how do you get buy in for agile techniques? [00:05:35] Let's talk about that Super Bowl, that where this is going to be done in an agile fashion, [00:05:41] not because we want the agile brand, but because we want the results. [00:05:45] Yeah, so I think they, to be honest, most of my engagements have been this sort of stuff, [00:05:51] but maybe I've had it easy. But in the case of organizations like Gillette, it typically goes like [00:05:58] this. They were trying something that they were very good at up until that point. So David talks [00:06:08] about this publicly, David is the leader at Gillette, the R&D leader at Gillette that reached out. [00:06:13] In his words, they were experts in building things using waterfall, using sequential phase [00:06:22] thinking things through, doing the full thing in R&D and when it's ready, moving it over to the [00:06:28] commercial organization. And they had a huge failure, essentially, with a program where that was [00:06:35] the approach. They built something and they showed it to the commercial organization. And they said [00:06:43] that's great, but I don't think we don't think we can sell it to Costco, Target, Walmart, whatever, [00:06:50] are channels because there's a certain pricing where it can work. And at that point, David realized [00:06:58] that instead of using relay race, they need to start to play a different game and involve commercial [00:07:05] and R&D along the way. He heard about Scrum, Scrum was being used in the bigger Procter and Gamble [00:07:12] as an agile approach. And he was pretty set on that's what we want to do, at least at his level and [00:07:19] his senior leadership. But the recommendation that he got was it's not going to work out of the box [00:07:25] for you. There's a huge risk that if you take Scrum literally, out of the box, out of the guide, [00:07:34] and apply it, it would become a theater. It would become mechanics, ceremonies, and you would be able [00:07:42] to say that you're doing Scrum, but it won't really make a difference. It might actually make things [00:07:47] worse. If you want to succeed with it, find somebody who talks about the principles, [00:07:53] who understand it in depth, who can make changes while still being aligned to the spirits. [00:08:01] And that's how he found me. And that was what we were focused on. From a buying perspective, [00:08:08] they had a huge problem. Leadership wanted a flagship launch. The timeline that they had for it, [00:08:16] that this point was much shorter because they had burned through some of that time in the previous [00:08:22] program. So the old way of doing things simply couldn't work to make the impact that they needed [00:08:28] to make in the business of companies like Gillette, who essentially invented the [00:08:37] blades and razors, literally invented the blades and razors business model every couple of years. [00:08:42] They need a new system because of patents and whatever. So it was a huge business at stake [00:08:50] that they had to do things this way. Interesting. Is pain usually the driver of openness to doing [00:08:58] things differently? At least when it comes to, oh, we'll consider agile when we previously had a [00:09:03] different way of working. There's also another scenario that's biotech firm that I talked about, [00:09:08] it wasn't pain that was driving them. It was opportunity from their perspective. They [00:09:15] were scientists. They were exploring better ways to build things, to build the company. And [00:09:27] from their perspective, there was an interesting potential to rethink some of the classic discipline [00:09:35] of this scientist that has assistance in the lab and the silos in the typical biotech firm. [00:09:44] And they were thinking, what if beyond designing new DNA for people, could we design new DNA for [00:09:53] the company and what role could agile play in that? That's the essence of, I mean, I never asked [00:10:00] them that way and maybe you should ask them why did they use agile, but that's my interpretation [00:10:08] of what was the driver there. And they, by the way, tried the mechanical agile first and that was [00:10:14] the pain. That's interesting. The mechanical agile didn't work that well for them and then they brought [00:10:19] me to help with shifting their agile from activity to impact. That's interesting. They were willing to [00:10:27] take more than one iteration of trying something before. Yeah, they literally called it their [00:10:33] agile V1 and we were working on agile V2. And then we worked on agile V3. It wasn't fixed. It was an [00:10:42] evolving, I mean, in general, I see ways of working kind of like software. It should be evolving. You [00:10:50] should develop it as a product. You should deploy it as a product. Maybe we'll get to that [00:10:55] later. Yeah. Is there a rule of thumb for how often you should reinvent? Maybe it's too strong of a word, [00:11:04] but you know, enhance the system. All continuously. Okay. I've heard the term recently yesterday, [00:11:12] which is called I think Compound Engineering. I don't think we've talked about it. Compound [00:11:19] Engineering is essentially, if you think about the development lifecycle, especially with AI [00:11:26] agents these days, as a human, you don't need to be involved that much in the coding or even the [00:11:33] testing, hopefully even in the code review. But maybe you need to do some of that. But the most [00:11:40] important thing that you should do is reflect at the end of developing a spec, a PR or whatever. [00:11:48] Is there anything that we've learned while doing this? Is there anything that we caught in the code [00:11:53] review that we should now feed into the constitution, into the guidance, the standing guidance that we [00:12:00] think into our operating model, our ways of working, whatever that is for humans, for the agents, [00:12:09] and that's where you really get the value. So that's the process of continuously sensing and [00:12:16] responding to what's effective about how you're working, how you're structured, whether it's in [00:12:22] engineering or at the company level and improving it. Then sometimes it could be a small evolutionary [00:12:30] change. Sometimes you do need to reimagine because you're stuck at the local optimum until you really [00:12:37] reimagine it, you won't get to where you need to be. I want for some reason, I want to call that [00:12:42] introspective engineering. But anyway, labels aside, okay, you have renamed this podcast and [00:12:49] I'm wondering, this is the very unkind way to put this question, but are you just jumping on the AI [00:12:55] bandwagon? I think it's an interesting question for the listener and for you to reflect on after [00:13:05] this podcast. You're saying the listeners can decide if you're just jumping on the side. I mean, [00:13:11] if I say I'm not, then you know, it's me saying I'm not, I think it's through the, at least what [00:13:18] I'm trying to do is not make it just a rename because everybody is now in the AI transformation [00:13:26] coach and AI coach, AI enablement. That's, that's all over the place. What I've been, what I've been [00:13:34] seeing in my work and what I observe in the landscape around me, what I see in organizations, [00:13:40] when we work on AI adjustments stuff over over the years and work that's done related to AI adoption [00:13:50] more recently is that there is a lot that is common. There are a lot of patterns that I've seen [00:13:58] over the years in my work on improving development life cycles and how companies work that is even [00:14:07] more relevant these days in the world of the of AI. I think I'm jumping and interrupt, which I have [00:14:16] an terrible tendency to do. I'm glad I have it as well. Yeah, it'll go both ways, I'm sure. So [00:14:24] like what's that, what's an example of that, that parallel that you see between AI and, you know, [00:14:32] the agile stuff? So one is the there's theater in both places. So we've talked already about the [00:14:39] fact that some organizations focus agile on activities and outputs and they measure story points [00:14:46] and velocity and they do a lot of hoo-ha ceremonies and you're starting to see that with AI, [00:14:53] you're seeing token maxing in people that are measured based on how many tokens they use and [00:14:59] if they don't use all of the tokens by the end of the month, then they will get less tokens the next [00:15:04] month and they will be on some lists where, you know, they won't be considered a 10x underdex employees [00:15:12] and there's an interesting jumping to conclusions here. Well, which kind of reminds me the South Park [00:15:20] episode about the underpenned gnomes, which is, you know, step one, we use all the tokens. Step three, [00:15:27] profit. But many organizations don't really know what step two is. They don't really make the [00:15:34] connection between all of this activity that we're seeing and really impact on the bottom. [00:15:39] Some of them are going ahead and laying off thousands of people without seeing the impact of AI. [00:15:47] That's a different story. I don't think that's related to the impact of AI. It's just recovering from [00:15:54] some dynamics that we've seen in the business world after COVID. But AI theater definitely has [00:16:01] a lot in common with the agile theater that I've been seeing. And another, I would say, [00:16:07] even more concrete pattern is bottlenecks. So I mentioned that I'd be sort of a plumber [00:16:14] and in one of my first engagements as an agile coach back in let's call it 2010 or so. [00:16:22] I was working with a group at a very large computer technology firm, two-letter computer technology [00:16:31] firm at the time. Starts with an agent, finishes with a P and in that group, they were looking to [00:16:39] implement agile and improve. But they were looking at Scrum. But one of the things that we very [00:16:45] quickly noticed was that they had a difference in capacity in throughput, in output between the [00:16:53] development organization, the developers that were building features, and the testing organization. [00:16:59] At that point in time, the teams were still not combined. It was before the notion of [00:17:06] empowered product teams that were able to test everything was a reality, even in an organization [00:17:13] that builds software testing products. And one of the early insights that we've had once we [00:17:21] modeled, showed this information on flow diagrams, cumulative flow diagrams, was that this gap is [00:17:28] happening and it doesn't make sense to focus too much on improving the development throughput. [00:17:37] It makes more sense to focus on the bottleneck, which is the testing. What that means is not [00:17:44] necessarily writing the testing organization harder. What it means is subordinating the whole way [00:17:51] we were working to this fact. The testing is a high overhead activity, even if you're making [00:17:58] a small change in a complex system. Because at the time, regression testing wasn't fully automated [00:18:04] and required unique servers and whatever. That was the du jour challenge of the era. [00:18:15] Some of the listeners are probably familiar with that. But the same pattern is something we're seeing [00:18:22] today. If you look at the AI coding, organizations that are starting to explore or even dive deep [00:18:28] into an agentic software development life cycles, or AIDLCs, whatever you want to call them, [00:18:37] they're seeing that even if their bottleneck was engineering or coding, the bottleneck is not [00:18:46] there anymore. The coding step is, let's say, 10x faster, but you don't necessarily see 10x [00:18:57] throughput at the end of the development life cycle. For sure, you're not necessarily seeing [00:19:02] 10x impact because a feature that you build is not necessarily a feature that delivers value. [00:19:08] And the more features that you build, actually the fewer of that can deliver value, or it doesn't [00:19:16] necessarily grow linearly, because there's a different bottleneck. The bottleneck might be in [00:19:21] code review, it might be in coming up with the right features, it might be in adoption of these [00:19:26] features, it might be different places. But the thinking of looking for bottlenecks and orienting [00:19:34] your work around these bottlenecks, rather than focusing on the local optimum of a certain function, [00:19:40] that's something that was very useful in the in the age of days was actually much was one of the [00:19:48] most useful interventions that went beyond the Scram mechanics. For many years, that was what I [00:19:55] was focused on. That is a very useful intervention, or at least a perspective today that I don't see [00:20:04] enough organizations and enough leaders looking at. If I'm interrupting a longer list of parallels [00:20:12] between Agile and AI, let's come back to that list. But I want to ask one of the most devastating [00:20:20] criticisms of AI in general that I see is as follows. Show me the new features. Show me the new [00:20:27] capabilities. So this is aimed at like SaaS software, where some SaaS companies have big [00:20:34] public layoffs recently, and I think this criticism has come in response to those layoffs. If your [00:20:40] engineers are so much better, where are the new features? Where are the new capabilities? Where's [00:20:45] a new market share in your product? And is the moving bottleneck phenomenon that you're talking [00:20:51] about a response to, does it support that criticism? Or is it really kind of criticizing the criticism? [00:20:59] No, I think it's 100% aligned with maybe not 100%. I think a lot of that criticism. [00:21:06] Again, the fact that companies are laying people off, I think is unrelated. It's not because their [00:21:12] business is doing so great that they're laying people off. It's just tech grow, talk and the sort [00:21:19] of thing that's expected from some of these people. But the reality is that if you look at [00:21:26] some of these companies, and you look for what value have they found in their product, [00:21:36] how have they managed to turn all of these AI outputs, potentially, I output into impact, [00:21:43] they haven't managed to. So there is a bottleneck. And there are many, it's not a controversial thing [00:21:52] to say there's a lot of research and examples of the fact that we don't necessarily see the impact. [00:22:00] Part of the challenge, by the way, is that most organizations have never measured things this way [00:22:08] because it's hard, right? We are very good at measuring activity at one of my clients [00:22:14] a couple of years ago. We were talking about improving flow and looking at flow metrics. And [00:22:19] as we were doing that work in one division, one group that was very into these things, [00:22:26] the bigger organization was doing an engagement with one of the big consulting firms, one of the [00:22:32] MBBs. And they showed me the list of metrics that they got as a recommendation [00:22:39] from those consultants from the suits. Can't wait to hear what this is. [00:22:46] One thing on that list was lines of code. Lines of code written, yes, yes. Wow, okay. [00:22:54] Yes, it was a bit before COVID, but it was in the last decade. So I was shocked. But maybe I shouldn't be [00:23:05] because it's so hard to measure the impact of what we're building that were tempted for these vanity [00:23:12] metrics for the activity, were tempted to measure lines of code hours worked to measure, you know, [00:23:22] plan versus do to measure how many tokens people use, how many people are using their [00:23:29] plot code or co-pilot or Slack AI, but whatever, how many days a week do they use these things [00:23:38] and how many agents can you run? How many agents are you running in parallel field? [00:23:42] The more agents you run, the more bragging rights you have, right? And that's easy to measure. [00:23:50] It's harder to measure the output that you're creating, but it's possible, right? It's possible [00:23:57] to measure, you know, how many features are you creating? How many articles are you publishing? [00:24:03] You've all how many skills are you creating on the podcast? Are you publishing? It's possible to measure [00:24:10] even, you know, how many listeners I have and how many followers I have, it's much harder to [00:24:17] measure my impact on the world. It's much harder for a product team or an internal team that's [00:24:24] supporting to organization to understand what impact are we making in general and even harder [00:24:31] each small thing that we do, what's the impact of that thing? Because it's so hard to measure, [00:24:36] we often measure the output and the activity. Here's an attempt that I fear over simplifying that [00:24:43] is impact more qualitative in nature, while activity can be more easily quantified. [00:24:49] Or is that? No, no. Okay, I'm missing it. Well, so if you, the way I think about it, [00:24:56] there's actually something in between impact and output. So let's think about a software development [00:25:03] team that's working on a product activities, they're working on the product, right? They're doing [00:25:09] something, they're coming to work or opening their machines, they're using AI. Let's use the [00:25:14] AI example there. They're using AI in their work. They're consuming tokens, opt to it. In the world [00:25:23] of the GitHub, GitLab, whatever, they're creating code, they're creating PRs, pull requests, and [00:25:33] that's the output of the coding step, okay? That's still not good because a PR that's waiting to be [00:25:42] merged is useless, right? It's just inventory in the system. That's what the theory consensus is. [00:25:50] Eventually, if the PR is merged and released and it's something that is available for the users of [00:25:58] that product to use, you could consider that end-to-end output. In outcome, you could say it's more [00:26:05] qualitative. It's, has it changed the behavior or enabled new ways for the people that are using the [00:26:13] product to use it? Easy driving behavior change. Ideally, the behavior change that we intended it to [00:26:21] have. A lot of the time we don't even talk about that when we're building software, so it's hard to [00:26:27] measure when you don't even set out to achieve an outcome. That outcome ideally is something that [00:26:34] you can quantify. For example, if one of the things I noticed on some of the AI coding harnesses [00:26:42] recently is the ability to sort your threads according to their state. It tells you this is [00:26:54] blocked. It's waiting for you. This is running in progress. This is something that's, that's definitely [00:27:00] output. The fact that this showed up on my coding harness, but an outcome would be if it changed the [00:27:06] way I behave. For example, one thing I would measure as a flow from a flow perspective is did that change [00:27:14] reduce the idle time or the block time of sessions that we're waiting for for feedback from the user? [00:27:22] Because I think that was the intent that they had in mind. That's the qualitative outcome is [00:27:30] I feel like I get more done. I feel like I'm more focused. I feel less confused. There's less [00:27:36] cognitive load of where my different sessions are going. From a quantitative perspective, I can measure [00:27:43] the flow of my sessions and how my flow efficiency looks like. Less time blocked, less time idle waiting [00:27:52] for me compared to the overall time that it takes. Impact would be turning that into money or the [00:28:01] bottom line business effect. It doesn't. It isn't always money, but hopefully the fact that I'm more [00:28:08] effective, my flow, my zone of AI usage is more effective. I'm creating more value for my business. [00:28:17] That's a big leap that's often hard for for teams to establish, which is what a lot of time [00:28:23] we focus on outcomes rather than the business. Okay, that was really useful. Thank you for that. [00:28:29] Okay, so kind of backing ourselves out of this to me anyway, fascinating rabbit hole. I think [00:28:34] the listeners too. So you were talking about some of the parallels between the tenets of agile [00:28:41] and what you see in the AI world. Was there anything else on that list? [00:28:45] So I think this is what we talked about just now is another parallel, not necessarily between agile [00:28:50] but between product thinking and AI models. A lot of my work with organizations in recent years has [00:28:58] been not on the mechanics of agile but more on shifting towards orienting around outcomes. [00:29:04] What's the right way to find leading indicators initially to orient work around goals rather than [00:29:14] you know, activities to enable probing, sensing, responding using these sort of goals as a way to [00:29:22] enable agency for teams and how to scale that agency. In the AI world, it's both the same sort [00:29:30] of challenges because to be honest, a lot of organizations didn't reach the mode where they have [00:29:37] empowered teams and individuals that are goal oriented that can, you know, react and [00:29:44] sense and respond and move fast. So they still need to work on these things in order to really [00:29:48] leverage AI because AI enables you to move faster but if you don't have [00:29:53] empowered teams, they cannot move fast. So at the minimum, that's that but when you start to talk [00:29:59] about the genetic development and the fact that you have agents that can go and do things, [00:30:07] you start to see that those agents also react better and perform better when you shift them from [00:30:14] to this activity for me to build this output for me to achieve this goal for me. [00:30:21] I've recently been playing with slash goal, which is an option that's available on the coding [00:30:29] harnesses and exploring what can you do with it. And you can see that even in the examples that the [00:30:38] frontier labs are giving that anthropic is giving for how to use these goals, [00:30:45] they are focused on output, they are not focused on customer outcomes. And I think there's a [00:30:51] fascinating challenge, both from a technology perspective, how do you create agents that can [00:30:59] achieve outcome oriented goals? What do you need to give them in order to do that? What [00:31:05] things do they need to observe to manipulate? What tools do they need to access? Like what the [00:31:11] lint or linter that enables agents not just to say this code looks good and works well and passes [00:31:22] all of the repository quality criteria but also is driving some useful behavior for our customers. [00:31:32] That's the technical side of AI adoption. The human side is how as humans, whether it's the [00:31:38] engineers, whether it's the product people, whether it's people that are doing using co-work or [00:31:47] applying AI elsewhere in the organization, can we learn to speak in outcomes so that we can [00:31:55] give agents the right level of agency? We shouldn't be focused on activities as humans, [00:32:02] we should be focused on outcomes. That's the level of intelligence or that's the right way, [00:32:10] I would say. That's what I believe. It's maybe even some sort of mission of driving people to the [00:32:17] level where they have the right level of interest in what they do, agency around what they're doing, [00:32:24] and they're not doing routine work, they're not running the activities, they're constantly [00:32:31] developing and evolving and improving the things around them, including specifically the agents that [00:32:38] serve and that they can offload or delegate to all of the others. [00:32:42] There's an interesting thread that I think runs through a lot of what we've talked about and [00:32:48] it seems to me that I'm thinking of it in this way. How do you get a group of people to depart [00:32:56] from the status quo and specifically in a way that improves things, but this idea that [00:33:05] a status quo kind of takes hold in some context and the status quo gets to where, [00:33:12] maybe it starts out as a maladaptive status quo or it becomes one that just doesn't serve [00:33:19] what that group of people or the larger organization wants to achieve or where it wants to go. [00:33:26] So there's a couple questions related to that. One is AI is quite new. I mean, the heavy use of AI [00:33:33] in organizations is relatively new. Just measured in, I would say, the time span of like two years. [00:33:42] Maybe, maybe a little longer in some organizations, but not much longer than that. [00:33:46] And yet we seem to have arrived at something that appears like a status quo. [00:33:50] It updates maybe more frequently than most status quo's do or status's quo anyway. [00:33:59] What do you say? What about it looks to you like a status quo? [00:34:04] The what's the fancy word for this? I don't know. What's the plain word for this? [00:34:09] The surrender to, well, this is just what you do. You get AI and you make more stuff with it more [00:34:17] quickly or you. So that's a facet, I suppose, of the status quo is like, oh, we can ship or deliver [00:34:23] code more quickly or with less human oversight. So I could imagine and I'm thinking of Andrew [00:34:31] Carpathy talking about just like in six months going from I really only use AI as a line level [00:34:40] auto complete in my IDE to much more recently saying, yeah, I just tell it what I want to let it [00:34:47] write the code. I'm simplifying something that I know he said, but that's a pattern that I see [00:34:54] that seems like I sort of surrender to a particular status quo. And I don't think that's where it comes [00:35:00] from for him. But I think for a lot of organizations, it does. And I'm really what I'm curious about [00:35:07] here, you've all is how do you help clients depart from the status quo in an intentional way to go [00:35:13] where they really want to go? What do you see happening? I mean, I would phrase it as the status quo is [00:35:19] that there is no status quo for organizations that are really pursuing potential of native AI. They [00:35:28] were realizing we need to think about ourselves as a product and apply engineering principles and [00:35:37] run iterations very quickly to what's working, what's not working. And I think that makes sense. I think [00:35:44] changes, the only constant is how you need to be treating this. But I'm also seeing organizations [00:35:52] that are not going through these cycles that are not going through these cycles at the pace that [00:35:58] they would need to if they need to survive and not to say thrive. What I've seen way too often, [00:36:06] and is another repeating nightmare dish of the pattern, the mandate or inflict motion, [00:36:14] which is AI is the new shiny object. We have to do AI. We give AI harnesses whatever they are to [00:36:24] all of our people. We give them tokens. We expect them to use up until a couple of weeks ago that [00:36:32] didn't cost as much now. There are some questions, but we'll just expect everybody to token max and [00:36:41] we'll measure token usage and that would be we are using AI. And part of the dynamic in that is [00:36:47] that when you inflict AI on people, when you mandate AI usage, it's kind of similar to inflicting [00:36:56] early quality movement ideas where people, somebody mentioned this to me the other day literally, [00:37:04] that it feels like they're sitting on a branch and they're very busy cutting, sawing off the branch [00:37:11] that they're sitting on for their employer at the big tech firm. And that's common, right? That's [00:37:19] the reality. And especially when you combine mandates and infliction and these sort of changes, [00:37:27] people are very smart. They will find a way to use AI without really getting any value. They [00:37:34] will find a way to generate a lot of activity, but not really create any change in the impact. [00:37:42] Maybe they'll even create a lot of outputs. [00:37:45] But kind of a good arts law, the measure becomes the target. Yeah, exactly. And you combine that with [00:37:51] the fact that you think about Densheeper, I think, talk the other day, somebody about the [00:37:58] the sabotage manual, something along those lines, the manual that the allies gave resistance, [00:38:08] you know, during the NASA regime, how do you continue to come to work and, you know, resist as an underground [00:38:16] and a lot of the time when they look at what's happening in organizations, it kind of feels [00:38:20] like that. Both with the agile theater wall, as well as with AI theater, AI theater caught up [00:38:28] very quickly to something that took a decade in the, in the agile wall to happen. And, you know, [00:38:35] that's the reality. AI is much faster about everything. But the alternative that I've seen [00:38:40] work in the agile space that I believe and I'm starting to see signs of signs that it actually [00:38:47] works better in the in the AI space as well is to invite people to change. [00:38:52] Rather than tell them you have to use AI tools and you have to shift appeal to their intrinsic [00:39:00] motivation. People are motivated by autonomy, or let's say agency, by mastering something [00:39:08] and by being connected to the purpose. And there's also the Maslow hierarchy of care about what [00:39:15] they're worried about what, you know, what are they striving for. Organizations that are [00:39:23] thinking about AI as a product that is there for the people to use. Now, that's something that [00:39:29] the organization is telling people, but is there for people to use to make their job better, [00:39:39] to make them enjoy their work more, feel more connected to the organization. And to acknowledge [00:39:45] that people might not want to use AI, maybe even ask the question, would you care if you got to use [00:39:53] Cloudco tomorrow? Or if you don't have access to Windsor for Devon or co-pilot tomorrow, what, [00:40:00] how would that make you feel? Organizations are not asking that question often enough. [00:40:06] And they're not designing the AI intervention as a product. If they were, they would be measuring [00:40:13] different things. They would be measuring things like awareness of people, activation, real retention. [00:40:22] Do people refer? Do people create skills and share them with others? Are they becoming [00:40:28] evangelists of all those AI tools internally? And if you realize that an organization is a market, [00:40:35] and it operates like a market, and you look at things like Jeffrey Moore's crossing the [00:40:40] chasm, you realize that, you know, some people would react better to waiting with the AI adoption, [00:40:48] not just jumping on board right now. They need to see others succeed. They need, you know, [00:40:53] better solutions. Others won't jump ahead, but you cannot use what's working for the people that [00:41:00] jump ahead by an ears and give that copy paste to all of the others. And to expect that you have [00:41:06] 10 pioneers or 100 pioneers, and then the thousands of people behind them will do the same thing, [00:41:12] be as effective as motivated that typically falls flat. Yeah, another status quo question [00:41:23] is, let's say there is some at the leadership level, some openness to question the status quo [00:41:29] and change it if need be. Is there, I'm thinking of this as a theater diagnostic question, right? [00:41:36] Like, you know, we think about people whose lives are not on a good track and they get some kind of [00:41:40] wake up call or maybe, just maybe they say, maybe my life is not on a great track here, and they have [00:41:47] this self awareness moment. Anyway, is there, are there ways that organizations can become [00:41:53] more self aware about whether they have fallen into a theater kind of status quo? [00:41:59] Yeah, so I've been thinking about that for a while in writing about it, and I even have [00:42:06] one of these, you know, self assessments of are you a theater? Are you a feature factory? Are you [00:42:14] an impact lab? One of the simple questions to ask is what do you measure? What are you measuring? [00:42:22] What's the goal of what you're trying to do? Another is do people have to use this thing? [00:42:29] Are you willing to ask people the PMF product market feet survey question, Sean Alice's question, [00:42:37] what would, what would happen if, you know, your product, your change disappeared overnight? [00:42:44] Would you be disappointed? Are you willing to even ask that question? That's a very simple [00:42:50] question that is frightening for a lot of agile leaders to ask and a lot of AI leaders to ask [00:42:57] themselves, because they're not designed to, they're not currently designed around this [00:43:02] around this change. I guess I saw someone very jokingly, actually, I don't know how much they [00:43:09] were joking, but it seemed like it might have been a little bit of a joke. They, they proposed [00:43:13] this as maybe on X, which is sort of my main social media channel for the most part. They said [00:43:20] Microsoft Teams should have a feature wherein if more than 50% of the people who were on any [00:43:26] given meeting vote to end the meeting, it just automatically terminates the meeting. [00:43:31] That's a good idea. That's a good idea. But yes, we all love it. But there's something, [00:43:36] there's something real there that you're getting at in this. [00:43:42] Yeah. And, you know, we, I often work with organizations and they have their change management [00:43:48] experts and there's at the car, awareness, desire, knowledge, but they still treat change management [00:43:55] as a project. And there's a fear that in the AI world, we're still doing that. I was having a [00:44:01] conversation yesterday with, with the client, we were, we were thinking about how to deploy [00:44:08] a new value realization framework for the organization that is in par, going in parallel to AI adoption [00:44:15] and how to use AI along the way. And one of the, one of the questions that people [00:44:22] rare is not just how can we automate and make it, make it, I mean, one thing we could do with AI [00:44:29] is make it easier to create the presentations that we would use to train people on, you know, [00:44:35] the new approach or even use AI to use 11 labs, whatever to auto record a script and create the [00:44:43] training without us having to deliver it. Okay, fine. But the real question is how could we stop [00:44:49] training people? Or how could we reimagine the outcome? Again, it's the difference between [00:44:55] output and outcome. The outcome that we want is people understand this thing and want to try it. [00:45:02] So the way I'm thinking about it is the fact that people are using a Gentic AI or even, you know, chat [00:45:09] bots more often these days gives us an opportunity to inject invitations rather than [00:45:16] inflict mandates in a more structural way. There's a way for, you know, agent preferences and the [00:45:25] skills that we create to drive people towards or to even consider the things we want them to consider. [00:45:34] So for example, my agent preferences is driving me to think more about outcomes and about leading [00:45:41] indicators rather than jump to concerns about solutions. And that's one of my recommendations [00:45:46] to anybody that, you know, is starting to think about what should exist in my agents and the plot [00:45:53] and the whatever. Think about what changes do you want to see in yourself or in your organization. [00:46:01] And that's a way that's a carrier signal to, you know, I don't want to say brainwash, but in a way, [00:46:09] it's kind of it's not brainwashing, but it's creating, maybe you could call it the habit stacking, [00:46:17] whatever you're talking to the AI. That's the right time to think about a new decision filter, [00:46:23] a new perspective to consider. Are we measuring the right things? That's a question that makes sense [00:46:30] on on agent preferences, for example, so that it gets more out of you as the human. [00:46:36] Okay. Thank you for that. There are two more high-level questions I want to touch on. [00:46:44] So the first, there are two phrases. Some people might think of them as taglines. Some people might [00:46:51] think of them as part of your branding. Some people might think of them as a point of view. It's not [00:46:57] really obvious to me which of these this really is, but sort of two ideas almost memes, if you will, [00:47:03] that I've heard you mention, one is this idea of unreasonable agility, and the other is this idea [00:47:09] of having a genius in the loop. And I want to just throw those out there and then hear whatever you [00:47:16] want to say about either of those notions. Yeah, sure. And maybe it's worth a deeper dive, [00:47:22] especially since we've been at this for a while and I doubt it. I'm sure the listener wants to move [00:47:30] on with their day. But unreasonable agility is a term that came to mind as I was talking to a [00:47:39] cybersecurity CEO the other day, who's essentially taking has done some thinking after they had a [00:47:51] successful exit with one cybersecurity company. They were thinking about what, like beyond the tech. [00:48:01] Finding new cybersecurity problems to solve. How could we leverage AI? That's one thing that was [00:48:08] on his mind. But the other was, what could be possible if engineering wasn't the bottleneck anymore? We [00:48:15] were talking about the fact that in his last company, like on 99% of the product companies out there, [00:48:25] or even organizations out there that rely on technology, the technology organization is a [00:48:30] bottleneck. And because it's a bottleneck, you create processes and structures and ways of working, [00:48:37] lifecycles that protect it. He called it defensive R&D. Everything about classic agile, [00:48:44] scrum, safe, whatever, whatever in product management is organized around this notion. [00:48:51] What he was thinking, and he comes from defensive and offensive cybersecurity. So that's his language. [00:48:59] He was thinking about what would happen now that we have AI and they started with a genetic [00:49:06] software development lifecycle from day one of that company. So they have an advantage. But [00:49:12] how can we leverage that? How can we take R&D on the offense? What would such a capability look like? [00:49:21] And then he connected it to the ideas that you find in unreasonable hospitality, which are that [00:49:28] you essentially aren't just hospitable. You're not just a restaurant that treats its [00:49:38] patterns well. You're surprised that you do unreasonable things. He gave me an example of [00:49:45] a customer that mentioned a challenge, not something that was strictly within the product. [00:49:50] They mentioned it on a meeting and the next day they show that customer what they need working [00:49:56] within the product. That should be how we leverage agentics software development lifecycles and [00:50:04] front deployed engineering. For me, I connected that with my language and for me, that is what agility [00:50:13] should be about. That is the promise of agility. It's the promise of agility. [00:50:21] Like it's not the agile processes. It's the promise of if there's something that's highly [00:50:27] valuable, we can do it. We don't give excuses. We don't play the soup Nazi and tell people to come in [00:50:34] later. We don't plan deep backlogs and create predictability, which was the old game creating [00:50:41] predictability because we had very little predictability. Now, it's not about predictability, [00:50:48] it's about agility. It's about unreasonable agility. Things that we never could imagine [00:50:56] in the past, but if our R&D is no longer the bottleneck, we could actually jump on opportunities [00:51:03] to do these sort of things. I find it an interesting term. I don't know if it's a point of view or a [00:51:11] positioning or a category or a framework, whatever. Maybe it will turn into something. I'm not sure [00:51:19] exactly what it will turn into. Maybe the podcast will turn into the unreasonable agility podcast [00:51:25] someday. I wouldn't be surprised. But it's top of mind for me. I'm fascinated and I'm very optimistic [00:51:36] about this perspective to what's the potential that AI can provide to the possibilities of what [00:51:44] we can do with our organizations. Yeah, I'm just acutely aware that right now, [00:51:50] I might be bullshitting, but there are innovations that are too soon to the market and they need [00:51:57] something else to enable them to be useful or desirable or economic to deliver at scale. [00:52:04] They need something else for that to happen. There's a sense in which it seems like Agile was [00:52:10] sort of waiting for AI. I think that's not a genius. I think agility might have been waiting [00:52:18] for AI. Okay. Agile had its day, but agility, real agility, unreasonable agility. Yes, I think [00:52:29] you're right. It might have been waiting for AI. [00:52:33] We'll see. Yeah. Okay. The second thing I wanted to ask you all is I'm going to ask you to tell [00:52:40] listeners where they can learn more. If they're ready to do something about this now, what should [00:52:46] they do? And if they're not ready to do something about this now, if they need to just kind of absorb [00:52:51] and learn more, what should they do? So I'm always happy to have a conversation with anybody that's [00:52:57] also fascinating about the potential of unreasonable agility or trying to figure out what to do with [00:53:05] the moving bottlenecks in engineering or anything related to scaling AI adoption from activity [00:53:11] to impact. And my name is Distinct Enough that if you search, you value it. You'll find me wherever [00:53:18] you search, whether that's on LinkedIn or Google search at GPT Cloud. You can also email me. [00:53:27] It's uvollet, you're at agility.com or go to my website uvollet.com. I write about these things [00:53:34] pretty often. You've always come away from these conversations with something new to think about. [00:53:40] And that's even more so true today. Thanks for talking with me. Thank you, Philip. Always a pleasure. [00:53:47] And thank you, the listener. This is the scaling from activity to impact podcast. [00:53:53] Talk soon. ## 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.