Lou has overseen the portfolio for years, and nothing about the work looks any different. The reviews still happen on schedule. The templates still fill in. The numbers still reconcile. But he sees now that the existing processes have become the bottleneck now that the build system outpaces funding.

The delivery teams now build in weeks what once took quarters. The strategy that the teams and portfolio align to revises itself whenever an assumption stops holding. Between those two, Lou’s allocation sits where it has always sat, set once and defended until the cycle turns. His is the only part of the system still moving at its original speed.

In a review that quarter, Alex, a delivery leader Lou has worked alongside for years, repeated something an old mentor had said to him. He did not aim it at anyone in particular.

“Your teams can change their minds every week. Your money changes its mind once a year. So who is deciding what your company becomes?”

Nobody answered. Lou noticed, with some discomfort, that the question was addressed to his job.

Demand Versus Capacity Allocation

Lou’s first move to address the problem was to improve the articulation of the requests, and it was not a foolish one. If the money could not move faster, the objectives could at least be clearer. He sent them back to every product group with instructions to state outcomes rather than outputs and to attach a measure to each.

They came back better, and they came back quickly. Agents drafted most of them, and the drafting was good: well formed, outcome-shaped, measurable. Nothing moved. The capacity underneath those objectives had been committed before they were written and would not be revisited until the cycle turned.

That articulation became cheap is precisely what makes its limits visible. Roger Martin named the failure before any of this was automated. Writing about the gap organizations leave between an objective and its key results, he observes that “the setting of key results will have little or nothing to do with their achievement.” Desire is not a mechanism, and a well-drafted desire is still not one. An objective that no funding decision responds to is a statement of intent rather than a commitment.

Writing a better objective got cheap. Deciding and acting on one did not.

Three Clocks, No Gearing

Lou stopped studying the allocation and started studying the timing.

He wrote down when each outcome actually changed. That moment of change became the “signal.” Strategy changed when an assumption underneath it stopped holding, which was irregular and driven by evidence. Objectives changed on a quarterly rhythm. Capacity changed once a cycle, when the plan was set. Three clocks, running at three speeds, with nothing connecting them.

A system moves at the pace of its slowest clock, and Lou’s deciding and acting was the slowest. Every improvement made downstream arrived at his boundary and waited there.

Funding rhythms vary widely, and some organizations reset in months while others reset in years. The length of the cycle matters less than one question: whether capacity renews faster than the assumptions it was committed against expire. Telemetry now retires assumptions in weeks. An allocation defended for a full cycle is defending a picture of the business that stopped being accurate somewhere in the middle of it.

A Backlog Worth Approving

An objective names a capability gap. It does not tell anyone what to start.

What converts one into the other is a portfolio brief: a problem stated small enough to approve, carrying the outcome it targets, the key result it moves, and its standing against everything else already waiting. Ninety days is the outer edge of that window rather than the target, but smaller targets are even better. Len Greski sets the same ceiling in his work on software economics, funding value streams and products in outcome-gated envelopes lasting no longer than 90 days. A problem that cannot be framed inside a quarter has not yet been made small enough.

A portfolio brief must establish three things: the problem, the outcome, and the key result. The problem, sliced to the first piece a real user can respond to rather than the capability in full. The outcome, named against the people whose behavior is meant to change, and what each of them will be able to do that they cannot do today. That is the capability. And the single key result it moves, ranked against everything else in the backlog, because priority that is not comparative is not priority.

Ranking is where an agent earns its place. Scoring a backlog consistently against a stated rubric is work humans do badly, slowly, and inconsistently, and it is work a model does well. Delegating it removes the oldest distortion in portfolio management, which is that priority tends to reflect who argued hardest. What cannot be delegated is the rubric. A rubric encodes what value means to the organization right now, which makes it a decision rather than a calculation, and it expires. Agents rank against a definition of value. A real person must own the definition rather than delegate it, and revisit it before it goes stale.

Lou ran his own backlog against the key-result test first, and most of it failed to meet the priority thresholds. The items were real. The sponsors were senior. Not one of them connected to a key result anyone could name aloud. A portfolio backlog whose items cannot each name the key result they move is a list of requests wearing a strategy’s clothes. It scored low, and it was not funded.

Two Questions at the Gate

Every approval turns on two questions about capacity. The first asks whether the organization can build the thing. The second asks whether the customer it is built for can absorb it. Most portfolios ask the first and assume the second.

Is there build capacity?

Then comes the discipline that makes a backlog mean anything. A problem with no capacity behind it does not get approved. Not deferred with a nod, not approved in principle, not held pending. Not approved.

That rule changes what funding is. Funding is the available capacity to do the work. So when a problem worth solving has no capacity behind it, two honest moves remain. Reallocate capacity from somewhere or fund additional capacity against a longer view of the strategy. Somebody owns each of those decisions. Approving the work regardless leaves the decision unmade.

The third option carries a cost that appears on no ledger. Work approved without capacity behind it does not sit quietly. It keeps drawing effort from people who cannot act on it, in status asked for, plans revised, sponsors updated, and expectations maintained. Writing in Harvard Business Review, Rose Hollister and Michael Watkins list unfunded mandates among the six root causes of initiative overload. A backlog of commitments nobody can execute carries its own change load, and that load lands on the organization long before anything reaches a customer. Declining to approve removes work that was never funded in the first place.

Risk decides which problems reach this gate at all, sorted by reversibility and the cost of being wrong. A small, reversible bet inside one product group belongs to that group, decided there against capacity its own leader already holds. What travels to the portfolio is work that binds more than one group, or commits capacity somebody else is counting on. A gate everything passes through is a queue with a formal name.

Can the customer absorb it?

The second question is the one almost nobody asks, and without an answer to it the decision to commit is not executable.

Lou stopped asking what each product group had shipped and asked something else. What had one customer group received from the portfolio over the last cycle, counting every product that served them? Nobody had the answer, because every group reported its own.

This is the part that changed. Assembling that view used to take a quarter of somebody’s attention and rarely survived contact with the next reorganization of the reporting. A portfolio agent now holds every product’s release record, adoption telemetry, and support volume against a single customer and returns the aggregate in an afternoon. The synthesis is no longer expensive, which means a portfolio team can be held accountable for a view it could previously claim was impractical to produce.

The list was longer than anyone expected. Each group had reported adoption on its own releases and each number had looked fine, but nobody had added them up. Together they described a customer absorbing more change in one cycle than anyone had chosen. Every team had shipped a defensible amount. Together they had shipped too much.

Adam Whaley’s work is where the evidence for this lives. He defines feature usage as “the share of what you’ve shipped that people actually use, measured from instrumentation in the product, not from opinion in a meeting,” and the Standish research he cites puts 45% of shipped features in the never-used column, with another 19% used only rarely.

None of this is new, and none of it is about technology. Hybrid seed corn reached the American market in 1924 with a yield advantage approaching 20%, and a farmer could try it on a single acre. Bryce Ryan and Neal Gross studied 257 operators across two Iowa communities. The average interval between first hearing of hybrid seed and first planting it was five and a half years, and the first commitment was a median of 12% of a farm’s corn acreage. Absorption was slow and partial even where the arithmetic was obvious and the trial was nearly free.

Capacity to build and capacity to absorb are different resources, and only one of them can be bought.

An agentic system can tell a portfolio team that no capacity exists on either side. Only a person can decline to approve the work anyway, absorb the disappointment that follows, and answer for the choice afterward. The ranking can be delegated. The refusal cannot.

Every approval asks whether the work can be built. Almost none ask whether it can be absorbed.

Confirmation Is Not Payback

One piece of gearing remains. An approved problem runs to a period, and at the end of that period something has to happen other than the next cycle arriving.

The window buys confirmation, not payback, and the distinction is what allows the model to survive a conversation with finance. Deloitte’s research on return from AI investment places satisfactory ROI on a typical use case at two to four years, with 6% of organizations reporting payback inside 12 months. Against that curve, a portfolio brief promising a return inside its own charter period is either measuring the wrong thing or teaching the organization to report optimistically. A brief establishing whether the capability is being built, and whether the assumption underneath the bet still holds, is measuring the right thing on the right clock.

That evidence is also what should open the next tranche. Len Greski states the mechanism plainly, describing portfolio approval for the next scope of work as something that “releases per verified outcomes, not an annual spending plan.” A boundary that opens only when the calendar turns converts fast evidence into a queue.

Evidence triggers used to be aspirational, because nobody was watching continuously and the review calendar was the only thing that reliably arrived. That constraint is gone. An agent can hold the assumptions underneath every funded bet and surface the ones that have stopped holding, which turns the evidence trigger from an intention into something that actually fires. It surfaces the condition. It does not open the boundary, because opening a boundary moves money and commits people, and that has an owner.

What Lou Learned

Two quarters on, the portfolio review opened with the backlog rather than the spend. Three of 11 approved problems had been stopped at their first boundary, when the evidence said no and stopping was still cheap. Two more had never been approved at all, because nothing had been freed to build them and nobody was willing to pretend otherwise.

Alex asked what Lou would tell a peer walking into the same position. Three things:

1. Briefs, not objectives. An objective names the distance between the capability the strategy requires and the capability that exists. A brief turns that distance into a problem small enough to approve, carrying the outcome it targets, the single key result it moves, and its standing against everything else waiting. Agents can rank that backlog consistently, which is more than most portfolios manage, but the rubric they rank against is a decision with an expiry date on it.
2. Capacity, not permission. Ask both questions, whether the organization can build the thing and whether the customer can absorb it. Funding is the available capacity to do the work, and a customer with less absorption capacity does not adopt later so much as adopt less.
3. Evidence, not the calendar. Ninety days is rarely long enough to earn a return. It is long enough to learn whether the work is heading somewhere worth funding. The first round is judged on what it proved, and the next round opens when the proof arrives rather than when the quarter ends. The real test is whether funding decisions get revisited faster than the facts behind them go stale.

The question Alex repeated still gets asked, and now it has an answer. A company becomes whatever its capacity keeps confirming. The same people still decided. What changed was that the deciding could finally hear something back before the next cycle began.

This post comes from our Management Consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.

Sources

Bryce Ryan and Neal C. Gross, Acceptance and Diffusion of Hybrid Corn Seed in Two Iowa Communities, Iowa Agricultural Experiment Station Research Bulletin 372, Iowa State College, 1950. Originally published as “The Diffusion of Hybrid Seed Corn in Two Iowa Communities,” Rural Sociology, 1943. https://didawiki.cli.di.unipi.it/lib/exe/fetch.php/wma/agricultural_research_bulletin-v029-b372.pdf

Deloitte, AI ROI: the paradox of rising investment and elusive returns, October 2025. https://www.deloitte.com/global/en/issues/generative-ai/ai-roi-the-paradox-of-rising-investment-and-elusive-returns.html

Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press, 1984. Character homage, names only, in tribute.

Leonard Greski, “The New Software Economics: Earn the Right to Invest Again, in 90-day Cycles,” LiminalArc, May 2026. Originally published in Architecture & Governance Magazine, April 2026. Direct-quote source, and the source of the ninety-day funding window referenced. https://www.liminalarc.co/2026/05/the-new-software-economics-earn-the-right-to-invest-again-in-90-day-cycles/

Roger L. Martin, “Stop Letting OKRs Masquerade as Strategy,” Playing to Win / Practitioner Insights, November 2021. Direct-quote source. https://rogermartin.medium.com/stop-letting-okrs-masquerade-as-strategy-a57fc2cea915

Rose Hollister and Michael D. Watkins, “Too Many Projects,” Harvard Business Review, September–October 2018. https://hbr.org/2018/09/too-many-projects

