In the Episode

When AI spending lands in the operating budget, the first thing many companies cut is people. This episode explains why that happens and what to do instead.

• Why AI costs end up as headcount cuts: AI token spend is an operating expense, usually charged to IT, and labor is the easiest line to cut once capital and SaaS commitments are locked in.
• Cost myopia: cost is right in front of you, and value is further away. Leaders focus on cost because it’s easier to control and because cause and effect between investment and value is hard to prove.
• Value engineering, explained: a practice that began at GE in the 1940s. It breaks a capability down into what its parts cost and the value each part produces. Value is benefits minus cost per unit of time.
• What chargebacks hide: centralized infrastructure costs left IT spend understated by 40–60%, until a corporate split forced every dollar to land in someone’s budget.
• Avoiding the wrong investment: a value engineering analysis prevented a $20M platform spend and found that the real problem was back orders.
• Measuring what seems unmeasurable: if you find the right indicator, you can measure things that look intangible.
• Where to start: change is driven by pain more often than by vision. Fix what’s in your control first, then deliver value in 90-day vertical slices that fund the next step.

Frequently Asked Questions

Why does AI cost cutting lead to layoffs instead of smarter IT budget decisions?

AI spend, especially tokens, is an operating expense, and it usually lands in IT. Capital spend and SaaS contracts are locked in, so labor is the easiest line left to cut. The real problem is cost myopia: leaders manage the cost in front of them because value is harder to see and harder to prove.

What is value engineering, and how does it measure business value?

It’s a discipline that began at GE in the 1940s. You break a capability, process or value stream into what each part costs and the value it contributes. The basic test is simple: value is benefits minus cost per unit of time.

How do IT chargebacks and cost-only budgeting hide the true cost of technology?

Chargebacks move costs around without tying them to value, so nobody owns the real number. In one company, chargebacks hid enough infrastructure spend that IT costs were understated by 40–60%. In another, a value engineering analysis stopped a $20M platform investment and pointed the money at the real problem, which was order fulfillment.

Can internal teams run a value engineering analysis and measure intangible benefits?

Yes. These skills already exist in finance and engineering teams. Almost anything can be measured once you find the right indicator.

Will value engineering prevent AI-driven layoffs and improve AI ROI?

Not on its own, but better math is better than no math. Financial models keep you from making the wrong cuts and the wrong investments, and they keep productivity gains from disappearing without ever turning into value.

How do leaders move from cost cutting to value-based decision making?

Not by starting with culture, because culture is an effect, not a cause. Start where the pain is and fix what’s in your own control first. Then deliver value in 90-day slices, and let each one fund the next.

Podcast Transcript

Len Greski
Executives at the Museum of Science and Industry in Chicago wanted to figure out what the most popular exhibit was. And they sent out a survey. People were likely to mention snobbish exhibits that were scientifically complicated. If you actually looked at those locations in the museum, there were not many people that typically frequented those exhibits.

They asked some sociologists at the University of Chicago how they’d solve this problem. And the answer that came back was, “Let’s go talk to the maintenance engineers and figure out where they replace tiles, floor tiles throughout the building.” And the winner was the baby chick exhibit. And so one could make an argument you can’t measure the most popular exhibit because people will lie to you on a survey.

And the answer was actually you can measure, but you just have to know what’s a better way to measure it.

Stacy Gordon
Hey everybody. Stacy Gordon here, host of the podcast Future State Now. I’m happy to be spending time with Len Greski, chief scientist at LiminalArc. Len, you wrote an amazing article recently called Why Value Engineering Beats AI-Driven Cost Cutting.

And I loved how you opened the article because you talked a lot about reports that are out there today saying AI is eliminating jobs, but I believe you don’t think that’s the right story. What is the right one?

Len Greski
Well, the right story, and it’s been this way for decades related to AI, is about value. And that people have been working in the AI space for 40 years, 50, if you go back to the 1970s applications like MYCIN, which was an early tool for doctors to diagnose illnesses. And at that time, AI or expert systems and neural network applications were targeted at very specific business problems that were trying to be solved where there was a very clear value proposition because at the time everything was custom software.

You couldn’t download a neural network as a Python package, for example. And now AI is so much more accessible that people are focusing on how do you free up costs to experiment with it versus looking at what are we actually going to do and how does what we’re going to do generate value?

Stacy Gordon
And so why does that AI usage bill always seem to end up on headcount?

Len Greski
Well, because if you think about what happens in a company with various cost structures, there’s a big distinction between capital expenditures and operating expenses. And in an earlier article I wrote this year called The New Software Economics, talk about the history of accounting treatment for software development work and how AI enabled development introduces new categories of spend like the dreaded AI tokens.

And those categories of spend are inherently operational because they’re not baked in to the newly created software asset. So companies typically centralize these operational costs in IT because if it looks like IT and it smells like IT, IT going to get the expenses and IT may or may not allocate those expenses out to business units based on some form of rationalization, whether it’s number of employees or number of servers that are used by business unit.

And if the costs aren’t allocated to a business unit, then the IT department gets stuck with them and then it’s got to figure out where else to cut to meet the annual budget commitments. And so if in IT, the labor is neither unionized nor protected by some fixed bid contract, like you’ve outsourced X, you said you’re going to spend 20 million a year on it and it’s the outsourcer’s responsibility, staff the labor, you’re still on the hook for the 20 million. Labor’s the easiest thing to cut.

Stacy Gordon
Right. Is that where you came up with your term? And if you haven’t spent a lot of time with Len, he always will give you what I call Len-isms, things that he brings back from the past to make a harder situation sound easier to understand. But I loved your term cost myopia.

Len Greski
Well, that was something that as I was writing the article, I kind of like to break the text up into chunks with some kind of heading. And that paragraph, that’s what it is. Myopia is a vision problem where the visual images come to a focus in front of the retina and that results in poor vision of distant objects.

And a secondary definition is a lack of foresight or discernment or a narrow view of something. And cost is right in front of you, whereas value is further out. And so myopia is a good way to metaphor for the focus on cost rather than value. And leaders focus on cost rather than value for two reasons.

Number one, it’s easier to control your costs rather than benefits or more specifically revenue. And second is that many companies struggle to establish cause and effect between the investments they make and the value they expect to realize from them.

Stacy Gordon
And is that why you would say labor’s kind of always the relief valve? It’s the easier one to understand?

Len Greski
That’s right because typically a department is going to, a budget is broken out into different categories of expense. And in IT, you’ve got labor and non-labor expenses and then you’ve got capital expenses versus operating expenses. And the things that are easiest to change or it’s easier to change OPEX than CapEx because once you’ve capitalized something, you’re stuck with its amortization schedule.

You can’t undo the capital expenses in some ways. They’re like the gift that keeps on giving. Once you’ve spent it, you’re stuck with it for you. And so then you’re looking at your operating expense budget and then within the operating expense budget, you have labor and non-labor.

Now, over the past 20 years, more non-labor expenses have become operating expenses where it used to be you’d buy a wave of servers for your data center, you’d depreciate them over, you’d put them on a seven year amortization schedule and those costs were fixed for the better part of a decade. While you couldn’t undo them, they were lower than if you were paying operating expenses each year for that compute capacity.

With the rise of software as a service and cloud computing, as I wrote about in the new software economics, those categories of expenses have moved from CapEx to OpEx. And so if you’ve got a commitment of 10 million a year in spend to your SaaS vendor, it’s really hard to reduce that.

Stacy Gordon
Sure.

Len Greski
And so then labor becomes the relief valve.

Stacy Gordon
Yeah. Well, I mean, it’s got to be frustrating. You’ve sat in a number of executive seats throughout your career, but when you get handed at an operating budget that you didn’t get to set and you’ve got to make tough decisions within that, that’s a struggle for anyone.

Len Greski
Well, it is, but it’s also a reality of a business that we all have to face into is the budget is a fixed thing and that’s why it’s so important to be able to understand the value that’s generated by your budget. Because if I don’t understand the value being generated by my budget, I can’t communicate that to stakeholders.

And if I can’t communicate the value, I’m at risk for severe cuts. Because when the senior most executives come looking for budget cuts, the budget monster is out trying to grab as much spare cash as possible, they’ll target a percentage reduction and peanut butter spread it across all the departments. And it’s very difficult to say no when your budget cuts our peanut butter spread and it’s like everybody’s got to give their pound of flesh.

One way that I’ve defended myself against that in other companies is to outsource work and run it on annual contracts so that if nobody wants to pay for an asset, you just shut it off. And in one company, our fiscal year ended on the 31st of October, and I would literally talk to my stakeholders like, “Well, if you don’t want to pay for that anymore, it’ll turn into a pumpkin on Halloween and it won’t be there on all saints day.”

And that would lead to some very difficult conversations with business stakeholders because people are often very excited about building new capability, but nobody wants to pay to operate what you’ve already got in place.

Stacy Gordon
Oh, well, I’ve heard that statement over my career. You’re always more valuable somewhere else than you are internally at times, but I’m sure I’m not the only one. Now, you’ve mentioned a couple times value engineering. Break that down for me.

What does that actually mean to the common person and where did it originate from? Because I think it’s like a wartime manufacturing thing. Is that right?

