What You Owe Before You Delegate
I have been brought in after the lift-and-shift more than once. The pattern is consistent: a new system is in place, the migration is complete, and leadership is frustrated because the problems they expected to leave behind came with them. The new system is running on the same assumptions, the same data hygiene (or lack thereof), and the same workarounds that made the old system inadequate. The technology changed; the underlying conditions did not.
The organizations I work with are now making the same error with AI, and they are making it faster.
In software development, technical debt is the accumulated cost of shortcuts taken during development. Managed well, it's a tool, but without intentionality, it's reckless. A startup building its first product may deliberately choose a simpler architecture to get to market, with a clear understanding that the design will need to be revisited when volume demands it. A team managing a process touched only a handful of times a month may reasonably hold a workaround until the volume justifies a more permanent fix. Managed technical debt — named, documented, with defined conditions for resolution — is a legitimate tool. Organizations that use it well understand what they owe and when they intend to pay it back.
Unmanaged technical debt is something different. It accumulates without anyone naming it, without conditions for resolution, and without a clear picture of what it will cost when it surfaces. The lift-and-shift failure is unmanaged technical debt made visible in the most expensive way possible. The organization skipped the structural work — the data governance, the process redesign, the decisions about what the new system was actually supposed to do differently — because that work was harder and slower than the migration itself. The result is a modern system faithfully replicating the problems of the one it replaced.
I have seen this play out in two agencies. The first selected a gold-standard ERP — a system capable of transforming how the organization managed its work. But the legacy structures, processes, and data they brought into the implementation were so entrenched that the organization ended up using a fraction of what the system could do. It was the organizational equivalent of using a 747 to taxi the runway. The system had the capacity; the organization was not ready to use it.
The second agency took a different path. Rather than buying the most capable system available, they moved their work onto a Microsoft Access database — not because it was the right long-term answer, but because everyone knew how to use it and it forced the team to get clear about what they actually needed to track across multiple revenue streams. That clarity was the real work. After a few years of building it deliberately, the agency was ready to buy a more robust system that could eliminate the manual processes. The sequence mattered: they understood what was essential and what was legacy structure worth leaving behind before they committed to a platform that would lock those decisions in.
AI adoption is following the same sequence — capability before foundation — and the cost of that inversion is quieter and harder to locate than any system migration.
Teddy Svoronos, a senior lecturer at Harvard Kennedy School who teaches statistical methods and AI application, introduced the concept of cognitive debt in a recent podcast conversation from Harvard's Data Smart City Solutions. He describes it as the growing distance between what AI is doing and what the people using it actually understand — and he draws the analogy deliberately from software: every time you delegate to AI without understanding what it is producing or why, you take out a small loan. The individual transaction looks reasonable. The work gets done, the output is polished, and the leader saved time. But the understanding that should accompany that delegation was not developed. It was deferred.
Unlike managed technical debt, cognitive debt rarely gets named. There are no conditions set for resolution, no structure for building the understanding that was skipped, and no clear picture of what the exposure looks like until a consequential decision has already been made on the basis of output no one was equipped to evaluate.
This is where the lift-and-shift parallel holds most precisely. Technical debt surfaces eventually — systems slow down, integrations break, something downstream fails in a way that traces back to a decision made under deadline pressure years earlier. The failure is painful, but it is at least visible. You can locate the broken thing and trace it back to its source.
Cognitive debt is harder to locate because the output does not look broken. AI is exceptionally good at producing work that reads as authoritative and complete — a polished summary, a well-structured analysis, a set of options formatted for executive review. These outputs signal competence. They do not signal the gaps in the reasoning that produced them, the data limitations the tool was not told about, or the organizational context that would change the interpretation entirely. The leader who approves that output without the knowledge to evaluate it is not exercising judgment. They are ratifying something they cannot assess, and the exposure lives in what they did not know to question.
The response to this is not to slow AI adoption or to second-guess every output. It is to be clear about what delegation actually requires — and to do that work before the delegation happens, not after the exposure surfaces.
When a leader delegates to a person, the work of delegation is not simply handing off a task. It requires establishing context: what problem are we solving and why does it matter, what values and principles must hold regardless of how the work gets done, what are the parameters and guardrails, what does a good outcome look like, and what decisions belong to the delegate versus what decisions must come back. When a team member has that foundation, they can make confident decisions in the leader's absence. They are not filling gaps; they are working within a structure the leader built.
The same foundation is required when delegating to AI, and most organizations are skipping it entirely. The tools are capable enough to produce output without it — that is precisely what makes the gap hard to see. But an AI operating without clearly defined context, parameters, and outcome criteria is filling the gaps the leader left, confidently and at scale. The output may be directionally sound. It may also be optimized for the wrong thing, built on assumptions the leader never examined, or missing the organizational knowledge that would change the answer. Without the foundational work, there is no way to know.
This is what unmanaged cognitive debt looks like in practice: not a single bad output, but a growing accumulation of decisions made on the basis of outputs that no one was fully equipped to commission, evaluate, or own.
The organizations that will use AI well are the ones that treat delegation to AI the way effective leaders have always treated delegation to people — as a leadership act that requires prior work. That means developing the domain expertise to evaluate what the tools produce, establishing the context and parameters that give AI something real to work within, and building the structural conditions that allow the team — human or AI — to make confident decisions and have those decisions hold up under scrutiny.
That investment is slower than adoption. It does not show up in the efficiency metrics that tend to dominate AI implementation conversations. But without it, what looks like transformation is closer to a new interface on an old problem; the underlying conditions unchanged, the debt accumulating quietly, and the cost deferred to a moment no one planned for.
Bearing Check
Before your organization delegates the next category of work to AI, what foundation has been laid — the context, the parameters, the outcome criteria, and the domain knowledge required to evaluate what comes back? Where is cognitive debt accumulating in your organization, and what are the conditions under which you intend to address it?