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.

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

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

Video Transcript

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

Gotcha, gotcha, gotcha.

Melissa Roberts

So those are some—

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

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

Stacy Gordon

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

Melissa Roberts

How do you make it real?

Stacy Gordon

Yeah.

Melissa Roberts

So that’s part two of my article.

Stacy Gordon

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

Melissa Roberts

Well, besides reaching out to you, Stacy?

Stacy Gordon

Well, yes, please call me. Yeah.

Melissa Roberts

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

Stacy Gordon

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

 

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

Widespread deployment of Artificial Intelligence is forcing companies to scrutinize their cost structures in new ways. News reports of companies laying off thousands of workers due to the impact of AI are increasingly common, such as Megan Cerullo’s CBS News report last month. To her credit, she questions whether layoffs are a “harvesting of value” produced by AI or caused by some other factor.  Ben Cagle, Managing Partner at Cagle Partners, is blunter in his assessment, “The narrative? AI productivity. The reality? AI capital expenditure.” [2]

The truth is that companies are struggling to squeeze investments in AI into their already constrained operating expense budgets.  Who loses that struggle? The workers whose jobs are eliminated to make room for increased operating expenses generated by “pay per use” generative AI tools such as ChatGPT or Claude.

A Common Pitfall: Cost Myopia

The approach of making space for generative AI expenses by large percentage reductions in labor spending is a common, but serious error due to its focus on cost rather than value. It is too easy for an organization’s finance team to solve a cost overrun by mandating a reduction in labor costs. Once these reductions are baked into a budget, they become non-negotiable as Operators in the business are held accountable to achieve the cost numbers articulated in the budget.

A Better Way: Value Engineering

Value Engineering, the analysis of a good or service in terms of the cost of its subcomponents and the relative value they contribute to a finished good, is a concept that has its roots in purchasing and materials management. I was introduced to this style of analysis back in the 1990s via a purchasing management class based on the book, Purchasing and Materials Management – Text and Cases, by Dobler, Burt and Lee, Jr.

The approach has value beyond purchasing and materials management. We can apply the fundamental idea to any business in two specific areas: growing a business by improving its ability to attract more customers or improving the efficiency with which customers receive products or services.

We begin with a simple definition of value: the benefits generated by a product or capability minus its costs.  A key characteristic of this definition is that the benefits must be monetized so costs can be subtracted from them. The definition is important because it forces us to wrestle with ways to monetize things that many leaders consider to be “intangible,” such as functional value, aesthetic value, or environmental value. [3]

What can be “Value Engineered?”

From its inception at General Electric in the 1940s to keep products affordable without sacrificing quality during World War II, value engineering has been most frequently associated with products: finished goods that are sold to external customers. [4] However, the technique can be applied to other elements of a business and at various levels of abstraction, including:

• Value Streams
• Business capabilities and their subcomponents:
  • Roles / People
  • Business processes
  • Assets (both physical and technology [including data])
• Organizations/business units

One of the benefits of evaluating a set of items (e.g. business capabilities, business processes or assets) is that it enables the organization to understand the relative value being created by various elements in its business.

Sometimes this type of assessment unlocks “surprises” that are hidden in the financial and usage data. I once led a value engineering analysis of a suite of e-commerce applications for a large technology firm. We discovered a pattern that the centralized infrastructure function routinely purchased 3x the hardware needed to run an application. Our average utilization was 12%, and workload rarely exceeded 25% of capacity.

Purchase of unnecessary capacity inflated costs allocated to other business units in multiple ways because the centralized infrastructure department allocated cost to business units by number of servers deployed to a business unit. Once discovered, our value engineering team was able to immediately save scores of millions of dollars in annual infrastructure costs by shutting down the unnecessary servers.

Value Engineering in Eight (Not So) Easy Steps

At the highest level of abstraction, value engineering is a combination of eight steps.  The first two are challenging because they set the guardrails for the remaining work.  The last one is challenging because it forces the organization to convert the benefits generated into cash that can be used to fund subsequent improvements.

1. Identify the unit of analysis,
2. Quantify how the unit of analysis generates benefits,
3. Identify subcomponents,
4. Calculate one time and ongoing costs for subcomponents,
5. Find improvement opportunities,
6. Break opportunities into discrete units of value,
7. Prioritize and begin working the list, and
8. Monetize the results.

Identify the Unit of Analysis

 Identify the “thing” to be analyzed: value stream, business capability, process, or set of assets. Effort to conduct the analysis is largely correlated to the number of things being analyzed.  For example, a mid-sized to large organization typically has 8 – 15 “level one” capabilities, the highest-level abstraction in a business capability map. Each capability has multiple business processes, roles and supporting assets. To prevent scope from quickly expanding to an unreasonable amount, it’s often useful to select a unit of analysis based on the degree to which it is underperforming, either financially or against its planned cycle time and quality service levels.

Quantify Benefits

Quantifying the benefits a unit of analysis generates is often the most challenging step in the process, particularly for items classified as “strategic and governance” capabilities.  Generation of value must be quantifiable and convertible to cash. Value must also be generated as the unit of analysis operates its business processes or work is processed by an asset.

The measurable benefits are going to serve an important role in the rest of the analysis, not only for benchmarking current performance, but also placing an upper limit on investments in improvements. For example, an organization would not spend $5 million improving something that only generates $100,000 a year in value.

Identify Subcomponents

Having identified a unit of analysis and its source(s) of benefits, the next step is to identify its subcomponents. For a value stream, its subcomponents are the value stream stages. For a business capability, its subcomponents can be either a more granular business capability, or the combination of the people (roles), business processes, and assets that instantiate the capability. For an asset, its subcomponents are the labor and non-labor elements needed to operate and sustain the asset.

Calculate Subcomponent Costs

Calculate the one time and ongoing costs for each subcomponent, taking care to ensure that the sum of the costs is a valid representation of the value stream, process or capability. One way to do this is to count the frequency with which a process is executed and then calculate the cost per execution. Once the cost per execution is known, then it can be extrapolated based on the daily, weekly, or monthly frequency with which the component is utilized.