Len Greski
That’s right. It started in the 1940s as a practice at General Electric where they were trying to during the wartime period, reduce the cost of their products and services while maintaining an appropriate quality level. And value engineering is simply the analysis of a good or service in terms of the cost of its sub-components or inputs and the relative value that they contribute to the finished good.

And the idea is to find ways to deliver equivalent or improve value at the finished good level by reducing the cost of its sub-components. And so that approach, not only can it be used with parts and finished goods, like say like a vacuum cleaner or a jet engine, it can be used with a business process or a capability or a value stream to be able to understand the sources of cost and how they contribute to overall value that’s produced by your value stream, your business process, or a capability or an asset.

Stacy Gordon
So give me an example here. If I were at a company and I ran a business capability, what would be the first number you would ask me for?

Len Greski
Well, I would want to understand for labor and non-labor, what does it cost to operate that capability? And then I would want to know how it generates benefits so that I could per unit of time subtract benefits minus cost to see if the capability is above water, that it’s generating more value than cost.

Okay. More benefits than cost, because value is simply benefits minus cost per unit of time.

Stacy Gordon
Right. Well, you had a really great example in your article about this. Why don’t you tell me about the servers? I though that was pretty powerful.

Len Greski
Well, there are three or four different directions that I could take that question about servers, most of which require adult beverages to be fully appreciated.

Stacy Gordon
Oh, well, next time I’ll bring the Manhattans.

Len Greski
Since the sun’s not over the yard arm across most of the US, a straightforward answer is that the company in question had centralized its global infrastructure to the degree that the dozen or so business units consumed infrastructure from the centralized organization without having direct control over its costs. So infrastructure was treated as a vendor to the business units through a chargeback mechanism.

And since this particular company manufactured computer equipment, the infrastructure team could buy hardware at 30% of retail.

Stacy Gordon
Oh, wow. And

Len Greski
They also figured out that the more hardware they purchased, the more staff they needed operated. And so they over time realized that they could actually buy three times the amount of hardware you needed for a particular project or capability without raising suspicions in the finance group. And that allowed them to hire three times the amount of staff they needed to run operations.

And the chargeback mechanism obfuscated the accountability for the burgeoning infrastructure costs because the infrastructure department’s P&L statement was considered profitable because it had the authority to pass the costs along to the other departments without any accountability for the value or lack thereof that was actually being delivered. Now you’d wonder, wouldn’t the CIOs or the business units be concerned about that?

Well, the payoff to the CIOs is that the infrastructure was actually charged to the business P&L, not the business unit’s IT department.

Stacy Gordon
Oh.

Len Greski
So IT costs as a percentage of sales were frequently understated by 40 to 60%.

Stacy Gordon
Well, I hope that there’s a lot of people listening and understanding how to get around their overspend of next year or this year. That is interesting. Do you think today there are still a lot of companies that are typically doing this?

Len Greski
Well, it varies a lot. And in this particular company that they had really the supporting capabilities like HR and IT and finance would typically bill the other business units for their “services”. And so you had this very unusual culture where a department like IT could say, “I’m profitable because I’m bringing in more than chargebacks than I’m costing.”

But it was all interdepartmental chargebacks. There was no actual revenue being brought into the company. And in this particular company, it was so hard to untangle the web of chargebacks that they had to split the company. They had to basically divest it in order to force every dollar of cost to be assigned to one of the new businesses that was being spawned out of this company.

Stacy Gordon
Wow. So you literally had to divest to create a new company so you could practically start over because there was no way to untangle the web.

Len Greski
Yes.

Stacy Gordon
I mean, well, I always say Len, you have great stories. So why don’t you tell me the one about, which I really did love this one, about the argument between the two executives and who wanted to build the new… Again, you’ve already mentioned it, people love to build new capabilities, but understanding what that means and how that impacts the company as a whole, I though this was a really interesting story when you talk about value.

Len Greski
Well, if the podcast viewer’s interested in the long version of this story, I wrote an article called Getting Beyond Ourselves for Architecture and Governance Magazine back in 2022 that includes a more detailed fictionalized version where the names were changed to protect the guilty. The condensed version is that beyond the two senior executives, there are four actors in this drama, the e-commerce VP, the chief technology officer, the director of e-commerce customer service, and the business architect who did the value engineering assessment.

And through the agreement, it’s like for the chief technology officer, that debate went really well. He was successful because he avoided a $20 million unnecessary capital expense and the existing infrastructure worked as planned, as load increased, and over a three-year period, the systems worked as expected without having to make a big capital expenditure.

For the director of e-commerce customer service, her part of the story was that she had a significant problem with back orders for e-commerce orders. And what the value engineering analysis showed was that the most important thing to fix was her problem. So she got a good outcome because she finally got the attention she needed to fix her back order problem, generating millions of dollars a year in productivity gains and increasing customer satisfaction because you had a higher fulfillment rate.

Now the e-commerce business VP, things didn’t go so well because a 30% compound annual growth rate was baked into a sales plan.

Stacy Gordon
Oh no. And

Len Greski
Since his primary strategy for growing his business was, “Make it like WebKins, the virtual pet website for children,” he failed to achieve his growth target. And finally, for the business architect who conducted the analysis, it was a bit of a mixed bag. On one hand, the demand model that was used to assess the architecture scalability turned out to be accurate to within one half of 1%, 18 months in the future, which was a huge success and why the infrastructure didn’t fail under load, because the forecasting model was highly accurate.

But on the other hand, since the numbers didn’t support the e-commerce VP’s position and the architect was a direct report of the e-commerce VP, she was exiled to IT. And as an old friend of mine once said, “Righteousness is always an attractive option, but a true statement that sometimes takes years to play out, and that’s a story for another time.”

Stacy Gordon
Well, what I thought was interesting about this, I would’ve thought that most companies would have to hire a consulting firm to come in for value engineering. Can you oftentimes, do most larger companies have team members internally that can actually execute against an analysis like that without having third party objectivity?

Len Greski
Well, it’s many companies like say General Electric, they have a strong tradition of industrial engineering and have high quality finance departments and that those skills are readily available. I mean, they’re taught at universities, particularly either in industrial and systems engineering or master’s of business administration courses. I was first exposed to it in a purchasing management class, but because once you have a tool, the tool can be applied in multiple contexts and it’s knowing what tools to apply in what context that help you improve the operations, the value being generated by your business.

Stacy Gordon
Yeah. I just often wondered, it makes sense if you have a tool to be able to do that. It just was kind of interesting if you’d be swayed in one way or the other. I know in your article it talks about having to actually take something that people often say is intangible in cost and put a cost associated to it.

So I didn’t know if sometimes that’s maybe harder for someone to get to ground on that if you’re internal than it would be external.

Len Greski
Well, I mean, there is a big debate in both industry… It’s actually more challenging in economics and the social sciences of does everything that exists, can everything that exists be measured? And in the social sciences, in academia, you learn as an undergraduate that everything that exists can be measured, and then it’s just a question of how good you are at operationally measuring something.

So for example, many years ago, executives at the Museum of Science and Industry in Chicago wanted to figure out what the most popular exhibit was, and they sent out a survey and the survey came back with all kinds of bias in it that people were likely to mention snobbish exhibits that were scientifically complicated that were in the museum.

But if you actually looked at those locations in the museum, there were not many people that typically frequented those exhibits. So they asked some sociologists at the University of Chicago how they’d solve this problem, and the answer that came back was, “Let’s go talk to the maintenance engineers and figure out where they replace tiles, floor tiles throughout the building.”

And the winner was the baby chick exhibit. And so one could make an argument you can’t measure the most popular exhibit at the Museum of Science and Industry because people will lie to you on a survey. And the answer was actually you can measure it, but you just have to know what’s a better way to measure it.

Stacy Gordon
Sure, sure, sure, sure. Think outside of the box, I suppose. Kind of circling back on where we started, Len, we talked about AI is associated for being the cause of these labor cuts and the overage of operating expenses. When we look at value engineering, do you believe that if companies start focusing more on value engineering that this will stop the layoffs, or would you say it maybe just gives better math?

Len Greski
Well, as I think about that, I’ve got a couple of responses. First, better math is an obvious improvement over no math.

Stacy Gordon
I think that should be our headline. Better math is better than no math. Okay.

Len Greski
Next is that financial models help avoid making the wrong cuts or the wrong investments as the e-commerce story where $20 million in spend on a new e-commerce platform wouldn’t fix the back order problem in the supply chain, and its ability to create the growth promised by the e-commerce VP is dubious at best.

Now, a consistent theme in my coaching of senior executives is to start by fixing things that are under your control and to use the improved performance to develop influence with peers and stakeholders to change things that are at the boundaries of your responsibility. Because if you’re a good steward of your responsibilities, that’s going to create opportunities for influence and growth.

Because what happens often in productivity plays is people say, “Well, we’ll repurpose the capacity to something else,” and the capacity never gets repurposed to something that generates incremental value. So all you’ve done is invested in some productivity gain and increased your operating expense footprint. Right,

Stacy Gordon
Without solving the real problem.