Adam Whaley, “Are You Building the Right Thing: The Metrics That Measure How Fast You Learn,” LiminalArc, July 2026. Direct-quote source, and the source of the feature usage measure and the Standish figures cited. https://www.liminalarc.co/2026/07/are-you-building-the-right-thing-the-metrics-that-measure-how-fast-you-learn/

A working AI pilot proves less than most executives assume. This episode digs into why AI initiatives clear a demo and then stall in production, and the constraint is rarely the model. It’s whether the organization’s data, applications, and ownership structure are actually ready to run on it. That readiness gap shows up two ways: AI use turning into the next shadow IT, and teams mistaking individual productivity wins for organizational proof. The conversation also breaks down a framework for sorting what AI can already do inside a business from what it can’t do yet, and why context, not model quality, is becoming the real differentiator.

Host Stacy Gordon talks with LiminalArc CEO Mike Cottmeyer in the relaunch episode of Future State Now, formerly SoundNotes, tracing the company’s shift from LeadingAgile to LiminalArc and what AI transformation means as the next chapter of enterprise change.

Video Transcript

Mike Cottmeyer:

This is where I think we’re starting to see the pattern of stuff Gartner writes about, about the percentage of AI pilots that are going to fail, pilots that are not getting the ROI, token spend out of control, again, not getting the value out of it that these organizations expect. And I think that’s an artifact of trying to exploit AI capabilities on top of a organization, application, and data infrastructure that just isn’t ready for it.

Stacy Gordon:

Hi, everyone. Thanks for being here. I’m Stacy Gordon, the host of our inaugural new podcast called Future State Now. You may remember it as sound notes previously, but we’ve rebranded and renamed our podcast and are excited to be back in your feed. My guest today is founder and CEO of Liminal Arc, Mike Kotmeier. We’ve got a number of topics to talk about, specifically the new name of the company, Liminal Arc, and a number of other things. So we’re going to get right into it. Thanks again for being here. Hey Mike, it’s been a hot minute. So glad to have you back in the seat. How are you?

Mike Cottmeyer:

I’m doing good. I’m happy to be here. Glad we finally got this on the calendar so we could have a chat. I

Stacy Gordon:

Know. So tell me what’s been going on really.

Mike Cottmeyer:

Gosh, it’s almost like what hasn’t been going on? Yeah. I mean, anybody who’s in the consulting industry knows the consulting industry’s been a ride for the last couple years. Yeah. So aside from trying to continue to scale and grow our business and serve our clients, the journey over the last, gosh, probably since 2021, 2022, maybe a little bit earlier than that, kind of the big news that you might see some evidence up on the website about or on blog posts and things, but we built a studios practice. We really converted the company from a pure play agile transformation company into more of a full service consultancy. So probably our tech staff’s probably 60% of the company at this point. Most of our engagements are some mix of organizational transformation, some agile stuff, some technology modernization, refactoring. And so me leading the company, it’s like marketing and branding and websites and working with our talent group and working with our infrastructure to figure out how to build out and support. And then given my unique perspectives, I get a lot of reps helping with methodology and providing clarity and onboarding and such like that. So yeah, just a ton, growing and scaling a company, trying to integrate technology and rebuild all our systems and processes. And yeah, it’s been a busy couple years.

Stacy Gordon:

Well, I mean, you teed it up for me. So there’s a name change about a year ago. Tell me about that.

Mike Cottmeyer:

Yeah. Well, yeah, it was fascinating. So just a little bit of history. So Leading Agile, the brand had been out in market as a company, I guess, for, this is our 16th year. Gosh, I think we literally just had our 16th anniversary, August 1st. I can’t believe I just kind of missed that, just kind of blew right through that one. So it’s been busy. Yeah. And so when I first started it, the history before the company started is that Leading Agile started off as my blog. I was working for a company here in Atlanta in the financial services industry. And a guy I was working for at the time basically put on my performance criteria for the year he wanted me to start writing. He though I had some good ideas and he though I should start a blog. So I named the blog Leading Agile. And then that lasted for a couple years through my time with VersionOne here in Atlanta.

And then when I started the company, I had the website, I had followers, I had social media presence, and it just didn’t make a whole lot of sense to think about trying to create a different name. And so I just went with what I had. And so the company became Leading Agile by default. And I remember thinking in those early days, because most things, they have a life in the marketplace. I don’t want to say Agile’s a fad. It wasn’t a fad. It’s not a fad. It’s still around and it’s still doing its thing. But like anything, whether you go back to Six Sigma or critical chain project management or rationally unified process, everything has its moment in the sun. And so I remember thinking like, “Yeah, I just named my company with this word Agile in it. How much legs does it have?” And so every year in the first couple years, I was always like, “Oh, when are we going to have to change the name? When are we going to have to change the name?” And it ran about another 12 years is what it came down to. And I think part of that was because we had a fairly differentiated perspective in the market. We weren’t trying to sell training, although we did training. We didn’t really go to market as a scrum certification company. And we weren’t really an agile coaching company per se. We weren’t really a software engineering shop. We were really this enterprise transformation company.

And so I think it lasted and we had a lot of success as it started to downturn. But I had this kind of interesting life event that I haven’t really talked about publicly and I’ve kind of wanted to. It’s almost like I feel like it requires an explanation a little bit. Back in 2019, my wife got diagnosed with leukemia and that was a ride for a little while. And on the backside of that, I took a bit of time off to take care of her. She’s doing really well, by the way, totally recovered. It’s a pretty awesome story. But coming back from that, I started getting really hands-on with the company again and I start looking at our sales pipeline and I start looking at our account concentration. I start looking at our website traffic and I’m just like, “Oh, something changed.” It’s fascinating. And so yeah, it kind of took my eye off the ball and the game moved a little bit while I was away. And so from that place, I’m like, “Oh, this is fascinating.” So you start to figure out, okay, what are we going to do? How are we going to keep this thing going? And so we kind of wrestled with that. I guess it was 2026, so it was about a year ago since we changed the name.

So it would’ve been 2025. This probably started happening around 2022 as I started contemplating a name change. And we noodled around on that for a long time. The name Leading Agile meant a lot to me. I toyed with the idea of getting it tattooed on my leg. I still might at some point. So I don’t have any leading Agile tattoos, thankfully. I think it’s kind of like getting your girlfriend’s name tattooed on your arm and breaking up with her or something. So I’ve been thinking about name change for a long time and we tried to crowdsource it in the company and like, oh man, just nothing resonated with me. Nothing resonated with me. And so yeah, I just kind of woke up one night and we had been exploring this idea of liminality as a company and transformation and change and getting people to think differently about stuff.

I read Dave Gray’s book, Liminal Thinking and just literally just woke up one night with the name in my head and then noodled on it for about a month and got kind of attached to it. Started searching for domain names and things like that and just got kind of attached to it. And probably the thing that really locked it in for me is that a lot of people call our company LA, and so it preserved the LA. I though that was kind of neat. I sat down with marketing and we talked about what would we do from a branding perspective? And if you notice we kept the same branding footprint, the same basic blaze logo that we have, just trying to change it to an arc instead of a little peak. I though that was kind of cute. So I think that was the thing that finally settled it is I was like, okay, this is cool. I kind of like the name. I kind of like the transition. It was meaningful to me. And so yeah, we just cut the cord and just went with it.

Stacy Gordon: Well, I think when you talk about the idea of liminality, I do want to explore that a little bit with you

Mike Cottmeyer: Because you

Stacy Gordon: Love to create content, but you went quiet for a year. What caused you to take a beat?

Mike Cottmeyer: Well, let me explain. Yeah, you mentioned an interesting point that I want to come back to. The idea of liminality. A lot of times that’s a funny thing about the name is most people don’t know what the word means.

Stacy Gordon: Okay?

Mike Cottmeyer: Well,

Stacy Gordon: I have to be honest, I didn’t

Mike Cottmeyer: Know. Yeah. And so I think I was hesitant to use that name until we started talking about the Dave Gray book, Liminal Thinking. I’m like, oh, okay. Somebody else knows what the word means in our industry. And it had kind of a really neat context to it. And so liminal to me, it means a lot of things to a lot of people, but it’s all in the same space. It’s all about in between spaces. It’s all about going from one place to another, having to let go of one thing to get to a different thing. And the story about my wife’s leukemia introduced, imagine a lot of change into our lives and it kind of changed me as a human. And so going through that phase and then COVID right behind that and some of the changes that were going on in our company, I really started thinking about this idea of liminality. It came up in spiritual spaces and it came up in psychological spaces. And then Dave introduced it and it’s like, oh, it came up in a business space. So the name started having a lot of depth for me and I like things that mean things.

So leading Agile meant something to me. The word liminal started meaning something to me. And so it was very personal for me, this idea of liminality and the journey from one place to another. And then I started thinking about that name and the context of the journey that we were going through as we’re moving from a pure play agile transformation company into more of a full service business process re-engineering technology transformation change management company. And so I started thinking about our company being in a liminal space.

And even the last year since I announced the name change has been a bit of a liminal space for us and kind of what we’re maybe getting ready to talk about. And then the idea of Arc, how can you map the journey through the liminal space? Because one of the things we’ve talked about for years is the idea of creating safety for change. And if you’re going to go from where you are today into where you need to get to in the future, you need to be able to do that in an incremental and iterative way. You need to be able to do that with some sort of plan. It’s hard to ask somebody to let go of what they’re doing today if they don’t have a clear path to how to get to the next place.

And so that’s where the arc side of it came in. And so again, it just started accumulating and accumulating and accumulating more meaning as we went deeper into the naming. And so what was your question? So you asked me when I went quiet for a year? You went quiet. Yeah.

Stacy Gordon:

Yeah. I mean, do you feel like after the last year since you named the company that you know something different today that you didn’t know a year ago?

Mike Cottmeyer:

Yeah, great question. So for me, it’s a bit of a personal journey, right? So I grew up, I think it’s super ironic given what I do, that I actually went to school for computer science. So I have a computer science basis 30 years ago, so not much is relevant, but a shocking amount actually still is. And so I spent the first 10 years of my career doing IT infrastructure stuff, and then I spent really the second 10 years doing project program management first in the IT infrastructure space and then more so in B2B, B2C businesses and then moved into financial services and then moved into the consulting stuff that I did with Version One and then ultimately into Leading Agile. But the point was is that I’d really grown up and what LeadingAgile did, I grew up in that space and what Leading Agile did was really a manifestation of my point of view that had been developed over the previous 20, 25 years. And so as we started bringing in more technology stuff, my challenges, this is again, a personal story for me.

My challenges is that I’ve been around this stuff forever, but I’m not a hands-on guy doing the technology stuff. I’ve been a hands-on guy doing the other stuff. And so if I’m going to get on stage or I’m going to write an article, one of the things that I would say is I was kind of like an inch wide and a mile deep on some of these things. And so I just didn’t feel like I could defend a thesis. I couldn’t defend my point of view. And so a little bit of a journey over the last year is, we’re getting ready to flip our website over again, but I think our website as it stands of this recording is we do a lot of things. What makes I think us unique is that we’re very much a first principles company and those first principles can be applied into a lot of different areas. And so we get involved in cloud migration stuff and we get involved in ERP integration stuff and we get involved in security and we get involved in application builds. We get involved in a lot of things depending upon what our clients need from us.

And I think our website over last year was an attempt to talk about the breadth of what we could do. But the problem is that what you want to talk about is first principles because first principles apply everywhere all the time, no matter what you’re doing. But then you apply those first principles into six or seven different things and you’re like, “Well, it doesn’t really sound like you’re an expert in anything.” And I was dancing on this line between do I go back and start explaining first principles? Do I try to explain what we do in ARP or what we do in security or what we do in data or what we do in enterprise transformation? And after a year of doing that, I’m just like, “Ah, not landing.” It wasn’t landing the way I wanted it to land. And so as the market changed, I mean, think about all the change that has been introduced just in the last six months with AI. And it is the hot topic. And whether it be agentic coding or agentic SDLC or agentifying business process, it’s out there. It’s what everybody’s talking about.

