Digital transformation without the theater

Why I’m writing about a term I banned

My own style guide bans the phrase “digital transformation.” It sits on a short list alongside “game-changing” and “synergy” — words that tell the reader they are about to receive marketing rather than engineering. I have kept that ban for years and I am not lifting it. This article is the exception that explains the rule.

Here is the problem with simply refusing to say the words: the words control budgets. Enormous ones. When a board approves a nine-figure program, the line item does not say “replace the claims platform and fix the change process that made it unmaintainable.” It says digital transformation. The engineers who roll their eyes and leave the room concede the program’s shape to people who will never carry a pager for the result — and then inherit whatever gets built.

So the useful move is not to mock the phrase. It is to take it apart, understand what it actually gets funded to mean, and be precise about the difference between the programs that work and the ones that produce a rebranded version of the same problems. I have spent years on both sides of this: leading technical direction for enterprise accounts at DXC, and now as an enterprise architect in an internal IT organization, where the results of past programs are not slideware. They are the systems my group operates.

What the phrase actually gets funded to mean

Strip away the language and most funded transformation programs contain some mix of five concrete activities. It is worth naming them, because each one is legitimate engineering work when scoped honestly — and each one fails in a characteristic way when bundled under a banner.

What’s funded	The legitimate version	The failure mode
Legacy system replacement	Retire a system for lifecycle, cost, or risk reasons	Rebuild the same system on newer technology, keep both running
Cloud migration	Re-platform workloads where the deployment model fits	Lift-and-shift everything, discover the bill, repatriate quietly
New customer-facing software	Build products the business demonstrably needs	A new front end wired to the same brittle core, now with more layers
Data platform consolidation	Fix ownership and quality, then centralize	A third data platform added to the two that were never decommissioned
”Ways of working” change	Change funding, decision rights, and team boundaries	Rename project managers, run stand-ups, change nothing structural

Notice what the money buys in every row: things. Platforms, licenses, migrations, software. The right-hand column exists because things are purchasable and organizational change is not, so programs drift toward the part that can be put on an invoice.

That drift has a measurable outcome. McKinsey’s research puts the share of transformations that succeed at less than 30 percent; BCG’s figure is similar, with roughly 70 percent falling short of their objectives. I treat consulting-firm survey numbers with appropriate suspicion — these firms also sell transformation services, which is its own kind of funny — but the direction matches what I have seen inside enterprises for two decades. Most of these programs do not deliver what the business case promised. The interesting question is the mechanism.

The operating model is the system

The mechanism is almost boring once you see it.

An organization’s systems are not an accident. The tangled integration layer, the ERP customized beyond recognition, the four overlapping CRMs — each of these is the output of an operating model: how the organization funds work, who gets to make decisions, where the team boundaries sit, what people are measured on. Conway’s law is usually quoted about software architecture mirroring communication structure, but the general form is broader and harsher. The organization ships its org chart, its budget process, and its incentives — in every system, every time.

Now run the standard program. You replace the systems. You leave the funding model, decision rights, team boundaries, and incentives exactly where they were.

The machine that produced the legacy mess is still running. You have fed it newer inputs.

This is why the five-year-later state of so many transformations looks eerily familiar: the new platform has accumulated its own layer of exceptions and point-to-point integrations, the old systems were never fully decommissioned because the last 20 percent of migration was hard and the program budget ended, and the run organization — which was not in the room — is operating a strictly larger estate than before. The program added a generation of technology without subtracting one.

HBR made this argument in 2019 under the title “Digital Transformation Is Not About Technology,” and it was correct, but I want to sharpen it from an engineering seat: the operating model is the system. The software is a projection of it. Modernizing the projection while preserving the source is not a partial success. It is the specific, predictable way these programs fail, and it is why the failure rate has been stable for a decade while the technologies being deployed have changed completely.

What real modernization looks like

Real modernization is led — in design authority, not necessarily in project management — by people who must operate the result. That single property predicts more than any methodology choice, because it changes what the program optimizes for. People who leave at go-live optimize for go-live. People who stay optimize for year three.

From the programs I have watched succeed, and the ones I have helped run, the pattern looks like this:

It starts from operational pain, not aspiration. The honest inventory question is not “what could we become?” but “what does it cost us to run what we have, where does it break, and what can we no longer hire for?” A mainframe billing system might be the most reliable thing in the estate — in which case it stays, and the program’s energy goes where the pain actually is. Modernization sequenced by lifecycle and risk is slower to announce and much faster to finish.

Decommissioning is a first-class deliverable. A real program has a kill list with dates, owners, and budget for the unglamorous last mile: the final data migration, the interface nobody documented, the two downstream consumers everyone forgot. If the program plan only adds systems, you are not looking at modernization. You are looking at accumulation with a press release.

The operating model changes land first or alongside — never “later.” If team boundaries, funding, or decision rights need to change for the new architecture to survive, that change happens while there is still program leverage to force it. “We’ll reorganize after the migration” means never, and everyone in the room knows it. This is also where explicit decision-making machinery earns its keep: the one-way-door choices in these programs are rarely technology selections. They are ownership and boundary decisions wearing technology costumes.