Find Improvement Opportunities

Having determined the costs and sources of benefits for the subcomponents of our unit of analysis, we can identify outliers (high cost + low benefits, or where benefits – costs is smaller than the organization’s expected values). Identify potential improvements, structuring them as discrete changes that generate measurable value and can be implemented in less than 90 days.

Define how success will be measured, as well as the mechanism(s) that will be used to monetize the improvements. Develop a high-level cost estimate and expected improvement quantified in cash for each item.  Sometimes this means adding an incremental sales goal to a sales plan when the benefit is an increased conversion rate, and at other times it may mean booking headcount reductions to monetize improvements in efficiency.

Prioritize the Opportunity List and Implement Improvements

Use a technique such as weighted shortest job first to prioritize the opportunity list. The idea here is to solve problems in small chunks and quickly generate value so that subsequent improvements are funded by the value of the improvements we have already deployed to customers and end users.

Monetize the Results

As improvements are delivered to customers and end users, review the success measures relative to their planned values, and act on the results. Aside from establishing the unit of analysis and determining sources of benefits, this is the toughest step. Many companies plan to generate benefits from improvement initiatives, but they fail to convert improvements in productivity to cash, with the unintended consequence of increasing overall operating expenses rather than decreasing them.  For example, customer experience improvements can be monetized in one or more of the following ways:

• Increases in a conversion funnel times an average order value,
• Increased purchase frequency per unit of time,
• Increases in the number of product categories purchased per unit of time,

A/B and Multivariate testing are important tools organizations can use to test actual customer response to changes in capabilities or processes. Successful tests increase an organization’s confidence that the planned improvements are perceived as such by customers and end users.

Case Study: A Focus on Facts Leads to Wise Investments

One of the key benefits of the value engineering technique is that through the assembly of relevant facts, a leadership team makes decisions based on empirical evidence rather than gut feel or personal persuasiveness. For example, I once participated in a decision about whether to spend $20 million in capital to upgrade an e-commerce capability because the line of business owner asserted a system replacement was needed to achieve a 30% sales growth rate.

Another executive didn’t want to spend the capital on e-commerce and pushed back against the proposal. Both executives were looking for facts to support their intuition. A team was assembled to value engineer the e-commerce capability, including its ability to handle a 30% compound annual growth rate in sales over three years.

The team discovered that while the e-commerce software could support 30% annual growth, the customer service center would need to hire 60 additional people to handle the resulting backorders. Instead of spending $20 million on a systems replacement, the organization redirected funds to fix supply chain backorders, generating $2.5 million in annual productivity gains.

Common Objections

Value Engineering of things beyond finished goods has a lot to recommend it. Why do so few companies use it as a tool to accelerate profitable growth?

Objection 1: We don’t have time/data/skills, etc.

It’s true that organizations rarely have idle capacity to analyze the effectiveness and efficiency of their value streams and capabilities. It usually takes pain in the form of serious underperformance in a business area to justify an investment in value engineering. Scoping this form of analysis to one to three underperforming areas will give an organization some quick wins as well as developing experience with the approach.

Objection 2: Value Engineering is old-school Manufacturing – doesn’t apply to SaaS / Digital

Ironically, changes in corporate cost structures have been significantly impacted by technological advancements over the past 30 years, including cloud computing, subscription-based Software as a Service, and now pay-per-use operating expenses associated with the use of Generative AI tools.

Many of these expenses are either out of direct control of the end user departments to which the expenses are allocated, or only indirectly controlled. Therefore, knowledge of the details of sources of costs, as well as the entities who actually control the costs, are increasingly important for line of business executives to maintain predictability in their P&L statements.  As “old-school” as value engineering may be, it is a straightforward way to isolate sources of benefits and cost, and clarify who directly controls the costs.

Objection 3: This is too academic for our organization to adopt

The ability to scale the technique up or down as needed allows teams to value engineer their own areas before making a larger push for department or organization-wide. Value engineering is a much easier sell when a leader presents it to colleagues in a package that includes actual results generated within the organization’s specific context. If it can be proven to improve results, the degree to which the technique is rooted in academia is irrelevant.

Conclusions

Value Engineering is an important technique for leaders to dust off and add to their toolkits to generate profitable growth in companies of all sizes. Its focus on value versus cost, combined with simplicity of implementation, enable it to be implemented at a small enough scale to produce results quickly. Value Engineering is also sufficiently scalable to generate scores of millions in annual value.

Start small this quarter: Pick one underperforming capability or process, assemble a small cross-functional team, and run a focused Value Engineering workshop. The data-driven insights you uncover will quickly pay for the effort – and may fundamentally change how your organization approaches AI-related cost pressures.

References

[1] Cerullo, Megan –  AI Emerges as Top Cause of Layoffs, Accounting for 26% of April’s Job Cuts, CBS News website, retrieved May 17, 2026.

[2] Cagle, Ben – Search for AI ROI. Focus on the Business Impact, LinkedIn article, retrieved May 17, 2026.

[3] Rahman, M. Abdur – A Comprehensive Guide to Value Analysis and Value Engineering, Kindle Edition, self-published, 2025, p. 45.

[4] Ibid., p. 46.

Are our teams actually getting better?

It’s a simple question, and not enough technology leaders are asking it. Some assume the answer is yes. Others are too buried in day-to-day delivery to step back and check. But every leader should be asking it, and that’s more true today than it was even a few years ago.

Teams are moving faster than ever, and AI is a big reason why. AI tools can help a team produce working code at a pace that would have seemed unrealistic not long ago. That speed is an opportunity. It’s also a risk. If you’re not watching whether your teams are genuinely improving, AI just helps you move faster in whatever direction you’re already headed. Including the wrong one.

So it’s worth asking honestly. Are your teams shipping value faster, creating fewer defects, and keeping the system easy to change? Or are they slowly turning it into something nobody wants to touch?