So what I started to think about was, well, what if we just said, okay, we do all these things and we’re going to get involved in all those things because organizations are complex and those pieces exist everywhere. And so within that frame, just lead with AI transformation. It’s kind of a quick tie back to agile transformation. Obviously AI’s got legs for a while. And so I started to think about, well, what if we just became an AI transformation company and just really led with that and then did everything else that we do downstream from that? And so really the thing, probably our number one performing piece of content is something I did, I think we posted on YouTube like nine years ago or something like that. It’s called Why Agile Fails and What Can Do About It, right? And the funny thing about that story is I didn’t even come up with that name.

There was a conference organizer, I can’t think of his name right now, who suggested the name. And so anyway, why Agile fails in what you can do about it? And I said, well, it’s kind of a theme of everything that we do in Lemonal Arc is why something fails in what you can do about it. Because you just see people, everybody adopts kind of the surface level of a lot of the stuff that gets popular. And we saw Agile theater and I think to some degree we’re going to get some AI theater. I think we’re getting some AI theater right now. And so I started exploring this thesis of why AI fails. And so I published some stuff on my Personal X account, my personal LinkedIn account. It’s getting ready to go live on the LemonalArc account over the next week or two. And so I started developing this thesis and then it was just like the floodgates came out and it’s just like I just found I had stuff to say again.

And so that’s when we started talking about doing this podcast. It’s when I started publishing again and I’ve probably got hundred pages of rough cut stuff that I’ve built with AI, just ideas that I’ve been developing with my second.

Stacy Gordon:

You can’t keep mine quiet for long is what I would say.

Mike Cottmeyer:

Yeah. I mean, it’s one of those things, right? And it’s kind of funny. It’s like when I kind of got myself into the head space of writing and content, I actually asked my admin, I was like, “Just clear Tuesdays and Thursdays for me.” I’m not totally successful at it. It’s hard packing in a full week into Monday, Wednesday and Friday. But I’m trying to hold time, producing a lot of content. So I’ve got the one series teed up. There’s a series I’m working on, which I think is an interesting thesis that AI is really going to become the next shadow IT. I think that’s an interesting idea. This idea of context engineering is super interesting to me and just kind of where the industry’s going around it. And so I just see the same failure modes starting to happen again and I think it’s something we can get ahead of. It’s kind of cool. Excited.

Stacy Gordon:

Well, I do love how you guys anchor things in patterns. And so if we go back to talking about AI, knowing that it’s the hot topic across every boardroom, what are you betting on as it relates to AI?

Mike Cottmeyer:

Well, kind of the seminal event that really started locking this in for me is as we were doing more AI stuff, the consulting side of my organization would have a certain take on it. The engineering side of the organization would have a certain take on it. I had a take, other leaders on my team had a take. And so we got together and we did a little bit of an AI, I don’t know, what do they call it? A workshop, like an offsite or something like that. So you did this AI offsite, round table maybe is what I was looking for. And so we started a conversation over a couple days and the first morning of it is just all over the place. And so my brain goes, okay, this is all over the place. I have to bring order to it. I’m a facilitator, not by certification or anything, but it’s just what I do, right? Facilitator. So I start trying to figure out, okay, what is everybody saying? What buckets do they fit in? And we kind of came up with these three buckets and they’re not really market ready, but it’s easy for us to talk about internally. And the three buckets are extract, enhance, and exploit.

And so the enhanced side of it for me, the things that we put in that bucket are the things that we’re using AI for to optimize existing business processes. And it could be agentic coding or it could be we’re doing a bunch of agentic work in our marketing department right now. We have skills built and workflows built and a pretty small team, like five people. But I mean, the stuff that our marketing team’s doing is just phenomenal. And they were actually the leaders of AI within the Liminal Arc back office, right? Yeah. And we’re trying to figure out all kinds of things that we can identify, but that’s not really a scale pattern. We’re a pretty small company, about a hundred people, and so it’s easy to get your hands on everything.

And our systems were built on first principles and we have a lot of data encapsulation and single point ownership and stuff like that, not a lot of dependencies between things. And so there are places where you can run the exploit use case, not, excuse me, the enhanced use case right out of the box. The next one is the exploit use case. And this is where people are trying to do similar kinds of things. They’re trying to solve business problems. They’re trying to identify workflows in more complex systems where the application architecture isn’t aligned, the data’s not clean, the encapsulation patterns are not established. And this is where I think we’re starting to see the pattern of stuff Gartner writes about, about the percentage of AI pilots that are going to fail, pilots that are not getting the ROI, token spend out of control, and again, not getting the value out of it that these organizations expect.

And I think that’s an artifact of trying to exploit AI capabilities on top of a organization, application, and data infrastructure that just isn’t ready for it. And I think that’s a dangerous pattern and it feels very much like trying to put Agile on top of a legacy organization that isn’t ready for it. And so again, at best, we end up with shadow IT where you have work groups that are just out doing stuff.

And then at scale, you have just larger scale pilots that just don’t work. And so that leads me to my third use case, which is the extract use case. And so the question you asked me was, where’s the bet? And so we’ve made some pretty significant investments over the last. This conversation actually started about two and a half years ago. We were talking about the idea of test-driven organizations and composable enterprises. And I was talking with my CTO and just going, okay, how could we build software to take a legacy code base, figure out how to pull it apart, do all the modernization and refactoring without having to have deep, deep, deep experts, because there’s not that many of them that want to pull apart Cobalt systems or want to pull apart AS/ 400 systems or want to pull apart really any kind of legacy application.

And so we started developing this thesis about two and a half years ago, started investing in it about a year and a half ago. Well, about nine months ago, six months ago, the models started getting good enough to do some of this stuff. And there’s a lot of folks out there that are doing application modernization with AI. We didn’t invent that little pocket. But what I think is unique about us is that, and this is an insight that I had, is probably one of the first things I explored with ChatGPT when I got my ChatGPT-4 account Back in the day. I asked myself the question is, the thesis was, is domain-driven design and business capability modeling the same fundamental discipline in two different languages? Business capability modeling being kind of a framework for figuring out how to extract and encapsulate the business where domain-driven design is really about how to extract and encapsulate the technology and alignment with the business. And what was funny is that as I’m querying AI, it’s like fighting my thesis the entire time, but in fighting my thesis, I kind of went, “I’m right.” And then I spent the next six months enlisting the rest of the organization to see it the way that I see it.

We’ve got a couple of things that we got in place, but just to sit in the question that you asked is what am I betting on? I’m betting on that thesis. I’m betting on the idea that that thesis combined with AI extraction tools and the idea of context engines, we can start to go through and enhance. I’m getting tangled up in my own words, an extract, enhance, exploit cycle where you extract the business capability, you align it to the domain, you enhance it so that you can do really clean agentic development, you can run really clean AI use cases within that encapsulated component, and that you can start to expose that data in a way that’s available to other parts of the organization.

And then the enhance side of it, again, I’m getting tangled up my own words. I have to come up with better branding, right? So the exploit side of it is that once I have the encapsulated components, then what I can do is I can start to have agentic workflows going across them. Then the next step of that, and this is the stuff that’s super hard to talk about with everybody because it’s like that’s not where everybody’s head space is. Sure. Then that starts to imply agentic extraction and modernization.

It starts to imply agentic change management. It starts to imply agentic SDLC. It starts to imply agentic systems of delivery. And then what’s going to be required for all of that is we get in this idea of where do humans fit into that and the humans in the loop and where do they fit and where can they be taken out? And to even begin to have that conversation, I think this conversation that is happening in some places in the market, but I don’t think it’s super well understood is context engineering. I think that’s a really, really big deal. Yeah, we’re piecing all that stuff together and that’s what I’m betting on.

Stacy Gordon:

Well, I know you said that this is your thesis, but have you actually seen it start to work in any engagements that you guys are doing today?

Mike Cottmeyer: Yeah. Well, so it’s funny. What that brings me to is I pay a lot of attention to X and Substack and different things, and so I’m trying to figure out where people are talking about what they’re doing. And I read this article, there’s a couple articles I’ve read that have really kind of lit up my brain. And this one article was talking about the idea of going to CIOs or CEOs and saying, “Where in your organization do you have a hundred people doing something where two people could do it?” And going down that path, that’s kind of lit my brain up a little bit. And then this one person talked about this idea of, “We’ve done this a hundred times.” I just went, “I don’t think anybody’s done this a hundred times.” I mean, the technologies to really do it, and again, I’m sure they have a context and I’m sure they’ve done whatever they’ve done a hundred times. They have a context, but in our context, nobody’s done this a hundred times. Technologies didn’t exist six months ago to do some of the stuff that we’re doing.

The case that I have to make is that Liminal Arc has 16 years of doing this by hand. LiminalArc has just within our company, not to mention the people we’ve hired in to help us with this, we’ve been doing extraction and modernization work for six years by hand. We know the first principles of doing all this stuff and we know where humans and judgment need to be in place. And now with the advent of AI, what started to happen specifically over the last year and a half is we’ve been slowly building the pieces into the client engagements that we’ve done. So we have clients that we’ve done ingestion and extraction work on their code bases using something we just call internally Code Navigator. And as we’ve extracted and rebuilt, modernized different applications that we’ve done by hand, we’ve slowly started to bring in agentic practices into that to speed up that work. We’re doing a lot of stuff with agentic playbooks on our side internally. We’ve started working with some of our customers with regard to agentic governance.

And so all these little pieces that are emerging in the marketplace are all starting to snap to grid. And what’s kind of interesting is that because we’ve got this integrated methodology, we’ll use AI and we’ll use these techniques for the places where they’re mature and we can do them. And then we still have the background and expertise to do it by hand in other places. And we know the pitfalls in all the different areas just because we have so many reps doing it over the last 15, 16 years. And so where have we seen it actually work? We’ve seen it actually work by hand all over the place. We have some really, really solid use cases going right now where we’ve saved and made clients lots of money implementing these things and they’re just becoming more and more identified over time, which kind of ties me back into the bet that you asked earlier. I don’t think this is going away. I think the AI failure modes are going to become more endemic.

The AI is shadow IT is going to become more endemic and it’s going to get worse before it gets better because the technology is advancing faster than I think most humans and most organizations can absorb. And so that kind of gets me to another piece of this thesis I have that, and again, you just have to untangle some of this stuff because people see what they can do in work groups. I haven’t written code seriously in 30 years. And I was on a ski trip with my family in February and in like five hours built an iPhone app. Didn’t even know the mental models for what’s it? I mean, I used to write C code back in college. Wrote some stuff in Lotus Notes back in the day, VB a little bit back in the day. Never did anything in Xcode, never did anything with Swift. In four hours I have an iPhone app on my phone. Last weekend I was like, “Oh, I think it’d be kind of cool to have an app that did this. Let me see if I can write it.” So there’s all these powerful use cases that we’re experiencing and I think that’s hugely successful. Individual productivity, 100%. And then on the other side where I think we’re going to see AI have a really big impact is I took the leap and bought a Tesla with self-driving this year. Mind blowing, mind blowing. It’s super cool. It’s the only car I want to drive. I got a couple cars and it’s like that’s the only car I want to. I say drive. I think I’ve driven it 5% of its total miles. And so I think we’re going to see huge leaps in devices that use AI.

I mean, it’s going to be all over the place. I’m excited to see what the near future holds in that.