Len Greski
Without monetizing the value, and that’s why I make such a big deal about monetizing the value of work in my most recent writing. But that fixing your own stuff, I like to call it get off the Pareto chart where Pareto chart is a common graphic that shows problems by frequency in categories of problems, how frequently they occur, relative to a cumulative percentage of all problems where the idea is like the Pareto principle that 20% of the things cause 80% of the problems.

If you can address those high frequency problems, you’ll get a lot of leverage in improving the performance of your business without having to immediately fix everything. When you focus on fixing your own stuff, other executives aren’t going to get angry because you’re admitting their performance improvements needed in your area. In fact, a lot of your colleagues will be happy to point out where your problems are.

If you can enlist them in helping you resolve the problems so that you’re not on the Pareto chart anymore, then you have the ability to influence other stakeholders.

Stacy Gordon
Sure. I think that’s a foundational message that most executives should live by get your house in order and by doing that, you’ll lead by example and you can be more impactful again at your boundaries or beyond your own job. So with that said, there’s got to be people listening today that have a budget problem right now that probably have taken away some tips from our conversation and are wondering where do they start?

How do they change the culture? Is it a cultural change or can it be a small change, kind of like what you were just talking about to really start to see the impact of a value engineering analysis within their own organization?

Len Greski
Well, culture is never the right place to start because culture is an effect, not a cause. As a sociologist, I define culture as a set of shared beliefs and practices that make up the informal rules for how people in a group interact. And because it’s informal, it’s something that takes shape over time and is caused by other things.

So I always start with there are two primary drivers of change in life. One is a compelling vision and the second is pain. 2000 years ago, a dude walked along the shores of the Sea of Galilee and said, “Come follow me.” And commercial fishermen dropped their nets and followed.

Why? He had a compelling vision. But the second driver, there are not many compelling visions. The second driver of change is pain.

People, when they feel enough pain, when the severity of their pain exceeds the fear of change, then they’re ready to have an admission of need. And today there are a few compelling visions. And in fact, the most commonly used business example of vision is John F. Kennedy’s goal to send a human being to the moon by the end of the 1960s.

Yet the reality is that was actually a response to pain, the pain of having been beaten space by the Sputnik satellite in October 1957. So if even the shining example of vision is actually a response to pain, then you’re more likely to make change happen when the pain is sufficient to create an admission of need.

And my service story about the obfuscated infrastructure costs is a really good example of pain driven change because My company was six months into planning for a corporate split and every dollar of cost in the parent company was going to be allocated to one of the two resulting companies. And the CIO of my division, the business unit that I was currently then working in, had been bragging about how his IT expense as a percentage of sales was only 1.5%.

And in a manufacturing business, that’s really good. But since the infrastructure was centralized across all the business units, those costs weren’t charged to his budget. And I was like the proverbial prophet out in the desert in a hair shirt yelling sinners repent, repeatedly warning my manager about an incoming tsunami of infrastructure costs.

And I was basically ignored until month 11 of a 12 month divestiture process where my boss’s boss was told to absorb hundreds of millions of dollars of infrastructure costs into his budget, moving his IT as a percent of sales metric from 1.5% to 3.9%. And all of a sudden the “time I had been wasting” on understanding our cost structure wasn’t so wasteful anymore.

And so there’s a piece of being able to see where the puck is going to know where the pain will be to be prepared with a solution. And all of a sudden, my math was instrumental in taking scores of millions of dollars of costs out of various cost structures in that business unit.

Stacy Gordon
Is there a part of… You do a great job all the time of breaking things down and this seems like it could be an extraordinary large undertaking, but can one person start small, like a cross-functional team of one small pain point to start exercising those muscles on how to think differently? I mean, could change start to happen as small as that?

Len Greski
Absolutely. I mean, in fact, at LiminalArc, when we work with our clients, we very frequently structure change, whether it’s in an organization or product development or building a business capability into vertical slices so that you can deliver meaningful units of value every 90 days, like I discuss in the new software economics where you want to be able to make work small enough so that you can deliver a unit of business value no less frequently than every 90 days, generate value and then use the value generated to fund the next thing you want to change.

It’s a good risk mitigation tool as well because you can only spend so much money in 90 days, whereas if you have a 24 month project plan and if you don’t know that what you’re doing isn’t going to work until month 23, you’ve got a lot more risk hanging out there.

Stacy Gordon
Right. Absolutely. Well, Len, this as always, I enjoy our conversations. You always bring enlightening information to the table to talk about, and you do it in a very funny way for me.

I want to call it again for those who haven’t had a chance. Len’s latest article was Why Value Engineering Beats AI-Driven Cost Cutting. Len, why don’t you tell, you’ve mentioned a few other things. I know that you love to share your thoughts and authorship.

Where are some places that people could maybe find you or connect with you or read some of your things?

Len Greski
Well, I have a number of articles and podcast videos on the LiminalArc website at liminalarc.co. I’ve been writing for Architecture and Governance Magazine at this point for about 17 years and got articles on architecture and governance.com, probably going back to at least 2019 because it previously was a dead tree version back when trade magazines still existed in a paper format.

Stacy Gordon
Some of us still like those. I still love the paper format. Well, Len, again, thank you so much. I really appreciate it.

Everybody, thanks so much for listening. It’s Stacy Gordon here with Future State Now. Give us a like, follow us so that make sure that you can hear our next podcast when it comes out soon. Thanks. Take care.

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.

Podcast 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.

Discover how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that deliver business value at every step of the journey.

Podcast Transcript

Stacy Gordon:

We got to build the model, the heat map, we got to do the domain alignment, especially if you’re starting from scratch. That’s a lot of work and effort and expense before you actually even modernize one little thing. So how do you avoid this analysis by paralysis a year of just mapping and you deliver nothing?

Melissa Roberts:

Well, first of all, you scope it like anything else ruthlessly. So you don’t need an entire enterprise-wide capability model before you do anything. You start with the highest pressure business unit or domain and build that model on that heat map in that area and make the decision, deliver something, and then move on. The model expands as you go and is informed by real decisions rather than built in a vacuum. So the mapping exercise itself has taken a year, that’s assigned the scope was wrong to begin with. And you are not using the right approach that I am stating here, which is small chunks. What is that highest business value business domain that you’re going after? So if you use this approach, you can complete the scoped heat map in weeks, not years or months.

Stacy Gordon:

Hi everyone. Thanks for joining the conversation. My name is Stacy Gordon and I’m the director of strategic growth here at LiminalArc. I’m excited to be reconnecting with my friend Melissa Roberts to continue our conversation around why application modernizations fail. Melissa is a business architect and value engineer here at LiminalArc and has published a series of articles around application modernization and how organizations are bleeding money more often than not during their modernization attempts. So Melissa, let’s get right into it.

Melissa Roberts:

Sure.

Stacy Gordon:

Your last article argued most modernization efforts fail because organizations lack a decision framework. For someone who didn’t read part one, what does that failure actually look like inside a company and what’s the cost of getting it wrong?

Melissa Roberts:

Great question. So it looks like a multi-year program that is over budget, that when it finally delivers, doesn’t really deliver what the business needs. So what does that mean? Teams are rebuilding the applications. They’re building them in the cloud. They’re swapping out a database. They’re migrating his stack. Six months later, the business has the same issues. So the business is continuing to put in requests to make things work better. You’re not moving your market share like the strategy suggested that you would be doing. So what’s happened is nobody, it’s not a business decision at that point. It became the technology decision. And that’s the heart of it. Organizations are going to confuse. We need to modernize technology with, we need to improve the business. Those are not the same thing.

Stacy Gordon:

It’s interesting so often that it seems like people don’t really know that. One of the things I loved your comment was like you open your piece with the bowl of spaghetti image. First of all, I have to tell you, it made me think of like an old game called Kerplunk. I don’t know if anybody, you put the needles with the marbles, but I know that’s not exactly the same thing of what you’re doing here, but you talk about pull one noodle and four others break. Why is that interconnectivity the thing that makes modernization so hard to scope?

Melissa Roberts:

Well, a lot of it is because it’s the legacy system was never built with boundaries in mind. So they grew organically, either through a business request or technology needs. And over time, they started quietly depending on each other. And no one really knew that. So the moment you go to scope your technology modernization effort and you try to move one piece, three other things have broken and you don’t know why. There’s no documentation. No person is there anymore that started your legacy systems. So that’s why you pull one noodle and four others fall apart. So capabilities allow you to reason about that business problem. First, you can figure out what systems are entangled to help solve it. So then it helps your kerplunk, not kerplunk.

Stacy Gordon:

Okay. I love, thank you for tying it back to that Mattel game that just brings me back to my childhood. I think it’s got to be so frustrating. It’s like how documentation was a part of things as they went along and that’s part of like some of the core foundational issues for this. So when you’re going through your article, you talk about heat maps. And so help walk me through the heat map. You assess capabilities on value, performance and risk. How do these three dimensions combine to tell an executive where to spend the money and where to leave well enough alone? Well,

Melissa Roberts:

