Ellen has run product for her group for years, and she can name the week the job changed. It was not a reorganization and no one announced it. The gap between strategy and delivery simply became amplified, one conversation at a time. The build engine was faster than it had ever been, and every team lead, stakeholder, and steering group brought her the same four words. What do we do next?

The question arrived faster than she could answer it. Decisions that once waited invisibly in a long development queue now waited visibly on her calendar. Feeding that calendar was a wall of options: each one better polished, each one possible, each one assembled in greater efficiency with an AI agent collaborative process, complete with requirements and a business case. Ellen’s own role had changed. She used to spend her weeks eliciting ideas and shaping them. What the agents cannot do is commit the organization to one, or answer for it. The judgment to decide, the one thing that did not scale, had become her primary job.

The Fuzzy Front End Lost Its Buffer

Donald Reinertsen and Preston Smith named this territory more than three decades ago: the fuzzy front end, the stretch between a market signal and a committed decision to act, where initiatives wander before development begins. The fuzz always had a cost, but a buffer absorbed it. When building took quarters, the long queue behind every decision worked as that buffer. Intent had time to firm up while the engine ground through the backlog. The fuzz was never only a discipline problem. What to build is genuinely hard to know in advance, and the front end rarely had a rigorous process for making it clearer. It stayed that way because the constraint lived downstream. Fuzz was not the bigger problem, so it was tolerated rather than fixed.

A fast, inexpensive build engine removes the buffer. Fuzzy intent no longer waits; it passes straight through the engine and ships. There is no interval in which clarity catches up, so half-agreed intent becomes shipped clutter at machine speed. It spends the customer’s limited capacity for change on things nobody agreed were the problem.

Fuzz was tolerated while the constraint lived downstream. The buffer is gone.

The Scarcity Is Decision Capacity

So if ideas, build capacity, and information (telemetry, synthesized feedback, and adoption signals) are abundant, what is the scarcity now? It is decisions, the organization’s capacity to converge and agree, quickly and repeatedly, on the next problem worth solving for the customer. Clarity alone is not enough. One person can make a choice, but a choice becomes a decision only when the organization is bound to act on it. That is what deciding means at organizational scale. McKinsey’s research on organizational decision making suggests how strained that capacity already is. Managers at a typical large company spend 37 percent of their time on decisions, and say most of that time is used ineffectively. Only one in five reports an organization that excels at deciding.

37 percent of managers’ time goes to making decisions. The majority of it, by their own account, is used ineffectively.

A faster engine does not need a better decider. It needs an organization that can decide well many times over, in parallel, without routing every choice through one calendar. That makes decisioning a core governance capability, one the operating model has to hold deliberately, with people accountable for it and measures that show whether it is keeping pace.

Part of building that capability is shrinking what has to be agreed. In place of a long-range roadmap, one testable intent comes forward at a time: the problem to solve, a value hypothesis, and a confirmation plan describing how the team will know it was right within weeks. Options stop being arguments and become candidates for evidence. Decisions get faster because the thing being agreed on gets smaller.

Agreement also has a clock, and almost no one reads it. The engineering side of the house already measures its half of the loop; in “Are You Building the Right Thing,” Adam Whaley clocks time to feedback, the interval from starting a piece of work until a real user responds to it. The upstream mirror is simpler than it sounds. Measure the elapsed time from an idea arriving to its entry in a product backlog as committed work. Call it upstream lead time. Nearly none of that interval is production; it is deciding and aligning, which is what makes it the most honest proxy available for decision capacity. Deciding will need its own family of measures, the way delivery eventually got its own; this one is the place to start, because it is the one every organization can already compute.

One guard keeps the measure honest. Entry into the backlog has to mean committed intent, not a parked idea. Otherwise the number improves while nothing has actually been decided. Ellen stopped asking her teams how much was in flight and started asking how long each intent had been waiting to become one. The items waiting longest are not the hardest problems. They are often the ones nobody is empowered to decide.

Redesign the Clocks, Not the Gates

The instinctive fixes fail in opposite directions. More gates make agreement slower, rebuilding the heavyweight front end that was survivable only when the build was slower still. No governance makes agreement meaningless, because nothing binds the organization to act. The redesign is about placement and cadence, who holds which decisions and how often each decision renews.

Placement

A decision belongs at the boundary where its information lives, and risk is what sorts it there. Two properties settle it: reversibility, and the cost of being wrong. Low-risk intents, inexpensive to reverse and contained if mistaken, belong in the queue directly. Agents rank them, the team picks, and the confirmation plan catches the errors. Higher-risk intents need a named owner inside an explicit allocation envelope, because someone has to commit the organization and answer for the outcome. Some decisions genuinely cross boundaries: moving money or people between products, retiring a bet, changing direction. Those travel upward. Where the right value measurement does not yet exist, compensating controls hold the line until it does. Coordinated decisions are the ones that queue; the design goal is to grade honestly, delegate everything the grade allows, and need as few of the traveling kind as possible. Ellen graded every option on those two properties before asking who decides, and kept the high-risk calls herself.

Cadence

Three tiers set the rhythm. Strategy moves slowly, and should; direction is expensive to whipsaw. Portfolio allocation renews quarterly or on evidence triggers, adjusting envelopes rather than re-litigating every line. Product intent renews at the speed of the learning loop. One rule disciplines all three. Governance has to renew faster than the assumptions it governs expire. When assumptions held for years, calendar planning worked. Telemetry now retires assumptions in weeks.

Governance design is placement and cadence, who decides and how often. Get either wrong and governance becomes the bottleneck

The three tiers are connected, and that is the warning. A system moves at the pace of its slowest clock. Anything left on a slower rhythm will set the pace for everything else. Pace also depends on the size of the work.

How the enterprise moves money, and how strategy above the portfolio keeps up, is a larger redesign that deserves its own treatment. However fast the front end learns to decide, everything connected to it has to be able to follow.

What Ellen Learned

By the second quarter, Ellen’s review looked different. Intents came forward monthly, in units small enough to decide and confirm. Of the last eleven ideas, five were stopped before the build, when the evidence said no and stopping was still cheap. Alex, her group’s delivery leader, asked what she would tell a peer walking into the same storm. Three lessons she held:

1. Measure the front end as a queue. Upstream lead time is as measurable as the delivery lead time beside it, and until it is measured, the most expensive queue in the system keeps hiding in plain sight.
2. Test governance against the pace of evidence. Check where each decision sits and how often it renews. If evidence arrives in weeks and permission arrives in quarters, the teams are not the problem; the operating model is.
3. Sequence the redesign honestly. Start where the operating model can move now: placement and cadence. Then name what still sets the pace for everything connected to it.

The question that used to fill her calendar still arrives every week. What changed is that the organization can now answer it, at the speed the question deserves.

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

Donald G. Reinertsen and Preston G. Smith, Developing Products in Half the Time, Van Nostrand Reinhold, 1991. Popularized the term “the fuzzy front end.”

McKinsey & Company, “Decision making in the age of urgency,” April 2019.

Adam Whaley, “Are You Building the Right Thing: The Metrics That Measure How Fast You Learn,” July 2026. Source of the delivery learning-loop metrics referenced.

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

Alien, directed by Ridley Scott, 20th Century Fox, 1979. Character homage, name only, in tribute.

If you lead product today, you’ve probably felt the ground shift. The old advice was to ship something rough and learn in public. Now a rough launch gets punished. Users expect polish on day one, and a first version that looks unfinished can cost you the second chance you were counting on.

So the industry has done what industries do. It kept the Minimum Viable Product and swapped the adjective. First came the Minimum Lovable Product, the smallest thing people will love rather than tolerate. Then came the Minimum Adaptive Product, software that reshapes itself around each user. Both are sensible responses to a real change. Both leave the same assumption untouched.

That assumption is that the noun is what we’re optimizing. The product. When building was slow and expensive, that made sense. The first version was the costly thing, so we argued about how good it had to be before we dared show anyone. “Minimum” and “viable” were doing real work, because every build was a bet you couldn’t easily unwind.

AI has quietly removed that constraint. When a polished experience costs a weekend instead of a quarter, the first version isn’t the expensive thing anymore. Being wrong is still cheap to discover. Being wrong and unable to change course is what now costs you. The bottleneck has moved from making the product to changing your mind about it.