Most of us reach for DORA metrics to answer that, and that’s the right instinct. Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore are some of the best indicators we have for how well a software organization delivers.

But DORA has a blind spot. It tells you what’s happening. It doesn’t tell you why. And if you can’t see the why, it’s easy to spend real time and money fixing the wrong thing.

DORA Shows the Symptoms, Not the Cause

Picture three teams, each with a high Change Failure Rate. All three keep shipping changes that cause incidents or defects in production. On the surface, they look like they have the same problem.

They don’t.

One team might have almost no automated testing, so nothing catches a mistake before customers do. Another might have copied the same logic across dozens of files, so every change risks breaking something far away. A third might be bundling weeks of work into one big release, so when something fails, nobody can tell which change caused it.

Same symptom. Three completely different cures.

This is where a lot of organizations get stuck. They can see something is wrong, but they don’t have the signals to tell them what’s actually holding the system back. It’s worth borrowing one idea from the Theory of Constraints here: in any system, only one or two things are the real bottleneck, and effort spent improving anything else is mostly wasted. Finding the true constraint is the whole game.

Five Signals, and the Questions They Let You Ask

When I want to understand what’s really going on inside a delivery system, I look at five signals. They fall into three groups, and each group answers a different kind of question.

Delivery Signals

These tell you whether value is reaching customers, and whether it’s getting there safely.

When leaders tell me delivery feels slow, one of the first things I ask is: are teams finishing work, or just starting more of it? It comes back to a simple principle: start finishing, stop starting. Deployment Frequency is often less about speed and more about flow. The question for you as a leader: are we shipping in a steady rhythm, or is everything perpetually “almost done”?

Change Failure Rate tells me how safely teams are moving. One of my favorite sayings is “be quick, but don’t hurry.” The best teams move fast, but they stay in control while they do it. The question for you: when we move fast, do we stay in control?

Code-Health Signals

These are the signals DORA doesn’t give you, and they’re usually where the why lives.

When engineers start saying, “I’m afraid to touch that file,” cognitive complexity has usually already won. When cognitive complexity climbs, teams are usually patching around problems instead of simplifying the design. The question for you: is the system getting easier or harder to change?

Churn and Hotspots show you which parts of the system change the most. Churn is how often a file gets edited. A hotspot is a file that’s both changed often and complex. Sometimes a hotspot is the beating heart of the business. Sometimes it’s just a constant source of pain. Either way, it tells you where engineering attention will pay off most. The question for you: where is our risk concentrated?

Flow Signal

This one tells you how work actually moves.

Average Commits to Main per Day tells me whether teams are integrating work in small, safe steps. Higher commit frequency usually points to trunk-based development, which means small, frequent merges instead of long-lived branches. That gives you faster feedback and lower release risk. The question for you: are we working in small steps, or big risky ones?

Back to Our Three Teams

Here’s the payoff. These five signals do something DORA on its own couldn’t. They tell our three teams apart.

The team with no automated testing shows up in Change Failure Rate, paired with near-zero test coverage. The team with duplicated logic shows up in rising Cognitive Complexity and a cluster of hotspots. The team bundling big releases shows up in a low Commits to Main number.

Three teams, one shared symptom, three completely different stories. And now you can make three well-aimed investments instead of one expensive guess.

Signals, Not Targets

One of the biggest mistakes I see leaders make is turning a metric into a goal.

The moment a metric becomes a target, teams start optimizing the number instead of the behavior behind it. You get gaming, heavier process, and a lot of noise. People spend more time explaining the metric than improving the system. In the worst cases, you create an unsustainable pace where engineers are rewarded for chasing numbers instead of building good software.

Metrics should help you ask better questions. They should create understanding. They shouldn’t become a scoreboard.

A Real Example

I recently worked with a team supporting a legacy application that was three to five years old. When we started, it had no automated tests at all. Code coverage was effectively 0%.

Change Failure Rate was high, and so was Mean Time to Restore. Every production issue was stressful because nobody had much confidence that a fix wouldn’t make things worse.

Over time, the team adopted automated testing, trunk-based development, and feature flags. Coverage went from 0% to about 15%. That’s not a high number, but it was the first real safety net the team had ever had. Commits to main went up as work started moving in smaller, safer steps.

The results were significant. Defects dropped 63% quarter over quarter. Mean Time to Restore fell from days to hours, because the team could finally deploy a fix whenever they needed to. That meant customers spent hours, not days, living with a problem.

The DORA numbers improved too. But not because anyone was chasing them. They improved because the engineering system improved.

Why This Matters Even More with AI

AI coding tools can be incredibly effective. They can also produce insecure code, duplicate logic, and changes that are hard to understand and maintain. And they can do all of that faster than any human team ever could.

That’s exactly why these signals matter more in an AI-enabled organization, not less. They’re how you see the side effects. AI-generated code tends to push up Cognitive Complexity, create new hotspots, and raise Change Failure Rate when it ships without strong review and tests. Those three signals become your early-warning system.

Watch them, and AI accelerates good delivery. Ignore them, and AI just helps you create bad software faster.

Here’s the one idea I hope you remember: AI amplifies the engineering system you already have. If your teams work in small increments, keep the code clean, and have meaningful tests, AI speeds them up. If your systems are fragile and hard to change, AI amplifies that fragility too.

What These Signals Don’t Tell You

One honest caveat. Everything above tells you whether your teams are building software well. Safely, sustainably, and in a way that stays easy to change.

None of it tells you whether they’re building the right software. The features and outcomes that actually matter to customers. That’s a separate question, and it’s just as important. I’ll take it on in the next article in this series.

A Practical Next Step

You don’t need a new dashboard. You need a better conversation.

At your next engineering review, ask your leaders to bring these five signals, and ask them to bring the story behind the signals too. Pick the one or two that map to your biggest current pain, and keep asking why until you reach a root cause you can actually invest in.

