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
The Architecture of Authority: Why AI Is Reshaping Enterprise Leadership
For decades, the enterprise power dynamic was absolute and unchallenged: systems provided the data, and humans provided the judgment. Organizations termed themselves “data-driven” if an executive glanced at a dashboard before making a call, but the dashboard was a passive participant. It never actually changed who held the steering wheel or who was accountable when things went wrong. Technology was a silent partner—a repository of record that executed instructions only after the human “go” signal was given. That boundary has not just blurred; it is being erased. We are moving from an era of “Systems of Record” to an era of “Systems of Action,” and most organizations are fundamentally unprepared for the shift in authority that follows. The challenge isn’t the technology itself; it’s that we are attempting to run 21st-century intelligence on top of 20th-century governance. The End of the Dashboard Era The newest generation of AI has moved beyond recommending a course of action to initiate it. This is the critical pivot point where “support” becomes “participation”. In many modern enterprise stacks, the machine is already making high-stakes calls in milliseconds—isolating network devices, blocking multi-million-dollar transactions, or rerouting global shipments—often before a human analyst even sees an alert. When a system functions at this speed, the traditional “human-in-the-loop” model becomes a bottleneck or, in some cases, a myth. At this point, the system is no longer informing a decision; it is determining the outcome. This creates an immediate crisis for traditional governance. Most corporate frameworks are built on a 1990s-era assumption: that humans make judgments and systems implement them. When the system itself begins to determine what happens next, the separation between decision-making and execution—the very foundation of corporate oversight—becomes impossible to maintain. The Conflict of Logic vs. Intuition The most overlooked risk in AI implementation isn’t a technical failure—it’s the moment of disagreement. What happens when a machine’s data-driven recommendation contradicts a veteran manager’s years of intuition? In a traditional hierarchy, the senior leader wins by default. But in an AI-integrated environment, that “win” might come at the cost of operational speed or accuracy. Conversely, if the machine wins, who owns the liability? In regulated industries, these aren’t just philosophical debates; they carry significant legal and operational consequences. A system that blocks a transaction or flags a customer is taking an action that has traditionally required a signature and a clear chain of custody. If we haven’t designed the “Decision Architecture” to handle these conflicts, we aren’t innovating; we are simply creating a new type of organizational chaos. Decision Architecture: The Invisible Layer As decisions begin to emerge from within the technology itself, the structure of decision-making becomes an architectural question, not just a management one. This is the concept of Decision Architecture: the intentional design of how authority flows between people and software. Historically, authority evolved through hierarchy: information flowed up, and decisions moved back down through operational silos. Core platforms, like ERP systems, were built specifically to reinforce this “step-by-step” approval logic. These designs work perfectly when systems are executing predictable transactions. But they fail when an intelligent layer begins to evaluate context and trigger responses across those same processes. The friction we are seeing today isn’t a technical glitch; it is an organizational collision. Decisions are bypassing the management chain entirely and emerging from the “intelligence layer” of the stack. Without dedicated architecture to govern this flow, the CIO is no longer managing a technical stack—they are managing a fragmented, automated bureaucracy. The Danger of Accidental Authority Perhaps the greatest risk to the modern enterprise is “Accidental Authority.” This happens when AI capabilities are developed in isolated silos—one team building a fraud model, another implementing automated customer service, and a third deploying AI-driven cybersecurity. Each of these teams is essentially handing over “micro-slices” of corporate authority to different algorithms, often without a central registry of what decisions have been automated. Without coordinated architecture, you wake up to a fragmented environment where your systems have inconsistent levels of authority, lack oversight, and offer no clear way to override them when they go off the rails. We must stop building AI as a series of features and start building it as a unified decision-making ecosystem. The Practitioner’s Mandate: Designing for Authority For the modern CIO, the challenge is no longer the deployment of AI; it is the management of authority. The most dangerous path is allowing this authority to emerge accidentally, hidden within isolated teams or embedded deep inside individual platforms. To lead this transition, technology leaders must move toward three strategic imperatives: From Tool to Participant The organizations that survive this shift will be the ones that stop viewing AI as just another tool in the shed and start viewing it as an active participant in the business. The role of the leader is no longer to “sign off” on the data, but to architect the logic that governs the machine’s behavior. Success in the AI era won’t belong to the companies with the fastest algorithms or the biggest data lakes. It will belong to the leaders who treat decision-making as something that must be intentionally designed, rather than something that happens by accident as a byproduct of new technology. Frequently Asked Questions How is AI changing corporate hierarchy? Artificial intelligence is reducing the need for organizations to rely solely on traditional management layers to coordinate work and distribute information. As AI systems become capable of analyzing data, recommending actions, and executing routine decisions, authority increasingly shifts from information control to judgment, governance, and accountability. Organizations will need to redesign leadership structures to ensure humans remain responsible for strategic direction and oversight. What is the Architecture of Authority? The Architecture of Authority is the framework that defines how decisions are made, delegated, governed, and monitored within an organization. In the age of AI, it extends beyond traditional reporting structures to include intelligent systems that participate in decision-making. A well-designed Architecture of Authority ensures AI augments human judgment without weakening accountability or governance. Will AI
The Tech Leaders First 100 Days
The first 100 days of a new IT leadership role are a critical window. This playbook breaks down how to assess your team, identify the right opportunities, review the portfolio, and build a strategy that earns trust and sets the stage for lasting impact. You have been handed the keys. New title, new organization, new expectations, and a clock already running. Whether you are stepping into a CIO role for the first time or taking the helm of a technology function at a company you are still learning, the first 100 days are crucial. Those first 100 days are all about learning what the organization needs most, and positioning yourself and your team to deliver it. This is not a sprint, it is a structured reconnaissance. The leaders who move fastest in their first months are often the ones who stumble hardest by month six. The ones who invest early in listening, assessing, and aligning, deliberately and without ego, are the ones who build the foundation for durable change. The first 100 days are not about what you know. They are about learning what the organization most needs, and earning the right to change it. Executive Takeaways The Lumerai CIO First 100 Days Framework Phase Focus Objective Days 1-30 Listen & Learn Understand the organization before making changes Days 31-60 Assess & Prioritize Evaluate team, portfolio, and opportunities Days 61-90 Align & Act Build stakeholder alignment and begin execution Days 91-100 Commit & Communicate Finalize roadmap and establish accountability The most successful CIOs resist the urge to prove themselves immediately. Instead, they follow a structured progression from understanding to assessment, alignment, and execution. Section 1: Assessing Team Maturity Your team is your first and most important operating context. The tech team’s maturity is critical and that team must provide near flawless execution before you have earned the right to drive the organization where it needs to go. Now is the time to engage them and fairly assess the current maturity and the path to improve. You need an honest picture of where it actually stands, not where it thinks it stands, and not where your predecessor reported it to be. The Lumerai Team Maturity Model Team maturity is not simply a question of technical skill. It encompasses four overlapping dimensions: A technically brilliant team that cannot align to business priorities is just as limiting as a business-savvy team that cannot execute. The most capable IT organizations are both. Team maturity is a stronger predictor of transformation success than technical capability alone. How to Conduct the Assessment Resist the temptation to deploy a formal survey. The data gathered through direct conversation in the first 30 days is richer and more revealing than any survey. Structure your early 1:1s around a consistent set of open questions: Suggested Questions for Early 1:1s: Listen for patterns across these conversations. Recurring themes about process gaps, leadership behaviors, budget constraints, or talent deficits are more diagnostic than any individual answer. Maturity Levels: A Practical Framework Once you have completed your listening tour, work with your direct reports to score the organization across the maturity levels. The goal is not to render a verdict, it is to create a shared baseline that informs your strategy. Your first 100 days should give you enough data to know where you are and your first year’s strategy should have a clear line of sight to where you are going. Section 2: Identifying Strategic Needs and Opportunities Every new leader’s arrival creates an inflection point where people are more open to change. Your job in the first 100 days is to identify the best opportunities before the window closes and the organization settles back into its existing patterns. Quick Wins versus Long-Term Plays Not all opportunities are created equal. One of the most common mistakes new IT leaders make is chasing a large, visible transformation initiative in their first months before they have earned the trust or gathered the context to sustain it. A far more durable approach is to sequence deliberately: Where to Look for Opportunities The highest-value opportunities tend to cluster in a small number of recurring patterns: The highest-leverage opportunities are rarely technical. They are cultural, the invisible friction that slows decisions, creates rework, and keeps good people from doing their best work. Section 3: Navigating Your Own Assimilation The most overlooked dimension of a new leader’s first 100 days is internal. How you show up, how quickly you build trust, and how effectively you read the political and cultural landscape of your new organization will determine how much of your actual agenda you get to execute. The Assimilation Traps Experienced leaders fall into predictable patterns when they are new. Recognizing them in advance is the first step to avoiding them: The Four Assimilation Traps to Avoid: With your new team, a facilitated new leadership assimilation exercise can dramatically speed up the “getting to know each other” process. Warning Signs Your First 100 Days Are Going Off Track Building Trust Across Stakeholder Groups Your stakeholder map in the first 100 days should include at least four distinct constituencies, each with different needs, different definitions of success, and different levels of trust to build: The Working and Listening Tour In your first 30 days, conduct a structured listening tour across the organization. This is not a performance review of the IT function, it is your chance to understand the business through the eyes of the people it serves. Walk the walk and learn how the business operates and how technology either supports or hinders those processes. Work in a plant, warehouse, store of function to learn the end to end of the business. What you will learn will shape every strategic decision you make in the coming months. Section 4: Conducting a budget and ecosystem review A portfolio review is one of the most important and most frequently skipped activities in a new leader’s first 100 days. It is the process of systematically inventorying and evaluating every active