Because every transformation that moved fast and skipped the change work added to the balance. AI is the moment the bill comes due.
There’s a finding from Deloitte’s 2024 technology leadership research that deserves more attention than it’s received.
81% of technology leaders say they’re confident in their organization’s ability to scale AI.
75% say their operating model must fundamentally change to do it.
Most commentators have treated this as a contradiction — a gap between confidence and readiness that leaders need to close before they proceed. That’s the wrong read.
It’s not a contradiction. It’s a diagnosis.
What these numbers are describing is the accumulated weight of a specific organizational liability that has been building for years across every enterprise that has moved fast on technology and slow on the human side of it. Every ERP that went live without genuine adoption. Every cloud migration that automated the infrastructure without redesigning the processes running on it. Every digital transformation that delivered the system and skipped the behavior change.
What’s accumulated inside these organizations is what I call change debt — the liability that builds every time technology ambitions advance faster than the people, processes, and operating model can follow.
And AI is the moment the bill comes due.
What change debt actually is
Technical debt is a concept software engineers know well. It’s the accumulated cost of shortcuts — the quick fixes, the patches, the “we’ll come back to this properly later” decisions that look manageable in the short run and quietly make everything harder, slower, and more expensive as they compound. Technical debt is invisible on the balance sheet. It shows up as systems that break under pressure, development velocity that slows unexpectedly, and codebases that eventually require expensive rearchitecting to salvage.
Change debt works the same way — but on the human side of transformation.
It accumulates every time an organization implements a technology change without doing the full work of helping people understand what it means for how they work, who owns which decisions, what good performance looks like in the new model, and how to succeed in an environment that operates differently than the one they were hired into.
Each of those incomplete transformations leaves a residue. Not the dramatic residue of failed projects — those at least get attention and resources. The quiet residue of transformations that technically succeeded and humanly didn’t. Systems that are live and underutilized. Processes that were redesigned on paper and unchanged in practice. Operating models that describe one reality and employees who are navigating a different one.
That residue accumulates. It compounds. And it creates the specific organizational condition that the Deloitte numbers are describing — where leaders are confident in their technology capability and simultaneously aware that their organization isn’t structured to absorb what that technology requires.
That awareness — uncomfortable, honest, and increasingly urgent — is the recognition of change debt.
How change debt accumulates in technology organizations
Change debt doesn’t build through failure. It builds through a specific pattern of success.
The pattern looks like this: a technology program delivers on time, on budget, and to technical specification. The system works. The integration is clean. The deployment is smooth. The CIO presents a successful go-live to the board. Everyone moves on to the next initiative.
Six months later, adoption is at sixty percent of target. The old process is still running in parallel with the new one in two of the five functions the system was supposed to transform. The efficiency gains projected in the business case haven’t materialized because the workflow changes required to produce them were never fully adopted. A new initiative is being scoped.
The technical debt of that program is zero. The change debt is significant — and it’s been added to the balance without appearing anywhere in the program’s success metrics.
This pattern repeats across every major technology initiative the organization runs. ERP implementations. Cloud migrations. Data platform builds. Process automation programs. Each one delivered technically, each one underdelivered humanly, each one adding to the change debt balance without anyone tracking the accumulation.
Change debt builds specifically in five places:
Adoption gaps that were never closed. Systems that went live at sixty or seventy percent adoption and stayed there — because the program moved on and the reinforcement that would have driven full adoption never materialized.
Operating model misalignments that were never resolved. New technology that was implemented on top of processes and decision structures designed for the old one — producing friction, workarounds, and the organizational inefficiency of running two operating models simultaneously.
Leadership capability deficits that were never addressed. Leaders who were expected to lead their teams through continuous technology-driven change without the communication capability, the change management understanding, or the organizational permission to do it well.
Narrative fragmentation that was never repaired. Organizations where different functions have different stories about what the technology transformation means, why it’s happening, and what success looks like — because the shared narrative was never designed at the leadership level before it cascaded.
Trust deficits accumulated through poor communication. Organizations where the pattern of technology communication — announcing change, under-communicating implications, moving on before adoption is confirmed — has trained employees to be skeptical of the next technology initiative before it’s announced.
Each of these accumulations is a form of change debt. Each one makes the next transformation harder. And each one adds to the organizational weight that AI adoption — with its requirement for genuine operating model change — is now landing on.
Why AI is different — and why the debt matters now
Previous technology transformations could be managed with significant change debt on the balance. ERP implementations, cloud migrations, data platform builds — these required behavior change, but the behavior change was largely confined to specific workflows and specific functions. An employee who didn’t fully adopt the new system could often find a workaround. A function that ran parallel processes could often maintain performance. The debt was real but containable.
AI is not containable in the same way.
The operating model change that AI requires isn’t additive — it’s structural. It doesn’t ask organizations to add a new tool to an existing workflow. It asks them to redesign the workflow itself — the decision rights, the human-machine boundaries, the accountability structures, the definition of what human expertise is for when AI handles the analytical and administrative layers.
That redesign requires something that all the accumulated change debt has been quietly eroding: organizational capacity for genuine, sustained behavior change at scale.
Organizations with significant change debt — organizations that have been implementing technology without doing the change work — have been training their employees, leaders, and cultures in a specific direction. Technology is something that happens to us. Operating models are announced, not co-created. Communication about transformation is managed, not honest. Adoption is declared, not confirmed.
When AI arrives requiring genuine operating model transformation — requiring employees to change not just how they use a tool but how they think about their role, their expertise, and their relationship to the work — it encounters that trained expectation. And the trained expectation resists. Not out of change-aversion. Out of accumulated experience that technology transformations don’t actually change how we work. They just add something new to what we already do.
That resistance is the change debt coming due.
The CIO mandate has been restructured
The most significant implication of change debt in technology organizations is what it means for the CIO role.
Running reliable systems used to be the job. Keeping the lights on, delivering major technology programs on time and on budget, managing technical risk. These were the metrics. This was the mandate.
That mandate has been restructured.
The CIO’s job now is building an organization that can absorb continuous transformation — not delivering individual technology programs but developing the organizational capability to move through technology-driven change without accumulating the debt that makes the next transformation harder than the last one.
That’s a fundamentally different job. It requires a different set of capabilities — not just technology leadership but organizational leadership. Not just program delivery but change architecture. Not just system implementation but the communication, alignment, and behavioral design that determines whether system implementation produces organizational capability or just technical functionality.
The CIOs navigating this well have already made this shift. They’ve stopped treating change management as a workstream inside the technology program — a box to check, a budget line for training and communications, a function that gets called in when adoption is stalling. They’ve started treating it as the operating condition the technology program runs on.
Change management, in this framing, is not what you do after the system is built. It’s the environment in which the system either gets adopted or doesn’t. It’s the narrative architecture that determines whether employees understand what the technology is for. It’s the leadership communication that determines whether managers feel equipped to cascade the transformation or hesitant to engage with it. It’s the reinforcement design that determines whether behavior change holds after go-live or quietly reverts to the familiar.
When those elements are absent — when change management is the afterthought rather than the foundation — the technology works and the transformation doesn’t. The debt accumulates. And the next program starts from a harder position than the last one.
What paying down change debt actually requires
Change debt doesn’t get paid down through a single initiative or a new change management methodology. It gets paid down through a sustained shift in how technology transformation is designed, resourced, and measured.
Redefining success metrics for technology programs.
Programs measured only on technical delivery — on-time, on-budget, to-specification — will continue to produce technical success and human underdelivery. The metrics that capture change debt are behavioral: adoption rates at ninety days and one hundred eighty days post go-live, not just at go-live. Decision-making consistency across functions operating in the new model. The frequency and nature of workarounds. The extent to which informal processes are running parallel to official ones.
These metrics don’t require new technology. They require organizational permission to measure something other than what’s easiest to count.
Building communication capability at the leadership level.
The single highest-leverage investment available to a CIO managing a change debt balance is communication capability in their technology leadership team — not in a communications function that produces content for them, but in the leaders themselves. Leaders who can explain why a technology change is happening in terms that make personal sense to the people being asked to change. Leaders who can acknowledge uncertainty honestly rather than projecting confidence they don’t have. Leaders who maintain consistent narrative across functions and leadership levels rather than improvising differently in each context. (For the leadership communication skills that make this possible, read The Calm Communicator.)
Designing for behavior change from the start, not the finish.
Change debt accumulates when behavior change is treated as the downstream output of a technology program rather than its primary design objective. Programs designed around technical milestones — design complete, build complete, test complete, go-live — implicitly deprioritize the human milestones: narrative defined, managers equipped, adoption reinforced, behavior sustained.
Redesigning technology programs around human milestones alongside technical ones is the structural intervention that prevents change debt from accumulating in the first place. It requires different program governance, different resource allocation, and different definitions of what “complete” means. But it produces something that technical-milestone programs rarely do: a technology investment that generates the operational value it was designed to generate because the people using it have genuinely changed how they work. (For the full framework for this approach, read Why Training Isn’t Enough — You Need Reinforcement.)
Addressing the accumulated debt before the next program begins.
The most expensive change debt intervention is the one that gets done in the middle of an AI adoption program when resistance is already entrenched. The least expensive is the one done before the program starts — a deliberate audit of what previous transformations left behind, what operating model misalignments are still running, what adoption gaps were declared closed and weren’t, and what leadership communication patterns have trained employees to expect from technology change.
That audit is not a delay. It’s the diagnostic that determines whether the next program starts from a manageable position or a compounded one.
What this looks like in practice
I worked with a technology leadership team preparing to launch an AI-enabled process redesign across their operations function. The technical design was strong. The business case was clear. The program team was experienced.
When we ran the change readiness diagnostic, the change debt picture was significant. The previous ERP implementation — three years earlier — had officially closed at seventy-two percent adoption. The remaining twenty-eight percent had been categorized as “edge cases” and deprioritized. In practice, they represented the most complex and highest-volume transaction types in the function. Three years later, those transaction types were still being processed in the legacy system — in parallel with the ERP, using a workaround that had been in place so long it had become the official process.
The operating model misalignment from that program was the foundation the AI redesign was being built on. The AI was designed to optimize a process that half the function wasn’t fully using.
We paused the program design phase and spent six weeks on change debt remediation — not reopening the ERP implementation, but closing the adoption gap that had been left open and aligning the operating model across the function before introducing another layer of transformation.
The AI program launched eight weeks later than originally scheduled. It achieved ninety-one percent adoption at one hundred twenty days — the highest adoption rate the organization had recorded for any technology program in the previous decade.
The delay paid for itself in the first quarter of operation.
Change debt is expensive to ignore. It’s significantly less expensive to address.
Final thought
The Deloitte numbers — 81% confidence in scaling AI, 75% awareness that the operating model must change — are not a contradiction.
They’re the precise description of an organization that knows where it’s going and is only beginning to reckon with what it’s carrying.
Change debt is real. It accumulates quietly. It compounds reliably. And it comes due at exactly the moments — like AI adoption — when organizational transformation capacity is most urgently required.
The CIOs and technology leaders who will navigate this period successfully are not the ones with the best technology strategy. They’re the ones who understand that technology strategy and change strategy are not separate disciplines — and that the debt accumulated by treating them as separate is the liability that will determine whether AI delivers what the business case projected or becomes the latest entry in the change debt ledger.
The bill is here.
How it gets paid depends on whether leaders treat change management as a program workstream or an organizational capability.
Only one of those answers closes the debt.
FAQs: Change debt in technology transformations
Change debt is the liability that builds every time technology ambitions advance faster than the people, processes, and operating model can follow. It accumulates through technology programs that technically succeed but humanly underdeliver — where systems go live, adoption gaps remain, operating model misalignments persist, and behavior change doesn’t fully occur. Like technical debt, it compounds over time, making each subsequent transformation harder and more expensive than the last.
Because AI requires genuine operating model transformation — not just adding a new tool to an existing workflow but redesigning decision rights, human-machine boundaries, accountability structures, and the definition of what human expertise is for. That redesign requires organizational capacity for sustained behavior change at scale — exactly the capacity that accumulated change debt has been quietly eroding through years of technology programs that skipped the change work.
Through a specific pattern of technical success and human underdelivery. Programs that deliver on time, on budget, and to specification — but leave adoption gaps unclosed, operating model misalignments unresolved, and behavioral changes undone. Each program adds to the balance. The debt shows up as parallel processes, workarounds, inconsistent adoption, and organizations that have invested heavily in technology and haven’t captured the operational value those investments were designed to generate.
It restructures it. Running reliable systems and delivering technology programs used to be the core mandate. The CIO’s job now is building an organization that can absorb continuous transformation — which requires treating change management not as a workstream inside the technology program but as the operating condition the technology program runs on. CIOs who have made this shift are producing materially better adoption outcomes and accumulating significantly less change debt with each program.
Through behavioral indicators rather than technical metrics. Adoption rates at ninety and one hundred eighty days post go-live, not just at go-live. The frequency and nature of workarounds. The extent to which parallel processes are running alongside official ones. Decision-making consistency across functions. Leadership communication consistency across levels. These signals reveal the accumulated human underdelivery that change debt represents — and they’re visible to anyone who knows where to look.
By addressing it structurally rather than programmatically. Redefining technology program success metrics to include behavioral outcomes alongside technical ones. Building communication capability in technology leadership teams. Designing programs around human milestones alongside technical ones from the start. And conducting deliberate change debt audits before major programs begin — identifying what previous transformations left behind before adding another layer of transformation on top of it.
By providing the communication and change architecture that prevents change debt from accumulating in the first place. The diagnose principle identifies where adoption gaps, operating model misalignments, and behavior change deficits are concentrated. The define principle builds the shared narrative that gives technology transformation human meaning — answering why the change is happening and what it means for the people being asked to change. The design principle creates the rhythm that sustains behavior change through the full adoption curve rather than ending at go-live. The deliver principle ensures communication addresses the emotional and identity layers that determine whether change lands or doesn’t. And the measure principle tracks behavioral adoption rather than technical deployment — the metrics that reveal whether change debt is accumulating or being paid down.
Ana Magana is a change management and communications strategist based in Calgary, Alberta. She helps technology leaders build the change architecture that prevents change debt from accumulating — through The Clarity Framework™.
Leading an AI transformation and concerned about your organization’s change debt balance? Work with Ana →
Related reading: Why ERP Projects Fail — And How Communication Determines the Outcome → Why Training Isn’t Enough — You Need Reinforcement → How to Create an ERP Communications Plan That Actually Works →