From AI Theater to Unreasonable Agility

There’s theater in both places. Some organizations focus agile on activities and outputs. They measure story points and velocity, and they do a lot of hoo-ha ceremonies. And you’re starting to see that with AI. You’re seeing token maxing, and people that are measured based on how many tokens they use. If they don’t use all of the tokens by the end of the month, then they will get fewer tokens the next month, and they will be on some lists where they won’t be considered 10x, 100x employees.

There’s an interesting jumping to conclusions here, which kind of reminds me of the South Park episode about the underpants gnomes. Step one, we use all the tokens. Step three, profit. But many organizations don’t really know what step two is. They don’t really make the connection between all of this activity that we’re seeing and real impact on the bottom line.

AI theater definitely has a lot in common with the agile theater that I’ve been seeing. AI theater caught up very quickly to something that took a decade in the agile world to happen. AI is much faster about everything.

“If your engineers are so much better, where are the new features? Where are the new capabilities? Where’s the new market share in your product?”

Philip Morgan

If you look at some of these companies, and you look for what value they have found in their product, how have they managed to turn all of this AI output, potential AI output, into impact? They haven’t managed to. So there is a bottleneck.

The coding step is, let’s say, 10x faster, but you don’t necessarily see 10x throughput at the end of the development lifecycle. For sure, you’re not necessarily seeing 10x impact. A feature that you build is not necessarily a feature that delivers value. The bottleneck might be in code review, it might be in coming up with the right features, it might be in adoption of these features.

Part of the challenge, by the way, is that most organizations have never measured things this way. Because it’s hard, right? We are very good at measuring activity. At one of my clients a couple of years ago, we were talking about improving flow and looking at flow metrics. The bigger organization was doing an engagement with one of the big consulting firms, and they showed me the list of metrics that they got as a recommendation from those consultants. One thing on that list was lines of code. Lines of code written. I was shocked. But maybe I shouldn’t be.

Related: How to Turn AI Engineering Speed Into Business Impact

What I’ve seen way too often, another repeating nightmare déjà vu pattern, is the mandate or inflict motion. AI is the new shiny object. We have to do AI. We give AI harnesses, whatever they are, to all of our people. We give them tokens, we expect them to use them. We’ll just expect everybody to token max, and we’ll measure token usage, and that would be “we are using AI.”

Part of the dynamic is what happens when you inflict AI on people, when you mandate AI usage. Somebody mentioned this to me the other day, literally: it feels like they’re sitting on a branch, and they’re very busy sawing off the branch that they’re sitting on, for their employer at the big tech firm. And that’s common. That’s the reality.

Especially when you combine mandates and infliction and these sorts of changes, people are very smart. They 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. Maybe they’ll even create a lot of output.

Think about the sabotage manual, the manual that the Allies gave the resistance during the Nazi regime: how do you continue to come to work and resist as an underground? A lot of the time when I look at what’s happening in organizations, it kind of feels like that. Both in the Agile Theater world and with AI theater.

I have one of these self-assessments. Are you a theater? Are you a feature factory? Are you an impact lab?

One of the simple questions to ask is: what do you measure? What’s the goal of what you’re trying to do? Another is: do people have to use this thing? Are you willing to ask people the product-market fit survey question, Sean Ellis’s question? What would happen if your product, your change, disappeared overnight? Would you be disappointed?

Are you willing to even ask that question? That’s a very simple question that is frightening for a lot of agile leaders and a lot of AI leaders to ask themselves, because they’re not currently designed around this change.

The alternative that I’ve seen work in the agile space, and I’m starting to see signs that it actually works better in the AI space as well, is to invite people to change. Rather than tell them you have to use AI tools and you have to shift, appeal to their intrinsic motivation. People are motivated by autonomy, or you could say agency, by mastering something, and by being connected to the purpose.

Some organizations are thinking about AI as a product that is there for their people to use. Not something the organization is telling people, but something that is there for people to use to make their job better, to make them enjoy their work more, feel more connected to the organization. And they acknowledge that people might not want to use AI.

Maybe even ask the question: would you care if you cannot use Claude Code tomorrow? Or if you don’t have access to Windsurf or Devin or Copilot tomorrow? How would that make you feel?

Organizations are not asking that question often enough, and they’re not designing the AI intervention as a product. If they were, they would be measuring different things. They would be measuring things like awareness, activation, real retention. Do people refer? Do people create skills and share them with others? Are they becoming evangelists of those AI tools internally?