Which points to a different word than lovable, viable, or adaptive: adaptable.

The distinction is easy to miss and worth holding onto. An adaptive product changes itself for the user. That’s a feature, and it lives inside the product. An adaptable product is one you can change cheaply as you learn. It’s a property of how the thing is built, and of how ready your team is to keep experimenting: not a feature bolted onto the product itself. In practice, that means short feedback loops, components that don’t require a full rebuild to change, and a team with real authority to act on what they learn. One reshapes around the user. The other lets you reshape around the truth.

Seen this way, the strategic question changes. It’s less “What are we building, and is it good enough to launch,” and more “How cheaply can we learn we were wrong, and act on it.” The first version stops being a verdict on the idea. It becomes the opening move in a loop you intend to run many times.

None of this retires the discipline that made the MVP useful. Clear hypotheses, real users, and honest evidence still decide who wins. What changes is where the advantage sits. How much that’s worth still depends on how sure you are: a well-understood build doesn’t need to pay for it, but the more you expect to be wrong, the more that property is worth having. In a market where anyone can build almost anything quickly, the durable edge is how quickly the next version can be different, not the product you launch.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

For nine straight years, IBM i shops named cybersecurity their biggest worry. This year, something passed it.

In the 2026 Fortra IBM i Marketplace Survey, 69% of shops named IBM i skills their single biggest concern, ahead of security at 64%. That’s the first time in nearly a decade the top spot changed hands. The platform didn’t get less secure. The people who understand it started leaving faster than anyone is replacing them.

If you run manufacturing IT on an AS/400, you already know this story from the inside. You have a dev team of three to five people. At least one of them holds knowledge that exists nowhere else. And you’ve done the retirement math in your head more than once.

Here’s what the numbers say, and a practical way to gauge how exposed you actually are.

The Numbers Behind the IBM i Skills Shortage

The survey data reads like an actuarial table for institutional knowledge:

• • 72% of IBM i developers are now over 50, and roughly 36% are over 60

• • 91% of shops still run RPG in production, with no meaningful replacement pipeline behind the people who write it

• • 21% of shops run on just three to five developers, a number that hasn’t moved in ten years

• • 66% have fewer than three system admins; 10% have none at all

Meanwhile, more than 100,000 companies still run these systems in production worldwide. They survived four decades because they work, and because the cost of leaving always looked higher than the cost of staying.

That math held for 30 years. It doesn’t anymore, and we’ll get to why. But first, the part most teams underestimate.

Concentration Is the Real Risk, Not the Platform

The AS/400 itself is famously reliable. Ask anyone who runs one; the box doesn’t go down. What goes down is the number of people who can safely change what runs on it.

Decades of custom RPG carry the real logic of the business: how orders actually flow, how the plant actually schedules, what that one subroutine from 1998 actually does during month-end close. When that knowledge lives in two heads and zero documents, you have a single point of failure wearing a retirement countdown.

And it quietly constrains everything else. Enhancement backlogs grow because fewer people can touch the code. Integrations become workarounds. AI initiatives stall in the pilot phase because the data and logic they need are locked inside a system nobody dares disturb. Fortra’s survey shows AI and machine learning interest jumping from 30% to 42% in a single year; the appetite is real, and the platform is the blocker.

The exposure compounds on a schedule you don’t control. Every year, the bench gets shorter, the contractors get more expensive, and the option space gets narrower.

Waiting Is Also a Decision

Plenty of shops respond to all this with a reasonable-sounding position: it works, why touch it?

That position assumes waiting is neutral. It isn’t. There’s some evidence the market knows it, too: 70% of IBM i shops plan a hardware or software upgrade in 2026, a record in the survey’s history. Budgets are moving.

What changed the calculus is that the migration math itself changed. Large language models can now read the RPG dialects that kept these systems frozen for 30 years. Documenting what a system does used to be the step that made every modernization conversation stall. It went from a multi-year archaeology project to a tractable engineering task. What used to be a leap of faith can now be a measured, incremental program.

You don’t have to believe that today. This piece has one job: to argue that knowing your exposure is worth a half hour of your time, because every option you have, including staying put, gets better when you understand where the risk actually sits.

How Exposed Are You? A Five-Question Self-Check

Answer honestly. Give yourself a point for each “yes.”

1. 1. Bus factor: If your most knowledgeable RPG developer left tomorrow, could at least two other people safely change your most critical application?
   2. Horizon: Will the people who maintain your RPG today still be working for you in five years?
   3. Documentation: Does the knowledge of how your core system works exist anywhere outside people’s heads, in documentation or tests that someone new could actually use?
   4. Pipeline: If you posted an RPG role today, are you confident you could fill it within 90 days at a salary you’d approve?
   5. Change safety: Can you make a change to your core system and prove nothing else broke, without relying on one person’s memory of what connects to what?

Zero or one point: you’re on the cliff’s edge. The exposure is already shaping what your team can and can’t do, whether or not anyone has said it out loud. Mapping the risk should be this quarter’s problem, not next year’s.

Two or three points: you have time, but you’re spending it. Start capturing knowledge now, while the people who hold it are still in the building.

Four or five points: you’re in better shape than most of the installed base. Keep the documentation and cross-training habits that got you here.

The skills cliff doesn’t announce itself. There’s no outage, no alert, no audit finding. There’s just a Tuesday when the person who knew is gone, and the system that runs your business becomes the system nobody can touch. The teams that come through it well are the ones who measured their exposure while they still had choices.

If your score landed lower than you’d like, the next step starts with a clear read of where your risk and cost actually sit, not a migration decision. That’s a conversation we have every day, and we’re happy to share what we’ve learned.

Check Out Our AS/400 (IBM i) Workshop

Piece by piece, Alex had built the delivery engine his organization now had. AI agents drafted overnight. Test scaffolding that once consumed a sprint appeared in an afternoon. Features that used to take a quarter shipped in days, at a fraction of the old cost. Every DORA metric on his dashboard was green: deployment frequency up, lead time collapsed, change failure rate at an all-time low. The numbers that had anchored every hard budget conversation were finally, unambiguously good.

So the moment it fell apart was quiet. No outage, no escalation. Just a team lead standing in his doorway asking, for the third time that week, “What do you want us to build next?” The backlog that once stretched eighteen months ran thin by mid-quarter. Work was no longer waiting on engineers. It was waiting on his calendar. Alex had spent his career fighting a slow build engine. Now he stood in front of a fast, inexpensive one, and the organization wrapped around it had not changed at all.

The Constraint Moves

What Alex experienced has a name. Eliyahu Goldratt’s theory of constraints rests on a single insight: every system has one governing bottleneck, and improvement anywhere else is the illusion of progress. For decades the bottleneck in most technology organizations was delivery, which is why decades of investment went there: agile, DevOps, cloud, and now AI. For organizations that have done the structural work, the investment is finally paying off. McKinsey finds top performers achieving 16 to 30 percent improvements in time-to-market from AI-enabled development.

But Goldratt’s rule has a second half. A constraint you elevate does not disappear. It moves, and it rarely announces its new address. When the build engine becomes dramatically faster and cheaper, the constraint leaves delivery. For most organizations it surfaces where it surfaced for Alex: in deciding what is worth building.

The bottleneck did not vanish with the faster build engine. It moved to the decision itself: AI can inform what is worth building, but it cannot own the choice, or answer for it.

The Economics Invert

Alex’s first move was to rerun the prioritization model that had settled arguments for years. It came back useless. Every initiative scored “do now.” The math was behaving correctly; the world underneath it had changed. Cost-of-delay rankings, the flow economics Don Reinertsen taught a generation of product organizations, divide value by duration, and AI had collapsed the duration that once separated the options.

Delay still costs money; it just accrues in new places, in front of the decision and after the release, while customers absorb what shipped. So price delay where it now lives: rank work by its value and by how quickly that value can be confirmed, and treat a slow decision the way a slow build used to be treated, as the most expensive queue in the system. And the stakes rose while the math changed: a fast build engine does not forgive weak prioritization; it amplifies it.