But kind of my thesis is that where humans are actually required, we’re building products for humans or humans are required to be part of the process of building it, their taste and judgment and expertise and background, all stuff that can’t really be modeled into a context engine. I think it’s that middle ground that is going to be, for the next three to five years as organizations transition and try to figure out how to get their heads around this, you could make the argument that some companies are just going to go out of business and they’re going to be taken over by smaller companies that. I mean that’s the whole thesis behind SaaS right now. Sure. I don’t know. I don’t know. I don’t think I’m totally sold. I know a lot of our clients are running mission critical software on stuff that they can’t really do agent decoding on safely right now.

They can’t really run great AI type use cases on right now. And so for that big group of people in the middle that are going to struggle with this and they’re going to be in business and they’re going to thrive and they’re going to have clients and they’re going to have people, but they’re still going to want to use AI and they’re going to want to use it well and they’re going to want to use it in a structured, controlled, governed way. I think there’s going to be a space for that for a while. Does that change in a year, three, five? I don’t know, right? Back to the bet thing. I mean, I think everything’s moving so fast right now that I don’t think anybody knows exactly where this is going to go or where it’s going to land. And so if you want to use AI and you want to optimize your AI use and you want to get the most out of it, I think we’ve got a story and I think we can help kind of a thing. So it’s kind of a messy answer to have you seen it work? Yes, we’ve seen it work. Have I totally seen it work end to end? Nope. But I think we’re close. I think we’re close and I think we’re close enough to really start talking about it and share what we’re learning. I think there’s going to be some people that are going to go along for the ride with us.

Stacy Gordon:

Well, I love it. I mean, I think when you think about your history and understanding the change management piece and then the engineering, you’ve done both sides of the coin. And so I think that really allows you to see opportunities earlier because you’ve seen the pattern, right? Yeah, for sure. So I’m really excited that you were able to share all this with me today. One of the questions I like to ask a lot of the guests that I have is that if you were going to talk to a CTO tomorrow or a CEO that goes into the office tomorrow, what is something that you would encourage them to think about differently based on some of the things we’ve talked about today?

Mike Cottmeyer:

The thing I think, and again, I think it’s the thing that nobody’s really talking about, is my imagination has been captured by this idea of context engineering. And it’s fascinating because if you’re paying attention online, the conversations move so fast. So we’re talking about one day we’re talking about prompt engineering and the next day we’re talking about context engineering and the next day we’re talking about loop engineering and then somebody starts talking about memory engineering. And then the thing that seems to be bouncing around right now is graph engineering. And it’s all stuff. I don’t think the industry’s really caught up with prompt engineering and then everybody’s saying it’s going away. Well, there’s a lot of prompting going on out there. You know what I mean? So the engineering moves, the thing people are talking about moves and everybody’s still trying to catch up with the first thing. But I think prompt engineering’s kind of solved. We have a company that we acquired earlier this year called Atomic that does some prompt engineering stuff. It’s actually really cool. Not really the topic to go into today, but it’s really cool.

The next feature set for that based upon a lot of the work that we’re doing is really around this idea of context. And I think I talked a little bit about that earlier, but this idea of how do you ingest all the streams of information that an agent would need to know to make a good context aware decision? And so that’s when about six, nine months ago when I started playing with this really heavy, I’m like, I don’t see how people use AI without a context apparatus around it in a meaningful way. I mean, sure, you can upload a document, you can work on a paper, whatever, but if you want to have long running, I don’t even say conversations because that’s still kind of achievable too. But as the world changes around you and the AI needs to make decisions along with you, how are you building that context engine around you? So I got really passionate about that. There’s a small group of us within LA that we’re really passionate about it and we’re starting to roll it out and create context engines for our company. And we have clients that we’re building context engineering with not only to support our teams, but to support what they’re doing there. And again, the simple thing that you can do is just get your Claude account and point at it in Obsidian database and just tell it to start remembering stuff and just start putting stuff in it. That’s the best thing that you can do. And then it’ll start remembering all the stuff around you.

And then if you want to get really interesting with it, you can connect your email to it, you can connect your calendar to it, you can connect your to-do list to it. I have it ingesting recordings of all the meetings I go to, which is absolutely game changing when it starts to understand the conversations that you’re having outside of when you’re talking to it. And then I journal every day and so I load my journals into it and I save X articles and. God, I just lost it for a minute. X articles and Larry, it doesn’t matter, right? Just other websites and things like that. You just ingest everything that you’re thinking about into it. And what’s fascinating is over time, and this is kind of the behavior you want, it starts making connections between things. And then you can ask it long running questions like, how has my thinking on this evolved over the last year? Since I have so much journal information I plugged into it, how has my thinking on this topic evolved over the last eight years? That’s fascinating. How have my tools and techniques and the things I talk about evolved? What have the seasons of my life been over the last eight years? It’s crazy to be able to look back on that. And that’s why I think that’s going to be so much the key to the things that we do where humans are required. Again, I think humans are kind of like natural context engines. We just somehow store all this stuff in our brains. And if we want AI to be able to approach that level of decision making, it has to be exposed to the factors that are going on in your business and the conversations that are happening in your business.

And yeah, humans can be in the loop and they can monitor it and they can decide what’s canonical versus what’s transient and all these different things. But your question was, what should executives be paying attention to? I think I just tell everybody, just get a cloud account and connect it to an obsidian database and just start playing with the power of it. And once you see that, it’s something you can’t unsee. And then maybe the other thing is there’s a lot of noise in the industry right now, and I think it’s just going to get noisier. And so I think at some level you’ve got to figure out what you’re going to ground into, what’s going to be kind of your floor. And that’s where I’ll go back to some of the first principles. This is just kind of a funny aside, but as we started moving in and started doing more cloud work and I started getting up underneath the hoods of it, I used to do virtual server stuff back 25, 30 years ago when I was doing, and I’m just like, “Oh, that’s the same as that. Oh, that’s the same as that. Oh, that’s the same as that.”

And now granted, the technologies are more advanced and it’s more at scale and it’s more widespread and it’s more robust and everything. It’s the same fundamental concepts. And so yeah, these principles and patterns are the things that are fundamentally timeless in this. So whether it be the patterns of change management or the patterns of encapsulation or organization or the patterns of how to get humans to move or how to optimize an organization or how to structure an organization or how to structure a technology stack, it’s all the same stuff. How to structure data, it’s all the same stuff. So now what we’re trying to figure out is where AI can help us in that work, at least again, for the companies that are in the middle trying to figure out how to apply AI into the things that they’re doing now. And so yeah, that’s my take on a lot of this stuff.

Stacy Gordon:

Well, I think it’s easy to feel or for people to feel out of control, but I love what you’re saying is anchor to the fundamentals and the patterns because that gives you control back and you can then make calls with confidence. And I think the other thing that really resonated with me of what you said was knowledge is power and you’re out there doing the things so that you can lead and have conversations with people about what you’re actually learning and experiencing and there’s nothing better than that, Mike.

Mike Cottmeyer:

Yeah. It blows me away that I’ve been running this company for 16 years and I’m just messing around in my office and I’m out talking about stuff that seems all over the place in my world, but I don’t think the stuff is all over the place in everybody’s world. I mean, vast majority of humans are still using ChatGPT as chatbots and an advanced Google search. And there’s a couple more steps that are really ready to take advantage of right now that I think are accessible to most folks. And so yeah, just get in and start playing with it and see what’s possible. And AI will tell you how to do it. Well, that’s pretty cool. Hey, I read this article. How do I do this? It’ll say, do this, do this, do this. The barrier to entry has gotten pretty low on being able to optimize yourself at this point. And then what you start to realize, you optimize yourself, you can optimize your work group, you start to optimize your company, you start seeing the patterns, and then you’ll just realize they’re all the same.

Stacy Gordon:

Well, Mike, this has been great. I cannot thank you enough seriously for joining me today. And let’s be clear, I hope it’s not another year before you decide to sit down and shsre your thoughts again.

Mike Cottmeyer:

Yeah. Well, I’m going to be writing a ton. So what I’m going to ask you to do for me is just pay attention to stuff I’m writing and then let’s just, on some of the further ones, as we start to go down blog post series or whatever, let’s just pull them apart and let’s have a conversation about them.

Stacy Gordon:

Well, I would love to do that. So thank you again, everyone. This is future state now. We have a number of great conversations on tap, so I hope you’ll join us again soon. Thanks.

In this video, Stacy Gordon sits down with John Greisner, a management consultant at LiminalArc, to explore why AI doesn’t remove your software delivery bottleneck so much as move it. Drawing on Goldratt’s theory of constraints from The Goal, John walks through what happens once engineering gets fast and cheap: the real slow point shifts to product management, funding cadence, and how much change your customers can actually absorb.

Stacy and John dig into why flooding your backlog with every new idea only makes that constraint worse, and why deciding better, smaller, and more often works instead. Watch so you can stop chasing engineering speed as the finish line, start treating decision capacity as your real constraint, and finally get the return on AI adoption that an operating model built for a slower era has been quietly blocking.

Video Transcript

John Greisner

AI is definitely an enabler to help build things more efficiently and faster and to automate the things that were often manual. And so the engineering work has gotten fast enough and more efficient in reducing costs that it’s kind of prompting a whole new set of questions. Where is the constraint in the system? Where is the weakest link? We are now looking at other areas that are slower than the build cycle that we’ve been trying to follow from engineering to the front end. Once you sell the front end, really then the question is how much could our customers even consume and be able to take to make it effective that they’re going to love our products?

Stacy Gordon

I’m Stacy Gordon, and every week I pull up a chair with someone willing to talk about all the unglamorous stuff that is really behind why the thing actually works or doesn’t. My guest today is John Greisner, a management consultant with Luminal Arc. John published an article titled The Bottleneck Moved: Your Operating Model Hasn’t. And it’s one of those articles that honestly I had to read many times. But at the end, John, your takeaways were simple, but extremely powerful. I’m very excited that you’re on the podcast with me today. Welcome.

John Greisner

Thank you, Stacy, for having me. I appreciate the opportunity to share a little bit more. It was kind of a fun write for me for several reasons, but I do love the story from the book The Goal and it’s one of those pieces of work that’s been around for many years. Companies like Amazon and Tesla through Elon Musk and Jeff Bezos are always kind of promoting the reading because it really teaches a lot of fundamentals about building things. And in our world, mostly we’re talking about building software, but it does teach us the very important lessons about where is the constraint in the system, where is the weakest link? And so the story of the hiking is one of those examples that’s in the book. And I can share my own hiking story. I took a whole group of nephews and nieces and friends out a couple summers ago and I had to live through the story myself.

And it was kind of funny because in the back of my mind, I am thinking about the book the goal and the hiking. And so we started off and the younger guys, they’re just sprinting up the hill and we’re all trying to keep pace. And there was a few of us, me included, that probably hadn’t hit the gym enough and we were kind of huffing. And so we ended up getting spread out. And so we all wanted to stay together and be able to get there at the same time. So the plan was is that I would go first. I would set the pace and I was setting the pace based on generally who was the slowest and that’s how we all kind of stayed together. So that’s my little story and I’m sure you all have similar stories that you can relate to.

Stacy Gordon

Oh my gosh. Well, I love it when something in your real life actually ties back to things that you experience in your professional career. It always makes it more real for me. You’re actually making me want to go read the book. So I’ll have to put that on my list. But one of the things, you have a line in your article that says Goldrat’s rule has two halves and the second half is that a constraint you elevate does not disappear. It moves and it rarely announces its new address. I really loved how you phrased that. So basically your argument is that most companies finally fixed their old slow spot. They found Herbie, they fixed building software, but they didn’t realize that a new slow spot was going to take its place. When did you start seeing this?

John Greisner