Because the goal was never to collect more numbers. The goal is to understand the engineering system that produces your software, well enough to improve the right part of 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.

When transformation isn’t producing results, the first instinct is to look at delivery. Teams aren’t shipping fast enough. The backlog is bloated. The release cadence is inconsistent. The organization reaches for the familiar remedies: new frameworks, better ceremonies, more alignment meetings. Sometimes this helps at the margin. The underlying problem persists.

Look closer, and the diagnosis shifts. Product teams aren’t unclear because they’re undisciplined. They’re unclear because the direction they’ve been given isn’t defined precisely enough to act on. Priorities change without notice. Investment decisions made last quarter are quietly re-litigated this quarter. Teams spend a disproportionate amount of time trying to understand what they’re supposed to be building and why — and not enough time building it.

Go deeper still, and the real constraint comes into focus. The connection between the strategy Executives have articulated and the execution happening in teams is broken. Not because the strategy is wrong, and not because the teams lack capability. Because the system connecting those layers, the governance that should be shaping how decisions are made, at what altitude, with what information, hasn’t been designed. Ambiguity that arrives from above is transmitted downward unchanged. Decisions that should be resolved at the Portfolio layer are escalated or deferred. The organization mistakes motion for direction, and remains, despite genuine effort, largely unchanged.

Nobody intended this. The system produced it.

Governance Is What Connects Every Layer

The four layers of an organization (Executives, Portfolio, Product, and Delivery) are not a reporting hierarchy. They are a system for making and sustaining decisions at different altitudes. Executives own the investment thesis: where are we committing capital and capability, and why? Portfolio translates that thesis into an explicit strategy. A defined set of outcomes, expressed as bets, with measures that make progress visible. Product owns the solution space. Determining what is worth building and why, grounded in evidence from the market. Delivery produces working solutions that test the assumptions underneath those decisions.

What makes this system function is not the existence of these layers. It is governance, deliberately designed, that connects them: the defined decision rights, the evidence flows between layers, the forums where direction is set and updated, and the transparency that ensures every layer is navigating by the same version of reality.

When that system works, value is realized quickly. The path from investment commitment to measurable outcome is short, visible, and actively managed. Disagreement produces better decisions rather than circular conversations. Each layer moves with confidence because it knows what it is accountable for and what the layer above and below it is accountable for.

When governance isn’t designed, or has been left to form by habit, the system seizes. Strategy stays aspirational. Discovery stays disconnected from investment. Delivery stays busy without direction. And the cost accumulates invisibly across quarters, in work that ships without compounding into capability and in investment that continues to flow without evidence that it is working.

Design How Decisions Flow Before You Design the Org Chart

Most organizations design their governance as a reporting structure that presents to whom, which forums exist, and for which updates. That is the wrong starting point. Governance defines how decisions work: who owns what decision, at what altitude, with what information, and what the system does when the evidence shifts.

Each layer has distinct decision rights. Executives own the investment thesis. Portfolio owns the strategy.  The translation of that thesis into explicit, testable bets. Product owns the solution space, determining what is worth building based on market evidence. Delivery owns execution. Building, testing, and learning at a cadence that surfaces results before the budget is spent.

When these rights are clear and the interfaces between layers are designed, the system can move. When they blur, when Executives are making product decisions, when Portfolio is managing delivery detail, when teams are left to infer a strategy that was never made explicit, the system seizes at exactly the points where it should flow.

Good governance doesn’t just define who decides. It defines the quality of information each layer operates with, the cadence at which decisions are reviewed, and the mechanism for updating direction when evidence demands it. Without it, every layer defaults to one of two failure modes: over-controlling decisions that belong at a lower altitude, or absorbing ambiguity from above rather than resolving it.

Discovery is Strategic Intelligence, Not Product Speculation

One of the most consequential flows in the system runs upward. And it is the most consistently underdesigned.

Discovery done well is not a product team exploring possibilities. It is a disciplined, objective inquiry into market opportunity and customer reality: what problems exist, what behavior patterns are present, what unmet needs have commercial consequence. The goal is not to generate ideas. It is to produce a clear, factual picture of where value can be created that the business is not currently creating.

That evidence only becomes strategic intelligence when it is filtered through specific business goals. The question is not “what could we build?” It is “given where we want to compete and what we need to achieve, what does the market tell us about the direction worth pursuing?” That framing transforms discovery from a product function into a direct input to the investment thesis, something that Executives and Portfolio teams need to engage with actively, not receive as a slide summary after the fact.

Which means discovery has to happen in full transparency. Not as a report delivered upward once conclusions have been reached, but as a shared process in which every layer, Executives, Portfolio, Product, and Delivery understand the game being played, the hypotheses under test, the evidence being gathered, and what success looks like at each stage. When everyone navigates by the same evidence, re-litigation loses its raw material. Parallel versions of reality cannot survive shared visibility.

A Bias to Action is a System Design Choice, Not a Team Characteristic

The organizations that move quickly do not have unusually decisive individuals. They have systems designed to produce decisions rather than defer them.

A bias to action, designed into governance, means every layer operates with the information it currently has; it defines what success looks like, commits to a timeframe, runs the experiment, and surfaces what it learned. It does not wait for certainty before moving. It creates certainty by moving. Each tranche of investment is contingent on the evidence produced by the previous one, which keeps risk bounded and learning compounding.

For Portfolio, this means claiming the agency to shape the path when direction from above is ambiguous, rather than waiting for permission to materialize. Waiting is not a neutral act. In a system that requires decisions to flow, deferring them is itself a structural choice to transmit confusion downward. For Product, it means committing the most informed hypothesis to a testable bet rather than continuing to discover in the absence of a decision. For Delivery, it means building toward observable outcomes and surfacing evidence on a cadence short enough to influence the next investment decision.

The governance creates the forum where that evidence is integrated. Not a status meeting. A decision meeting where each layer reports what it expected, what happened, and what that means for where investment flows next. The agenda is consistent. The decisions are different every time, because the evidence is always moving.