And if you realize that an organization is a market, and it operates like a market, and you look at things like Geoffrey Moore’s Crossing the Chasm, you realize that some people would react better to waiting with AI adoption and not just jumping on board right now. They need to see others succeed. They need better solutions. Others will jump ahead. But you cannot take what’s working for the people that jump ahead, the pioneers, and copy-paste it to all of the others. You have ten pioneers or a hundred pioneers, and then the thousands of people behind them will do the same thing, be as effective, as motivated? That typically falls flat.

I often work with organizations that have their change management experts and their ADKAR: awareness, desire, knowledge. But they still treat change management as a project. And there’s a fear that in the AI world we’re still doing that.

I was having a conversation with a client about how to deploy a new value realization framework for the organization, going in parallel to AI adoption, and how to use AI along the way. One thing we could do with AI is make it easier to create the presentations that we would use to train people on the new approach. Or even use AI, ElevenLabs, whatever, to auto-record a script and create the training without us having to deliver it. Okay, fine. But the real question is: how could we stop training people? How could we reimagine the outcome? Again, it’s the difference between output and outcome. The outcome that we want is that people understand this thing and want to try it.

The fact that people are using agentic AI, or even chatbots, more often these days gives us an opportunity to inject invitations rather than inflict mandates, in a more structural way. There’s a way for agent preferences and the skills that we create to drive people towards the things we want them to consider. For example, my agent preferences drive me to think more about outcomes and about leading indicators rather than jump to solutions.

That’s one of my recommendations to anybody starting to think about what should exist in their AGENTS.md, CLAUDE.md, whatever. Think about what changes you want to see in yourself or in your organization. Maybe you could call it habit stacking. You’re talking to the AI. That’s the right time to think about a new decision filter, a new perspective, to consider: are we measuring the right things? That’s a question that makes sense in agent preferences, so that it gets more out of you as the human.

Unreasonable agility is a term that came to mind as I was talking to a cybersecurity CEO who has done some thinking after they had a successful exit with one cybersecurity company. Finding new cybersecurity problems to solve, how could we leverage AI? That was one thing on his mind. But the other was: what could be possible if engineering wasn’t the bottleneck anymore?

We were talking about the fact that in his last company, like in 99% of the product companies out there, or even organizations out there that rely on technology, the technology organization is a bottleneck. And because it’s a bottleneck, you create processes and structures and ways of working, lifecycles that protect it. He called it defensive R&D. Everything about classic agile, Scrum, SAFe, whatever, and product management is organized around this notion.

He comes from defensive and offensive cybersecurity, so that’s his language. They started with an agentic software development lifecycle from day one of that company. So they have an advantage, but how can we leverage that? How can we take R&D on the offense? What would such a capability look like?

And then he connected it to the ideas that you find in Unreasonable Hospitality. You essentially aren’t just hospitable. You’re not just a restaurant that treats its patrons well. You surprise them. You do unreasonable things. He gave me an example of a customer that mentioned a challenge, not something that was strictly within the product. They mentioned it in a meeting, and the next day they showed that customer what they needed, working. That should be how we leverage agentic software development lifecycles and forward-deployed engineering.

I connected that with my language, and for me, that is what agility should be about. It’s not the agile processes. It’s the promise of agility: if there’s something that’s highly valuable, we can do it. We don’t give excuses. We don’t play the Soup Nazi and tell people to come back later. We don’t plan the backlogs and create predictability.

That was the old game, creating predictability, because we had very little predictability. Now it’s not about predictability, it’s about agility. It’s about unreasonable agility. Things that we never could imagine in the past. But if our R&D is no longer the bottleneck, we could actually jump on opportunities to do these sorts of things.

I don’t know if it’s a point of view or a positioning or a category or a framework. I’m not sure exactly what it will turn into. But it’s top of mind for me, and I’m very optimistic about the potential that AI can provide to the possibilities of what we can do with our organizations. Agile had its day. But agility, real agility, unreasonable agility, might have been waiting for AI.

This piece comes from my conversation with Philip Morgan on the Scaling AI podcast.

I’m always happy to have a conversation with anybody who’s also fascinated by the potential of unreasonable agility, or trying to figure out what to do with the moving bottlenecks in engineering. Get in touch.