Yeah. So I mean obviously in delivering on a lot of the AI work that we’ve been doing over the last couple years, AI is definitely an enabler to help build things more efficiently and faster and to automate the things that were often manual. And so what we’ve started seeing in a few of our clients that we’ve been working with through this phase is that the engineering work has gotten fast enough and more efficient in reducing costs that it’s kind of prompting a whole new set of questions. And so it’s really a statement about yeah, it’s a tremendous accomplishment for a lot of the companies that have spent decades to focus in on adding agile practices, DevOps, cloud migrations and all the different capabilities to make that engine DevOps as well to really make it work more efficient and faster and cheaper. Even breaking down work, like I said, between 90 days of strategy, all of that helps get worked through.

But what it does is when it’s done is to the point of the book, the constraint moves. And the question that I’m posing is where does it move and what’s next?

Stacy Gordon

And so do you find, this is relatively a new concept, right? AI is changing on a regular basis. You hear customers constantly trying to figure out how they use it to develop faster. So do people even realize that they’re solving this problem, the engine of building software was always slow. Have they even really grasped the fact that they are kind of moving their bottleneck somewhere else? Do they recognize that that’s what it is that’s happening to them?That’s

John Greisner

A funny question because when I started reflecting on this this spring after seeing it, it actually took me by surprise because like I said, we’ve been working this problem for decades in this very specific area of our overall strategy to deliver customer value. And so it kind of became that epiphany moment to be like, oh my God, we are now looking at other areas that are slower than the build cycle that we’ve been trying to follow. So this is another reason why I wanted to write the articles because I love being aware of what’s coming and it even took me by surprise because the short time it took to really implement the full benefits is why.

Stacy Gordon

Well, I bet it’s a fascinating conversation to have with executives at companies because again, I’m sure they’re having that same aha moment that it’s taking them by surprise now that they’re sitting here kind of faced with different challenges. So you talked a lot about a company’s operating model, the wiring that turns strategy into things customers actually get was built for a problem that no longer exists. In plain terms, what do you mean by that and why is that kind of what I believe is probably the real headline here?

John Greisner

Yeah. So I mean the operating model, all the components kind of stay the same. So what we’re essentially doing when we’re implementing AI is we’re kind of adding almost like a race car engine to the process. And the way that I kind of think about that a little bit and the effects of that is that if you have your operating model and it’s not quite kind of wired to some of the points that I said earlier, like you don’t really have your DevOps kind of squared away, your practices and synchronizations are a little bit off and not really flowing, you add that bigger engine and it’s like putting it in an old car with a bad front end and you’re going to go off the road a whole lot faster. And so that is some of the things we’re hearing too. They’re like things are getting crazy and we’re discovering a lot more things.

So it amplifies all the operating model components. And so there are different pieces of it that start to need to be tailored a little bit more for that faster engine.

Stacy Gordon

Okay. I loved that description of the old engine with the bad front end and running off the road because I’m sure that that’s what people are feeling like right now. They’re like going, “We’ve solved a problem that we’ve been trying to solve. We’re now going super fast. We’re going to win the race. We’re going to win the competitive race,” but yet they’re not starting to see or they’re not feeling like they’re accomplishing what they though they would by being able to develop and do things faster. If you look at all the wiring that’s in someone’s organization, so all the different pieces of the operating model, help me understand how do decisions get made? How often do you plan? Who owns what? Which roles matter? Which one of those kind of gets out of date the fastest, right? So we’re turning our lens to look at the different parts of the business.

So which one of those do companies need to start looking at?

John Greisner

It’s really who’s been impacted the most in this change is the product manager. One that is getting the feedback from the engineers and the one that’s responsible for providing the highest value of work. They’re being asked more frequently. So the change in which if you think about a team that maybe might do two week sprints, the product manager is trying to build up that backlog. We tend to like to have a little healthy backlog of like two to three sprints out so there’s clarity on the team and what they’re going to be doing. That gets consumed really fast if you have a high speed engine in there. And so that puts a lot of burden on the product manager to keep that backlog healthy as well as validating did they build the right thing? Is it fit for purpose? And being able to. So it’s really putting a lot of strain and stress on that one person and that’s kind of the biggest impact.

How do they then navigate this new world that they’re living in?

Stacy Gordon

Yeah. I think that’s interesting because I think one of the concepts that you had in my plain language is that if ideas are cheap or free, why not build them all? Why does throwing more ideas at the problem actually make things worse? And so this is really, I think, what you’re describing for that product owner of going, he’s got people coming in from every direction giving him all these new ideas and he’s got this really fast engine of being able to build them, but that doesn’t necessarily mean that you should just because you could.

John Greisner

That’s right. And I think that’s the hazard or the impulse is just fill that backlog as fast as you can for them. And that puts a lot of stress on the back end of it, which is the customer receiving things they really don’t need and the change impact to that. So it really takes that discipline, which we have been talking about for many years too, to understand what’s the highest priority and being really spot on. And so it’s that decision that is first and foremost on the spotlight now. It’s like make clear decisions on what the customer needs and being able to prioritize that.

Stacy Gordon

So you believe that a company can actually get better at that. That is something that if they have the right guidance or the right framework or the right research, what is it that a company can do to kind of make more informed decisions about which ideas are worth investing in and which ideas aren’t?

John Greisner

Well, and AI, just like with engineering, is a great companion to help those discussions, but it still, at the end of the day, takes a human to be able to make that judgment call on what’s the most important business problem to solve, what capabilities need improving and to be able to do that. But they do have a helper too to kind of go through and vet ideas, but the cost of delay scenario that I mentioned in the article is a little bit different than the way it’s traditioned because we’ve often looked at how much effort someone takes over value. And now with effort being low, we’re really focused on highest value and what that means to our customers. So the disciplines are there. I mean, different companies excel in that space a little bit more than others, I would say, to the point of if your capabilities and skills aren’t there, this is going to amplify and make it clearer.

So if companies are still struggling with product management and how it should work and connect to strategy, you’re going to feel this pain much more and more faster essentially.

Stacy Gordon

Well, one of the things I thought was so interesting or the claims from your article is that it talked about the real slow point actually may be outside your company entirely. Customers can only, and I love this word, absorb so much change. So how did you actually land on that?

John Greisner

Well, so it’s really the full circle. So in just thinking about if we trace this constraint, if you will, from engineering to the front end, once you sell the front end, really then the question is how much could our customers even consume? And we’ve all been victims to too much change and the change fatigue we feel in some of the products that we use and how rapidly. So it is a real problem and a challenge that companies are now going to have to really wait and take a look at. We didn’t have this problem so much because we often couldn’t keep up with what the customer needed.

Stacy Gordon

So

John Greisner

That wasn’t the problem space, but now we do have to really weigh how much can the customer consume and be able to take to make it effective that they’re going to love our products. So we are now dealing with really two different areas that are highlighted now because of the faster engine.

Stacy Gordon

Yeah. I do wonder, again, I think the pattern within your article talks about, again, having to look at different areas of the organization under different lenses. And so I can only imagine the heightened effort that an organization will have to put on customer research of being able to go, okay, we’re going to really have to measure the changes that we’re making to start getting that real powerful feedback fast so that we are kind of meeting the pace that they’re interested in. Not going too fast, but also not going too slow.

John Greisner

Yeah. I love what you’re saying about measurements because we focus so much on engineering measurements to make sure that engine is running smoothly and is efficient. And we haven’t so much on the front end and back end because that wasn’t our constraint, that wasn’t our problem. But now that those are becoming first class rights to focus on, we have to think about what are the metrics that we want to kind of measure to make sure that we’re not causing or slowing the whole system down. So the question on ideation becomes really a powerful area that we’re going to have to look at and see how long does it take to iterate through our ideas and connect the strategy? Because if it takes us the same amount of time, which was very forgiving in the because we were waiting always on the engineering side to finish the work, God bless them for all the hard work that they have to go through.

So we had slack in the system to be able to deal with this problem. Now the slack is being taken away, so we have to really manage and measure that side as well as like you said, the customer side too, how much could they consume?

Stacy Gordon

Well, and I think it’s probably something that they didn’t even realize that it’s like, I’m sure nobody really had a foundational measurement for how long it took to go from ideas to getting them vetted and put them in the backlog, right? They were just constantly complaining that their ideas never made it out fast enough. So I think the change that organizations are going through is in such real time evaluation of all of their different parts of their organization that they probably, when we talk about that bottleneck or that constraint moves, is it always the product person that they go to first or is it even if the product person gets something, is there more of a revenue officer that might have it sitting on their desk? I mean, I’m assuming an organization may have to look across the board to see who’s slowing the process down.

John Greisner

Well, it’s all interconnected on the front end and even starting to signal, and I mentioned it briefly in this article and there’s another article that’s going to come out in talking about the portfolio side of it with funding. And so when we talk about how often do we fund ideas in this new world of going from ideation to delivery much faster, that feedback loop into how we fund and how we allocate across all the capabilities is also going to connect to that. So the front end is all interconnected. And so what the product manager will need is ability to flex much more faster than the system was willing to do before. Well,

Stacy Gordon

On the finance end, I do think that’s interesting because I think traditionally you get a bucket of money, you build out a roadmap, you align budget items to each one of those things. So maybe that’s where you’re getting that flexibility on the product owner to go, from finance and them managing their P&L, you can’t really look at it the way that you used to do on your roadmap. Okay, I’ve got $100. I’m going to $25 in first quarter for this feature and $25 in second quarter for this feature. I mean, you have to be able to change and move faster about even your overall thinking about budgeting.

John Greisner

Yeah. And like I said, some companies have narrowed the focus to look at budgeting more frequently. Some do it on quarterly. Some are still locked into the annual. And so for those that are still locked in, then there’s going to be definitely a system constraint or a barrier to be able to move faster because it’s tied to something that isn’t, I’ll call it cadenced or synchronized. And that’s something also that I mentioned about one of the changes is that you have to reevaluate your cadences based on your placement of that and the frequency you need to make that decision. And funding is one of those that it does get impacted if you’re able to produce more quickly.

Stacy Gordon

So ultimately, if you kind of step back and you start to look at the entire organization, I mean, ultimately this could mean full organizational transformation unless you just want to tackle one small little thing and then figure out where the bottleneck moves. It potentially says, “Hey, for the best of the best companies out there who recognize they’ve solved this 20 year problem of software development that they’ve had, they really should probably look at the organization over as a whole and start really using those different lenses to kind of identify perhaps for them specifically what their problems are.” But organizational management change and transformation has always been slow and painful and can cost a lot of money. So in your mind, how long is this really going to take for a company to be successful and where do they maybe start or where do they maybe get stuck?

John Greisner

Well, so I think looking at the fundamental question is where is their slowest part is where they should start. And so different companies are in different places in adopting AI, but the cautionary tale is a little bit like if your system isn’t set up to handle a faster engine, you probably have some work to do still in the area of the build to be able to apply it. And so like I said, it’s going to amplify a lot of the outer boundaries and even the things within delivery, it’s going to amplify. So back to the car metaphor, it’s going to steer you off the road very quickly. So I hate to say it depends like the consulting answer, but it depends on where you’re at, where your problems are. But as people are kind of trying to gravel with adopting AI, they’re running their pilots, they’re trying this out, and there are definitely some challenges they’re starting to see.

And I think the challenge is really putting the spotlight on their operating model. And it’s a good thing to try to advance and companies are looking to use it, it is going to highlight deficiencies or other areas that need to be fixed. So transformation is a loose word, but just implementing AI like, “Hey, if we just do these couple things and we set up the AI environment, we’re good.” It definitely impacts a lot more than just the capability itself. So to your point, it’s a wider change that you need to think about and strategize around.

Stacy Gordon

Well, that’s what I thought was interesting about your article too, your example leader, Alex. He doesn’t fix everything. He just starts because sometimes analysis by paralysis. And so if someone were to take a first step, what would you recommend they do?