For the CFO, the inversion reads differently but lands in the same place. The cost side of the ROI equation, what it takes to build, is falling fast; the return side now depends almost entirely on choosing well and on whether what ships actually gets used. Engineering efficiency will show up in the spend line either way. It reaches EBITDA only when the delivered value changes a revenue or cost curve, and that is a prioritization and absorption question, not a build question.

Put together, the inversion is simple: when building is fast and cheap, the scarce work is deciding what is most valuable and what the customer can absorb into real return. That is a capability, product management and the measurement of customer value, and it is where the operating model must invest next, because investment follows the constraint.

The Wrong Fix: Feeding the Funnel

His second move was the instinctive one: fill the intake. AI generates candidate ideas as cheaply as it generates code, and within a month the funnel was overflowing. His problem got worse. Pushing more input into a decision bottleneck does not raise its throughput. It raises work-in-process and lengthens the very queue it was meant to feed.

The honest objection is worth stating: if building is nearly free, why not build it all and let the market sort it out? Because building is cheap; having built is not. Every feature shipped spends two budgets no tooling can refill. It spends the customer’s, in attention, workflow change, and trust, where unused features clutter the product and erode confidence in it. And it spends the future’s, because everything built must be maintained, secured, and integrated for as long as it lives, and unowned complexity reassembles the old tangle at machine speed.

Ideas are now as cheap as code; the right ones are as hard as they have ever been. What is scarce is decision capacity, and it has two halves. One is cadence: deciding more often than the calendar allows. Gartner finds only 18 percent of CIOs practice dynamic, off-cycle reprioritization, and those who do are 24 percent more likely to be top performers. The other half is judgment: a shared, current definition of customer value, agreed between business and technology up and to the left, before capacity is spent. AI sharpens the inputs to that judgment, telemetry and customer signal at a depth no team had before, but it does not make the call. Cadence can be fixed with governance. Judgment is a capability, and it is the half the industry struggles with most.

The Customer Sets the Pace

Two failed fixes in, Alex called Jonah, an old mentor with a habit of answering questions with questions. Alex described the fast engine, the flooded funnel, the rankings that no longer ranked. Jonah asked only two things: “What limits the system now?” and “Is it even inside your building?” Then, being Jonah, he hung up.

The answer arrived from outside. Account managers began reporting an unfamiliar complaint: customers asking for fewer releases. Adoption lagged each launch a little further. The team was shipping faster than the people it served could change.

That absorption capacity is measurable, and it is shrinking. Gartner found the average employee experienced ten planned enterprise changes in 2022, up from two in 2016, while willingness to support change fell from 74 percent to 43 percent. Alex’s final constraint was the rate at which his customers could absorb what he delivered. Tooling can soften it, smoothing each change and surfacing adoption signals earlier, but unlike delivery it cannot be scaled on your schedule: the ceiling belongs to the customer. It can be paced to, not owned. Here the value of speed changes meaning: from throughput, doing more, to responsiveness, sensing sooner and delivering the right next thing.

The final constraint is not in your delivery system. It is your customer’s capacity to absorb what you deliver.

What This Does to the Operating Model

An operating model is what turns strategy into delivered value, repeatably. A build engine this fast and this cheap changes every component of it.

• • Capabilities and domains. The change here is indirect but relentless. A fast build engine creates new capabilities faster than the business architecture can place them, and every one of them needs a home: a domain it belongs to, an owner who answers for it, and data whose ownership is settled rather than assumed. Capabilities without a home recreate the gray area faster than anyone can own it.

• • Structure and boundaries. Boundaries get redrawn in both directions. When a domain needs less engineering capacity, team structures consolidate: accounts payable and invoicing keep their own bounded contexts, but one delivery team can now own both, because the demand side changed. And a new gray area opens between strategy and delivery, a seam that needs a named owner exactly as any unowned boundary does.

• • Governance and decision rights. The quiet change is beneath the waterline: every deployment hands AI more decisions, and few organizations can say which ones, or at what threshold of risk and value a person must re-enter the loop. It accrues slowly, then catches the organization off guard. What a portfolio governs, what a product group governs, and what a team governs with AI now look different, and each is managing risk at a speed governance has never had to move at. Where the right measurement does not yet exist, compensating controls hold the line until it does.

• • People and roles. The product roles become pivotal. Product managers and owners who connect customer needs, internal and external, to strategy, and who carry the competencies to make those value decisions well, including the decision to stop, now sit exactly where the constraint sits. That is no knock on the AI engineer or the delivery system; it reflects where the scarcity moved. And the division of labor has to be explicit: what AI does, what humans decide, and where they meet, written down rather than assumed.

• • Cadence. The deepest change. Annual planning cannot govern a weekly build engine. Strategy, funding, and validation have to move at the rhythm of a continuous flow, with intake ultimately paced to customer absorption rather than team capacity. As Gartner’s Chris Howard puts it, “gone are the days when organizations planned annually and locked in workstreams for the year.”

The diagnostic does not require a framework. Ask one question of your own organization: where does work wait longest today? If the answer is still the build queue, the structural work remains. If the answer is a decision, a funding cycle, or a customer’s capacity to take on change, the constraint has already moved, and the components above are where it is hiding.

An operating model built around a scarce build engine cannot govern an abundant one. Every component, from decision rights to cadence, was calibrated to a constraint that no longer exists.

Where Alex Began

Alex did not fix this in a quarter. He began, and the beginning is the point. He shortened the decision cadence instead of lengthening the roadmap. He pushed the definition of value up and to the left so choices stopped queuing on his calendar. He named an owner for the seam between strategy and delivery, the gap he had been filling himself, one doorway conversation at a time. And he started reading customer adoption, not team velocity, as the system’s true speedometer.

If this piece leaves you with three things, let them be these:

1. 1. The constraint moves. When delivery becomes fast and cheap, find its new address before optimizing anything else.

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

1. 1. Downstream, the customer sets the pace. Absorption, not capacity, is the final constraint, so build the cadence that senses it.

The quarter’s closing review told Alex what had changed. Nobody asked how much the team had shipped. They asked what customers had absorbed, what the measurements had killed, and what the organization now knew that it had not known ninety days earlier. The build engine was still fast. The difference was that the organization around it had finally started moving at the speed of its decisions, not the speed of its tools.

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

DORA, Accelerate State of DevOps Report, Google Cloud. Deployment frequency, lead time, change failure rate, and time to restore as the standard measures of delivery performance.

Goldratt, E. M., and Cox, J. The Goal: A Process of Ongoing Improvement. North River Press, 1984.

McKinsey & Company, “The AI Revolution in Software Development,” 2026.

Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Gartner, 2026 CIO and Technology Executive Survey.

Gartner, Workforce Change Survey (2016–2022), and change-fatigue research, 2024.

Howard, C., quoted in “Gartner Unveils Top Predictions for IT Organizations and Users in 2026 and Beyond,” Gartner, October 2025. (Direct quote source.)

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.

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

The adoption and leverage of AI capabilities are advancing quickly across most organizations. It is an exciting time, a cautious time, and a challenging time, all wrapped up in the same AI journey. But many are finding that scaling requires a step back first, an honest assessment of organizational readiness. Adoption, it turns out, depends on a few conditions being in place to achieve the outcomes leaders expect.

Our AI adoption across the company was “on track.” Pilots were running in four departments. Developers were shipping faster. Marketing had a chatbot live. By every visible measure, things looked good.

But that isn’t the full story. Ask the broader question, though, and it forces a pause: an honest accounting of where the organization actually stands. If the board asked tomorrow whether the AI initiatives were governed, auditable, and tied to a number anyone would recognize as ROI, could you prove it in 90 days? Most leaders pause for a long moment before answering honestly: no.

That pause is the story of most AI adoption. It is not a story about whether organizations are using AI. Nearly all of them are. It is a story about the widening gap between activity and readiness, between deploying a tool and being organizationally prepared to scale it responsibly. IBM’s own diagnosis of the moment is direct: AI capability is advancing faster than organizational capability.

That single sentence describes more failed AI initiatives than any technical postmortem ever will.

Readiness, in this sense, is the organizational capacity to answer four questions honestly, at any moment, for any AI initiative running inside the company.

