The Fifth Kind of Debt
Your Business Is Carrying

In 1992, Ward Cunningham was trying to explain something to his business stakeholders at a financial software company. His engineering team had shipped code fast, taken shortcuts they knew about, and now those shortcuts were slowing them down. Every new feature took longer. Every change risked breaking something. The codebase was full of expedient decisions that were costing them compounding interest.

He reached for a metaphor they'd understand: debt.

The metaphor stuck. Not because it was clever. Because it was true. Engineers immediately recognized the pattern: short-term speed, long-term cost, compounding interest. Technical debt became one of the most useful concepts in software, because it gave teams a language for something they were already experiencing but couldn't articulate.

What Cunningham probably didn't anticipate was that his metaphor would spawn an entire family.

The Debt Family

Over the next three decades, other thinkers noticed the same pattern in other domains.

Management debt. In 2012, Joanne Bradford coined the term inside Microsoft, and Ben Horowitz made it famous. Management debt is what happens when a leader makes an expedient management decision for short-term convenience, knowing it'll be expensive to unwind later. Paying a key employee above market rate because you need them now. Putting two people in charge of the same thing because it's easier than choosing. Tolerating a brilliant jerk because they produce results. Each one makes today easier and tomorrow harder.

Horowitz wrote: “Like technical debt, management debt is incurred when you make an expedient, short-term management decision with an expensive, long-term consequence.” The debt compounds. The longer you wait, the more it costs to fix.

Organizational debt. In 2015, Steve Blank extended the metaphor to people and culture. Organizational debt is the accumulation of expedient organizational decisions—hiring fast without defining roles, skipping onboarding because there's no time, letting culture happen by accident instead of design. Blank argued it's worse than technical debt because it's harder to see and more painful to unwind. You can refactor code. Refactoring a culture that formed around shortcuts is a different kind of surgery.

Process debt. This one emerged more diffusely through the 2010s, with multiple practitioners naming it. Process debt is the accumulation of inefficiencies and redundancy in existing workflows—steps that were added during a crisis and never removed, approvals that made sense three years ago, handoffs that exist because of an org chart from a previous era. The work was specified, but the specification is outdated, inefficient, or contradictory.

Four debts. Code. Leadership decisions. People and culture. Workflows.

Each one is real. Each one compounds. Each one has a growing body of practitioners, literature, and tooling dedicated to identifying and paying it down.

And each one has a blind spot.

The Seat That Was Empty

Here's the thing nobody noticed, or at least nobody named: all four debts assume the work was specified in the first place.

Technical debt assumes code exists. You wrote it; now you're paying the cost of how you wrote it. Management debt assumes a decision was made. You made it expediently; now you're paying the cost. Organizational debt assumes people were structured into roles. You structured them hastily; now you're paying the cost. Process debt assumes a process was defined. It was defined badly or stale; now you're paying the cost.

What about the work that was never specified at all?

Not a bad process. No process. Not an outdated workflow. No workflow. The work lives in people's heads. It runs on intuition, memory, and “just ask Sarah.” It can't be inspected because it was never externalized. It can't be improved because there's nothing to improve. It can't be transferred because the only documentation is the person who does it. Those are the cowboys and surgeons every operation quietly depends on.

Why This Gap Matters

I didn't come to this from theory. I came to it from watching businesses break in a specific way.

A company would hit 30 people and start feeling friction. Not product friction. Not market friction. Operational friction. Everything took longer than it should. The same questions got asked and re-asked. People who were hired to do new work spent their first three months reverse-engineering how the existing work got done. Key people couldn't take vacation without something breaking. It's the same pattern I've written about as the three symptoms of an operation that was never designed.

And the response was always the same: “We need to document our processes.” So they'd open Notion or Confluence, write some SOPs, build a wiki. Within two months, the wiki was stale. The SOPs didn't match reality. Nobody read them.

The documentation failed because it was documenting something that didn't exist in a designable form. You can't write an SOP for work that was never designed at the step level. You'll capture a snapshot of one person's interpretation of how the work gets done on a good day. That's not a process. That's a memoir.

The Numbers

Operation Debt isn't abstract. It's quantifiable.

These aren't small leaks. These are structural losses that most companies have normalized because they've never had a language for the root cause. (I've put a full dollar figure on it for a 30-person company in The Actual Cost of Operation Debt—conservatively, about $346,000 a year.)

Why It Compounds Now

Technical debt compounds every time you add a feature to a messy codebase. Operation Debt compounds every time you add a person to an undesigned operation.

But there's a new compounding force: AI.

MIT's Project NANDA studied enterprise AI adoption and found that despite $30–40 billion in GenAI spending, 95% of pilots deliver no measurable P&L impact. The cause is a “learning gap”—tools that don't learn from actual workflows, because the actual workflows were never specified.

Companies are trying to automate work that only exists as tribal knowledge. They're handing AI a process that no human could follow from documentation, and expecting the machine to figure it out.

McKinsey's own analysis of GenAI's economic potential is explicit: capturing the $2.6–4.4 trillion in potential value requires redesigning business processes. Not layering AI on top of existing ones. Redesigning them. That redesign is the work nobody's doing, and its absence is the debt nobody's tracking.

The Theoretical Bedrock

The deepest version of this insight comes from Ikujiro Nonaka, writing in Harvard Business Review in 1991. His framework for “The Knowledge-Creating Company” established the distinction between tacit and explicit knowledge—the idea that people know more than they can say, and that competitive advantage comes from converting tacit knowledge into explicit, transferable form.

Operation Debt, at its core, is unconverted tacit knowledge. The work lives in people's heads (tacit). The organization needs it externalized into designed, inspectable, transferable form (explicit). The debt accumulates every day the conversion doesn't happen.

Nonaka saw knowledge conversion as the engine of competitive advantage. Operation Debt is what happens when that engine stalls.

The Position No One Has Claimed

There's a reason I'm spending time on this lineage. It's not academic vanity. It's that the term “operational debt” already exists in the wild, and it's being used loosely by a dozen different practitioners to mean a dozen different things. Tonkean uses it to mean process inefficiency. Rework uses it to mean management shortcuts. GCE Strategic uses it to mean growth impediments.

None of them isolate the root cause: work that was never specified in the first place.

You can't refactor work you never defined. You can't improve a process that doesn't exist in an inspectable form. The precision of the definition is the entire point.

And the precision creates the solution path. If Operation Debt is unconverted tacit knowledge—work that lives in people's heads instead of in designed systems—then paying it down means converting it. Designing the work at the step level. Making it explicit, inspectable, transferable.

I call the result an Operation Map. It's the operational source of truth that never existed before—the Design Layer between strategy and execution. Not a wiki. Not an SOP. A living, designed system that captures how the work actually gets done—every input, every output, every handoff, every decision criteria.

The Family Is Complete

Code. Leadership. People. Workflows. The work itself.

The first four have had decades of practitioners, tooling, and methodology built around them. The fifth one is just getting its name. And the companies that recognize it first will have a significant structural advantage—because you can't fix what you can't see, and you can't see what you haven't named.

Now it has a name.