From Strategy to Learning Without the Rewrite Cycle

Consider a mid-sized enterprise software business in the middle of a significant shift in its commercial model. The executive team has concluded that long-term growth depends not on serving every customer’s every request, but on investing deeply in a small number of differentiating capabilities that position the business distinctively in the market. The strategic intent is clear at the top.

Three layers below, the picture looks entirely different. Customer-facing teams are measured on retention and satisfaction scores, so they advocate loudly, and understandably, for features that address the most vocal accounts. Engineering teams, operating largely independently, are making architectural decisions optimized for technical coherence rather than commercial outcome. Product teams are trying to build towards broader customer value, but are pulled constantly toward the most recent escalation. Everyone is working hard. Nobody is working on the same problem.

The absence is governance. There are no explicitly defined decision rights: no clarity on who can commit the product to a customer-specific request, who can decline one, or what the standard is for calculating whether a piece of work is worth doing relative to the business strategy. There is no mechanism for surfacing the cost of misalignment. The accumulated drag of investment flowing toward work that doesn’t compound into the executive team’s stated direction. Teams pull in different directions, not because they are misaligned in their values, but because the system was designed to let them.

The fix is not a new strategy deck. It is how the system is designed. Stable, cross-functional teams where customer knowledge, technical judgment, and commercial accountability are integrated rather than siloed. Change the incentive structure at the point of decision. When the team building the product also owns the customer relationship and is accountable for the commercial outcome, the tension between what an individual customer wants and what the business strategy requires becomes a decision the team has to make explicitly, not a conflict they can refer upward or quietly ignore.

Decision rights, defined at the right altitude, make the cost of misalignment visible. Discovery, done in full transparency rather than within functional boundaries, gives every layer, including Executives, the same objective picture of where the market is moving and which capabilities need to express differently to get there. Portfolio works with Executives to translate that picture into a defined set of bets: explicit outcomes, measurable over a bounded timeframe, funded in tranches contingent on what each previous tranche produced. The governance creates the forum where those bets are reviewed on a consistent agenda. What did we expect, what happened, what do we do next with the investment, and where changing course requires engaging with the evidence, not simply calling a new meeting.

The system does not eliminate tension between customer needs and strategic direction. It forces that tension to be resolved at the right altitude, by the right people, on the basis of shared evidence. That is what makes the disagreement productive rather than circular.

What to Look for in Your Organization

If the transformation is moving more slowly than it should, the diagnostic is rarely about individual teams. It is about the system connecting them.

Decisions get re-litigated when governance doesn’t define who owns them and what evidence settles them. Discovery gets disconnected from strategy when product teams explore in one direction while executives invest in another because the system was never designed to make those two things visible to each other at the same time. Portfolio decisions stall when the agency to shape the path hasn’t been claimed, and Product and Delivery teams slow down when they are absorbing ambiguity that should have been resolved one layer above.

The organizations that install durable transformation systems design the system deliberately. The decision rights, the evidence flows, the forums, the cadence, and the transparency that makes it structurally difficult for any layer to operate on a different version of reality than the one everyone is navigating by.

The system does not change itself. Governance does.

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.

I’ve spent the last 25 years trying to answer one question: how do you actually get a large, complex organization to deliver software predictably? The question hasn’t changed. The technology has changed. The buzzwords have changed. The funding model has changed. But the underlying problem has been the same one the whole time, and right now it’s wearing a new costume called AI.

So when CIOs ask me what they should be telling their board about AI, I tell them the same thing: don’t tell them about AI. Tell them about the preconditions.

The Pattern I Keep Watching Repeat Itself

If you’ve been following our work for a while, you’ve heard me say that agile fails when the structural preconditions for it to work aren’t in place. We’ve been saying that for almost 20 years. It was true when the new thing was Scrum. It was true when the new thing was DevOps. It was true when the new thing was cloud migration. It’s true again now that the new thing is AI.

The pattern goes like this. A new technology emerges that promises a step-change in business outcomes. Leadership gets excited. Pilots get funded. The pilots produce a couple of demos that look great in a boardroom. The demos don’t scale into the actual business. Six months later the conversation turns to how much the team is learning. 18 months later the initiative quietly gets de-funded and replaced with the next new thing.

I’ve watched that arc play out with every major tech wave in the last 25 years. It’s playing out right now with AI. It will play out next with whatever comes after AI. The pattern is a structure problem.

Why Most AI Pilots Aren’t Scaling

A partner of ours said something to me about a year and a half ago that stuck: the move to AI is going to force digital transformation to become real. He was right. There was a lot of room in the cloud-migration wave for a CIO to spin up some containers, claim victory, and tell the board they were digital. AI doesn’t grant that kind of room. AI either solves a real business problem using your actual data and workflows, or it doesn’t.

Most of them don’t, and the reason is structural. Your AI pilot is sitting in a system that wasn’t designed for it. The data it needs is locked inside a system of record from 30 years ago that runs on a different operating assumption. The workflow it’s supposed to accelerate runs through six teams that don’t share a backlog. The output it produces has to be trusted by an executive whose dashboard is wired into a different governance system entirely. The pilot demo works because the demo conditions are controlled. The production reality isn’t, and the production reality is what your board cares about.

I’ve been saying for a long time that the unit of agile delivery is a complete cross-functional team with a clear backlog producing a working tested increment of the product on a regular cadence, with no dependencies they can’t manage themselves. Teams, backlogs, working tested software. That’s it. That’s the whole frame. Every word in that sentence is doing real work, and every word of it applies just as much to AI as to anything else we’ve ever tried to ship.

If your AI team is six engineers spread across three reporting lines, dependent on a data team in another building, releasing into a workflow they don’t own, against KPIs nobody has agreed on, the outcome is predictable. Your AI pilot will behave exactly the way every failed agile pilot has behaved for 20 years. In any useful sense, it’s a structure problem wearing AI clothes.