The steps are reversible where possible, and honest where not. Strangler patterns, parallel runs, incremental cutovers — not because incrementalism is fashionable, but because every big-bang cutover is a bet that your understanding of a decades-old system is complete. It never is. I have watched enough plant-floor and data-center cutovers to know that the undocumented dependency always announces itself at the worst possible hour.

Run cost and operability are success metrics from day one. Not “workloads migrated.” Not “percent complete.” The questions that matter: did change lead time drop, did the incident rate drop, did run cost per unit of business actually go down once both estates are counted, can the team that operates this staff an on-call rotation without heroics. These numbers are harder to produce than activity metrics, which is exactly why theater avoids them.

None of this requires abandoning large programs or big budgets. It requires aiming them at the operating model and the estate simultaneously, and accepting that the second half of the word “transformation” was always about the organization, not the software.

The anti-pattern catalog

Every failed program I have seen up close was assembled from a small, recurring parts bin. In the spirit of a field guide:

The rebranded lift-and-shift. Everything moves to cloud as-is; the program declares victory on migration count. Two years later the economics force a quiet re-architecture or a quieter repatriation. Cloud is a deployment model with real strengths — elasticity, managed services, speed of provisioning. Copying virtual machines into someone else’s data center at retail prices exercises none of them.

The innovation lab. A small, colocated, hoodie-friendly team is exempted from all the processes that make delivery slow, and produces impressive demos precisely because it is exempt. Nothing it builds can survive contact with the core estate, because the core estate’s constraints were the actual problem, and the lab was designed to avoid rather than fix them. The lab’s real output is evidence that the constraints are organizational — evidence the organization then ignores.

Two-speed IT. The formalized version of the lab: a fast “digital” layer on top of a slow “legacy” layer, with an API gateway as the demilitarized zone. The seam becomes the most contested, fragile, and politically radioactive part of the architecture. You have not created two speeds. You have created a queue with better branding, and the people assigned to the slow side heard exactly what you called them.

The veneer. A new mobile app or portal on an unchanged core. Customers tap a modern interface; the request lands in the same overnight batch job it always did. The veneer buys a year of good demos and then the core’s limitations reassert themselves through it — now with an extra layer to debug at 2 AM.

The transformation office that outlives the transformation. A program office is scaffolding. When it becomes a permanent org unit with its own headcount, dashboards, and gravitational pull, it starts to need the transformation to continue existing — and programs that need to continue never conclude. Scaffolding that becomes load-bearing is a defect in buildings and in organizations.

The metric mirage. Success reported in activity: workloads migrated, APIs published, story points delivered, “adoption” of internal platforms that were made mandatory. Every one of these can trend up while the business outcome trends down. If a program’s dashboard contains no number that could possibly embarrass it, the dashboard is an instrument of the theater.

The common ancestor of all six: each lets the organization purchase the appearance of change while deferring the operating-model work that change actually requires. They are not stupid mistakes. They are locally rational moves inside an unchanged incentive structure — which is the whole point.

Telling a real program from theater

If you are an engineer, an architect, or an executive being asked to fund, join, or bless one of these programs, the diagnostic questions are short and they are all operational:

1. Who operates the result, and where do they sit in the program? Design authority or town-hall audience? If the run organization first sees the architecture at handover, the program has already chosen its failure mode.
2. Show me the kill list. Which systems are decommissioned, by when, with whose budget? No kill list, no modernization — only addition.
3. What changes besides the technology? Funding model, team boundaries, decision rights — anything? If the answer is a slide about culture, the operating model survives intact, and so does its output.
4. What would falsify the program’s success? Real programs can name the operational numbers that must move — lead time, incident rate, run cost — and report them even when they are unflattering. Theater reports momentum.
5. What happens in year three? Who maintains this, on what roadmap, with what lifecycle plan and what run budget, after the program brand is retired? Silence here is an answer.
6. Is anything reversible? Where are the parallel runs, the fallback points, the strangler seams? A plan with no undo anywhere is not confidence. It is a bet placed with someone else’s operations.

Six questions, maybe twenty minutes of any steering meeting. Programs that survive them exist — I have worked on them — and they tend to share a suspicious property: they rarely call themselves transformations. They have narrower names, because they have narrower, honest scopes: retire these platforms, collapse these data stores, restructure these teams around these services, and prove it with these numbers.

The word will change; the failure mode won’t

“Digital transformation” is already aging out of fashion, and the same budgets are being rebadged — AI transformation is the current favorite, and my own group’s work in AI enablement puts me close enough to watch the pattern attempt to repeat in real time. The vocabulary rotates every decade. The failure mode does not, because it was never about the technology being deployed. It is what happens whenever an organization tries to buy a new projection of itself while keeping the projector.

The engineering position is neither cynicism nor evangelism. The money behind these programs is real, the legacy pain is real, and modernization done honestly is some of the highest-leverage work in the industry. The discipline is to keep asking the operational questions — who runs it, what gets retired, what actually changes, how will we know — through however many rounds of renaming the industry has left in it.

Labels will keep transforming. The systems only change when the organization that produces them does.