# Why the Pivot? Tracing the Line from Scaling Agility to AI Impact: 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.