What I’d Actually Tell Your Board

Here’s what your board needs to hear: we’re going to be predictable.

If I were the CIO, here’s how I’d frame the board conversation. We are going to deliver AI-enabled business outcomes every 90 days, against a small number of capabilities at a time, and we’re going to deliver them predictably. We’re not going to commit to a portfolio of 15 AI use cases on a slide somewhere and then come back in 18 months apologizing for what didn’t ship. We’re going to commit to one capability that we can actually land, ship it, and earn the right to fund the next one with the value we just shipped.

That is a delivery commitment the board can hold us to. It’s the same predictability promise I’ve been trying to get technology organizations to make for 20 years. AI doesn’t change the standard. If anything, AI raises it, because the cost of AI tooling and AI talent makes a slow, unpredictable AI program more financially painful than a slow, unpredictable agile transformation ever was.

The reason this lands at the CIO level is that you’re the one who has to translate the structural reality into board language. Engineering can talk to engineering about modular architecture and complete cross-functional teams. The CFO can talk to the CFO about CapEx and OpEx. You sit in between. You’re the one who has to take “we need to break the dependencies between our systems before AI can scale” and turn it into “we will deliver business outcome X by date Y at confidence level Z.”

That’s a structural conversation, not a tooling conversation. And it’s the conversation our industry has been bad at having for a long time. We tend to want to tell the board about the new thing we bought. The harder, more honest CIO move is to tell the board about the old thing we’re redesigning so the new thing can work, and to commit to a delivery cadence the board can verify against the calendar.

Where to Start

If you take one thing from this post, take this. The structural work and the AI delivery aren’t sequential. They happen inside the same 90 days, against the same capability, by the same team.

Pick one business capability where AI would materially matter. Not five. One. Make it the one you’d most want to win. Then ask three questions about it.

One. Is there a single team that owns this business capability end-to-end, with no external dependencies that they can’t resolve themselves? If not, your first move inside the 90 days is forming that team.

Two. Is the data this AI needs encapsulated in a service that team can call, or is it sitting inside a legacy monolith that has to be touched every time something changes? If the latter, part of the 90 days is extracting and encapsulating just enough of that data for this one capability to work cleanly. Not all of your data. The slice this capability needs.

Three. Does the workflow this AI is meant to accelerate have a clear, measurable business outcome that an executive sponsor will hold their team to? If not, the 90 days include defining that outcome, in operational terms, with the sponsor signed up to it.

By the end of the 90 days, three things are true. The structural preconditions for this capability are in place. The AI is deployed against the capability in production. There is a measurable business outcome that the team and the sponsor agree was hit. That’s your first delivery. That’s what you take to the board at the end of Q1.

Then the next 90 days add the next capability. By the end of year one, you’ve got four capabilities running on the new structural pattern, each with AI compounding on top of it, each with a clean business outcome the board can point to. Most CIOs don’t see this coming. The structural work you did for capability one pays forward into capabilities two and three. The team gets faster. The data layer gets cleaner. The governance model gets more practiced. The cadence becomes the operating rhythm.

That’s a very different story than “we’re not delivering AI this year.” It’s “we’re delivering AI quarterly, against the capabilities that matter, on a cadence you can take to the audit committee.” Same underlying preconditions argument. Very different message in the boardroom.

Most of the CIOs I talk to are already deep into an AI program that doesn’t look like that. The move isn’t to throw it out. The move is to pick the one capability inside it that’s most worth saving, restructure the work around that one, and let the unsalvageable pieces wind down naturally as funding cycles end. Don’t take a year off from AI to prepare. Take 90 days to do one capability right, then prove the pattern repeats.

The firms that figure this out in the next two years won’t be the firms that bought the most AI tools. They’ll be the firms that learned to deliver AI predictably against a small number of capabilities at a time. The rest will spend year three explaining to their boards why the AI bill keeps going up and the business outcomes haven’t moved.

That’s the story. Tell that one.

In my last article, Why Most App Modernizations Fail, I made the case that organizations know they need to modernize but are lacking a framework that removes the ambiguity from the decision making. This article moves us from strategy to practice, walking through how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that delivery business value at every step of the journey.

Breaking Down Silos Through Domain Alignment

Application modernization cannot happen in a silo. Legacy applications in many instances can be considered a bowl of spaghetti when pulling one noodle somehow breaks four in the process. By understanding domains and aligning technical teams to those domains, organizations create a cross-functional structure that ensures modernization efforts consider the impact on various departments and promote an integrated approach. This alignment also follows Conway’s Law [1] where organizations design systems that mirror their internal communication structures, turning an organizational reality into a deliberate design advantage.

Delivering the Value

To begin delivering value during application modernization, organizations must have an established business capability model with corresponding heatmap. In this article, I will not be describing how to establish the model, nor will I be describing how to create the needed heatmap. It is also assumed that a definition of business capability is not needed though one can reference the article Organizing Around Business Capabilities. This article will describe how using capabilities focuses strategic refactoring decision making on changes that increase value rather than simply rebuilding every application.

Precursors to a capabilities-driven application modernization

The first step is to recognize that not all business capabilities have the same significance.  Business capabilities are stratified into three layers [2]

• Strategic – direction setting or typical executive focal points
• Core – customer facing or what an organization does to thrive in the marketplace
• Supporting – what the organization must have to function as a business

For those not as familiar with business architecture, a similar concept can be found with Martin Fowler [3]. He describes how to determine if IT is strategic or utility. Technology is strategic where it contributes or supports capabilities that differentiate the organization. As with Strategic and Core business capabilities, if the business value for the technology is determined strategic then that is the area one wants to be as good as possible.

The stratification of capabilities and Martin’s concept of IT being strategic or utility are keys to unlocking sound investments. An additional key is to establish a capability-driven organization that contains both technical and business operations into the capabilities. These keys will unlock the next steps in determining how to make sound economic application modernization investments. These steps include:

1. Assess the value, performance, and risk of your capabilities using a capability heatmap
2. Align domains to your capabilities

Asses the value, performance, and risk of your capabilities using a capability heatmap

Since many organizations fail with their application modernization efforts, using data to determine what areas of the organization they should focus on should be standard practice. Those who engage in a business capability assessment will have a clear advantage by having data that shows what the organization should focus on for improvements. In Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders, Whynde Kuehn [4] identifies the business capability assessment as offering ‘a data-based view of business performance, at an aggregate level.’

Assessing the value (strategic importance), performance (people, process, and technology), and risk (flexibility/suitability) of business capabilities is the basis of a capability heatmap. Creation of the heatmap should occur before any decisions around application modernization efforts are made.

Align domains to your capabilities

A domain is the activity or business of the end user [3]. A simple explanation is a domain is equal to a business object which includes its behavior, state transitions, and data associated with an element of a business. It is a specific problem space that a software solution is meant to address. Examples of domains are Product, Market, Work Order, and Customer.

There are a few important distinctions between business capabilities and domains. Business capabilities are described at a higher, more abstract level, and they are non-redundant across the organization. Domains can be redundant across the organization. They participate in one or more bounded contexts that facilitate encapsulation of teams and systems from each other that distinguish the distinct meaning and rules inside and outside the area. For a domain the smaller the boundary the smaller the teams and the more modular the service architecture. Larger boundaries will result in larger teams and more complex or monolithic architecture. In other words, alignment of business capabilities and domains follows Conway’s Law [5] where organizations will design systems that mirror their own internal communication systems.

What happens when domains are redundant across the organization? Does it matter? The short answer is it depends.  Redundancy in domains does not mean there should and will be redundancy in data models. Attempting to unify the redundancies breaks the core principle bounded context and will in effect drive accidental complexity and monolithic coupling. For example, ‘Customer’ can appear in both ‘billing’ and ‘shipping’, but has different attributes in each context (e.g. billing address does not always equal shipping address, etc.).

Eric Evans, in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) [3], explicitly warns against forcing a single unified model across contexts. Each bounded context owns its own ubiquitous language, meaning “Customer” in billing may carry attributes like payment history and credit status, while “Customer” in shipping cares only about address and delivery preferences. The behavior and attributes should differ because they serve different capabilities. The key is to ensure that the domain has a consistent meaning across all contexts in which it participates, and that when needed attributes from multiple contexts can be combined to fulfill a particular business need.

Sam Newman, in Building Microservices (2nd ed., 2021) [5], reinforces this by describing how shared models across service boundaries create tight coupling — the very problem that bounded contexts are designed to prevent. He recommends tolerating some data duplication across services rather than introducing shared libraries or databases that erode autonomy.

With that said, there are instances where a domain should have the same behavior and attributes across capabilities. Take for example ‘Product’ domain.  It is undesirable for calculation of pricing within the Inventory domain to be different than the calculation of pricing in the e-commerce domain. This would lead not only to teams solving the same problem, perhaps leading to different outcomes but also to increased operational costs when resolving any issues and/or updating the calculations. This is the organizational mirror that Conway’s Law predicts: siloed teams produce siloed, inconsistent implementations of logically shared concepts.

In short, if the behavioral difference has no business justification and exists purely because two teams built the same thing independently; refactoring is warranted, but the target is not necessarily a shared service. Often the right move is to designate one context as authoritative (a published language or open host servicein Evans’ terminology) and have the other consume it through a clearly defined application programming interface (API), rather than collapsing both into one monolith.

When aligning business capabilities and domains, ensure the smallest possible bounded context per domain while also taking into consideration if the redundancy within the domains has a business justification or not is critical.  Otherwise, a system that continues to perpetuate dependencies across the organization is created. If the language of the consumer varies significantly from the authoritative context, one can establish an anti-corruption layer to translate an external model into terms that are more meaningful within the consumer’s bounded context.

Pulling it Together

Nicholas Tune and Jean-Georges Perrin point out ‘To get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities’. [6]

To do this, leverage business capability and domain heatmap. At the most basic level, the tool visually identifies which capabilities are most critical to improve from a strategic level. The heatmap also indicates the impacts that the strategic decisions will have on the organization. Is the strategy to increase speed of innovation, operation costs, or scalability? Will the strategy impact multiple highly strategic capabilities that all have highly inflexible and are performing below average? What is the current technical debt? The executive will know that a higher level of investment will be needed to improve the capabilities and domains.

Conversely, the heatmap will also show areas that are already performing within the needed objectives and goals. The executive will know that investment in these areas is not wise as it is unnecessary to continually improve on a capability that is already performing at a high level.

Companies who may have a good understanding of their distinctive business capabilities fail to associate them with their domains. Ensuring the alignment between capabilities and domains and their associated technologies improves an organization’s awareness of where they are wasting money on non-strategic, overperforming or adequately performing capabilities. Ultimately this prevents the company from hemorrhaging money on unnecessary application modernization efforts.

This article was originally published in Architecture & Governance Magazine in May 2026.

References

[1] Conway, Melvin E., “How Do Committees Invent?” Datamation, 1968, https://www.melconway.com/Home/Committees_Paper.html.

[2] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79

[3] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.

[4] Kuehn, Whynde. Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders. Morgan Jame Publishing, 2022

[5] Newman, Sam. Building Microservices: Designing Fine-Grained Systems. 2nd ed. Sebastopol, CA: O’Reilly Media, 2021.

[6] Tune, Nick, and Jean-Georges Perrin. Architecture Modernization: Socio-Technical Alignment of Software, Strategy, and Structure. Manning Publications, 2024.

Most Fortune 100 companies aren’t struggling with AI because they lack the right tools or models. They’re struggling because AI fails at the organizational level: fragmented data, misaligned incentives, no clear ownership of outcomes, and legacy systems that weren’t designed to feed production AI. It’s these issues that stop promising pilots from scaling into production. Addressing these organizational issues is key to realizing the potential of AI. This article explains why your pilots aren’t scaling and the five conditions that enable AI to reach meaningful production scale.