• Who owns this?
• What data is it built on?
• What does it cost, and what is it returning?
• Who is measuring it to know if something has gone wrong?

Organizations that can answer those questions have built governance deliberately rather than drifted into it. Those that cannot are accumulating a different kind of debt, one that does not show up on a balance sheet until a board asks that same question.

When readiness is missing, the gap does not stay abstract. It shows up as seven concrete, recurring problems: governance and oversight that cannot keep pace with deployment, data infrastructure that was never built for AI, cost that outpaces the value it was meant to create, individual productivity gains that never compound into organizational ROI, a workforce that leadership assumes is ready when it is not, a talent bench built for the wrong skills, and pilots that never leave the lab. These are symptoms of the same underlying condition: organizational readiness that has not caught up to organizational ambition. 

Let’s unpack each of these, and what closing the gap requires.

When Readiness Is Missing: Seven Recurring Problems

Across recent industry research, the readiness gap shows up in the same seven places, regardless of sector or size.

Governance and oversight can’t keep pace. 

EY found that over half of department-level AI initiatives are running without formal approval, and 78 percent of technology leaders say adoption is outpacing their organization’s ability to manage the risk it creates (1).

Data was never built for AI. 

Teams routinely discover mid-project that the data they assumed they had is inaccessible, incomplete, or structured the wrong way. Gartner projects that 60 percent of AI projects will be abandoned through 2026 for exactly this reason (2).

Cost is outrunning visibility. 

Rising token and tool spend has overtaken security and quality as the top adoption concern among engineering leaders, cited by 42 percent as their primary obstacle (3).

Individual gains aren’t compounding. 

Ninety-seven percent of executives report their company has benefited from AI, yet only 29 percent see significant organizational ROI, a gap wide enough that 54 percent of C-suite leaders admit adoption is straining their organization (4).

Leadership overestimates workforce readiness. 

CIOs and CTOs are five times more likely than COOs to believe their workforce is ready to adopt AI, and training remains the most underfunded investment area even as it stays disconnected from the workflows people actually use (5).

The talent bench is built for the wrong skills. 

Organizations that spent the last two years hiring for prompt engineering now need people who can manage integration, security, and governance across live AI systems, a very different bench (6).

Pilots never leave the lab. 

Across more than 120,000 enterprises surveyed, only 8.6 percent report AI agents running in production. The rest remain in pilot or have no formal initiative at all (7).

Each of the seven is what the same underlying condition looks like once it surfaces in a different department’s metrics.

Closing the Gap: What Readiness Requires

If the seven problems share a root cause, the fixes share root disciplines as well. None of them start with a new tool.

Governance as an operating model. The organizations closing the oversight gap, and the ones finally moving pilots into production, are treating governance as an organization design question rather than a policy memo: which decisions can be safely encapsulated inside an agent’s own boundary, and which must be orchestrated by a person, a team, or a process sitting above it. Get that decision boundary right once, and both the oversight problem and the pilot-purgatory problem start to resolve together, because a system with a clearly drawn boundary is also one a board can audit.

Business process as bounded context. Data readiness is rarely a data problem first. It is usually a business process mapping problem wearing a data costume. Data is a byproduct of process. If a business process is fuzzy, ad hoc, or exists differently in five people’s heads, the data it throws off will be fuzzy too, not because anyone failed at data management, but because there was never a clean process generating clean data in the first place. Most of “our data isn’t AI-ready” complaints are actually “we never wrote down how this part of the business works” complaints. Fix the second thing, and the first thing tends to resolve on its own. McKinsey’s research bears this out directly: across 25 factors tested against companies’ financial returns from AI, workflow redesign, rebuilding how the process runs, has the single largest measured effect on whether an organization sees real bottom-line impact (8).

Redefining skill and competency alignment. The workforce and talent gaps both live in the same uncomfortable space, the gray area between the role someone was hired to do, and the role AI has quietly started to reshape. Training that only teaches a tool leaves that gray area undefined. Training that redesigns the role around it, and rebuilds the talent bench alongside it, is what closes both gaps at once.

Scaling with ROI intact. Much of the ROI translation gap comes from business and technology working as separate silos, each with its own view of what “valuable” means. The strongest AI strategies close that gap by aligning business and technology on a shared definition of value; that means giving the business team that will use an AI workflow real ownership over it, not just sign-off rights, while IT holds the oversight layer that keeps it governed. Aligned this way, ROI stops being something IT claims and business doubts, or business demands, and IT can’t deliver.

Budgetary guardrails. Full cost visibility takes time to build. Until it exists, usage caps, tiered access, and budget guardrails function as compensating controls, guarding against runaway spend while the underlying metering catches up. The point is to make sure enthusiasm and accountability travel together.

Conclusion

These seven problems trace back to a systems issue rather than a tool or the new capability itself: a lack of clarity around decisioning (governance) and bounded context (structure). From the outset, our point of view has been direct: a well-constructed governance and operating model is a readiness condition, not just for adopting AI, but for any new capability an organization adds to create value for its customers.

“A well-constructed governance and operating model is a readiness condition for any new capability that creates value.”

The scale of the gap is why this matters more now. Separate research from MIT found that 95 percent of enterprise AI pilots deliver no measurable bottom-line impact, and that only the small share reaching production create real value (9). That number belongs alongside the seven problems above, further evidence of the same underlying condition: organizations that have not yet built the capacity to know what to pursue, where to focus, how to deliver, and how to capture the value once it exists.

“95 percent of enterprise AI pilots deliver no measurable bottom-line impact”

In practice, closing that gap tends to take a consistent shape:

1. Value Aligned: A prioritized view of where the value lives
2. Governance & Structure: Ownership and decisions sitting with named roles and business owners rather than left implicit
3. Measure: A KPI framework that can defend the investment when the board asks, and a validated path that moves an idea from concept to proof before it is asked to scale.

Organizations that build that discipline once tend to reuse it. It’s how they evaluate any new capability meant to create value, whether or not AI is involved. Organizations that treat readiness this way, as an ongoing practice rather than a gate, are the ones building AI capability that holds up under scale.

LiminalArc CEO Mike Cottmeyer has described the alternative bluntly: most stalled AI programs are “a structure problem wearing AI clothes.” Fix the structure once, prove it in production, and the same pattern repeats faster with each cycle that follows.

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.

References

1. EY, “EY survey: autonomous AI adoption surges at tech companies as oversight falls behind,” 2026.

2. Gartner, 2025 Survey on Data Management Practices for AI, cited in Cygnet.One, “AI Adoption Challenges: Enterprise Guide 2026.”

3. Jellyfish, “State of Engineering Management,” 2026.

4. Habib, M. (WRITER), 2026 AI Adoption in the Enterprise survey, conducted with Workplace Intelligence.

5. Grant Thornton, 2026 AI Impact Survey.

6. IBM, “The Biggest AI Adoption Challenges for 2026.”

7. Recon Analytics survey (120,000+ enterprise respondents, March 2025-January 2026), cited in TechRepublic, “AI Adoption Trends in the Enterprise 2026.”

8. McKinsey & Company, “The State of AI: Global Survey,” 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

9. MIT NANDA, “The GenAI Divide: State of AI in Business,” 2025.

Organizations modernize legacy infrastructure for sound reasons: lower cost, better performance, elastic scale, stronger disaster recovery, and earlier ROI. Yet many find the move is not cost-effective, or that it obstructs the very transformation it was meant to enable. They finish the technical migration, but the savings never materialize, and they end up maintaining two environments instead of one.

The reason is rarely the cloud. Legacy systems cannot move cleanly because they are not encapsulated: their components are entangled through buses, APIs, connectors, and shared data into a dependency network no single team or vendor owns. The most dangerous dependencies live in the gray area between components, where each vendor’s piece works in isolation yet the integrated whole fails because nobody owns the path between them.

Migration fails when it is treated as a technology event rather than a change to how the business and its systems are structured.

The Impacts

Applied to an unencapsulated system landscape, migration produces predictable failures. Companies recreate the monolith in the cloud, lifting everything onto SaaS, customizing it region by region, and leaving processes and org design untouched, so the same tangle reassembles in a costlier place. And the data center will not die: a single missed gray-area dependency, a hardwired payment-processor or compliance connection that cannot be re-pointed, can force an organization to carry physical infrastructure for years.