John Greisner

Yeah. So I think a great question first and kind of lead into when we think about transformations, limital arc, we do like to think about it as a slice, one particular area. And so you can continue to develop the capabilities and understanding and competencies around AI, running some pilots, looking at it, but really look at one slice for your organization and see how you would implement it and the changes you would make and then be able to kind of scale that out. So take more of a pointed view on, yes, fixing the one problem, but in more of an isolated area until you understand the impact and change to the overall area.

Stacy Gordon

I loved the takeaways. I mentioned this up at the top of the interview, that I felt like I walked away with three really simple items from your article that made a lot of sense to me. And so I want to make sure people hear these and walk away with them as well. So it basically says your bottleneck moves. When delivery becomes fast and cheap and is no longer the bottleneck, the bottleneck will find a new address and you need to figure where that is before optimizing anything else. Number two, upstream. The scarcity is decision capacity, not ideas. Feeding the funnel faster makes the bottleneck worse. Deciding better, smaller, and more often makes it work. And finally downstream, the customer sets the pace. What they can absorb, not the capacity, is the final constraint. So build the cadence that senses it. Anything else that we’re missing from those three things?

I think they’re simple but powerful in ways that leaders in their companies really need to look at AI, how they’re using it and how they’re going to be competitive in their landscape.

John Greisner

Yeah. I mean, the important thing is start where you’re at, but understand where it’s going too. That’s the important thing. As you do start to resolve and implement some of these benefits, you will need to start looking more at the pace of the customer. You will need to address the front end frequencies, the funding models. And so yeah, but start exactly where you’re at, just keep moving. And if you have more work to do in the build area, that’s the place to spend it. You can definitely start to take advantage and have AI and some of the agents and skills help you through that process. So there’s some great ways to leverage to get you to a full implementation. So

Stacy Gordon

John, one of the things that I always like to ask is if we had a product owner, for example, listening to our conversation and you were going to recommend him one thing to do on Monday when he went into work that he could impact or change based on what we’ve been talking about, what would it be?

John Greisner

Yeah, I think the first fundamental is what we’ve talked about with cadence and placement. And so the one company that we’ve been working with for a while, one of the things that the product manager quickly did was as the team changed from more of a scrum base to a flow base because time boxing in that sense didn’t make as much sense with the synchronization, it was about placement of those decisions. So understanding what are the decisions you’re making upstream and downstream and then repositioning the cadences around that. And so that will help smooth out what they need to do and keep things going to help kind of flow the work through.

Stacy Gordon

Sure. Well, I think that one big takeaway for me is if people aren’t open to change, they’re in big trouble because I think we all have to look about how we change from a very personal level and how we do work and productivity to an organizational level and at a competitive level and things like that. So I definitely think people better be ready for change for sure.

John Greisner

And there’s a little bit more summer left for your summer reading, and if you haven’t had a chance, you can first read the article, but also read the book the goal that this is based on.

Stacy Gordon

I mean, listen, John, we cannot put too much on my reading to-do list. Let’s be clear. I mean, I’m a girl of $2 words. We talk about it all the time, but I felt like it was very interesting. I’m going to put it at the top of the list, which I have two books on it. So I think we’ll definitely be able to get there. So now I’m going to turn it back to you now that I’ve told the whole world about my maximum two book reading list. I always like to ask my guests two questions. I am a big energy drink fan, and so I’d like to know from my guests, what’s your energy drink of choice and why?

John Greisner

I’m going to throw you off a little bit. It’s probably water.

Stacy Gordon

Water. Oh my gosh. And the answer I never thought I would get, water. Okay.

John Greisner

And maybe at best Gatorade. So that’s my-You’re not

Stacy Gordon

Even

John Greisner

A coffee drinker? I drink too much coffee in the morning, so I have to make sure I stay hydrated in the afternoon.

Stacy Gordon

Oh, another healthy guy. I love it. Okay. I will just on the side stick to drinking the bad energy drinks. Okay. Now the real question, this is my favorite. If you were invited to pick a topic to present on at a conference, what’s a topic you would choose that would get you booed at the industry conference?

John Greisner

That AI adoption is easy.

Stacy Gordon

I mean, you definitely get some giggles for sure. Yeah,

John Greisner

Definitely.

Stacy Gordon

Especially since what’s the actual number, less than 20% of enterprise AI efforts are actually in production today. So I’m going to make sure I get a ticket to that conference for sure. Well, that is a wrap everybody on our topic today. The bottleneck moved, your operating model hasn’t. John, if listeners wanted to find this article or get in touch with you, how would they do that?

John Greisner

Yeah, you can go to the liminalarc.co website and under resources, you’ll find a series of blogs, and this is one of them to what Stacy mentioned. We do try to publish pretty regularly industry perspectives and helps as people are trying to gravel with some of this information. So definitely encourage you to sign up for it and take a read.

Stacy Gordon

Awesome. John, again, thank you so much and thanks to all of you who tuned in. If this made you side-eye your own company a little bit, good. That was the plan. Share our conversation with the one person who needs to hear it. Hit follow so our next conversation finds you, and I’ll catch you next time. Same chair, more caffeine and a new topic. Take care.

My last six posts made an argument: AI fails on conditions, not models; capabilities are the unit; AI has three jobs and one it can’t take; transform by slices, never all at once. The most common response I get is some version of: okay, I buy it. What do we actually do on Monday?

Fair question. Here’s what it looks like on the ground: the way we run it, and honestly, the way anyone should run it, including your own internal team. Steal the process. The stages matter more than who executes them, and each one is built to earn the trust the next one spends.

Stage One: Understand, Before Anyone Signs Anything

It starts with conversations, not contracts. The lay of the land: who the players are. Who owns what, who’s carrying the board pressure, who becomes the champion, who might feel threatened. What the goals and objectives actually are, in the sponsor’s own words. The known constraints: regulatory, technical, political, budgetary. Every enterprise has walls that don’t move, and pretending otherwise is how proposals get written that deals die on. And most important: what success looks like, in numbers somebody is willing to write down.

Underneath those questions we’re really testing two things from earlier in the series. Is there a real business problem with money attached, not a use case hunting for a justification? And does the fourth condition exist: is intent governed, is there a sponsor who can say what winning means and kill what isn’t working? If either answer is no, the honest move is to say so and stop. Trust required so far: none. Cost: conversations.

Stage Two: Align on One Room, One Frame

Next, a working session with the leadership and the people who’ll live with what follows. We walk the argument you’ve just read: why pilots die, the four conditions, capabilities versus applications, what AI is actually for, why slices. Not as a pitch, but as a working frame the room applies to their organization in real time.

Remember the warning about automating the artifacts, that the point of a story was never the story but the shared understanding? The workshop is that principle applied to strategy. The deliverable isn’t the deck; it’s collective cognition: a leadership team that can make consistent decisions about this work when nobody from the outside is in the room. The test of a good workshop is the same one I’ve seen convert career transformation leaders: everyone can locate their own work inside the frame. The output is concrete: shared language, and a chosen area of the business where the pain, the value, and the appetite line up.

Stage Three: Hypothesize Where We Think the Seams Are

In that chosen area, we form an extraction hypothesis: which capabilities we believe are trapped in which containers, where the value sits behind which seam. Notice the word. It’s a hypothesis: written down, specific, falsifiable. That’s what directed R&D means, and the next stage exists to test it. The code gets a vote.

Stage Four: Ingest Two to Three Weeks of Truth

Then the navigator goes to work. We ingest the code, and the data around it, and map what’s actually there: domains, subdomains, bounded contexts, the duplicates, the dependency knots. Machines do the archaeology at about 80% accuracy; experienced humans judge the rest. Months of discovery compressed into weeks.

What comes out is the value backlog: the inventory of value propositions worth solving. Each is scored on two axes, how much the slice is worth and how cleanly it cuts, then sequenced economically by weighing value and cost of delay against effort. We are hunting for a specific shape: high-value use cases that can be extracted in ninety-day increments. And it’s a living backlog: the first study seeds it, every delivered slice refreshes it, and the ranking moves as the work teaches us. Alongside it, an end-state picture: if every piece could move freely, this goes to the ERP you already own, this retires, this gets built custom because it’s how we win.

Three honest notes. The depth of the map flexes with the need: some problems can be pulled apart and monetized without a full architectural view, some estates demand the deep map first. The stages don’t change, the depth does. Sometimes the study says not here or not yet, and a few weeks of truth that prevents a multi-year mistake is one of the best purchases an enterprise can make. And notice where we still are: nobody has touched production. Everything to this point sits deliberately below the trust barrier.

Stage Five: Extract the First Ninety Days

Now we cut the seam: the top of the value backlog. Inside the slice, the four conditions get created for real: the capability encapsulated, the data validated at its source, one team that owns it, your people on that team from day one, and intent governed by the number we wrote down in stage one. The navigator maps, the junior engineers build under test-first supervision, humans judge. The slice goes to production. And then the only measurement that matters: the value we promised is the value we produced, in numbers your CFO accepts.

Then the loop turns. Slice two starts easier, because slice one left the conditions behind. Somewhere around slice three, the cadence should be yours, not ours. The goal was never a permanent engagement. The backlog has a bottom: we go only as far as there’s economic value to be achieved, and when the marginal slice stops paying, the work is done. What stays when we leave is a capability that was previously not possible for you.

One structural promise ties all five stages together: every stage is a gate. Stop after any of them and you keep everything of value: the map, the frame, the backlog, the proof. If a partner won’t structure the work that way, remember the tell from the last post: anyone proposing to transform everything before proving anything is asking for trust they haven’t earned.

The whole series was the whole story. This is the first slice. Buy the slice.

This is Part 7 of a seven-part series. Start wirh Part 1 here.

The argument so far, in one breath: your pilots work and don’t pay because they simulate conditions your enterprise doesn’t have; the conditions are four, and testable; the place you create them is a capability, not an application; and once created, AI has three real jobs and one it can never take. That leaves the question every executive actually gets paid to answer: how do you run this? Across a real enterprise, with a real board, on a real clock?

Here’s where transformations die a second death. Having accepted everything above, the organization does the instinctive thing: it tries to do it everywhere at once.

Horizontal Is Why Your Last Transformation Failed

You’ve seen the horizontal play. Pick a layer: a new governance model, a new team structure, a new engineering practice. Roll it across the whole organization. Train everyone. Announce the operating model. Measure adoption. We watched this fail for fifteen years in agile transformations, and you’ve watched it fail in ERP rollouts, Six Sigma programs, digital, and cloud. The failure has a signature: everything moves and nothing finishes. Every team is 20% transformed, no team is done, the old system and the new system run simultaneously everywhere, and eighteen months in, the sponsors quietly stop asking.

The alternative is vertical: pick one slice and install the whole system in it. Not one practice everywhere. Everything, somewhere. One capability, cut at its natural seam, with new structure, clean data, a new delivery model, lightweight governance, and AI inside the boundary, all the way to production. When I walk transformation leaders through this, including people who’ve spent careers pushing horizontal change uphill, I have yet to hear a real objection. They’ve lived the alternative.

The Loop

The whole approach fits in one loop.

• Identify the business problem: a real one, with money attached, not a use case hunting for a justification.
• Carve the slice: the capability that owns that problem, cut at the seam, through the org, the application, and the data.
• Create the conditions inside it: the four from earlier in the series, built for real in one bounded place.
• Put AI to work: navigator first to map it, junior engineers under supervision to build it.
• Prove the value: in production, in numbers your CFO accepts, in roughly ninety days.
• Then do it again.