It’s a super cool concept. So each dimension is asking or answering rather a different question. So when you’re talking about the value, it tells you how strategic the capability is. So does it differentiate you in the market? So don’t take strategic as meaning like your HR system’s not strategic. It’s strategic because you cannot operate without it, but it doesn’t differentiate you in the market. You’re also looking at your performance. How well is it being delivered today? Is it fully automated? Does it need to be fully automated? Do you have the right people in place? Are your processes okay? And then you have that third dimension of risk. And that’s simply how flexible or inflexible it is to move. So think of your bowl of spaghetti. If that bowl of spaghetti, if that legacy application is inflexible and it breaks every time you try to change something, it’s a high risk.

When you combine all three of these together, let’s say you have a very strategic capability like customer service and your legacy system is a bowl of spaghetti. When you try to change something, that’s high risk, but you have to change it because it differentiates yourself. That’s a capability in the heat map that your executive is going to hone in on and is going to want to change. But if you have something like HR, it doesn’t differentiate you in your market. And it may not be flexible, but you’re not going to invest that much in it because it doesn’t move your market. It doesn’t move your strategy. It doesn’t move whatever business goals you have.

Stacy Gordon:

So ultimately you’re saying it gives you, instead of a list, you get a picture. So it’s a better way to kind of look at how all the things interact together. It’s almost like on a matrix, right? Of when you start pinpointing those items.

Melissa Roberts:

Absolutely. Yeah.

Stacy Gordon:

Okay. Well, I start to see why that would be a much better way to approach this at the beginning. And Melissa, you talk a little bit about strategic versus utility items. And so when you tell a leader that a capability is just utility, how do they take that? We talked a lot before about how ego plays a big part in this as executives continue to walk down the same path as people before them and these application modernizations fail. So knowing that there’s some ego here, is this a hard conversation to have?

Melissa Roberts:

It can be a very hard conversation, especially if that leader has spent years building and championing that system. But I try to reframe it before I go in and before it becomes personal. So utility doesn’t mean it’s that important. It just means that’s not where you differentiate. Every business needs utility capabilities like HR or like payroll. They all have to work. So the question isn’t, is the capability good or bad? It’s, is this where we win in the market? And if it’s not, then we just need to keep it humming and moving along as cheaply as we can.

Stacy Gordon:

I like how you say to frame it before you go in so it isn’t personal. I can see that that would be a huge differentiator when you go in to talk to someone about these issues because again, there’s a lot of pride in their business. It’s their baby. And I can see any chance you get to kind of soften that conversation would make it go over way easier. So if we were to look at some counterintuitive points in this piece, the heat map tells you where not to invest. But in my experience, most firms are actually pitching you to do more, not deliberately less. So what are your thoughts on that?

Melissa Roberts:

So I think it’s the most valuable and the most underused part of the exercise. Like you said, most modernization pitches are doing around more, not less. But the real value of your heat map is giving you permission to stop. If the capability is already performing well and it isn’t strategically differentiating it, then why continue pouring your money in a modernization budget? That’s just a waste. It’s not moving you where you need to be. Organizations tend to hemorrhage money on exactly that pattern, improving things that don’t need to be improved because nobody had the data that they needed to say to leave it alone. Saying

Stacy Gordon:

No

Melissa Roberts:

To a modernization request with a heat map behind you is a very different conversation than saying no to a gut fill.

Stacy Gordon:

Yeah. It’s so interesting on the permission to stop. I talk a lot of times to my customers and it is prioritizing the work that needs doing. And it’s so oftentimes that that’s a different concept that people don’t hear very often. And it definitely stands out when they’re like, “You mean I don’t really need to spend money and budget on this and I can now allocate that somewhere else where it’s a better bang for my buck where it’s going to help me stand out in the market.” I really like that. But I’m going to challenge you a little bit on the heat map concept. So the heat map scores value performance and risk, but ultimately it’s based on people’s judgment. So you have two architects in a room. They could rate that same capability very differently. So how is this genuinely supposed to be more objective than those gut feel decisions that we were just talking about?

Melissa Roberts:

Well, Stacy, that’s a fair challenge. And I won’t pretend that the heat map is going to remove judgment entirely. It doesn’t. But it’s important to keep in mind that it’s not just two architects in an ivory tower doing this. It’s the business coming together and scoring it. The heat map does make the judgment visible, structured and comparable. And what’s really, really cool is when you start scoring these and folks say, “Oh, I think this is strategic,” or, “Oh, I think this is high risk.” You have a conversation of things that were inside the person’s head that were never brought up before. So yes, it’s subjective, but that objectivity isn’t eliminating the subjectivity. It’s forcing the subjectivity into a consistent framework.

Stacy Gordon:

Okay. So the key element here, of course, then ultimately is making sure you have all the relevant parties in the room to be scoring together. And that is how it really creates, it bubbles up differentiated thoughts that people have on this kind of stuff. So I’m assuming these exercises are live, right? They’re happening with everybody in the room. So I mean, tell me, do they get heated? Have you got some fun stories to share? I mean, who leaves the room first because they’re mad? I mean, it’s got to be.

Melissa Roberts:

Honestly, it’s probably the architects that leave

Stacy Gordon:

Okay. Well, maybe we can live Zoom that and do a play by play the next time that we get together because I think that’d be pretty interesting. Yeah.

Melissa Roberts:

You get a technical architect in there. They have very, very, very, very solid, usually correct opinions.

Stacy Gordon:

Well, I wonder if it’s interesting for them too, because I think sometimes everybody can put blinders on and only think through their lens. I know on teams that I worked in before, how important it is to make sure that you’re constantly talking to your technical teams about the business goals because they can get disconnected from those. And when you understand them, it helps you make decisions in a different way. So, okay, everybody in the room, and then we’ll bring them out for beers afterwards to say thanks for all the pressure filled hard work. Absolutely. Yeah. So moving on, your framework presupposes you already have a capability model and a heat map, but most organizations don’t, right? Or maybe they have a half built one that nobody trusts. Is this only useful to the minority who’ve already done the hard part? What does someone do if they’re starting from ground zero?

Melissa Roberts:

Right. So you’re right. Most organizations don’t have a fully baked business capability map, and that’s okay. So the article does assume the model exists and that’s deliberate because building the model is its own body of work and deserves its own treatment. If you’re starting from zero, the answer isn’t to skip straight to modernization decisions. You need to step back. You need to invest in building what I would consider a minimal viable capability model first. So what that means is you start with the domain or the area or the concern that you’re working on first. I’m going to pick on customers again. If it’s customers and customer service, you start on that first. You don’t care about your payroll or your HR capabilities. You care about those customer service capabilities.

Stacy Gordon:

Okay. Well, so we talked, I know, about boiling the ocean. So this is saying it’s okay if you don’t have this, but don’t try to take it all off in one bite. Let’s prioritize and focus on one effort. So I think hopefully that’ll make some people feel a little bit more comfortable out there that there is a place to start that is actually reasonable to think that you can actually get it done.

Melissa Roberts:

Yeah. Yeah.

Stacy Gordon:

You talk about Conway’s law as a design advantage rather than a warning. Most people invoke it to explain why systems turn out badly. How do you flip it into something that’s more deliberate?

Melissa Roberts:

Yeah. I mean, you’re right. People do tend to invoke it after the fact. They do that to explain why their architecture turned out tangled. Well, of course it’s a mess. Look how your teams are organized. So yeah, I’m going to blame Conway’s law. I’d rather use it before the fact. So systems produce what they’re designed to produce. Then the lever isn’t fighting that tendency. Okay? It’s designing your teaming structure deliberately. So the system produces is the one what it produces is what you want.

Stacy Gordon:

Aligning

Melissa Roberts:

Your teams to domain boundaries on purpose. And Conway’s law starts working for you instead of against you.

Stacy Gordon:

Well, I like flipping that for sure. So talking a little bit about capabilities. So you say that capabilities are non-redundant, but domains can be redundant. So why does that distinction matter for someone making, let’s say, a refactoring decision?

Melissa Roberts:

Yeah. I mean, it tells you what kind of duplication is a problem and what isn’t. So you see customer showing up in five different domains. Your instinct might be to automatically consolidate, “Hey, there’s only one capability call customer.” But the capabilities are non-redundant. It’s where the duplication is that shows that red flag. So domains, when I talk about domains, you’ve heard me a couple of times. They’re different. It’s the same concept, legitimately means different things in different bounded context. Then you have to understand which layer you’re looking at. So for example, because this is very complicated for non-technical folks. Thank

Stacy Gordon:

You, thank you, thank you. Okay. Okay. You’re picking up what I’m laying down. Okay. Pull out your crayons here. Give me some examples. I hope I’m not the only one, but at least let’s bring it into real life. So walk me through it.

Melissa Roberts:

Okay. So let’s take. I’m going to take billing, for example. So you have a customer, they’re going to buy something from your website and they have to pay for it. They get invoiced. Now they get invoiced and payroll or finance also has an invoice. Do they mean the same things? No, because an invoice in finance could be an invoice for your vendor. It could be an invoice for your customer. It could be an invoice for something else. But in the customer’s world, their invoice is always what they’re being charged, always what they have to pay for. So in that instance, it’s not the capability of invoicing or a customer that’s the same. Those are two different, distinct things in a domain.