The market is voting with its feet:

• 21% of workloads repatriated, often because applications were never refactored for the cloud (Flexera 2025) [1]
• 86% of CIOs planning to move some workloads back, the highest on record (Barclays, Q4 2024) [2]
• 85% of enterprises now say legacy systems block their AI adoption [4]. The same entanglement that strands a data center also strands the data and architecture modern AI depends on.

When the business case is funded by retiring the data center, one unowned dependency can erase the entire ROI.

Building on the November 2023 Conversation

This piece extends a November 2023 conversation in which LiminalArc’s Mike Cottmeyer and Dennis Stevens diagnosed the same problem: dependency is the obstacle, the gray area is where migrations fail, and organizations recreate the monolith when they move technology without changing the business. That diagnosis holds. What has changed since is the cure, not the problem. What was once invisible can now be made clearer with AI capabilities. Repatriation has moved from informal observation to measured trend, and AI has transformed the economics of the solution. What follows carries their thinking forward.

The Solution: Where to Draw the Boundary

If the problem is structural, the solution cannot be purely technical. It requires changing the operating model, not just the stack. What has always blocked that is cost and feasibility, which is exactly what AI now changes. But first, what makes a boundary real, and where does it belong?

The goal is to encapsulate: to give each component a boundary clean enough that it can change without breaking the others. What cannot yet be encapsulated has to be orchestrated by hand instead, and that orchestration is the cost the work sets out to reduce, not the aim.

Encapsulation is a property of the boundary, not of the technology that crosses it. A bus, an API, or an event stream can each either honor a real boundary or quietly violate one. What matters is whether a component can change behind its boundary without forcing changes on everything connected to it.

The question that matters is where a real boundary belongs, not which integration technology to use. Technology alone does not answer it; an API drawn in the wrong place leaks internals and orchestration just as a shared bus does, and the tangle returns with newer parts. The answer comes from the business. This is where domain-driven design earns its place: a bounded context is precisely that boundary, and the right place to draw it is around a sub-domain: a coherent slice of the business that changes for its own reasons, on its own cadence.

Encapsulate along sub-domain lines and the boundary holds, because the business itself has a seam there; encapsulate along arbitrary technical lines and the dependencies reassemble. The relationships between those contexts then become explicit and owned, closing the gray area no one previously held. The sub-domain is where business meaning and technical boundary coincide.

The AI Inflection

Agentic tools now map dependencies across hundreds of services and run impact analysis, surfacing the cross-system paths once found only at go-live. AI also documents poorly understood code and generates the test scaffolding the model depends on. Studies report 30–60% productivity gains on refactoring and 40–50% faster modernization timelines [3][5].

But AI amplifies whatever structure it is pointed at. Aim it at an unencapsulated monolith and it generates entangled, duplicated, insecure code faster, recreating the rat’s nest at machine speed. AI-generated code was insecure in roughly 45% of cases without explicit security instruction [3]. The gains appear only when AI runs inside a governed, small-batch, dependency-aware workflow.

The Real Outcome: A Changed Operating Model

Of the outcomes AI transformation is meant to deliver, better efficiency, new capabilities, and a changed operating model. It is the last that decides whether the first two endure. Realizing its value requires changing how the business operates: its processes, its decision rights, and above all its roles. A dependency graph that AI mapped in days is inert unless teams, funding, and accountability are restructured around the newly encapsulated capabilities. That means product owners accountable for outcomes rather than projects, and an explicit owner for the gray area that previously had none. Technology change without operating-model change recreates the old constraints.

The Change Model

Begin by stabilizing the system so its hidden dependencies become measurable, then decide deliberately where each decision belongs inside a team, one level up, or at the portfolio tier, pushing decisions up and to the left, early enough to inform budgets. Where a dependency cannot yet be broken, manage it with compensating controls: a deliberately heavier layer of governance and test scaffolding than the end state needs, run in small batches to keep delivery moving. These are scaffolding, not architecture. Like the framework around a building under restoration, they hold things together while the work proceeds and come down as each piece is encapsulated. Orchestration here is a means to an end: it is meant to fall away as boundaries become real, not harden into permanent overhead.

From there, sequence the move: inventory every dependency (AI-accelerated, human-verified); wrap complex, poorly understood logic in containers with disposable test scaffolding so it can move safely; lift and shift where pragmatic, then extract services one sub-domain at a time. Starting with the boundaries that most reduce cost or risk and retiring the surrounding orchestration as each becomes real; and plan for data gravity, treating migration as a series of moves rather than one event [6][7].

The Way Forward

Pulled together, the approach is one repeatable move, applied capability by capability, not as a single grand migration.

Stop migrating applications; start encapsulating capabilities. Modernize one sub-domain at a time, let AI make that affordable, and change the operating model and its roles in step — so cloud economics and AI-readiness are realized together, not traded against each other.

The LiminalArc Point of View

We believe most modernization fails for a single reason: it is owned in pieces. Vendors move the technology, consultants tune the process, and product teams chase features; the failures collect in the seams between them, in the gray area no one owns. Our conviction, formed over more than a decade of moving monolithic organizations toward composable ones, is that technology, organization, product, and business architecture are one system, and must change together. Incrementally, safely, and in small batches.

AI is the catalyst that finally makes this affordable. But a catalyst accelerates a reaction; it does not design one.

Pointed at an unchanged operating model, AI scales the mess. Paired with a disciplined change model, it is why we believe LiminalArc can move an organization to where it wants to be, realizing the cloud economics and the operating-model change together, without recreating the monolith it is trying to leave.

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.

References

[1] Flexera, 2025 State of the Cloud Report, via InfoWorld, “Cloud trends 2025: Repatriation and sustainability make their marks,” March 2025.

[2] Barclays CIO Survey, Q4 2024, as cited in CIO.com and industry coverage of cloud repatriation, 2025–2026.

[3] Altimi, “The AI-Powered Legacy Modernization Playbook,” March 2026 (citing GitHub, Google, GitClear, GitLab DevSecOps, Apiiro, and Gartner data).

[4] Entrans, “Legacy System Modernization Trends 2025–2026”; Gartner agentic-AI projections; Stack Overflow 2025 Developer Survey.

[5] Augment Code, “AI-Powered Legacy Code Refactoring: Implementation Guide,” updated February 2026.

[6] Dave McCrory, “Data Gravity – in the Clouds,” datagravitas.com, December 2010; definition corroborated by TechTarget.

[7] DataStackHub, “50 Cloud Migration Statistics for 2025–2026,” citing data gravity and cost as repatriation drivers.

Welcome, we have a new team member!

The first time I welcomed Arthur onto a team, I made the mistake of simply letting him take on the team’s existing tasks. I assumed onboarding meant transferring tasks. It took time before we fully understood that the team had not actually gained the full benefit of the unique skills and experience Arthur brought. We had only added a faster pair of hands for work we already knew how to do. The harder, more valuable conversation — about what each of us should now own — never happened until something fell through the gap between us. I think about Arthur now in light of introducing AI agents and AI skills into our teams, and why we need to think about the problem similarly. Organizations are about to make the same mistake at scale, with a new kind of team member that does not yet have a name on the org chart. Meet our new AI team member.

The instinct, when an AI arrives, is to hand it a task. That is reasonable, because it is how we onboard a tool. But it is not only a faster tool. It makes choices. And the moment something on your team makes choices, the question stops being “what can it do” and becomes “what is it allowed to decide, and who answers for the result.” That is not a tooling question. It is a question about the team’s working agreement, and most teams never reopen it.

That gap is worth naming before any agent is deployed. To see why it matters, it helps to be precise about what an AI transformation means.

What an AI Transformation Actually Is

The phrase collapses three different ambitions that demand different work and produce different returns:

• AI as leverage on existing work: copilots and agents that make current activities faster or cheaper.
• AI in the product: intelligence embedded in what customers buy or use.
• AI reshaping the operating model: changing how work flows, where decisions are made, and how the team is shaped.