The pattern behind the loop is the strangler fig. The fig doesn’t fight the tree; it grows around it, capability by capability, until one day the old tree is structure, not function. That’s how you get off the legacy platform without the bet-the-company rewrite. Each slice you pull gets a deliberate decision: this piece goes to the ERP you already own, this piece retires, this piece gets built custom because it’s how we win. Slice by value proposition, never lift-and-shift. The backlog of slices burns down over time, and every one of them pays its own way.

Two disciplines keep the carving honest. First, slices are cut from a map, not freehand. The capability map and the end-state picture come before the knife, and every slice is a deliberate move on that map, so the slices accumulate into an architecture instead of a new kind of fragmentation. Second, the backlog is sequenced economically. Inventory the value propositions worth solving and weigh value and cost of delay against effort. Many of you know this as WSJF. Take them in that order, and re-rank as each slice teaches you something. All of which surfaces the thing no transformation program ever says out loud: you only go as far as there’s economic value to be achieved. When the marginal slice stops paying, you stop. The transformation has a bottom.

Ninety Days or It Isn’t a Slice

The economics are the governor on the whole system. If a slice can’t prove its value in about a quarter, it wasn’t scoped as a slice; it’s a project wearing a slice costume. Cut deeper. The ninety-day proof does three jobs at once: it pays for the work, it buys leadership patience with evidence instead of vision, and it de-risks the next slice before you cut it.

It also respects something the transformation industry keeps pretending away: trust is earned in stages. Nobody, no vendor and honestly no internal team either, should be handed production on a promise. The gradient runs: map the estate first, which requires almost no trust. Show the plan. Prove one slice. Widen the aperture. If somebody proposes to transform everything before proving anything, the size of the ask is the tell.

What Compounds

Here’s what the horizontal play never delivers and the vertical play can’t help delivering: each slice leaves the conditions behind. An encapsulated capability. Data that’s clean at the source and stays that way. A team that owns something and knows it. A governance rhythm that funds hypotheses and kills losers. The second slice starts easier than the first; the fifth starts easier than the second. Somewhere along the way, transformation stops being a program you’re running and becomes a thing your organization knows how to do, which was the actual goal all along. Not “we adopted AI.” Not a vendor relationship you can’t exit. A capability that stays when the program ends and the consultants go home.

The Whole Story

We drew a map: pilots live in the quadrant with conditions; enterprises live in the quadrant without them. We read the gauge: twenty working pilots and zero ROI is a measurement, not a mystery. We named the four conditions and gave you the tests. We changed the unit from applications to capabilities, and found the seams. We put AI in its three right jobs and kept judgment human.

And now the ending, which was hiding in the first post all along: don’t move the pilot to the organization. Move the organization, one slice at a time, to where the pilot can live.

Somewhere out there is a CTO with twenty pilots and a board asking where the money went. The next twelve months can be more demos. Or they can be four slices. Clean one boundary. Deliver one slice. Measure it. Do it again.

In my next post, we’ll explore why you can’t bet prodcution on a promise.

This is Part 6 of a seven-part series. Start with Part 1 here.

This series has been about conditions: why pilots die in production, what the four conditions are, why capabilities and not applications are the unit you create them around. Now the question underneath everything: once you’ve done that work, once a capability is genuinely free, encapsulated, with clean data and one team that owns it, what is AI actually for?

The market offers two answers, and both are wrong. One camp says AI replaces the engineers: the workforce story, the one boards want to hear. The other says it’s a better autocomplete: the skeptic’s story, the one your senior engineers mutter after the third demo. The truth is more specific and more useful: inside a clean boundary, AI has three real jobs. And there is one job it can never take.

Job One: The Navigator

Before AI writes a line of production code for you, it should tell you the truth about what you have. Point it at a legacy estate and it can extract domains and subdomains, cluster what changes together, map the data, and surface the duplicates. The archaeology I described in the last post, months compressed into days. Point it at your data, same move: don’t ask AI to make sense of the swamp, ask it to show you the swamp, where the data is born, where it breaks, where two systems disagree about what a customer is.

Two disciplines keep this honest. First, navigator, not oracle: in our experience this class of analysis comes back about 80% right, and the remaining 20% is exactly where the danger lives. Every finding gets a human judge. Second, the output isn’t the deliverable; the decision is. The navigator exists so that humans can decide where to cut, what to keep, what to kill, faster and with better information than archaeology ever allowed.

Job Two: The Junior Engineer

I’ve been calling AI a junior engineer all series, and I mean it precisely. A junior engineer is genuinely productive under specific management: clear scope, bounded assignments, tight feedback, and somebody checking the work. Rope management. Give a junior engineer a vague mission inside a tangled codebase and you get confident chaos. Give them a well-defined story inside a clean boundary and they’ll outwork everyone.

So the discipline inside the slice looks like this: keep the cycles small, the context high, and the dependencies low. Constrain the agent with tests: humans define what done means, the agent works until the tests pass, humans inspect what it did. The sandbox is the management system.

And here’s where it compounds. Inside a genuinely clean boundary, this stops being one developer with a copilot and becomes a delivery team of agents: distinct agents for analysis, design, build, test, and deploy, working a separation of concerns, supervised by a pair or two of experienced developers sitting above them at the product tier. The people who used to do the typing move up a level and orchestrate. Whether the delivery tier eventually needs any humans in it at all is a live hypothesis where the conditions are real. But notice what never goes away: supervision doesn’t disappear. It moves up.

Job Three: The Operator

The first two jobs work on the software. The third works on the business, and it’s the one everything else exists to unlock.

Something important happens once a capability is genuinely encapsulated: the business objects inside it stop being rows scattered across systems and become real, addressable things. The order, the claim, the candidate, the crew, the policy. Each with one definition, validated data at its source, a clear interface, and an owner. And once the business objects are clean, AI can act on them, and across them.

On them: the use cases everyone wanted from day one, finally standing on something. Triage the claim. Score the candidate. Route the order. Price the policy. Decisions made at machine speed, inside governed bounds, auditable precisely because the boundary is clean.

Across them is where it compounds. Because the bounded contexts share well-defined seams, AI can reason across the object graph: the customer as they actually exist across sales, service, and billing, with no data lake in between. Next-best-action. Anomaly detection before the quarter closes. Forecasts built on data you actually trust. New products assembled from assets that used to be trapped in the monolith.

Here’s the uncomfortable recognition: this is the job everyone tried to give AI first. The twenty pilots from the start of this series were almost all attempts at job three, launched before jobs one and two had created the conditions it runs on. The job was never wrong. It was just gated.

And notice what changes economically. The navigator and the junior engineer pay in cost and speed, which is engineering leverage. The operator pays in revenue, margin, and decision quality: the ROI the board was actually asking about. We think of the arc as extract, enhance, exploit: extract the understanding, enhance the capability, exploit the clean estate. Most of the market is trying to exploit what it never extracted.

The Job It Can Never Take

Everything above is execution. Magnificent, economically transformative execution, at machine speed, inside human-drawn bounds. What it is not, and will not become on any timeline that should affect your planning, is judgment.

Taste, insight, discernment. The connection between two ideas that no training corpus holds because nobody has written it down yet. The call that weighs a decision against twenty years of watching this specific industry punish that specific mistake. General AI has read everything public and knows nothing about you: your team, your clients, your history, the reasons behind the reasons. Without that context, it is, for real knowledge work, far less useful than the hype suggests. Building that context layer for organizations is, I’d argue, the most underexplored frontier in enterprise AI. Almost nobody is working on it. That’s a future post.

This is why the replace-the-humans story fails on its own terms: it automates the cheap part and discards the scarce part.

The Trap: Automating the Artifacts

One warning before the next post, because I watch smart teams walk into it. The artifacts of software delivery were never the point: the stories, the specs, the plans. They were the excuse for the conversation that got everyone on the same page. Have AI generate the stories and skip the conversation, and you’ve reinvented the functional spec, thrown over a wall, at machine speed. You haven’t saved toil. Automate the typing. Keep the thinking together. If your AI rollout is quietly deleting the places where shared understanding gets built, it’s amplifying more than your codebase.

So: navigator, junior engineer, operator, and a judgment layer that stays defiantly human. What’s left is the part the whole series has been building toward: how you actually run this. One slice at a time, proven economically in ninety days, compounding as it goes. That’s the next post.

This is Part 5 of a seven-part series. Start with Part 1 here.

The last post ended with a question: which slice? If the way out of the pilot graveyard is creating the four conditions in one real place at a time, one boundary with production inside it, then everything depends on where you draw that boundary. And here’s the problem: most organizations can’t answer the question because they are thinking in the wrong unit. They think in applications.

So before we can find the seams, we have to break a thirty-year habit.

When You Hear “Application,” Hear “Monolithic Container”

An application is not a thing. It’s packaging. It’s how a set of business capabilities happened to get bundled together: by a vendor’s roadmap, by an acquisition, by a decade of “just put it in the same codebase because that’s where the team was.” When somebody says we need to modernize the ERP, or we have to get off the AS/400, they are talking about the box, not what’s in it.

And what’s in it? Everything. We’ve run capability analysis against a lot of these systems, and the honest description of what comes back is an antique mall: live capabilities next to dead ones, duplicates of things that exist in three other systems, the genuinely differentiating logic of the business sitting in the same container as commodity functions you could buy off the shelf tomorrow. The application is a La Brea tar pit with all the bones in it. The bones don’t belong together. They just sank in the same place.

You cannot create the four conditions around a container like that. You can’t encapsulate everything. You can’t assign one team to own all of it. The application is exactly the tangle we’ve spent two posts saying you can’t automate.

Capabilities Are the Unit of Decision

A business capability is a thing your company does: take an order, screen a candidate, dispatch a crew, price a policy. Capabilities decompose cleanly: domains, subdomains, bounded contexts, all the way down to the data. And unlike applications, capabilities have natural edges. A bounded context is precisely the line where one definition of customer ends and another begins. Those edges are where encapsulation is possible. Which means those edges are where the four conditions can actually be created: where a team can own something, where data can be validated at its source, and where an agent can work inside a boundary instead of drowning in a container.

This is the answer to which slice. A slice is a capability, cut at its natural seam, taken all the way down through the code and the data.

Nobody Knows What’s in These Things

Here’s the objection, and it’s a legitimate one: nobody in your organization can tell you what capabilities live in the estate. The containers are dark. The people who packed them are gone. The documentation lies.

This is where AI earns its first honest paycheck, before a single agent writes a line of production code. Point it at a legacy codebase and AI-assisted capability extraction can map the domains and subdomains, cluster what changes together, and surface the duplicates. In our experience it comes back about 80% right, with humans judging the rest. Work that used to take months of archaeology compresses into days. Notice what that is: AI as navigator, making the estate visible, not AI as easy button rewriting it. That distinction is the whole subject of the next post.

Better Seams to Cut

Once you can see capabilities instead of applications, a strategic question replaces a technical one. For each capability, ask: is this where we win, or is this table stakes? Where you differentiate, it deserves to be custom: encapsulated, owned, evolved, eventually agentic. Where you don’t, it belongs in a system you already have. Most of what’s inside that AS/400 isn’t going to be custom software in your future. It’s going into the ERP, the GIS, the platforms already on your floor.

All of which exposes lift-and-shift for what it is: repackaging the tar pit. Point AI at the whole container, rewrite it, and you get a new big application nobody understands, still unintegrated, with all the hard decisions still unmade. The alternative isn’t heroic. Draw out the cuts before you touch anything: this piece to SAP, this piece retired, this piece custom because it’s how we compete. Then cut one seam.

So what’s the recommendation here? Exactly what it sounds like: build the capability map. You don’t need to boil the ocean. Pick the area of the business where the pain lives and map that. It’s the first artifact of everything that follows, and it’s the one deliverable you keep no matter what you decide to do next.