Stacy Gordon:

Okay. So how about the flip side? If you have the logic, if the same logic. Okay, let me make sure I’m getting it right. The same logic is in two places, that’s the problem. So how does someone tell the difference between healthy duplication and the kind that’s quietly costing them money? Yeah.

Melissa Roberts:

So again, the difference is the business justification, like you said. So billing cares about payment history and credit status. Shipping cares about delivery address and preferences. Those aren’t the same concept, wearing different clothes. They’re genuinely different responsibilities. So you can’t force them to be the same thing. Billing cares about the payment history of that customer. Billing cares about were they invoiced? Were they not invoiced? Net 30, net 60, whatever it is. The customer, from a customer service perspective, just cares that they got the bill.

Stacy Gordon:

Right. Right, right, right.

Melissa Roberts:

So those business rules, those business justifications are different. So it’s okay to have the customer billing and billing and finance be in two separate places.

Stacy Gordon:

So what I think is so interesting about this conversation truly is that this is not easy to untangle. And so it probably explains why you have so much duplicative data and why people are dealing with the issues that they have today. Because it really takes almost an outside, it takes an outside consulting firm or a very dedicated effort to sit down and start understanding, again, what is okay to be duplicative and what is not. So I don’t think that that’s easily solved, but can be solved, which is I think what you’re helping me understand.

Melissa Roberts:

Yeah. So if we take, for example, pricing. And that pricing is you find pricing in multiple places. Let’s just take two for simplicity. You find pricing in two places. Pricing is pricing, is pricing. I mean, you don’t change the business logic for pricing. But if you see that logic in one area and it’s different than the logic in another area, that’s a red flag. A place where you want to dig in and say, “Is this duplication business justification or not?” And it probably is not.

Stacy Gordon:

Okay. All right. Well, at least now I know what I’m supposed to be telling people to look for. I just find that just so interesting because it’s easy to gloss over, but it makes such a big difference. I can tell once you get into it. Switching tracks. When we talk about wanting to refactor or refactor as warranted, you say the target isn’t necessarily a shared service. You designate an authoritative context and have others consume it via API. Why is collapse it all into one service so often the wrong move for someone to do?

Melissa Roberts:

Well, the goal isn’t unification for its own sake. It’s removing that accidental complexity while preserving the autonomy that lets the team move fast. So what do I mean by that? If you collapse everything into one service, then you’ve just had everyone having to wait on that one team to get everything done. And that’s the exact opposite of what we’re trying to do. So think of it as encapsulating it too much.

Stacy Gordon:

You

Melissa Roberts:

Encapsulate what you need to and you orchestrate everything else. So that’s the exact problem that bounded contexts are designed to avoid.

Stacy Gordon:

It seems just like for a $2 word, which I’m known for here at Luminal Arc, it sounds like it’s just creating another bottleneck for you. You’re not able to move fast or accelerate on kind of any business decision because now it’s all in one small area to get it done.

Melissa Roberts:

Yes. As long as you remember that there’s only one authoritative source of the truth, which is that one API, and everybody who goes after that API is going after that source of truth. They don’t have their own sources of truth about the same

Stacy Gordon:

Thing. Okay. That makes sense to me. So when a lot of what I know Luminal Arc talks about is aligning teams to domains and that’s reorganizing people. And that is hard. That is not easy to do, especially in a large enterprise organization. So I’m going to ask you kind of a tough question. Is this your approach on, are you smuggling in like this massive organizational change program, but we’re going to call it an architecture decision? Is it really realistic that a modernization budget can also move the organizational chart?

Melissa Roberts:

So a couple of things. One is when we’re talking about aligning teams to domains or business capabilities, that’s not an organizational change. That’s not an HR change. That’s just a teaming structure change. So I can give an example if you have in your organization, all your business architects in one area and they’re reporting to one person, that’s not working. You need to spread them out along the different business capabilities. They still report to the one person, but they’re also dotted line to their team. And that’s their first priority is their team. So the realistic. It’s not a small ask, but the realistic answer is you also don’t need to do this for the entire organization. Pick that one domain, that one strategic area, that one business capability that you need to work on first and do that. And then slowly start rolling out the other changes.

Stacy Gordon:

Well, and the good thing about that is, and I know it’s something that we talk a lot about at Lemonal Arc, is doing things in prioritize small scoped work slices because it also allows you to, within your organization, something that may be foreign to them that they are really questioning. You can showcase how it’s going to work and then you can build credibility. You can build safety in order to continue to roll this out into other areas. So it definitely, it’s nice to hear that you can do it in a way that is smaller. And it doesn’t, again, going back to that boil the ocean. You don’t have to do it across the entire enterprise all at one time because again, then ultimately things will fail.

Melissa Roberts:

Right. Right.

Stacy Gordon:

I do have to laugh because I tease all of my friends that have been in consulting forever. And I love the phrase, “It depends.”

Melissa Roberts:

Oh, yes.

Stacy Gordon:

And I get it. I get it. I get it. I get it. But if I’m an executive who has to make a decision on Monday morning, if I use the word it depends, that sounds a little fuzzy. I mean, how do I turn it depends into something someone can actually act on?

Melissa Roberts:

Okay. Well, that’s a fair hit. We do love that it depends.

Stacy Gordon:

It depends.

Melissa Roberts:

But it depends isn’t fuzziness. It’s precision about what the answer depends on, which okay, is also kind of fuzzy. But the heat map and the domain alignment exercises exist specifically to convert the it depends into it depends on these three things, three measurable things. And here’s where we land on each one of these for a specific capability. By Monday, an executive doesn’t need to know the universal rule. They don’t need to know the whole organization. They need a ranked list of which capabilities to focus on first. And that’s exactly what that heat map gives you. A prioritized list with the reasoning attached.

Stacy Gordon:

Okay. So even though they have all the factual credibility to support it, I guess they can still say it depends as long as there’s the three things on the backside. So let’s pivot and focus on getting buy-in. Your title says Business Value at Every Step. This approach talks about delivering value incrementally versus the Big Bang rebuild, where it takes forever to see anything. Talk to me about that.

Melissa Roberts:

Yeah. I mean, simple terms that you’re no longer scoping the effort around rebuilding the application. You’re scoping it around improving your capabilities. And a capability can be improved in increments. A process changed here, a targeted refractory there, a piece of automation somewhere else. Each one delivering value on its own without waiting for some grand unifying rebuild finish. And the heat map lets you sequence those in increments by where the value performance gap is widest. So the business sees improvement step by step instead of holding its breath for three years and going, “Did it give it to me? I don’t know. Three years are up. Do I have it?”

Stacy Gordon:

Well, I like too that the heat map helps you understand where to focus first. So again, contributing back to this business value at every step, moving things into production faster rather than waiting for 18 months. I mean, by 18 months, half the people on the team could have moved on to something else, but that’s another story for another day. Another day. In your article, you quote, “Tune and parent on needing stakeholder buy-in and a clear line to strategic priorities.” In practice, how does the heat map become the artifact that gets a skeptical executive to actually say yes?

Melissa Roberts:

Well, first and foremost, it speaks the executive language instead of an architects. They don’t get excited about microservices. Shoot, I don’t get excited about microservices or refractory patterns at all. They get engaged when you show them a visual that says this right here, this is where your strategic priorities and your actual performance are furthest apart. And here’s where it’s costing you to leave it that way. So the heat map turns in architectural conversation, which is important into a business conversation. And that’s what earns the buy-in, not the technical elegance of the plan, but the clarity of the trade-off.

Stacy Gordon:

Well, and it’s so different than probably most of the conversations they’re having. I mean, the premise of this whole conversation is that application modernizations fail and there’s billions of dollars that people are contributing to year over year in that failure. And so it’s just nice to see that the heat map is at the core of all of this. And it’s allowing the team to have more informed, better researched, just better conversations in general and very different than they’ve probably ever had when it came to tackling an event like this.

Melissa Roberts:

Oh, absolutely.

Stacy Gordon:

When I think of why customers modernize, a lot of times it’s something that’s forced. So it’s more of a vendor end of life. There’s a skills gap that we have, a compliance deadline, maybe We just acquired another company and we have two tech stacks colliding. Does this framework actually survive contact with a forced timeline or is it a luxury for organizations that just aren’t under the pressure yet?

Melissa Roberts:

It does survive, but it’s going to change its role. Like you said, you’re forced. You don’t have the luxury of doing a full capability assessment before you act, because deadline’s a deadline. If it’s compliance, you’ve got to get it done. If it’s an M&A, you’ve got to understand what you’re doing. What the framework does give you in that situation is a faster, sharper way to scope the forced work. So even under pressure, you know which capabilities the force change touches. Then you know which of these are strategic, which are utility. It helps you decide where to invest the extra care and where it’s fine to do the minimum to get compliant or supported. Doesn’t remove the forcing function, but it stops the forced work from sprawling into capabilities that didn’t really need the attention.

Stacy Gordon:

Okay. So the basic message is, hey, be more proactive. Don’t get into a forced situation, but you’re lucky. If you do, you can still use this same methodology to help you. But just again, like you said, it changes its role a little bit. Yes. So kind of another question here. The framework exists to stop wasted spend, but okay, we got to build the model, the heat map, we got to do the domain alignment, especially if you’re starting from scratch. That’s a lot of work and effort and expense before you actually even modernize one little thing, even in your prioritized work effort thought process. So how do you avoid this analysis by paralysis a year of just mapping and you deliver nothing?

Melissa Roberts:

Well, first of all, you scope it like anything else ruthlessly. So you don’t need an entire enterprise-wide capability model before you do anything. You start with the highest pressure business unit or domain and build that model and that heat map in that area and make the decision, deliver something, and then move on. The model expands as you go and is informed by real decisions rather than built in a vacuum. So if the mapping exercise itself has taken a year, that’s assigned the scope was wrong to begin with. And you are not using the right approach that I am stating here, which is small chunks. What is that highest business value business domain going after? So if you use this approach, you can complete the scoped heat map in weeks, not years or months.

Stacy Gordon:

Well, I think that’s something that executives definitely love and just like this conversation, probably something that they don’t hear very often. So I do believe that there’s people out there that are going to say, “I have a core system that can’t be modernized incrementally. You can’t half migrate a ledger or a system of record.” So where does this value at every step break down? And what do you tell someone whose hardest problem is this monolith that resists slicing? How do they go about it?

Melissa Roberts:

So I have a really cool example of someone who, an organization who did training or who is doing training. And they needed to replace their legacy monolithic system. It was a third party vendor and they were going to replace it with another vendor that was more core to what they were doing. But the cool thing was, is at first they were going in thinking they had to replace everything at once and they wouldn’t get anything for several years. But once we started breaking things down and building those domains and attaching them with the capability heat map, what we saw is we could do bits and pieces for them. We could do an upfront customer, let’s just say it’s an upfront customer inquiry system where they wanted to know what kind of things they could take and what would be beneficial for the customer to take.

They could fill that out and then they can see what was available. That’s part of the larger legacy system that was easier to put in, or it will be easier to put into production.

Stacy Gordon:

So sometimes they just have to have a little trust in the beginning to say, even though it seems foreign to them, that listen, we’ve seen it all. We’ve seen the largest of monoliths where people say there’s absolutely no way we can do it. But once we apply the approach, the Liminal Arc approach to this, what you’ve been so eloquently talking about, it’s like the light goes on and they’re like, “Oh my gosh, I would’ve never thought I could do this. You’ve helped me. You’ve given me kind of the keys to the castle or you’ve given me the insider’s tip on really how to do this.” It’s just so interesting.

I think it’s probably ultimately going back to why even like we’ve said a few times we’re having this conversation is that so often these modernization efforts fail, but they don’t have to if you just take a different approach. And just your example showed how you had a customer sitting there going, “There’s no way we can do it.” And the lights went on for them and they were like, “Oh my gosh.” And I’m sure they felt it like it was their birthday and they got such good news and information. So you’ve given so much great insight. So as we start to kind of close it up, help me here. If there is a leader who has budget, he’s got some money and his instinct is to rewrite, “I’m going to go tackle the oldest, ugliest system first because I got my money. I’ve been putting business places together for this for the last nine months.” What would you tell them they do before they ever touch a line of code?

Melissa Roberts:

Stop. Put the brakes on. If you don’t have your capability map, which like we said, most organizations don’t, what is that business problem you’re trying to solve? What is the value prop you’re going after? What is that strategic need that needs to be met? Then hone into those business capabilities. I keep bringing up customers are on my head lately. I don’t know why. If you’re customer service, if you need to get more market, then look at that customer aspect and find out. If it’s for whatever reason HR, probably not strategic, so you don’t need to refactor that right now unless you’re out of compliance, then you might need to. So it’s asking those right questions and determining where you actually need to go. Not the whole, it’s all ugly and I have to do it right away.

Stacy Gordon:

From your lips to God’s ears, girl, I hope everybody heard that. The answer is stop. Melissa, I want to say thank you so much. You have really opened my mind. There is a better and different way to approach application modernization. And just, I hope everybody listening, make sure that you are not one of those companies that continue to fund the bloodbath of failed modernizations. You don’t have to. So Melissa, help me share with the folks out there, where can people find part one of your article, the rest of your work? How can they get in contact with you?

Melissa Roberts:

So part one and part two of my article, you can find on the LiminalArc website. So feel free to look there. And you can contact me. You can reach out via LinkedIn if you’d like to talk to me more about this.

Stacy Gordon:

Oh, awesome. Well, again, thank you so much everyone. That’s a wrap. If you found this valuable, please give us a like. How about a comment as well? We’d love to chat with you. And really, if you found it valuable, please share it with your friends. And as always, the team here at Luminal Arc is here to help and chat with you about your upcoming modernization efforts. Reach out to me and I’ll be glad to get the team together for an initial call. Until then, enjoy the long days of summer. See you next time.

This video 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.

Nearly 80% of enterprise application modernization efforts fail, and the reason has nothing to do with choosing the wrong technology. In this conversation, Melissa Roberts, business architect and value engineer at LiminalArc, explains why modernization programs are designed to produce technology outcomes instead of business results, and why that design flaw is what kills them.

Melissa and Stacy Gordon walk through the four primary drivers forcing enterprises to modernize, the IT/business alignment problem that stalls most programs before they start, and how a capabilities-driven strategy changes what a modernization program is designed to deliver. If you’re leading or influencing a legacy modernization initiative, this is the diagnostic you’ve been missing.

Podcast Transcript

Melissa Roberts

I’ve worked with companies that did not even create benefits cases. They didn’t have strategic goals. They didn’t have your OKRs and KPIs and they just funded whatever they thought was the best thing to fund because they had feelings that it was a good thing to do. And that’s both on the business side and the IT side. And I’ve been in organizations where business is pretty solid. They may not have their business capabilities. That’s easy to do for them. But what isn’t there on the IT side is that connection because they have their own goals. So those goals and business goals don’t come together. So you’re at odds there. So that also makes the modernization difficult if you can’t get on the same page of what you’re trying to solve.

Stacy Gordon

Hi everybody. My name is Stacy Gordon and I lead our strategic growth initiatives at Liminal Arc. Today I’m joined by my colleague, Melissa Roberts, one of our business architects and value engineers at Liminal Arc who wrote an awesome new article titled Why Most Application Modernization Efforts Fail and How a Capabilities Driven Strategy Can Stop the Billion Dollar Bleed. I don’t know about you, but whenever I hear a billion dollar bleed that an organization is suffering, I’m going to stop and take note. Sounds pretty stressful. I’m going to kick us off, Melissa, by focusing on a pretty startling statistic that you call out at the beginning of your article and it states nearly 80% of modernization efforts fail. You’ve got to help me here. Why do you think organizations keep spending billions of dollars on something that fails way more often than it ends in success?

Melissa Roberts

Right. So that is the billion dollar question. So the reasons for modernization really don’t change. So an organization will try it, it fails, it’s spent a lot of money, but they still need to modernize. So they have to try it again and they have to try it again. So you either try it, you succeed, or you don’t exist as a business.

Stacy Gordon

Okay. That is just crazy to me that they keep repeating the same old patterns. So I think let’s kind of get into that a little bit. I picked up on a theme in your article and it really resonated with me, to be honest, because I think I do this a lot. But when it comes to modernization, the theme was most organizations seem to start with the end tech result. So the answer to our problems must be, let’s move all of our stuff to the cloud. Or now with everybody talking about AI, we’ve got to do AI. Let’s implement some AI. I don’t know where we’re going to do it, but let’s do it. Let’s just make it happen, everybody. So why do you think so many companies seem to start with the perceived solution, the solve to all of our problems versus, okay, wait a minute, why don’t we start with the problems that we actually are trying to solve and go from there?

Melissa Roberts

So the short answer is it’s easy to do it that way. It’s easy to hear, oh, AI is the new thing that’s going to fix everything. So we’re going to do that or cloud. We got to move things up to the cloud because we were told that’s the thing we have to do. But what’s really occurring is traditionally IT is considered not part of the business. So if they’re not part of the business, why do they care about business outcomes? Therefore, the technology and the technology says to move to AI, technology says move to cloud. So you couple that with this whole innovation of the marketing of the hype around everything and it’s not surprising that they just go for it. They go for the solution and not the business value.

Stacy Gordon

I do think it’s interesting that you talk about IT not being part of the business. I’ve only been at Luminal Arc for a short amount of time, but I hear us talk a lot about silos. And in my mind walking in, a silo meant often more about data. Data is in silos and that makes sense to me. So help me understand, is this a silo problem based on how the organization is set up that allows IT to operate over here without thinking about the whole of the business?

Melissa Roberts

Yeah, I think it can be a constructed silo. So culturally it’s a silo. Your IT, you’re in the back of the office. You don’t help us do anything. We are the business. We’re the important ones is what I’ve heard in the past.

Stacy Gordon