The first is table stakes, the second is positioning, and the third is where durable advantage lives — and where most of the difficulty sits. The dominant failure mode is running the program as a tooling rollout (the first ambition) while quietly expecting the returns of the third. Those returns do not arrive, because the constraint was never tool access. It was the operating model wrapped around an older set of assumptions about who does what.

Bringing AI onto a team is where these three ambitions meet in a single, concrete decision. Treat it as leverage alone and you get a faster version of the team you already had. Treat it as an operating-model change and you have to reset roles. The rest of this piece is about that reset.

The AI as a Team Member

It helps to name what you are adding, because it arrives in more than one form. An assistant, or copilot, responds when a person asks — suggesting or drafting while the human stays in control. A skill is a specific capability the AI can perform, such as drafting a contract clause, writing a query, or running a test suite. An agent pursues a goal across several steps, choosing its own actions and calling on skills as it goes. These are not competing categories but points on a single line: how much authority comes with what you add. In practice two things enter the team at once — new capability and new autonomy in using it — and the more authority you hand over, the more the team’s roles have to change. For that reason this piece speaks of the AI member in the generic sense. The principle holds whichever form arrives, and whichever form arrives next.

Harvard Business Review offers the right starting point, drawn from the most autonomous case: scale AI by thinking of it as a team member, not as software you switch on everywhere at once [1]. The distinction matters. A team member is onboarded into a role with scoped authority, supervision, and a path for escalation. Software is simply deployed.

What does the role look like in practice? Engineering teams are converging on a clean division of labor, often summarized as delegate, review, and own. The AI handles first-pass execution: scaffolding, implementation, drafting automated tests and code; people review that output for correctness, standards, risk, and alignment; and ownership of architecture, trade-offs, and outcomes stays human. The engineer’s center of gravity shifts from producing the work to orchestrating and judging it — part of a broader move toward senior people who set standards and orchestrate work across teams, vendors, and agents [2]. The same shift reaches well beyond engineering. A Product Manager who once spent a lot of time evaluating customer feedback, defining strategy, and creating a roadmap now reviews and sharpens the priorities and outcomes an AI builds from customer signals — spending less time producing the artifact and more time deciding what is worth building and why. Which role changes, and how much, depends on which capability you introduce and how close it sits to that role’s daily work.

This is why introducing AI with real autonomy is an organizational design question, not a technical one. An agent holds decision rights. The instant you let it choose its own steps toward a goal, you have delegated authority, and delegation is the substance of how a team is organized.

Honest test: transformation is not whether the team moved faster — it is whether the composition of roles changed. If work sped up while everyone kept doing the same things, the team bought leverage, not transformation. The human value line has to move: people concentrate on judgment, taste, ambiguity, and relationships, while the AI absorbs high-volume synthesis and pattern work.

Resetting Roles Within the Team

Resetting roles is the work of rewriting the team’s working agreement. The instinct is to respond to a capable new member by defining everything: every task assigned, every interaction specified, every contingency written down. That instinct is the mistake — an agreement that tries to control everything is brittle. It is committed to today’s conditions and cannot absorb the next change. The real work is narrower and harder: deciding which parts of the agreement to make firm and which to leave deliberately adaptive.

Three moves make that practical:

1. Stabilize the boundary
2. Design the edges
3. Protect the whole

Each one, in turn.

Stabilize the boundary

Separate the frame from the contents. Make the frame explicit and controlled: who is accountable, what the AI may decide, where it must stop and escalate, and what counts as reviewed. These are stable and carry the real risk. Leave the contents adaptive — which tasks the AI takes on and how far it is trusted will shift as its capability grows, so fixing them in place only costs the team its ability to learn. This is encapsulation applied to a team: wrap the AI in a controlled interface of accountabilities, decision rights, and escalation gates so the inside can keep changing without destabilizing the people around it.

One practical move: split tasks into AI-only, human-plus-AI, and human-only to surface where authority sits [3]. Make the ownership it reveals firm, but treat the allocation itself as a living boundary — revisited as trust changes, not a contract signed once.

Design the edges

Spell out the edges before the AI acts: when it must stop and hand off, when it should interrupt for input, and when it should stay silent [4]. Where you cannot fully trust it, wrap it in compensating controls — a review gate, a verification step, a limit on what it can commit without a human — so escalation is part of the role rather than an afterthought. And name an owner for the gray area of accountability, the decision an AI makes at the edge of its authority, before the gap is found rather than after. To sort what to make firm from what to leave open, use one rule: reversibility and the cost of being wrong. Stabilize early where a wrong call is expensive and hard to undo; hold it loose where it is cheap to adjust and let feedback settle it. The same rule flags overreach: the moment a boundary replaces judgment with a rote checklist instead of freeing it, it has gone too far.

Protect the whole

Guard the entry-level work that builds your future experts. The over-commitment to avoid is letting the AI absorb foundational work and quietly stopping the development of the people who used to do it. Freeze junior roles because the AI now writes the boilerplate and you remove the rung on which senior engineers are made — an inverted pyramid that starves the future supply of the very people who must review and own what the AI produces. A Google DeepMind analysis of AI delegation makes the point in general terms: the routine tasks most likely to be handed to an agent are exactly the ones through which junior people build judgment, so automating them away erodes the apprenticeship pipeline [4]. Faster output today, no pipeline to the judgment roles tomorrow. It is the parts-versus-whole trap — fixing in place what needed to stay adaptive, and precisely the trap systems thinking exists to catch.

Conclusion

It is fair to argue the opposite — that an AI is not a coworker at all but an instrument, programmable, bounded, and dependent on human judgment [5]. Teammate or tool, the test of success is the same. You still measure it, just not only for speed or cost. It shows up in a morning that feels like nothing at all.

By the time the team gathered, Andrew, our AI teammate, had drafted overnight, so the questions on the table were the ones worth arguing about rather than the busywork of producing the draft. Maura, who came up from junior to senior, ran the review. The early roles we might have automated away are the ones that built the judgment she now brings. She spends her time directing Andrew’s work, catching what Andrew cannot, and bringing along whoever comes next.

No one in the room treated Andrew any differently. Andrew had a clear job, a clear owner, and a clear edge — and that was the point. We knew who was accountable, where Andrew had to stop and ask, and what only a person should decide. The measure of success was never that the team just moved faster. It was that the team had changed shape and normalized around its newest member, with every person moving up to work that needs human judgment, making the team whole. Arthur taught me the lesson years ago. Andrew, an AI, is the proof we finally learned it.

References

[1] Telang, R. and Hydari, M. Z. “To Scale AI Agents Successfully, Think of Them Like Team Members.” Harvard Business Review, March 2026.

[2] Soller, H., Stefanelli, M., Goel, R., and Husain, U. “Designing an End-to-End Technology Workforce for the AI-First Era.” McKinsey & Company, April 2026.

[3] “No More Pyramids: Rethinking Your Workforce for the Agentic AI Era.” PwC, 2026.

[4] Tomašev, N., Franklin, M., and Osindero, S. “Intelligent AI Delegation.” arXiv:2602.11865 [cs.AI], Google DeepMind, February 2026.

[5] “The Future of Work: AI Agents as Instruments, Not Co-Workers.” IDC, December 2025.

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.

In the last article, we made the case for the technical signals that tell you whether your teams are getting better at building software. Near the end, we admitted those signals have a limit. They tell you whether you’re building software well. They don’t tell you whether you’re building the right software.

This article is about that second question.

How do I know my teams are building the right thing?

It’s a harder question, and a more uncomfortable one. Deployment Frequency, Lead Time, Change Failure Rate, and Mean Time to Restore measure your delivery engine. A strong DORA score means that engine is fast and reliable. It doesn’t mean the engine is pointed at the right target.

That’s the trap. A fast delivery engine aimed at the wrong thing doesn’t save you. It just means you build the wrong thing faster, and at greater cost. And with AI making teams quicker still, that risk is getting bigger, not smaller.

The real question isn’t whether you can know the right thing up front. You usually can’t. The real question is whether your team can find out, fast and cheap, before you’ve over-invested in the wrong one. That question, technical metrics answer well.

The Right Thing Is Discovered

Most of the time, nobody knows the right thing up front.

