The Actual Cost of Operation Debt.
And Why No One's Calculated It.

No engineer would ship code without version control.

Think about that for a second. The idea of writing software without Git, without pull requests, without a repository that tracks every change, every decision, every line—it's unthinkable. It would be reckless. Negligent, even.

Now think about how you run your business.

Your onboarding process lives in three people's heads. Your sales handoff works because one person just knows what to do. Your customer success playbook is a Slack thread from 2023 that four people remember exists. Your best operator carries the entire operating system for their function between their ears, and when they go on vacation, things break in ways nobody can explain.

That gap has a name. I call it Operation Debt. And after spending the last year building a tool to fix it, I think I can finally put a number on what it actually costs.

(To be clear: this has nothing to do with financial debt or balance-sheet liabilities. Operation Debt is the business equivalent of technical debt. It's an operational cost, not a financial one.)

What Operation Debt Actually Is

Operation Debt isn't a metaphor. It's a real, measurable liability that sits on every company's books without a line item.

Here's the definition: Operation Debt is the accumulated cost of work that was never designed at the step level. Work that lives in people's heads. Work that breaks when those people leave. Work that can't be delegated because nobody ever specified what "it" actually is.

Technical debt happens when engineers take shortcuts in code. They know the shortcut exists. They track it. They pay it down deliberately.

Operation Debt happens when the rest of the business takes shortcuts in how work gets done. But nobody tracks it. Nobody names it. Nobody pays it down, because nobody can see it.

Ward Cunningham coined "technical debt" in 1992. Since then, the metaphor has spawned siblings: management debt (Ben Horowitz, 2012), organizational debt (Steve Blank, 2015), process debt (various). Each names a different kind of shortcut. None of them names the debt from never specifying the work in the first place. That's the seat that was empty. That's Operation Debt.

It shows up as five things:

Undocumented processes. Not "we don't have documentation." Most companies have plenty of it. A Notion workspace with 200 pages that nobody reads. A Google Drive full of half-finished SOPs. A binder of printed playbooks collecting dust on a shelf in the corner office. The problem isn't the absence of documentation. It's that what's documented doesn't match how the work actually happens. The real process lives in muscle memory, side conversations, and "ask Sarah."

Tribal knowledge dependencies. Every team has someone who just knows things. How the billing exception works. Why we don't use that vendor anymore. What actually happens when a client escalates. That knowledge isn't written down anywhere because nobody thinks of it as knowledge. It's just "how things work around here." Until that person leaves. They're your Cowboys and Surgeons—and their heroism is easy to mistake for a healthy system.

Cognitive load on the founder. If you're the founder, you're carrying more of the operating system than you realize. Every time someone asks you "how should we handle this?" or "what do we do when X happens?"—that's a process that exists only inside your head. You are the documentation. And you're running out of RAM.

Failed delegation cycles. You've done this: you assign something to someone. They do it differently than you would. The result is wrong, or at least not right enough. You take it back. You tell yourself you'll "document it properly next time." Next time never comes. The work stays on your plate. The debt grows.

Inconsistent execution. Same work, different results, depending on who does it and what day it is. Not because people are careless. Because the work was never specified precisely enough to produce consistent output. Every person who does the work invents their own version of it. Some versions are good. Some aren't. You can't tell which is which until a client complains.

These five things are present in every company I've ever worked with. Every one. The question isn't whether you have Operation Debt. It's how much.

What It Actually Costs

Here's the part nobody's done. Each component of Operation Debt is measurable. Not precisely, but well enough to make the invisible visible.

Before I get into my own math, two numbers worth sitting with:

Those are large-company numbers. Let me bring it down to a 30-person company and show what each component actually costs.

Re-explanation hours

How much time do senior people spend explaining things that should be documented? Not training new hires—that's a separate line. I mean the ongoing, week-over-week cost of answering the same questions, walking someone through the same process, or being pulled into a decision because the criteria for making it were never written down.

Conservative estimate: 5 hours per week per senior person. At three senior people averaging $75/hour loaded cost, that's $58,500 per year spent re-explaining things that should be self-evident. And if McKinsey's 20% figure is any guide, that estimate is probably low.

Rework from inconsistent execution

When five people do the same work five different ways, some of those ways produce errors. Client deliverables that need revision. Orders fulfilled incorrectly. Proposals that miss a step. Each error costs time to find, time to fix, and often costs client trust.

At an 8% error rate across 500 annual deliverables, with an average fix cost of $200 in labor: $8,000 per year in direct rework. The trust erosion is harder to quantify but arguably more expensive.

Key-person dependency risk

You have people whose departure would cause genuine operational disruption. The person who knows how the integration works. The person who handles the biggest client. The person who built the reporting system in a spreadsheet that nobody else understands.

There's a term for this in engineering: bus factor. The minimum number of people who would need to disappear before a project stalls for lack of knowledge. A bus factor of one is a single point of failure. Most 30-person companies have at least three roles with a bus factor of one.

Each of these is an unhedged risk. The expected cost is the replacement cost multiplied by the knowledge-transfer gap multiplied by the probability they leave in any given year. For one key person at $150K salary with a 6-month knowledge gap and 15% annual turnover probability: $13,500 per year in expected cost. Multiply by however many key-person dependencies you have.

And here's the part that should matter to any founder thinking about an exit: in due diligence, a buyer who discovers the business only runs because one person knows how it works will discount the price. Operation Debt isn't just a friction issue. It's an enterprise-value issue.

Failed delegation cycles

This is the founder tax. Hours spent doing work you shouldn't be doing because you couldn't hand it off successfully. Not because you didn't try. Because the work wasn't specified well enough for someone else to do it your way.

If you're spending 10 hours per week on work that should be delegated, and your opportunity cost is $200/hour—what your time is worth spent on growth, strategy, or product—that's $104,000 per year. This is usually the single largest line item, and the one founders are most reluctant to admit.

Onboarding drag

How long does it take a new hire to reach full productivity? In companies with strong operational documentation, it's 2–4 weeks. In companies running on tribal knowledge, it's 8–12 weeks. That gap is pure Operation Debt.

At 3 extra weeks of ramp time per hire, $2,500/week in loaded cost, and 8 hires per year: $60,000 per year in onboarding drag. That's not a training problem. It's a knowledge-design problem—plus the hidden cost of existing team members spending their time bringing the new person up to speed instead of doing their own work.

AI implementation failure

This one's newer, and it might be the most expensive of all.

MIT's Project NANDA (2025) studied the state of generative AI in business and found that despite $30–40 billion in enterprise GenAI spending, 95% of pilots deliver no measurable P&L impact. Not 50%. Not 80%. Ninety-five percent.

The cause isn't bad AI. It's what the researchers call a "learning gap"—tools that don't learn from or adapt to actual workflows. Put more bluntly: companies are trying to automate work that was never designed in the first place. You can't hand off a process to an AI when the process only exists as intuition in three people's heads.

McKinsey's own analysis of generative AI'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.

A single failed AI implementation attempt runs $50K–$200K when you factor in the tool cost, the integration work, the internal time spent configuring and testing, and the opportunity cost of the months lost. Most companies have tried at least one.

The Roll-Up

Add it up for a 30-person company:

Why This Debt Compounds

Technical debt is painful. Engineers feel it as friction every time they touch the codebase. It slows them down. It annoys them. It shows up in sprint velocity and in the occasional outage that makes everyone's phone buzz.

Operation Debt is silent.

Nobody wakes up and says "we have Operation Debt." They say "we need to hire someone to manage the client onboarding process." But the reason they need that hire is that the process was never designed. They're hiring a person to compensate for the absence of a system. The person brings their own version of the process, which becomes new tribal knowledge, which creates new dependencies.

Or they say "the AI didn't work." But the AI was fine. What failed was the specification. You can't automate a process that exists only in someone's head. The AI needs inputs, steps, decision criteria, output formats. If those don't exist for a human, they don't exist for a machine either.

Or they say "onboarding takes too long." But they solve it by assigning a buddy, not by designing what the new hire needs to know at the step level. The buddy's interpretation of the work becomes the new hire's version of the work. Drift accumulates.

Each band-aid creates the conditions for the next problem. That's the compounding. The debt doesn't just sit there. It grows. Every undocumented process forces the next person to improvise. Their improvisation becomes the new tribal knowledge. The org gets larger, the tribal knowledge gets more fragmented, and the cost of unwinding it all goes up.

By the time a company hits 50 people, most of the operational architecture was designed by accident during the first 10. Nobody chose it. It just happened. It's the same pattern I've written about as the three symptoms of an un-designed operation—and it traces back to the moment the craftsperson never became the architect.

And the reason it went unchecked for so long? Nobody named it. You can't fix what you can't see. You can't scale what you don't understand. The moment you name the debt—name each piece of work that lives in someone's head instead of in a system—the gaps, the faults, the single points of failure become obvious. Not because they're new. Because they were always there, invisible, until someone said them out loud.

The Source of Truth Gap

Here's what I keep coming back to.

Engineers solved this problem decades ago. Not perfectly, but structurally. Git gave them version control. GitHub gave them a collaborative source of truth. Pull requests gave them review. CI/CD gave them automated verification. Every line of code has a history, an author, and a reason for existing.

Writers solved it too. Track changes, version history, collaborative editing. The document is the source of truth and everyone can see what changed and why. Designers solved it with Figma. One file, one truth, everyone sees the same thing.

Operations? Nothing.

None of these is a source of truth for how the business actually operates. Not a living one. Not one that evolves as the business evolves. Not one that's interactive, that you can query, that tells you "here's where your operation breaks and here's what each step looks like when it's designed properly." What's missing is the Design Layer—the invisible architecture between strategy and execution.

That gap is the reason Operation Debt exists. Not because people are lazy or careless. Because the infrastructure to prevent it never existed.

What Changes When You Close the Gap

I've spent the past year building this infrastructure. The product is called OkHenry—named, in part, as a nod to Henry Ford's insight about decomposing work—and it does something that surprised even me in how fundamental it turned out to be.

You talk to Henry. He asks about your business. In about 7 minutes, he delivers a structural diagnosis of where your operation is breaking. Not advice. A map. Which part of your customer lifecycle has the gap, why symptoms show up where they do, and what the structural root is.

If you want to go deeper, specialist agents help you design every step of your operation. What it needs, how it gets done, what the person on the other side experiences. Three dimensions, fully specified, at a level where you could hand the work to a new hire, a contractor, or an AI agent and they'd know exactly what to do.

The result is an Operation Map. And what I've realized, after watching dozens of operators build them, is that the Operation Map isn't just a deliverable. It's the operational source of truth that never existed before. The living, interactive, version-controlled system that captures how the business actually runs.

Next to it, the Knowledge Base captures what each role needs to know. Not a wiki. Not a handbook. Role-scoped operational context that evolves as the operation evolves.

Together, they close the gap. The $346,000 gap. The "why can't I take a vacation" gap. The "why did the AI fail" gap.

If you've ever felt like something is stuck but you can't name it, that's the debt talking. Now you can calculate it.