Yeah. I’ve read tons of articles just as I kind of sit forward with CIOs and CTOs and kind on the sales front of things. I hear and read articles about this clash between IT and business. And I know that at Luminal Arc, we’re constantly trying to educate people about how you can’t keep these two entities apart, that if you really want to do change and obviously modernization, you can’t keep them apart. They have to be talking to one another, aware of what other people’s pain points and concerns are and issues are to really pull things together. So that kind of leans me into, okay, you’re telling me we have to modernize. If the business is going to survive, be competitive, grow in the future, they have to modernize. And you even estimated that over the next five years they’re going to be spending 51, again, billion dollars on application modernization. And you talk about there’s four primary drivers that organizations are looking at that says, these are problems that we have we’ve got to modernize. Help me understand what this is and talk to me a little bit about more these four core things that organizations are challenged with and why they have to modernize.

Melissa Roberts

Sure. I think they’re all equally important, but some may ring bells with an IT department more than others. So cost. Cost is the one that IT is going to focus on most and probably the entire business. The older or more inflexible your application is, so you can’t make changes quickly, you have technical debt is going to cost you a lot of money and that’s your budget that’s being eaten away that you could be spending on something else. So the other is the scale. I briefly mentioned that when I said it was inflexible. So as market changes and it changes quickly, you can’t change because you’ve got this huge legacy application or this huge, I’ll call spaghetti we’ll talk about in a few minutes, I’m sure, applications that it just doesn’t move at all. You’re losing your market share there. Then another—

Stacy Gordon

One question real quick, what you said I thought was interesting. And I think maybe this is what you’re talking about from a competitive set. You’re like, there’s lots of legacy debt so they can’t change quickly. So it’s like if I’m a retailer and my competitor just implemented a new feature for a better user experience and I’m sitting here as the CEO going, “Okay guys, I’m calling my IT department.” I’m going, “Hey, why aren’t we doing this? I need you guys to figure out how to get this implemented.” Is these the types of problems that you’re talking about when you say they can’t scale or change?

Melissa Roberts

Absolutely. It’s like being, you should be the A team, but you’re really the Z team and you can’t get to A.

Stacy Gordon

Okay, that would be a problem. Definitely. So what about, you talk a little bit about technical debt, do you believe, I thought this was really interesting that you said in your article that once an application is launched from that moment on, it’s considered legacy. Now, okay, that stood out to me. And my question to you is, do you think most organizations realize that literally the moment that they put it into production, they should already start to think about it acquiring technical debt and being a legacy application and now being a maintenance cost center for them moving forward?

Melissa Roberts

Yeah, no, I don’t think they really do. They think they’ve got this great new application that they launched and it meets every single one of their needs right now. So they put it in and then they tend to forget, “Oh yeah, I got to keep looking at this. I got to keep seeing what’s changing in the market. I got to keep seeing what’s the new security feature I have to look out for.” And it just sits there and it just keeps adding onto that debt.

Stacy Gordon

How about on some of the elements and I know you said maybe they are or not all created equal. What do you think about that user experience? So much has changed since I 20 or 30 years ago started using digital applications for online shopping or managing my home finances or whatever and we’ve come to expect a certain type of customer experience. Do you think that that is kind one of the core drivers for why people recognize again, if their organization’s going to stay in business, they better have the best experience?

Melissa Roberts

Absolutely. So this younger generation, they want those same experiences that were shaped by what they’re using every day. So if you have an application that let’s say was built in the ’90s even, you can even build it in 2015 and it’s not that cool slit, you can move from this, you can move from that, you can go to Slack, you can go to Reddit, you can go all that seamlessly, you’re going to lose those potential customers because they just don’t have time for, “I got to click this button, I got to click that button, I got to go over here.” Yeah, you’re going to lose that.

Stacy Gordon

Gotcha. Yeah, I can see that one is one that rings true for me just because I get frustrated all the time when I have a bad user experience and it will cause you to literally take time out of your day to go find a replacement for that service that you’re using in your home. So I can see why that would be a huge driver for an organization to make sure that they can adapt and move quickly and change to stay ahead from a competitive landscape. We’ve talked a lot about why organizations must modernize. What is driving them to fortunately or unfortunately go down the path of modernizing their application, hoping that they are one of the 20% that actually successfully put something new into production. So I want to talk a little bit about why do these modernizations fail. So let’s give people the answer to the test. Why in the world do so many of these modernizations fail? In your article, you focus on a number of different things. I wanted to start first with, I think you called it boiling the ocean, the boiling the ocean problem. This is one I definitely do not understand. Why do organizations try to modernize everything all at once? What is it about this giant transformation program that seems to them that sounds like, oh my gosh, this is an amazing idea. I mean, go big or go home, catapult your personal success and I’m going to get a big raise and a new job and every person in the world is going to want me to come work for them. I mean, you tell me, what is it?

Melissa Roberts

Right. I mean, yeah, it’s appealing. What you said is appealing. Wow, I did this and my organization can reap the benefits for years, but it’s really more nuanced than that. I think there’s a lack of understanding of the impact that these giant transformations mean to the organization, especially if you’re replacing huge chunks of your application, your software systems, then you’re pulling it out, you’re changing your organization itself, you’re changing how the users interact, you’re changing everything all at once and it’s just a hard thing to do.

Stacy Gordon

So it is on one end, this appeal to being the savior and saving the day. How about on the other end? Is there a pressure that’s put on these stakeholders to say, “You’ve got to get in there and fix this problem and I want you to fix it now. I don’t want to take no for your answer.” And so going back to what you’ve stated already, they only know one way to do it. It’s an IT thing. I’m going to go put the pressure on my IT team to say, modernize this stack because I have to have a better customer experience. I’m assuming that has to be as much of a thing or in a back of a person’s mind as the, I’m going to be the big winner.

Melissa Roberts

And now you’re starting to get into how do we put the brakes on this? How do we go back to our leaders and say, “Yes, I know you want to do this and we can do this, but here’s data that’s going to show you what we should be doing first.”

Stacy Gordon

And does that go into this framework discussion? Because again, it’s like I bet you have a lot of the people that are responsible for these transformations and they know that it’s not the right thing and they’re throwing out these questions and they’re throwing out these propositions, but it’s like if you don’t have a framework to anchor it around, that creates a lack of understanding for perhaps people on that side of the business.

Melissa Roberts

That and it’s the loudest voice wins. I say, “I need this. I’m the loudest voice. I’m going to get it.” It doesn’t matter how much it’s going to cost.

Stacy Gordon

So Melissa, paint me a picture of what it feels like to be that person in an organization that has to start this giant transformation or he is charged with modernizing this application. Help me understand what he’s feeling each and every day.

Melissa Roberts

Right. Well, the first thing they would be feeling is it’s stressful. It’s stressful. Like you said, it fails, modernization fails all the time. So it’s on your shoulders to tell your team, this is the right direction, this is the way we’re going. And from an SVP, CIO all the way down to hands-on keyboard, your identity is wrapped up into your career and if this fails, you fail. So there’s a lot of pressure on yourself as well.

Stacy Gordon

And then if you’ve talked a lot about how organizations are structured, if you feel like you’re over here on an island, I mean, it’s got to even exasperate what you feel like you’re going through. Do you find that these leaders feel like they’re carrying this around in a backpack and it’s all on them? Do they feel like they can reach out to their peers within the organization to get support and feedback or do they just further isolate themselves? What have you seen in your experience?

Melissa Roberts

Well, it really depends on the organization itself. I’ve worked in organizations where if you went and asked for help, that meant you weren’t good at your job and you were going to get fired. So you did hold it all. You had to do everything. And then I’ve worked in extremes where it’s open. Everyone’s like, “Yeah, let’s talk about this. Let’s get it done. You have a great idea. Let me help with that idea.” So those are two extremes. I think most of the time you fall in the middle, you have to find out who you can talk to and who you feel you can trust with this. But I still think that most people are going to carry this on their own. They think they can solve this or they have to solve it.

Stacy Gordon

Right. Yeah, that’s a lot of pressure. I guess that’s why they get paid the big bucks to be able to support the weight of the world or the weight of their organization and the success of their organization, which is why it’s hopeful that people are starting to see that there are new ways of thinking or new approaches that they can consider a new journey rather than doing the way that they’ve done things all the time. And so thinking about that, you talk a lot about business-driven capabilities and you talked something about that’s a new way of thinking. So that’s hard. That’s hard for people to start doing things differently and thinking differently. How does someone start to embark on that journey to say, “I know the way that people have been doing it has failed. I don’t want to be that person. I’m going to try something different.” How does that seem to get into someone’s body and say, “We’re going to go down this way.”

Melissa Roberts

I think first you have to sit in that discomfort of failing. You have to acknowledge that I failed, it’s okay. It’s time to try something else. And that’s a really hard step for a lot of people. Once you get past this, you’re like, “Okay, so if somebody is telling me a capabilities-driven approach is the way I need to go, I need to figure out what that is. So what is that capability? What our capabilities makes no sense to me. I don’t understand that. Capability is simply what you do as an organization, not how you do it, the how is your technology, what. I’m running a donut shop and I want to make sure my customers come in and can select it on a kiosk, their donuts, and then check out. Your what is service management, customer service management is your what. How you do it is that kiosk and the technology under it.

Stacy Gordon

Gotcha, gotcha, gotcha.

Melissa Roberts