A well-known Standish Group study found that 45% of features in shipped software are never used at all, and another 19% are used only rarely. Most of what teams build doesn’t earn its keep. And it isn’t because the teams were careless. It’s because the right thing is genuinely hard to know in advance.

The right thing is discovered, not specified. You build a version, put it in front of real users, watch what happens, and adjust. Then you do it again. The teams that build the right thing aren’t the ones with the best up-front plan. They’re the ones with the fastest, cheapest way to find out they were wrong.

So “are we building the right thing?” is almost the wrong question to ask your teams. They can’t answer it with certainty, and neither can you. The better question is this: how quickly would we find out if we weren’t? That question has a measurable answer.

What Uninformed Progress Looks Like

When a team has no real learning loop, progress looks great.

Teams mark features done. The roadmap moves. The status reports are green. From a leader’s seat, it looks like a team executing well.

We call this uninformed progress. The team is moving, but nobody actually knows if they’re moving toward something customers want. They’re building on an assumption made months ago, and they won’t test it until the big release. By the time the truth arrives, the wrong thing is already built.

This is especially dangerous in a rewrite or a rebuild. A rebuild feels safe because the destination seems known. You’re just rebuilding what already exists. But a rebuild is actually a rare chance to ask a question almost nobody asks: is this ten-year-old feature still needed at all? Teams that skip that question carry a decade of unexamined assumptions straight into the new system.

Uninformed progress is exactly what the next four metrics are designed to expose.

Four Metrics for How Fast You Learn

Here are four metrics we watch to tell whether a team can actually find out it’s wrong. Two measure how fast the learning loop turns. Two measure what the loop reveals.

How fast the loop turns

Batch Size

This is how much scope a team builds before a real user can react to it. A small batch is a thin slice of a feature. A large batch is optimism hiding uncertainty. The larger the batch, the bigger the assumption. Ship small, and you find out you took a wrong turn in a week. Ship big, and you find out after a quarter, or after a two-year rebuild. Batch Size and DORA’s Deployment Frequency move together: if you deploy often, you can ship small; if you deploy rarely, every release carries more risk and more assumption. The leader’s question: are we learning in small bets, or betting big on confidence?

Time to Feedback

This is how long it takes from starting a piece of work to learning something from a real user. It builds directly on DORA. Lead Time for Changes measures how long from code committed to code in production. Time to Feedback picks up where Lead Time ends and keeps the clock running until reality has a chance to respond. Teams that learn fastest aren’t necessarily smarter. They just let reality into the room sooner. The leader’s question: how long can we stay wrong before we notice?

What the loop reveals

Feature Usage

This is the share of what you’ve shipped that people actually use, measured from instrumentation in the product, not from opinion in a meeting. It’s one of the most direct measures of whether you’re building the right thing. A feature that ships and gets no traffic is often the wrong thing, made visible. Those Standish numbers stop being abstract statistics and become a list of specific features you can name. Use is proof of value, not shipping. The leader’s question: do we care enough to check whether anyone actually uses what we built?

Rework Rate

This is how much recently shipped work gets redone soon after it ships. In the last article, churn was a code-health signal. Here it’s the same measurement read through a different question. When teams rework fresh code heavily right after release, that’s rarely a coding problem. It usually means the team didn’t understand the problem before they built. Some rework means the team is listening. Endless rework means they’re guessing. The leader’s question: are we refining what we shipped, or rebuilding it?

A Real Example

A few years ago we had a team that rebuilt a mobile point-of-sale app for a payments company.

The old app was more than ten years old. It was iOS only, which forced the company’s customers to buy expensive Apple hardware when cheaper Android devices were right there. It had no automated tests and a tangled, complicated codebase. Customers were leaving for competitors.

The company’s own estimate to rebuild it was two years. Two years before a single customer would see anything new. Two years of watching customers leave. And there was strong pressure to make the rebuild a perfect copy. Many people insisted the new app had to match the old one feature for feature before anyone could use it.

We didn’t do that. Instead, we built the simplest complete point-of-sale we could think of, for the simplest possible customer: a cash-only donut shop. That first release was ready in about four months, not two years. Then a taco truck, a slightly more complex quick-serve case. Then up the ladder, one customer type at a time, toward a full sit-down restaurant.

Each step was small enough to put in front of a real business. An actual restaurant ran each new version for a week and handed back what worked, what broke, and which options they missed. That is Batch Size and Time to Feedback working together.

The old app carried more than 700 configuration options, built up over a decade. The instinct was to rebuild every one of them. But because real customers were using the new app at every stage, we could see which options actually got used. Between 200 and 300 of those 700 turned out not to matter enough to build before the final release. We didn’t argue about them in a conference room. The usage data settled it.

None of this would have worked without a fast, reliable delivery engine underneath. The team integrated their work dozens of times a day and could release on demand. The new code was simple and carried close to 5,000 automated tests that ran hundreds of times a day. So when feedback said change course, changing course was cheap. It was an adjustment, not a rewrite.

The rebuild shipped about 25% faster than the company’s own two-year estimate, and across more than 1,000 features built, real customers hit only about 20 minor defects. But the thing we think about most isn’t a number. The staged approach bought us a conversation with the client. Every release, we sat down together and asked what the next kind of restaurant actually needed. We weren’t guessing in a room. We were deciding with evidence.

Why This Matters Even More with AI

In the last article, we argued that AI amplifies the engineering system you already have.

AI is collapsing the cost of building. A team with good AI tooling can produce a working feature far faster than it could two years ago. That sounds like pure good news. It isn’t.

When building gets cheap, building the wrong thing gets cheap too. The constraint moves. It used to be that building was the hard part. Now the hard part is knowing what is worth building at all. AI makes the learning loop the whole game. If your team can generate features faster than it can find out whether anyone wants them, you don’t have a productivity win. You have a faster way to fill your product with dead weight.

A Practical Next Step

You don’t need to interrogate your teams about whether they’re building the right thing. They can’t prove it, and pressing them will only produce confident guesses.

Ask the loop questions instead. At your next review, ask how big the last few releases were, and how long it took before a real user touched them. Ask which shipped features have the usage to prove they were worth building, and which ones nobody can vouch for. Ask whether recent work is being refined or rebuilt.

If your team can’t answer those questions, that is the finding. It means the learning loop isn’t instrumented, and uninformed progress is the most likely thing happening right now.

One caution. These metrics measure whether your team can learn fast. They don’t make anyone act on what’s learned. A fast loop feeding a roadmap nobody is willing to change is just a quicker way to be ignored. The metrics are the easy part. Listening is the leadership part.

Because building the right thing was never about getting the plan right up front. It’s about how quickly you’re willing to find out you were wrong, and how cheaply you can do something about it.

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

Two earlier pieces in this series made connected arguments. The first, Product Ops is Necessary but Insufficient on Its Own, argued that improving delivery execution rarely fixes a value realization problem on its own, because the real constraint is usually upstream: in the operating model, and specifically in how the business allocates capital and accountability. The second, Decision Friction is a System Design Problem, argued that even the right operating model will seize without governance: the deliberately designed system of decision rights, evidence flows, and shared visibility that connects strategy to execution.

Both are necessary. Neither, on its own, is sufficient. There is a third layer that neither piece addresses. It sits above the delivery system, above the governance, above the operating model itself. This piece is about that layer.

One note on timing. If your delivery system is still unpredictable, slow, or structurally unreliable, fixing it is the right priority, and the arguments in the earlier pieces apply directly. This piece is for a different inflection point: organizations where delivery is working, governance has tightened, and value realization still isn’t moving in proportion to the investment made in transformation.

The Diagnostic Gap

At some point in this version of the problem, a difficult conversation happens that nobody quite knows how to have.

Your transformation has taken hold. Teams are shipping consistently. The operating model has been redesigned around stable product teams with clearer ownership. Governance is more deliberate. By most available measures, the hard work is done.

Value realization still isn’t moving.

The temptation is to return to the delivery system: tune the cadence, clarify decision rights, improve feedback loops. This is the wrong diagnosis. The constraint isn’t inside any of those systems. It sits upstream of all of them, in a question the transformation was never designed to answer: which capabilities should this business be building, and why?

