Lumerai Technology Value Realization Series | Part 3
Why Better Discovery Doesn’t Always Lead to Better Decisions The Confidence Gap in Technology Investments Technology investment decisions rarely fail because organizations lack information. They fail because organizations often mistake more information for greater decision confidence. By the time a technology initiative reaches executive leadership, months of work have often been completed. Business cases have been drafted. Requirements have been documented. Vendors have been shortlisted. Demonstrations have been conducted. Scorecards have been completed. Research from organizations such as Gartner and McKinsey has consistently highlighted the difficulty organizations face in translating major technology and transformation investments into expected business value. Despite months of rigorous preparation, executive leadership is frequently left asking the exact same fundamental question: “How do we know this is the right investment?” That is the Confidence Gap: the distance between having enough information to make a technology decision and having enough evidence to make a confident decision about business outcomes. In the first article of this series, I argued that organizations often solve the wrong problem because they skip structured discovery. In the second article, I introduced the Lumerai Executive Discovery Framework, a disciplined approach to validating business opportunities before evaluating technology solutions. Discovery improves the quality of the problem definition. It does not, by itself, guarantee the quality of the investment decision. Transforming discovery into realized value requires structured executive decision governance. When Good Analysis Produces Poor Decisions One of the most persistent misconceptions in enterprise IT strategy is the belief that more analysis produces better decisions. It does not. During enterprise software evaluations, organizations routinely generate an extraordinary amount of analysis and documentation: Ironically, this abundance of data frequently induces decision paralysis rather than strategic clarity. Executives become overwhelmed by competing departmental priorities, conflicting vendor claims, and technical minutiae. As a result, executive discussions regress from strategic outcome validation to tactical feature grading, pricing negotiations, and deployment timelines. Technology selection becomes the primary objective, while business value realization fades into the background. Confidence Is an Executive Asset Enterprise technology investments are rarely approved simply because a vendor offers the longest feature list. Successful investments are approved when leadership establishes high decision confidence that the deployment will produce its intended business outcomes. Executive decision confidence relies on validating five fundamental governance questions: When these questions are answered with evidence rather than vendor assumptions, governance transitions from passive procurement to active strategic leadership. The Lumerai Executive Decision Framework The primary objective of the Lumerai Executive Decision Framework is not to select software. Its objective is to identify the investment decision that yields the highest confidence of achieving target business outcomes. The framework evaluates major capital investments across six progressive decision gates: Stage 1: Validate Strategic Alignment Establish whether the initiative directly accelerates enterprise revenue, cost efficiency, or competitive differentiation. Initiatives lacking clear strategic alignment should not advance to subsequent investment gates, regardless of technical capability. Stage 2: Define Decision Criteria Before engaging vendors, leadership establishes non-negotiable success criteria driven strictly by operational imperatives. Business outcomes drive technology selection—never the reverse. Stage 3: Evaluate Solution Architecture Assess integration complexity, scalability, security posture, and operating model alignment. Technology is evaluated as a capability enabler within the broader ecosystem. Stage 4: Assess Enterprise Risk Evaluate operational, financial, vendor stability, cybersecurity, and organizational change risks collectively rather than in isolation. Stage 5: Compare Future Scenarios Test how candidate solutions perform across distinct future business scenarios—such as rapid scaling, M&A integration, regulatory shifts, and emerging AI capabilities. Stage 6: Establish Decision Confidence Final investment sign off should occur only when the evidence demonstrates that the business problem has been validated, alternatives have been objectively evaluated, risks are understood, and clear value realization metrics have been established. Confidence does not mean certainty. No major technology investment comes with certainty. It means leadership understands the evidence, the assumptions, the risks, the alternatives, and the expected outcomes well enough to make a defensible decision. Five Biases That Can Distort Technology Decisions Even disciplined organizations are susceptible to cognitive bias. Five biases appear repeatedly during enterprise technology evaluations: Recognizing these biases does not eliminate them. The objective of governance is to make them visible, challenge their influence, and ensure that major investment decisions are ultimately supported by evidence rather than assumption. Executive Example Consider an enterprise modernizing its service architecture following a structured discovery phase. Three finalists remain: Vendor A: May create the greatest long term capability, but introduces significant organizational and implementation risk. Vendor B: May offer the strongest operational fit, but requires a higher initial investment. Vendor C: May produce the strongest financial case today, but could constrain future growth through customization requirements. All three can satisfy the requirements. The decision therefore cannot be resolved by requirements compliance alone. Which investment gives us the greatest confidence that we will achieve the business outcomes we defined? Under the Lumerai Executive Decision Framework, the decision shifts from “Which platform scores highest?” to “Which capital allocation provides the highest decision confidence for our strategic outcomes?” By evaluating each vendor against future operating scenarios and risk tolerances, leadership converts an ambiguous software comparison into a confident strategic decision. Better Decisions Require Better Governance Technology investments should never be authorized simply because a platform tops a feature matrix. They should be authorized because executive leadership has evidence based confidence that the investment aligns with strategic objectives, addresses a validated business problem, appropriately manages enterprise risk, and establishes a credible path to measurable economic value. True decision confidence is not executive intuition. It is the outcome of disciplined decision architecture. Conclusion Technology investment decisions are often portrayed as exercises in software selection. In reality, they are exercises in executive judgment regarding business outcomes. Organizations that consistently outperform their peers are not necessarily better at evaluating technology. They are better at making decisions. They understand that every technology investment is ultimately a business decision supported by technology, not the other way around. Discovery identifies the right problem. Decision making determines the right investment. Execution delivers the solution. Value realization measures success.
AI Capability Doesn’t Always Arrive as Features
Most organizations are running less AI capability than they own. The entitlement arrived, the gate is working as designed, and part of what accumulates now cannot be counted at all.
Nobody Decided to Let Software Decide
Decision rights have been migrating out of people and into business rules nobody owns. Real estate got the bill first. What every executive should know.
The AI ROI Panic Is About to Create the Next Legacy System
By Rob Purks, Founding & Operating Partner, Lumerai Advisors There is a quiet panic spreading through boardrooms right now, and it has nothing to do with whether AI works. It has to do with whether anyone can prove it. The numbers behind that panic are real. Hyperscalers are on track to spend roughly $675 billion on AI infrastructure this year alone. Meanwhile, MIT’s Project NANDA found that 95% of enterprise AI pilots deliver no measurable P&L impact. S&P Global reported that 42% of companies abandoned most of their AI initiatives last year which is more than double the rate of the year before. Forrester is now predicting a market correction with enterprises deferring a quarter of their planned 2026 AI spend into 2027. Even the debt markets have weighed in: Citi identified a measurable credit spread penalty for companies classified as AI adopters without evidence of return. Spending without proof is now literally priced into the cost of capital. I am not here to argue with the data. The data is right. I am here to argue with the response. Key Takeaways The Control Reflex: Why AI Governance Backfires When boards see numbers like these, they react the way boards have always reacted: with control. AI steering committees and per-use-case business cases. ROI attestation before funding. Approval gates between pilot and production. Governance councils that meet monthly to review initiatives that move weekly. Every one of these mechanisms is individually defensible. That is exactly what makes them dangerous. I have spent my career on both sides of this dynamic, as a CIO running technology for telecom operators in Latin America, and later advising enterprises on transformation at Accenture, IBM, and Ericsson. And I can tell you what happens next, because I have watched it happen with every major technology wave: the control structure built to manage today’s uncertainty becomes tomorrow’s constraint. It outlives the problem it was created to solve. Nobody is ever promoted for dismantling a governance committee. I learned this the hard way by inheriting the aftermath of one. At a Latin American operator a major CRM transformation had been put in front of a review board and killed on grounds that were individually hard to argue with: the projected budget was steep, the internal skills weren’t fully in place, and the business wasn’t deemed ready. Every objection was reasonable. The board did exactly what it was designed to do. And while we sat on a defensible “not yet” a competitor moved, modernized its customer platform, and took ground we never fully recovered. The control worked perfectly. The company lost anyway. That is the trap: the most dangerous governance failures don’t look like failures at all, they look like prudence. We have seen this exact movie before. Cloud and agile both promised speed. In most enterprises they delivered something closer to “the same speed with more meetings.” The technology arrived, the operating model absorbed it, neutralized it, and carried on. The gains didn’t disappear, they were quietly strangled by slow decisions and diffused accountability. The ROI panic is now rebuilding that machinery, at speed, with the best of intentions. Except this time there is a difference that should worry every executive: when the constraint is a legacy system you can eventually migrate off it. When the constraint is a legacy operating structure there is no migration project. It just becomes how the company works. I call this Governance Debt: the accumulated drag of controls that outlast the uncertainty they were built to manage. Like technical debt it compounds quietly and like technical debt the interest is paid in speed. The Wrong Diagnosis: It’s Not an AI Adoption Problem Here is the tell that we are solving the wrong problem. In one of the most striking findings of this cycle 97% of executives report personally benefiting from AI yet only 29% see significant organizational ROI. Read that gap carefully. It is not an adoption problem. It is not a model-quality problem. And it is emphatically not a control problem. It is a compounding problem. Value is being created at the level of individuals and teams and the organization has no mechanism to aggregate it, redirect it, or build on it. Adding oversight to that situation does not create compounding. It adds friction to the one place value actually exists. Look at what the successful 29% actually have in common: AI tied to revenue outcomes, business teams owning the workflows, and the whole effort treated as organizational redesign rather than technology deployment.[1] Notice what is not on that list: more approval gates. The organizations seeing returns did not out-govern their peers. They out decided them. What to Build Instead: A Velocity-First AI Operating Model If the answer isn’t heavier oversight, what is it? Three structural moves none of which require a committee: Replace approval gates with kill cycles. Don’t make initiatives prove their worth before they start, make them prove it on a clock. Every AI initiative launches with pre-agreed kill criteria and a fixed time box. The discipline shifts from “may we begin?” to “did we learn enough to continue?” That is governance measured in velocity, not meetings. Measure ROI at the portfolio level, not the use case. Demanding a business case from every individual experiment guarantees you will only fund the safe, incremental, and ultimately unimportant. Venture and private equity investors figured this out decades ago: the portfolio carries the math so the individual bets can take real risk. It is the same logic that drives value creation across a portfolio of companies, you manage the aggregate, not the average. Boards should hold leadership accountable for portfolio-level return and learning rate, not for the survival of any single pilot. Put a sunset clause on every control. Any governance mechanism created to manage AI uncertainty should carry an expiration date and a renewal test: what decision did this body accelerate this quarter? If the honest answer is none, it isn’t governing, it’s accumulating. This is how you keep
The 95% AI Pilot Failure Rate Is Good News
Why the MIT number is a portfolio management finding, not a technology verdict, and the three governance mechanisms that separate an AI experiment pipeline from a capital leak.
Lumerai Technology Value Realization – Part 2
Enterprise Technology Strategy: Closing the IT Discovery Gap Enterprise technology investments often fail long before a single line of code is written or a software vendor is selected. The structural breakdown happens silently in the transition between identifying an operational friction point and proposing a technology solution. In my previous piece, The Missing Stage in Every Technology Investment, I outlined how organizations consistently collapse problem discovery into immediate project execution. This second article explores that failure: The Discovery Gap. Organizations often believe technology investments fail during implementation. In reality, many fail months earlier. They fail during discovery, when assumptions are accepted as facts and proposed solutions are mistaken for business requirements. That is the Discovery Gap. In our work advising enterprise boards and private equity operating partners, the Discovery Gap typically manifests when an organization mistakes a technology request for a strategic business need. To close this gap and protect capital allocation, enterprise leaders must transition away from passive requirements gathering toward a disciplined, data-driven discovery process. The Capital Failure of Traditional Procurement Traditional procurement processes were designed to compare solutions, not validate problems. They excel at evaluating vendors once an organization has already decided what it wants to buy. What they rarely challenge is whether the organization should be buying that solution at all. A business unit submits a request for a new platform, and the IT organization immediately begins gathering requirements. This legacy approach asks: This approach turns technology teams into order-takers. It assumes the initial software requested is the correct solution to the underlying business problem. By skipping the diagnostic phase entirely, organizations spend millions automating fundamentally broken workflows. Is IT’s role to provide what is being asked for or delivering what the company needs? The macroeconomic cost of this gap is staggering. Contemporary enterprise data from Gartner indicates that over 27% of cloud and software spend is completely wasted on unutilized or redundant resources. Furthermore, McKinsey research shows that up to 70% of digital transformations fall short of their goals due to organizational and process misalignments. Unlike standard Business Requirements Documents (BRDs) or Agile User Stories, which merely log and format user desires, true enterprise technology strategy requires a framework that interrogates the business context before capital is deployed. The Lumerai Executive Discovery Framework The Lumerai Executive Discovery Framework reverses the traditional procurement paradigm. It introduces a disciplined, five-stage diagnostic process designed to validate the business opportunity, map the operating model, and challenge assumptions before any software alternatives are evaluated. Crucially, the framework introduces a financial model of Progressive Capital Gating. Rather than funding a major initiative based on unverified assumptions, organizations allocate minimal capital during initial discovery and incrementally unlock funding as risks are mitigated and the problem becomes clearer. Stage 1: Aligning Capital with The Enterprise Strategy Before discussing software, or software features, leaders must anchor the request in the overall corporate strategy. Capital allocation at this initial gate is limited strictly to validation with a small investment. Stage 2: Quantifying Operational Friction and Bottlenecks Establish an objective, data-driven baseline. Investment decisions must rely on operational data rather than anecdotal sentiment from business leaders. Stage 3: Optimizing the Corporate Operating Model over Software This is the critical inflection point where the framework diverges from traditional IT procurement. Capital is seed-funded to test non-technical fixes, focusing on corporate governance, and process optimization. This stage requires a cross-functional steering committee to formally sign off on process optimization before any software evaluation. Stage 4: Defining Board-Level Success Metrics and ROI Value must be quantified before vendor conversations begin. This stage establishes the precise leading and lagging metrics that will govern the final investment business case. Stage 5: Architecting the Technology Solution Only after passing the first four gates is the full capital expenditure (CapEx) budget unlocked. Technology enters the conversation not as a default starting point, but as a calibrated tool. Executive Reality: The AI Customer Service Trap To see the Lumerai Executive Discovery Framework in practice, consider a common modern scenario: A business leader requests an advanced Generative AI solution to automate customer service. The instinctive response from a traditional IT organization is to immediately evaluate AI platforms, compare LLM accuracy rates, and calculate software licensing costs. A discovery-led approach asks entirely different questions: If data reveals that 70 percent of customer inquiries stem from inaccurate billing statements or confusing corporate cancellation policies, implementing an AI chatbot does not solve the root issue. It simply automates customer frustration at scale. The superior investment is to redesign the billing workflow and clarify customer communications. Once the underlying process is effective, AI can be introduced to enhance an already optimized experience. The technology choice hasn’t changed. The definition of the problem has. And with it, the likelihood of realizing meaningful business value. Better Decisions Begin with Better Questions To shift your organizational culture toward a discovery-led mindset, leadership must change the vocabulary of technology procurement. 💡 The Lumerai Shift Conclusion Organizations often believe technology investments begin with selecting vendors, issuing RFPs, or evaluating software demos. In reality, successful digital transformations begin much earlier. They begin with curiosity. The enterprises that consistently realize the highest ROI from their technology investments are not those with the largest budgets or the newest platforms. They are the ones willing to spend the necessary time understanding the problem before pursuing the solution. The quality of every technology investment is ultimately determined by the quality of the questions that precede it. Better decisions begin with better questions. Technology should be the last answer we evaluate, not the first. Executive FAQ What is the difference between business discovery and requirements gathering? Traditional requirements gathering accepts a technology request as a given and logs the features users want. The Lumerai Executive Discovery Framework challenges the initial request, utilizing diagnostic frameworks to find the root business problem before evaluating any software options. Why do enterprise technology investments fail to deliver ROI? Gartner indicates that over 27% of cloud and software spend is completely wasted on unutilized
Governance Debt: The Hidden AI Liability Every Private Equity Investor Is Buying
For PE Operating Partners: the AI-era liability hiding inside every portfolio company’s tech stack, invisible to diligence until it’s already yours. By Rob Purks, Founder and Operating Partner, Lumerai Advisors The tech diligence came back clean. SOC 2 current, licenses reconciled, infrastructure spend in line with the model. On paper, the platform company was exactly what the thesis assumed – a solid operational base to build the value creation plan on top of. Four months into a hold, that gap stops being abstract. The automation initiative the plan counted on stalls – not because the AI model is bad, but because nobody can trust the data feeding it, no one owns the pipeline, and half the “adoption” the seller showed you was employees quietly using personal tools that leave the moment they do. That is Governance Debt. And by the time you see it, you already own it. The Blind Spot Standard Diligence Was Never Built to Find Governance Debt is the accumulated liability a company takes on when it deploys AI faster than it governs it: ungoverned pilots, shadow model usage, and unowned data pipelines that no one is accountable for. Like technical debt, it compounds quietly. Unlike technical debt, it does not show up in a code review or a cost audit – because it is behavioral, not architectural. That distinction is the whole problem for diligence. Standard tech due diligence is built to inspect things that are static and auditable: infrastructure, licenses, security posture, spend. You take a point-in-time snapshot and verify it. Governance Debt is neither static nor auditable that way. It is additive -accumulating every week through pilots that never got governed, models that never got owned, and AI tools employees adopted without anyone sanctioning them. A snapshot taken on diligence day captures none of it, because the debt lives in behavior and accountability gaps, not in the systems inventory. So the diligence report is not wrong. It is answering a different question than the one your return actually depends on. Why This Is an ROI Problem, Not a Risk Problem Risk language undersells it. This is not a tail risk that might cost you – it is a discount already priced into the return, whether or not it appears in your model. The mechanism is simple arithmetic against a finite clock. PitchBook and BCG put average private equity hold periods at roughly 5.8 to 7.1 years. Against that window, AI initiatives that require 12 to 18 months to reach production – if they reach it at all – consume a meaningful slice of the value creation runway before delivering a dollar. When the underlying data and governance foundation cannot support the build, that timeline does not hold. It slips, or the initiative is abandoned, and the efficiency gain your model underwrote never materializes. The base rates are sobering. MIT’s NANDA initiative, in its 2025 State of AI in Business study, found that roughly 95% of enterprise generative AI pilots deliver no measurable impact on the P&L – only about 5% achieve real revenue acceleration. That is the outcome distribution across an estimated $30 to $40 billion in enterprise AI investment. And critically, MIT traced the failures not to weak models but to enterprise conditions set before the model was ever built fragmented, ungoverned production data and no clear owner after deployment. Read that against your hold clock and the ROI logic is unavoidable. You are underwriting AI-driven gains on a foundation that, in 95% of cases, cannot deliver on the timeline your return requires. The Governance Debt is the reason the foundation cannot – and you paid for the gains at close. Four Questions Your Diligence Should Be Asking – and Usually Isn’t Governance Debt can be incorporated into diligence. It just requires questions aimed at ownership and behavior rather than inventory. Each of these maps to one of the failure conditions MIT identified – reframed as something you can ask before you close. Who owns each AI model and data pipeline after deployment? MIT found that a defining failure condition is that no one owns the model once it is live. Ask for the named accountable owner – a person, not a team – for every AI system and the data feeding it. If the answer is vague, the debt is already there. Can the data team define the top five KPIs and show they agree on each? Ask the data leaders to define the five metrics that matter most, show where each is sourced, and demonstrate that every function agrees on the definition. If that takes more than an afternoon or surfaces disagreement, the data estate is fragmented – and any AI deployed on it will amplify the fragmentation, not the value. What is the real inventory of AI tools in use – including the ones IT never sanctioned? MIT’s research documented a shadow AI economy in which employees at more than 90% of firms use personal AI tools even when official pilots fail. That usage looks like adoption in a demo and evaporates at close, because it was never owned or governed. Ask what employees are actually using, not what the company licensed. Was the workflow ever redesigned to use the AI output – or just bolted on? A pilot that produces output nobody’s process is built to act. Ask to see where an AI output changed a decision or a workflow in production. If the process still runs exactly as it did before, the pilot is not value – it is Governance Debt wearing a demo’s clothing. Reframe It as Underwriting Discipline Catching Governance Debt before close is not a compliance chore. It is an underwriting input. If the debt is real, it changes the price you should pay or the plan you should build – you can discount the entry, extend the timeline, or budget the remediation into the value creation plan from day one. Miss it, and you discover the discount after you have already paid full
The First 100 Days After Close
Why Technology Integration Determines Whether the Investment Thesis Survives. Lessons from post-acquisition technology integration, by Coy Wright, Lumerai Advisors Every acquisition has two closing dates. The one celebrated in the boardroom and the one that begins Monday morning when the systems must work together. Everyone gets excited about the diligence phase. AI-powered underwriting, data rooms parsed in hours instead of weeks, models that flag reserve risk before a human analyst finishes their coffee. It’s useful work, and it deserves the attention it gets. But diligence tells you what you’re buying. It doesn’t tell you what happens the Monday after close, when a field office in the Permian is still running production reports through a spreadsheet macro nobody has touched since 2019, the SCADA historian license responsible for operational production data is about to lapse, and the person who knows both systems just found out she’s “at risk” and is polishing her resume. The handoff, more than the diligence itself, is usually where deals actually lose value. For a PE-backed platform, this isn’t an IT problem sitting off to the side of the deal. It’s deal risk. The underwriting thesis assumed a certain pace of consolidation, a certain cost structure, a certain path to the next add-on. Every week the integration team spends firefighting instead of executing is a week that thesis quietly erodes, and it rarely shows up on a dashboard until it’s already expensive. Research on post-merger integration puts the failure rate at 70 to 90 percent of deals falling short of the value they were underwritten for, and the reasons named most often (incompatible systems, fragmented data, execution slower than planned) are exactly the ones that surface first in a technology stack. Executive Takeaways Technology integration is primarily an operational judgement challenge. Stabilization comes before modernization Institutional knowledge is often more valuable than documentation. AI should be deployed after data integrity is established, not before. The first 100 days determine whether deal value is realized or quietly eroded. Day one is about continuity, not transformation The instinct after close is to start modernizing immediately. New platform, new dashboards, new standards. Resist it for the first few weeks. The only job on day one is making sure nothing that currently works stops working: Production accounting keeps running Field data keeps flowing off the SCADA network Land and lease records stay accessible Payroll and AFE approvals don’t stall This means a real inventory before anything else, not the one sitting in the data room: every system actually touching production, land, HSE, and finance, who administers it, what the license and support terms are, and which of those systems have a single person who understands them well enough to keep them alive. That last category is the one that gets missed, and it’s the one that causes outages. A well-documented ERP is manageable. An undocumented historian configuration that lives in one engineer’s head is a ticking clock, especially if that engineer is uncertain about their future with the new owner. This lines up with what advisory firms like RSM have found studying post-merger integration broadly: the first 100 days is where quick, stabilizing wins need to happen, and where confusing that stabilization work with the long-term transformation plan is one of the more common ways integrations go sideways. Retention of institutional knowledge matters more than retention of headcount Every acquisition has some overlap to rationalize, and the pressure to move fast on org design is real. But the people who know why a particular well pad’s telemetry has been routed through a workaround for three years, or which spreadsheet is actually the source of truth versus which one is decorative, are not replaceable on a 100-day timeline. Identify them early, tell them directly why they matter, and keep them through at least one full reporting cycle before any staffing decisions touch their function. This is cheaper than the alternative, which is rebuilding tribal knowledge from scratch while also trying to close the books. Security comes before optimization A newly acquired asset is, for a window of time, the least defended part of the combined company: Credentials from the prior ownership are still active Vendor remote-access accounts haven’t been audited Nobody has yet mapped which of the acquired company’s systems can reach which of yours Access review and network segmentation belong in the first two weeks, not the first analysis of where AI could add value. This is unglamorous work and it rarely makes the integration deck, but it’s the difference between a clean 100 days and an incident report. Data architecture decisions get made whether you make them deliberately or not By day 60 or so, the temptation shifts from “keep it running” to “make it ours.” This is where the real architecture choice shows up: do you migrate the acquired company’s data into your existing platform, run both in parallel, or build a genuine integration layer between them. Each has a real cost. Migration is clean but risks losing context that lived in the old system’s structure, the tags, the naming conventions, the workarounds that encoded real operational knowledge even if they look messy. Parallel operation is fast but defers the actual integration problem and usually calcifies into permanent duplication if nobody forces the follow-through. An integration layer is the right long-term answer more often than either extreme, but it takes real engineering time that a 100-day plan rarely budgets for honestly. Underneath the plumbing question is a bigger one that most integration plans never name out loud: which system gets to be the source of judgment, not just the source of record, once the two organizations are running on shared data. Whoever’s platform wins that fight inherits the assumptions baked into it, good and bad. Get that decision right early and deliberately, and the rest of the technical integration follows a clear logic. Leave it to default to whichever system happened to be bigger at close, and you’ll spend the next two years discovering, one bad report at a
Your Operating Model Is the Real Legacy System
This is an expanded version of an article originally published on CIO.com. Reprinted with permission. © Foundry, Inc., 2026. All rights reserved. [https://www.cio.com/article/4168935/your-operating-model-is-the-real-legacy-system.html] Enterprise modernization isn’t failing because technology is outdated. It’s failing because the enterprise is still operating on a legacy decision model. For the past decade, enterprise modernization has been framed as a technology problem. Legacy systems. Technical debt. Monoliths that need to be broken apart and moved to the cloud. Those investments matter. But they rarely address the actual constraint. In many organizations, technology is capable of moving faster than the enterprise itself. The operating model has become the real legacy system. That framing may be convenient, but it is also incomplete. Technology has advanced dramatically. Cloud platforms, APIs, automation, AI, and modern engineering practices have given organizations unprecedented technical capability. Yet many enterprises continue to struggle to translate those investments into faster execution, better decisions, and measurable business outcomes. The reason is increasingly clear. In most organizations, technology isn’t the constraint. The operating model is. The Real Constraint Is Decision Latency You can see it in how decisions do or don’t move. A product team identifies an opportunity. It makes its way through architecture review, risk, finance, legal, compliance, and multiple layers of approval. Each step is rational on its own. Each exists for a legitimate reason. Collectively, however, they create latency. By the time a decision is made, the opportunity has changed. It’s worth pausing on that word legitimate. Most of this friction wasn’t installed by accident. Approval layers, architecture review boards, and risk sign-offs typically exist because an earlier version of the organization got burned: a compliance failure, a botched integration, a vendor risk nobody caught in time. Governance is, in effect, institutional memory. The problem isn’t that governance exists. It’s that most organizations never revisit which decisions actually warrant that level of scrutiny and which don’t, so a $50,000 vendor renewal and a $50 million platform migration move through the same gauntlet. This is rarely identified as the primary issue. It gets labeled as “complexity,” “organizational maturity,” or simply “the cost of operating at scale.” But the pattern is remarkably consistent. The system isn’t slow because the technology can’t move. It’s slow because the organization can’t decide, or, more precisely, hasn’t decided, which decisions deserve deliberation and which deserve delegation. Most modernization programs focus on replacing systems of record. They invest in platforms, APIs, cloud infrastructure, developer tooling, and application modernization. The expectation is that once the technology is updated, the business will naturally become faster and more adaptive. But the underlying decision structure remains unchanged. Funding is still annual and project-based. Authority is still fragmented across functions. Accountability is distributed in ways that make outcomes ambiguous. Risk is still evaluated in isolation rather than in the context of business intent. The organization integrates modern technology into its traditional operating model, resulting in predictable outcomes. While teams can move quickly in isolated pockets, overall speed does not improve, and enterprise-wide decisions continue to be delayed. As a result, the organization may seem more active, but it is not necessarily more effective. MIT’s Center for Information Systems Research (MIT CISR) has documented this fragmentation directly. Its research on componentized organizations found that as the digital economy accelerates the pace of business, companies need to redesign their people, processes, and technology to facilitate speed and identified rethinking accountability, not adding new layers of oversight, as the key lever (MIT CISR, “The Digital Operating Model: Building a Componentized Organization”). Organizations routinely measure modernization through cloud adoption, deployment frequency, application retirement, or engineering velocity. Far fewer measure how long it takes the enterprise to recognize an opportunity, make a cross-functional decision, establish clear ownership, and execute with confidence. McKinsey’s research on this exact gap found that only 37 percent of executives believe their organizations make decisions that are both fast and good and that speed and quality are not actually a trade-off, since faster decisions tend to be higher-quality ones (McKinsey, “Decision making in the age of urgency”). Increasingly, that decision cycle, not the technology stack itself, is becoming the true determinant of competitive advantage. Modern Technology Cannot Fix a Legacy Operating Model In practice, the operating model defines how work gets prioritized, how decisions are made, and how tradeoffs are resolved. It determines whether the organization can convert technology capability into business results. When that model is misaligned, even well-executed technology initiatives underdeliver. You can see this most clearly in cross-functional decisions. A customer experience initiative spans multiple systems, business units, and risk domains. Each group operates with its own objectives, constraints, funding model, and measures of success. No single decision-maker owns the tradeoffs across the entire initiative. As a result, decisions are escalated, deferred, or negotiated one function at a time. Nothing breaks. But very little moves with intent. The common response is to add another steering committee, another governance checkpoint, or another approval layer. Those changes may improve oversight, but they seldom improve throughput. The organization becomes more controlled without becoming more responsive. That’s not an argument against governance; it’s an argument for designed governance, calibrated to the actual risk and reversibility of each decision, rather than governance that grows by accretion every time something goes wrong. What it looks like when this actually gets fixed Allstate’s Claims division offers a concrete example of a company redesigning the decision layer rather than the technology layer. In 2021, Claims set out to simplify operations and deliver more frictionless digital experiences to customers. Rather than starting with a new platform, the organization redesigned decision rights: operational authority was pushed down to durable, cross-functional teams built around strategic objectives, replacing a traditional project-based way of working rooted in prescriptive annual plans with a continuous, iterative process (MIT CISR, “Allstate’s Digital Operating Model: Think Big, Act Small”). The technology stack Claims used wasn’t the differentiator. The decision architecture was. Teams that had previously waited on annual planning cycles and cross-functional sign-off could now resolve customer and business problems continuously
The modern CIO is no longer a technologist – they’re an architect of enterprise decisions.
As featured on CIO.com For much of the last three decades, the CIO role has been defined by delivery: platforms implemented, systems stabilized, programs executed. Success was measured in uptime, milestones, and budget adherence. When things went wrong, the diagnosis was familiar execution struggled, teams moved too slowly, or technology didn’t perform as expected. That framing is no longer sufficient. Most large-scale enterprise modernization efforts do not fail because teams cannot execute. They fail because the strategy and structural decisions were flawed from the start, and those flaws quietly harden long before delivery ever begins. In today’s enterprises, technology outcomes are rarely constrained by tools or talent. They are constrained by how clearly leaders define outcomes, how explicitly they make tradeoffs, and how intentionally they design the decision systems that translate strategy into action. That is why the modern CIO is no longer simply accountable for technology execution. They are increasingly accountable for the decision systems that determine whether transformation efforts ever translate into durable business value. I’ve come to believe this is the real evolution of the role. The modern CIO is no longer primarily a technologist. They are the architects of enterprise decisions. Where transformations actually fail I’ve been brought into many programs described as “behind schedule” or “underperforming delivery.” On the surface, they appear to be execution problems. Teams are busy. Roadmaps exist. Progress is tracked. Yet outcomes continue to disappoint. When you examine the root causes, the issues are rarely about effort or capability. They’re systemic. The same patterns appear again and again: When these conditions are met, delivery does not encounter random issues. It degrades predictably. Velocity slows. Dependencies multiply. Decision latency increases. Risk accumulates. Costs escalate. Credibility erodes. By the time leadership starts asking why execution is failing, the failure is already baked into the structure. This is where modernization efforts most often go wrong. Leaders declare a new strategy, but they leave the underlying decision architecture intact. Old governance models are asked to support new operating realities. Legacy funding structures are expected to enable adaptive delivery. Accountability remains fragmented while outcomes demand cohesion. Execution is then asked to compensate for design failure. It never does. Research published by McKinsey has consistently shown that organizational and operating model constraints, not technology, are among the primary reasons large transformations stall or reverse course. The more profound implication is often left unstated: if the constraint is structural, accelerating delivery without redesigning decision systems reveals the weakness more quickly. The CIO’s real leverage point Modern CIOs sit at a unique intersection of strategy, execution, and governance. They see where priorities collide, where accountability blurs, and where decisions stall under the weight of ambiguity. Historically, CIO influence was exercised through control of technology assets, budgets, platforms, architecture standards, and delivery capacity. Today, the CIO’s most consequential influence is exercised upstream of delivery, in how decisions are designed and governed. This is less visible work than a cloud migration or platform rollout, but far more determinative of outcomes. In practice, the CIO becomes responsible for orchestrating intelligence and ensuring that strategy is supported by structures capable of executing it. That requires deliberate design across several dimensions. Outcome clarity.What are we trying to achieve, and how will we know? If outcomes are vague, success becomes subjective, and tradeoffs become political. Decision rights.Who decides what, and at what altitude? When decision ownership is implicit, authority defaults to whoever can delay the longest. Tradeoff discipline.When priorities conflict, and they always do, how does the organization decide? What data is required? Who arbitrates? How long does it take? Without a mechanism, alignment becomes theater. Governance that enables movement.Governance should resolve ambiguity, not preserve it. Committees that exist primarily to distribute blame will reliably slow progress. Operating model alignment.Declaring “product teams” does not create product accountability. If funding, incentives, and authority remain project-based, the operating model is performative. Sequencing and capacity management.Every organization has finite change capacity. Strategy without sequencing diverts leadership attention and creates the illusion of resistance, when the real issue is design failure. When these elements are intentionally designed, something important happens. Execution becomes less dependent on heroics. Teams stop waiting for permission to solve obvious problems. Leaders stop relitigating the same tradeoffs. Delivery begins to resemble a stable operating rhythm instead of a constant escalation. This is the CIO’s real leverage point. Not tooling. Not velocity. But decision integrity. What boards increasingly expect from CIO leadership Boards and executive teams are beginning to recognize this shift, even if they don’t always articulate it in architectural terms. They rarely ask about specific platforms or methodologies. Instead, the questions sound like: These are not technical questions. They are governance and decision-design questions. Boards understand that digital transformation is no longer a discrete program. It is an ongoing operating reality. As a result, they are increasingly looking to the CIO not just for delivery competence but also for judgment, the ability to translate strategy into repeatable, governable execution. MIT Sloan Management Review has written extensively about the importance of explicitly designing decision rights and governance structures to sustain transformation outcomes. Organizations that do this well tend to move faster with less friction because ambiguity is no longer the default operating condition. This is why the modern CIO is increasingly viewed as a peer enterprise leader rather than a functional specialist. Boards do not need another executive who can “run IT.” They need an executive who can shape how the enterprise changes without losing control. The modern CIO mandate None of this diminishes the importance of technical competence. Modern CIOs must still understand architecture, platforms, data, and security deeply. In many industries, those responsibilities are existential. But those capabilities are now table stakes. The differentiator is whether the CIO can see and redesign the invisible systems that determine how work actually gets done: decision rights, governance structures, escalation paths, incentives, and accountability. In organizations where transformation sticks, the CIO has shifted from being the steward of technology to being the steward of decision integrity. They