So those are some—

Stacy Gordon

I think starting with the tech solution rather than the business capability. I see where you’re going with that. That’s a good example.

Melissa Roberts

Yeah. So understanding that. And then another really difficult thing for people to do is what is business value? What am I trying to achieve? So is it I want to increase my market share? Is it I want to have new customers coming in that are the younger generation? Is it I want my internal people to have what they call a single pane of glass when they’re doing customer service, which is on screen where all the information is. What is it that I need to do? So finding that out and how are you going to measure it? What are the success measures for this? What is the cost benefit analysis?

Stacy Gordon

Do you believe organizations have actually … They have that information, but it’s on the business side and it doesn’t get translated to the technical side? Or do you find that even sometimes some of the best businesses seem to get away from the foundational components that they should be doing each and every day? These things sound relatively simple to me on the way that you should be thinking about your business, but people aren’t doing it. So is it one or both? What do you think?

Melissa Roberts

I think it’s both. I mean, I’ve worked with companies that did not even create benefits cases. They didn’t have strategic goals. They didn’t have your OKRs and KPIs and they just funded whatever they thought was the best thing to fund because they had feelings that it was a good thing to do. And then I’ve been in … And that’s both on the business side and the IT side. And I’ve been in organizations where business is pretty solid. They may not have their business capabilities. That’s easy to do for them, but what isn’t there on the IT side is that connection because they have their own goals. So those goals and business goals don’t come together so you’re at odds there. So that also makes the modernization difficult if you can’t get on the same page of what you’re trying to solve.

Stacy Gordon

The interesting thing too, I think probably, and you tell me if I’m right or wrong here, is that you have this modernization, you have an executive that’s willing to think differently and say, “I want to align with business goals so I can determine what to do.” And we talk a lot about frameworks and roadmaps. How do you determine what you should do? You started the process on a new way of thinking, but what’s next? How do you make sure that what you’re deciding to do is the right thing to do?

Melissa Roberts

How do you make it real?

Stacy Gordon

Yeah.

Melissa Roberts

So that’s part two of my article.

Stacy Gordon

No, I always like to go straight for the good stuff. Okay. Well, now you’ve teased it. So everybody, please take note that there will be a part two of this amazing conversation for you to tune into. But before we let you go, if you were going to leave some lessons for leadership, so the biggest takeaways from our conversation today, what would those be? And maybe if there’s one thing that a leader who’s listening to this today that wants to do something different, what should they do today to try to make an impact in changing how they’re going to approach a modernization project in the future?

Melissa Roberts

Well, besides reaching out to you, Stacy?

Stacy Gordon

Well, yes, please call me. Yeah.

Melissa Roberts

I would say take a look back at how you’re approaching your modernization. Do you have a data-driven roadmap? Is it connected to all your spending and then all of the benefits that you should be seeing from that spend? Are your investment options grounded in real data or is it the loudest voice first? If not, then you probably should reach out to us, but also more importantly, you’re not alone. This application modernization is not easy if it was. Stacy and I would not be talking to you right now.

Stacy Gordon

Well, I think one of the things that you wrote in your article that I want to close with is you said the longer you wait to modernize, the further behind your organization falls. So please, everybody, if you’re looking to dive into this topic a little bit further, you can always go to our website and read Melissa’s article, Why Most Application Modernization Efforts Fail and how a capabilities driven strategy can stop the billion dollar bleed. So definitely go check us out and make sure to tune into part two of this interview to where we help you understand how to bring this to reality and put it into practice. I’m Stacy and that is Melissa, and thanks so much for joining us.

 

Read Melissa’s Article: Why Most App Modernization Efforts Fail, and  How a Capabilities-Driven Strategy Can Stop the Billion-Dollar Bleed

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.

Podcast 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.

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 this time the penalty is bigger. The pattern is everywhere: the demo dazzles, the pilot works, the rollout dies, and the board starts asking where the money went. The technology was never the problem. The way we went about it was.

There are seven reasons AI initiatives keep failing in 2026. Every one of them is fixable.

1. 1. It only works in the pilot
   2. It amplifies a broken system
   3. You never created the conditions
   4. You can’t automate a tangle
   5. You gave it the wrong job
   6. You rolled it out everywhere at once
   7. You bet production on a promise

   1. It Only Works in the Pilot

   Every pilot succeeds because somebody built it a protected world: small scope, clean data, one team, a leader who cares. Production is where your real conditions live, and that’s where pilots go to die.

   2. It Amplifies a Broken System

   AI doesn’t just execute broken processes faster; it generates work product inside them. Instrument a tangled system with AI and you get more broken stuff per unit of time. The chaos compounds. Your pilots aren’t failing; they’re gauging the distance between the conditions they had and the conditions you have.

   3. You Never Created the Conditions

   There are four, and they’re testable in a week: encapsulated technology, clean data at the source, an organization designed around ownership, and intent governed at the top. Either they exist where you’re trying to run AI, or they don’t.

   4. You Can’t Automate a Tangle

   Applications are packaging, not things. Capabilities are the unit of decision, and capabilities have natural edges where a team can own something, data can be validated, and an agent can work inside a boundary.

   5. You Gave It the Wrong Job

   AI has three real jobs: the navigator that maps your estate, the junior engineer that builds under supervision, and the operator that acts on clean business objects. Most organizations tried job three first. And there’s one job it can never take: judgment.

   6. You Rolled It Out Everywhere at Once

   Horizontal transformation is why your last transformation failed: everything moves, nothing finishes. Go vertical instead. One slice, all four conditions created for real, value proven in production in ninety days. Then do it again. And the transformation has a bottom: when the slices stop paying, you stop.

   7. You Bet Production on a Promise

   Trust is earned in stages: understand, align, hypothesize, ingest, extract, deliver. Every stage is a gate: stop after any of them and you keep everything of value. Anyone who wants to transform everything before proving anything is asking for more trust than they’ve earned.

   AI Isn’t Failing

   AI isn’t failing in 2026. Enterprises are failing at AI, in the same seven ways, over and over. That’s what makes this fixable. A failure you can predict is a failure you can design around, and every one of these seven has a known way out. The organizations that get value from AI this year won’t have better models than you. They’ll have stopped making these seven mistakes.

Nobody has done agentic application modernization a hundred times yet, because the AI models capable of it have only recently become good enough to use. LiminalArc’s bet starts with a thesis: business capability modeling and domain-driven design are the same discipline in two languages. One extracts and encapsulates the business, and the other extracts and encapsulates the technology aligned to it. Combined with AI extraction tools and context engineering, that thesis supports an extract, enhance, exploit cycle for legacy systems.

The approach rests on 16 years of LiminalArc transformation work, including six years of extraction and modernization done by hand. That history is where the judgment about keeping humans in the loop comes from. Agentic practices are already speeding up that work on client engagements, alongside agentic playbooks and agentic governance. It isn’t proven end to end yet, but it’s close enough to talk about openly.

Video Transcript

Mike: 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, over the last year and a half, we’ve been building the pieces into the client engagements that we’ve done.

Stacy: 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: We started developing this thesis about two and a half years ago, started investing in it about a year and a half ago. About nine months ago, six months ago, the models started getting good enough to do some of this stuff.

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 an insight I had, probably one of the first things I explored with ChatGPT when I got my ChatGPT-4 account back in the day.

The thesis was: is domain-driven design and business capability modeling the same fundamental discipline in two different languages? Business capability modeling being 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 in alignment with the business.

And what was funny is that as I’m querying AI, it’s 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.

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, 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 you can start to expose that data in a way that’s available to other parts of the organization.

So the exploit side of it is that once I have the encapsulated components, 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 that’s not where everybody’s head space is.

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: where do humans fit into that, the humans in the loop, 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 is super well understood, is context engineering. I think that’s a really, really big deal.

We’re piecing all that stuff together, and that’s what I’m betting on.

Stacy: 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: It’s funny. I pay a lot of attention to X and Substack and different things, and I’m trying to figure out where people are talking about what they’re doing. There’s a couple articles I’ve read that have really kind of lit up my brain.

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 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’m sure they’ve done whatever they’ve done a hundred times, 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 I have to make is that LiminalArc has 16 years of doing this by hand. 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, over the last year and a half, we’ve been building the pieces into the client engagements that we’ve done. We have clients that we’ve done ingestion and extraction work on their code bases using something we call Code Navigator. As we’ve extracted and modernized different applications by hand, we’ve started to bring agentic practices into that to speed up that work.

We’re doing a lot of stuff with agentic playbooks internally. We’ve started working with some of our customers on agentic governance. And all these little pieces that are emerging in the marketplace are starting to snap to grid.

What’s kind of interesting is that because we’ve got this integrated methodology, we’ll use AI and these techniques for the places where they’re mature, and we still have the background and expertise to do it by hand in other places. We know the pitfalls in all the different areas, because we have so many reps doing it over the last 15, 16 years.

So where have we seen it actually work? We’ve seen it actually work by hand all over the place. We have some 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.

Have I totally seen it work end to end? Nope. But I think we’re close enough to really start talking about it and share what we’re learning. There’s going to be some people that are going to go along for the ride with us.

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/

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.