That question is harder than it sounds, particularly in large enterprises. Many operate in B2B markets or at one remove from the end customer, where products have been in maintenance for years. Capability investment has long been driven by feature requests, client commitments, or internal efficiency agendas rather than systematic inquiry into where the market is actually moving. In many of these organizations, researchers, designers, and product managers believe it is their job to answer this question. Their work is not integrated into the investment decisions the business is actually making. Customer evidence sits in product teams. Capability priorities are set at the portfolio level. And the two rarely meet in a way that materially changes where capital flows.

This is a structural condition, not a capability gap. Designing the integration is the fix. Hiring better researchers or running more discovery sprints won’t close it.

What the Delivery System Presupposes

Teresa Torres makes an argument I find compelling: that Discovery and Delivery are co-equal disciplines. Delivery asks whether we can build something and sustain it. Discovery asks whether we should, and whether it will create value.

Enterprise transformation has, rightly, invested heavily in Delivery. Not from ignorance of this duality, but from necessity. The delivery system in most large organizations is genuinely broken: unpredictable, expensive, and slow to surface what isn’t working. The predictability gains from fixing it are real, and the operating model changes that enable reliable delivery are worth making on their own terms.

But the systemic implication of Torres’s framing is that organizations haven’t yet accounted for the other side of that duality with anything close to the same rigor. Organizations have invested in building the thing right without matching that investment in building the right thing. That asymmetry isn’t incidental. It’s the structural condition that produces the value realization gap.

And the consequences become visible in competitive markets. Smaller companies and startups, unburdened by the delivery complexity that large organizations have spent years trying to solve, are often closer to the market precisely because they can’t afford not to be. They don’t have the luxury of a capability brief that was written two years ago and never revisited. They build, observe, and adjust, and in doing so they compound capability advantage in the segments where the large enterprise has stopped looking closely. By the time the enterprise notices the gap, the startup has the differentiation and the customer relationship. The delivery system the enterprise spent years perfecting executes at scale in a direction the market has already moved on from.

The Integration Layer

The gap between customer evidence and capability design doesn’t close itself. Closing it requires specific work. In a well-designed organization, that work sits with the Portfolio layer.

Portfolio teams are positioned to do something neither product teams nor executives can do in isolation: integrate the market signal with the strategic frame. Product teams are closest to the customer evidence. Executives own the investment thesis. Portfolio is the interface between them. It translates what the market is telling the business into the capability priorities the business should be betting on, and directs those priorities back into the delivery system as an explicit brief. This is precisely the kind of evidence-informed, hypothesis-driven prioritization that the prior pieces argued governance should enable. The operating model creates the structure for it. Governance creates the forum. The integration layer is the evidence that makes the decision real rather than assumed.

But this work requires more than positional access. It requires craft.

Discovery, done with rigor, is not a matter of collecting customer requirements or documenting feature requests. It’s a discipline of investigation: understanding the pain points and gain creators that matter to customers at root cause, not just the surface-level asks that get escalated. A customer who asks for a faster report is often telling you something about a decision they need to make more quickly, or a process they are trying to stop managing manually. The surface request isn’t the problem. The underlying need, and whether solving it creates something the customer cannot easily find elsewhere, is what makes the evidence strategically useful.

That distinction matters because it connects directly to the investment question. Discovery evidence only becomes valuable to the business when it is filtered through a commercial lens: not “would customers value this?” but “would solving this create monetary value: through differentiation, retention, or the ability to serve a segment the business is currently locked out of?” Customer benefit and business value are not the same thing. Conflating them leads to products that are genuinely useful but commercially irrelevant, and to capability investments that are hard to justify when the business case is examined.

This is where human-centered design practice, user research, and product management discovery converge on the same function: producing the evidence that grounds Portfolio-level investment decisions.

What Good Discovery Signals Look Like

You don’t need certainty to change direction. But you do need evidence that points clearly enough to justify the investment. Four signals that do:

Five different customers. The same root problem.

One complaint is noise. The same underlying issue surfacing across five separate segments, in different forms, from different people, is a pattern worth acting on. It usually means the market has moved in a direction you haven’t designed for yet.

They say one thing. They do something else.

When customers build workarounds, use a competitor for one function and you for another, or quietly abandon features: that’s your real discovery data. Behavior tells you what surveys and roadmap requests don’t. Trust the workaround over the stated preference.

“Good enough” has become their dealbreaker.

Some capabilities have quietly become the price of entry in a segment you already serve. Being behind on those is a retention risk, not just a product problem. The urgency is different, and so is the investment case.

A smaller competitor is growing in a space you’ve ignored.

This is usually the last signal to arrive, because it requires looking outward. A startup winning in your market with something you don’t offer has found a customer need you deprioritized. That gap has a commercial price tag, and it compounds while you’re looking inward.

The weight each signal carries will vary by market maturity and where your organization is in its transformation. All four are worth scanning for regularly, not just when value realization is already in question.

The test across all four is the same: if you addressed this, would it create monetary value for the business, not just a better experience for the customer? Customer benefit matters. But it doesn’t make the business case on its own. Discovery done well produces both.

When the Signals Point Somewhere the Business Doesn’t Want to Go

The four signals above assume discovery is pointing you toward better investment within your current direction. Sometimes it doesn’t. Sometimes the evidence points somewhere the business isn’t organized to go: a market your existing customers don’t represent, a capability set your current products don’t support, a direction that requires cannibalizing what you’ve built rather than extending it.

Consider a business that built a platform to serve an entire market, including competitors of its own core business. The platform generates real revenue. The customer relationships are established. But the discovery evidence is increasingly clear: the highest-margin, highest-growth application of the same capability is not the external market. It’s the parent business itself, which has been systematically under-served because the platform was designed for neutrality rather than for the use case where it would create most value. Exiting or deprioritizing the external customer base isn’t a complicated technical decision. It’s an organizational one: abandoning certain revenue in pursuit of a higher-margin direction, and acknowledging that years of serving the broader market were quietly constraining the business’s most valuable capability.

This pattern repeats in different forms across industries. A financial institution that offers its payments infrastructure to competitors because the external revenue looked attractive, while its own products run on a slower, less capable version of the same thing. A media business that has optimized its technology platform for third-party publishers, at the cost of the features its own editorial teams most need. In each case, the discovery signal isn’t ambiguous. The margin profile, the growth trajectory, and the strategic coherence all point in the same direction. What makes it hard is not the evidence. The system was designed around the customers it currently has: the existing contracts, the account relationships, the revenue forecasts it has built around them.

This is structurally uncomfortable in ways that have nothing to do with the quality of the discovery. Large enterprises are, by design, optimized for the customers they already have. The investment thesis, the governance, the sales motion: all of it runs toward the customers who are already paying. Discovery that challenges that direction isn’t just inconvenient. It’s hard to act on, because the system wasn’t designed to fund investment against its own base.

This is also, frequently, how disruption takes hold. Not because the enterprise missed the signal; often they didn’t. It’s because the signal contradicted what the business had organized itself to do. The startup found the gap precisely because they weren’t carrying the weight of an existing customer base that needed to be protected.

The honest implication of taking discovery seriously at the enterprise level is that the evidence will, periodically, point not to a gap within the current model but to a question about the model itself. Whether the existing customer base is the right one to optimize for. Whether the margin on that base justifies the opportunity cost of not pivoting. Whether the capabilities being invested in are becoming commodities while a higher-value direction goes unexplored.

Discovery is working exactly as it should. The harder question is whether your organization, with its governance, its investment logic, and its appetite for cannibalization, is designed to act on it.

The organizations in this position, with delivery working and value realization lagging, are not failing at execution. They are succeeding at the wrong thing.

The diagnostic question for your organization is not how to make the delivery system more effective. It is: what is the delivery system actually delivering toward? And who, in your organization, is formally responsible for ensuring that answer is grounded in evidence rather than assumption?

If you cannot name that clearly, not as a function but as a practice with methodology, rigor, and a deliberate integration point into the capability decisions the delivery system executes, the delivery system is a precision instrument pointed at a target that someone chose without enough information.

The discipline that closes that gap isn’t new. It is the oldest idea in product development. What is new is the recognition that it belongs not just inside product teams, but inside the investment logic of the enterprise: the upstream input that makes every downstream decision better.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.