You Don’t Have an AI Problem. You Have a Systems Problem.

When we work with CIOs at large, legacy-heavy enterprises, we hear the same story: a lot of AI-focused activity but not much in production at a meaningful scale.

This is what we call pilot stall. And it’s the root causes have little to do with AI itself.

Pilots are typically initiated in a controlled environment. One where the conditions are created for success, and one that typically doesn’t reflect the operational and technical realities of the organization as a whole. The moment you tried to scale it, you hit the constraints of the legacy systems. Your legacy systems weren’t designed to feed real-time inference, so the “last mile” data problem stalls every deployment. The business units that would benefit from the AI don’t own the model, don’t feel accountable for its performance, and don’t change their processes to take advantage of it. Decision rights, funding flows, and governance processes were designed before AI was a real production constraint. None of these is an AI problem. They’re system problems.

Start with the System, Not the Symptom

Organizations are systems. They produce predictable results based on how they’re designed. If you want different results, you have to change the system’s design, not just its components.

For enterprise AI, this means asking a different set of questions before you reach for a solution:

What is the actual constraint limiting performance? Usually, it’s not the model quality. It’s the data pipeline, the decision-making structure, the incentive model, or the lack of mapping of AI capability to a value stream that produces measurable business outcomes.

What must be true for this to work at scale? AI Transformation succeeds or fails depending on whether the necessary system conditions are in place. What are the prerequisites? What has to be in place before you can build on it?

What does the system produce, and why? If your organization keeps generating pilots that don’t scale, there’s a structural reason. The behavior is an output of the system design. Find the design flaw, not the scapegoat.

Treating AI transformation as systems redesign rather than technology deployment changes what you do, in what order, and who needs to be involved.

The Five Conditions That Move AI to Production

Based on our work with complex, legacy-heavy enterprises, here’s what consistently separates the organizations that make it into production from those that don’t. The shape of the work depends on the type of AI problem and the organization’s maturity. The five conditions below are necessary in most Fortune 100 contexts; how you instantiate them varies.

1. Ruthless portfolio rationalization. Most organizations have too many pilots. Start by focusing on three to five capabilities that are connected to improving KPIs that the CFO is focused on: revenue, cost, customer impact, and cycle time. Everything else is noise until you’ve proven you can drive results in production.

2. Encapsulated capabilities, governed interfaces. Not a central AI team that everyone has to coordinate with. Not another tool. An architecture where each business capability owns its own models, its own data pipelines, and its own production lifecycle, connected through governed interfaces rather than central orchestration. Reducing cross-team dependencies is the prerequisite infrastructure that most organizations skip in their rush to build models.

3. Operating model redesign. Who owns the model in production? Who is accountable when performance degrades? How are cross-functional teams funded for ongoing capability, not one-time projects? These aren’t technology questions. They’re organizational design questions, and they’re the ones that determine whether your AI actually sticks.

4. MLOps and governance built in from the start. Model lifecycle management, monitoring, drift detection, and compliance workflows need to be part of the architecture from day one. Don’t bolt them on after a failed production launch. Governance without infrastructure creates bottlenecks. Infrastructure without governance creates risk.

5. Business-defined success metrics. If your AI program is measured by model accuracy, you’re measuring the wrong thing. The right metrics are end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. When success is defined in business terms, accountability follows naturally.

The LiminalArc Approach to Pilot Stall

Most AI consulting work focuses on the wrong layer: the model, the platform, the use case. The firms that consistently get AI to production at scale work at the systems layer instead, where the production failures actually originate. That’s the work LiminalArc was built for.

We work specifically with Fortune 100 enterprises where the bottleneck is organizational: incentive misalignment, cross-functional coordination failures, legacy architecture constraints, and governance gaps. We diagnose the system before we recommend technology. We install the five conditions and one capability at a time, end-to-end, until production AI delivers measurable ROI. Then we expand to the next capability.

If your pilots aren’t scaling, the firms that can solve that are the ones that treat your organization as the primary variable, not the technology. LiminalArc is built for that work.

Frequently Asked Questions

Why do our AI pilots keep failing to scale?

Pilot failure almost always traces back to organizational and infrastructure factors, not model quality. The most common causes are: no unified data layer, no business owner for the outcome, incentive structures that fund projects rather than capabilities, and operating models not designed for continuous AI deployment.

How long does enterprise AI transformation take?

For Fortune 100 companies with complex legacy infrastructure, realistically, 18-36 months to reach a satisfying ROI at scale. The first 90 days should focus on portfolio rationalization, constraint identification, and foundational architecture. Expect measurable production deployments within six months of starting structured work.

How do we avoid pilot stall?

Pilot stall happens when organizations lack unified platform architecture, MLOps infrastructure, governance frameworks, clear business ownership, or ruthless portfolio rationalization. Install all five conditions within a single capability before you build more pilots elsewhere.

What’s the difference between systems thinking and a technology-first approach?

Technology-first starts with “which model or platform should we use?” Systems thinking starts with “what is the constraint that’s limiting performance?” The questions look similar. The answers and the work required are entirely different.

How do we measure AI ROI?

Measure end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. Model accuracy is a technical metric, not a business metric. Build your business case in the language your CFO and board use: revenue impact, cost avoidance, margin expansion.

What’s the right size of an AI portfolio to start?

Three to five high-priority capabilities, each tied to a measurable value stream, with clear production infrastructure and business ownership. That’s it. Every additional initiative dilutes focus and slows execution until you’ve proven you can scale something.

Work With LiminalArc

If your pilots aren’t scaling, we should talk. Not about which tools you need. About why your system keeps producing the results it’s producing, and what it would take to change that.

Explore our AI Readiness work
Talk to a LiminalArc advisor

LiminalArc helps Fortune 100 enterprises move from AI experimentation to real business value by treating transformation as a systems problem rather than a technology problem.