Stop modernizing applications. Start liberating capabilities. The next post is about what AI actually does once a capability is free: what it’s genuinely good at inside a clean boundary, what it can’t do, and why the answer is neither replace the engineers nor just a better autocomplete.

This is Part 4 of a seven-part series. Start with Part 1 here.

In the last post I made the case that your AI pilots aren’t failing: they’re measuring you. Every pilot works because somebody builds it in a protected world; and every pilot dies in production because your real conditions live there. The gap between the two is your readiness gap, quantified. Which raises the obvious question: readiness for what, exactly?

Most of the industry answers with a maturity model. Five levels, a spider chart, an eighteen-month program to get to Level 3, and a comfortable consulting engagement measured in workshops. I want to offer something more useful: four conditions. Not levels, actual conditions. Either they exist where you’re trying to run AI, or they don’t. All four are testable, and you can test them this week.

The organizing idea behind all four: you can’t automate a tangle, only a clean boundary. Everything below is a different way of drawing a boundary.

Condition One: Encapsulated Technology

AI needs a bounded space to work in. That means capabilities with real edges: code that belongs to somebody, interfaces that hide what’s behind them, dependencies managed at the boundary instead of leaking through everything. The absence looks like the enterprise I described in the last post: shared codebases nobody owns, branches that live for months, eighteen teams required to touch anything. Dependencies don’t show up in the org chart; they show up in the code, and AI lands right where they show up.

The Test: can one team change one capability without asking permission of another? If the answer is no, an agent can’t either. It will just generate the merge conflicts faster.

Condition Two: Clean Data at the Source

Not clean data in aggregate. Clean data at the source: validated, owned, and documented where the team creates it. The industry has spent two decades building compensating controls for bad data practice: warehouses, lakes, lakehouses. Push everything into one place and make it one central team’s job to understand every business rule in the company. No team can. There is no easy button here, and pointing AI at the swamp doesn’t drain it: garbage behind an abstraction layer is still garbage.

Data work still matters, arguably more. This is an argument about where it happens. The pattern is a data mesh: data owned, validated, and served where it is created, by the team that owns the capability. Build it the way you build everything else in this series: inside the boundary you are about to automate, one slice at a time. Let the rest of the swamp wait its turn.

The Test: pick a critical data element. Do you know where it is born, and is it valid there, or does somebody fix it downstream? If it’s fixed downstream, AI is consuming the unfixed version everywhere else.

Condition Three: An Organization Designed Around Ownership

Teams aligned to business capabilities: domains, not components. The absence is familiar: a QA team, a front-end team, a back-end team, and a piece of work that touches all of them, coordinated by meetings. In that design nobody owns an outcome, so there is nothing an agent can be accountable to. AI doesn’t fix an ownership vacuum; it floods it with output nobody is responsible for. And scale doesn’t break the rule: a capability too big for one team decomposes into subdomains that aren’t. Ownership holds at every level.

The Test: for any business capability that matters, can you name the one team that owns it? One team. If the answer is a list, the condition doesn’t exist.

Condition Four: Intent Governed at the Top

This is the big one, the one condition that the twenty-pilot story violated most visibly. Energy without direction: boards demanding results, engineers experimenting, and no mechanism between them, no place where an AI hypothesis goes to get funded, measured, scaled, or killed. Governance here does not mean bureaucracy. It means somebody can say what we are trying to learn, what we are trying to earn, what we are going to stop doing, and what number tells us the truth. Directed R&D instead of undirected. Harmonized instead of standardized.

The Test: when a pilot succeeds, is there a system that moves it into production, and when a pilot fails, is there a system that kills it? If pilots accumulate, intent isn’t governed, it’s ambient.

Here’s the Part That Should Change Your Plan

You do not need all four conditions everywhere. That is the trap: hearing “conditions” and scheduling a three-year enterprise readiness program, which is just the maturity model wearing a new hat. Remember what we proved in the pilot. We can create these conditions. Your innovation colony created all four in a small, artificial space. That’s also the difference between a pilot and what comes next: a pilot simulates the conditions; a slice creates them for real, with production inside the boundary. A slice is not a bigger pilot. The work is to create the conditions somewhere real: one boundary, one capability, one portfolio, one slice of the enterprise where all four conditions genuinely hold. In the agile world, we called these expeditions. That’s the difference between transforming the company and transforming a slice of the company that pays for and builds momentum for the next slice.

Which slice? That’s the next post: why the application is no longer the unit of decision, and how to find the seams worth cutting.

Until then, run the four tests. They take a week, they cost nothing, and unlike your pilots, they measure the thing you can actually fix.

This is Part 3 of a seven-part series. Start with Part 1 here.

I was talking to a CTO client recently who mentioned he had twenty AI pilots running inside his organization. Twenty. Every one started the same way. A mandate from above to use AI, but all of them disconnected from all the others. His words: “We’re learning the same lessons twenty times over, in different places, and none of it is turning into forward progress.” And none of them producing clear ROI that anyone could point to.

The standard diagnosis goes something like this: too many pilots, not enough coordination, wrong tools, wrong models, wrong talent. The board wants results, so the prescription follows: buy better tools, hire more AI talent, try a newer model.

All of that misses. The pilots aren’t the problem. The pilots aren’t even failing.

Every Demo Works

In the last post I mentioned the LiminalArc Four Quadrants, the model I used for fifteen years to explain why agile pilots thrived in the upper-right quadrant and died when they moved into the upper-left, where the real enterprise lives. If you missed it, the short version is this: a pilot succeeds because somebody built it a protected world. Small, self-contained, no dependencies, hand-picked data. One team that owns the whole thing, and somebody who owns the outcome and genuinely cares if it works.

A pilot is a temporary simulation of the conditions AI needs: encapsulation, clean data, real ownership, clear intent. That is why every demo works. The demo isn’t lying to you. It’s a preview of what AI does when those conditions exist.

Then the pilot touches scale: other teams, other users, real requests. Production is just the place where scale becomes unavoidable, and it’s the upper-left quadrant, where your real conditions live. The shared codebase nobody owns. The data with three conflicting definitions of customer. The process with eleven handoffs. And it dies. Nothing changed between the demo and the death except the substrate. We watched agile pilots die this exact death for fifteen years. The technology changed, the map didn’t.

The Amplification Law

In 1990, Michael Hammer wrote “Reengineering Work: Don’t Automate, Obliterate” in Harvard Business Review. Companies were using technology to speed up broken processes instead of fixing them. Stop paving cow paths. There is a line often attributed to Bill Gates that says it even more plainly: automation applied to an efficient operation magnifies the efficiency; applied to an inefficient operation, it magnifies the inefficiency.

AI is that law with a much bigger multiplier. This is the “penalty went up” point from the last post, with the actual mechanism attached. For the first time, the automation doesn’t just execute steps faster. It generates work product: code, branches, tests, decisions. Instrument a broken process with AI and you get a process that produces more broken stuff per unit of time: the industrial production of AI slop. A codebase with no ownership plus AI-accelerated developers equals more branches, created faster, feeding the same merge hell. AI is a junior engineer you pay in tokens instead of a salary. Put a thousand junior engineers into your systems exactly as they are today. What happens?

The cause, said plainly: the conditions AI needs have not been created. Those are encapsulated technology, clean data at the source, an organization designed around ownership, and intent governed at the top.

Your Pilots Are Measuring You

Now put the two facts side by side. Every pilot works. No pilot pays. That gap is your readiness gap, quantified. The distance between the conditions inside the innovation colony and the conditions in production is the exact distance your organization has to close. Your pilots aren’t failing, they are measuring you, and most organizations have never even looked at the report card. It’s also why buying more instruments never moves the needle. A better tool, a bigger model, another platform: each measures the same gap, more expensively.

What to Do About It

Two moves. First, treat your pilot portfolio as diagnostic data. Where did each one stall? Data quality, handoffs, nobody owning the outcome, no path to production. Every stall point names a missing condition. You’re sitting on twenty free readiness probes you already paid for. Second, corral the energy, knowing it’s not the cure: convert every pilot into a hypothesis under lightweight governance, roll out the winners, kill the rest deliberately. Governance organizes the learning. It doesn’t create the ROI.

Creating the conditions does. That’s the next post: the four conditions, what each of those conditions actually means, and how to test whether or not you have them.

Stop asking why your pilots aren’t scaling. Start asking what they are telling you about your system and what about that system is killing them.

This is Part 2 of a seven-part series. Start with Part 1 here.

Over the past fifteen years I have stood on a lot of stages explaining why agile fails in large enterprises. What emerged over those years was a model LiminalArc calls the Four Quadrants. As we find ourselves in the midst of doing a ton of AI transformation work, I find the model as applicable now as it has ever been. AI transformation is failing for exactly the same reason that agile transformation failed, and the model saw it coming both times.

The Map

The Four Quadrants model suggests two axes. The horizontal axis is predictability versus adaptability. Executives need to make and meet commitments, and they need to respond to constant change, and by definition those needs will compete with each other. The vertical axis is emergent versus convergent. Sometimes you know exactly what you want and you need it fast, cheap, and on schedule. Sometimes the requirements aren’t defined, or even definable, and you’re testing hypotheses to find out what works.

Cross the two axes and you get four quadrants. The lower-left is traditional, governed, and predictable delivery. The lower-right is agile’s home base: making and meeting commitments in small batches. The upper-right is the land of experimentation. Small, independent teams, few if any dependencies, funded to solve problems rather than deliver against a fixed scope. Lean Startup lives there, along with innovation and most pilots.

The upper-left, predictive-emergent, is the quadrant of chaos and heroics. Organizations built for predictability, behaving emergently. Plans nobody believes, death marches, a handful of heroes making it happen when it counts. Here is the uncomfortable part: that’s where most of the enterprise market actually lives. It was true in 2012 and it’s true today in 2026.

The Agile Version of This Story

A company wants to go agile, so it stands up a pilot. Without quite realizing it, it builds that pilot in the upper-right quadrant. Small dedicated teams. No dependencies. Clear mission. Room to learn. The pilot works, because of course it works. Every condition it needs has been created for it.

Then the pilot “scales.” It moves into the upper-left, where the rest of the organization lives: the dependencies, the shared systems, the competing commitments, the heroics. And it dies. The company concludes that agile doesn’t work here. But agile was never the thing that failed. The conditions the pilot ran on didn’t travel. They were never going to travel. Nobody built them anywhere else.

The AI Version Is the Same Story

An innovation colony gets stood up: encapsulated scope, hand-picked data, one team that owns the whole thing, somebody who has a mandate and genuinely cares about the outcome. That’s the upper-right quadrant, a temporary simulation of every condition AI needs. The demo works, because of course it works. Then it moves toward production, into the upper-left where the real enterprise lives, and it dies there just like agile before it did. And the company starts wondering if AI is overhyped.

It’s the same map and the same trajectory. Only the technology changed.

Why I’m Writing This Series

Two things are different this time, and that’s why this deserves more than just a nod to the parallel. AI does more than underperform in the upper-left the way agile did. It amplifies the problem, because AI generates work product, so the chaos compounds instead of idling. The penalty went up. But the technology can also, for the first time, help build its own road. AI is remarkably good at mapping the upper-left: what’s in your estate, where the seams are, and what dependencies are getting in your way.

So over the next five posts, I’m going to make the full argument for why AI fails, and what you can do about it. We’ll look at what the pilot graveyard is actually telling you. We’ll name four conditions you can test in a week. We’ll build a map of your enterprise landscape you can actually use. We’ll get at AI’s real jobs once the conditions exist, and the one job it can never take. And we’ll lay out how to run the whole thing in a way that proves value every ninety days with a defined end-state.

It starts with a conversation I had recently with a sitting CTO who counted his AI pilots and got to twenty. That’s next.