Operational Debt: What It Is And How To Pay It Down

Operational debt is technical debt's analogue for how a business runs. What it is, how it accrues silently, why it compounds, and how to pay it down.

The idea, in one paragraph

The threshold that separates a shortcut from debt: has this happened twice? The first time you do something undocumented, that's not debt — that's discovery, and doing it manually first is how you feel its texture. The second time you do the same thing the same way with nothing written down, you've borrowed. So the rule is: on the second occurrence, you either write down how it works or you consciously accept the interest. Not maybe later. Second occurrence. Everything a business does more than twice is either an asset or a liability, and the only thing that decides which is whether anyone wrote it down.

Borrowing the term honestly

Software has a well-worn idea called technical debt. Ship the quick version now, and you've borrowed against the future: the code works, but every change you make later costs more than it should, because you skipped the structure that would have made changes cheap. The debt is real, it's invisible in the demo, and the interest is paid in every subsequent sprint.

Operational debt is the same shape, applied to how a business runs rather than how its software is written. It is not a term Brian coined and this page won't pretend otherwise. It's the closest available analogue for something OPERATE describes throughout without naming: every undocumented process, every step that only works because you remember it, every handoff that succeeds because you happened to be in the room. Each of those is a shortcut you took for a good reason, and each one is accruing.

The analogy is worth making because it imports something founders desperately need — the idea that a shortcut isn't free, it's financed. Nobody thinks of "I'll just handle it myself this time" as taking out a loan. It is one. The principal is the ten minutes you saved. The interest is every future instance where the thing can only happen if you're there.

What the principal actually looks like

Operational debt is not abstract. You can walk your business and point at it, and it usually looks like one of five things.

Undocumented processes: the client onboarding that runs correctly every time because you're the one running it, and has never been written down because you already know it. Tribal knowledge: the fact that this particular client is always three days late on assets and everyone works around it, which lives in exactly two heads. Undefined decisions: the discount you'd approve and the discount you wouldn't, which has no rule, so every instance routes to you. Silent handoffs: work that moves between two people because they're friendly, with no trigger, no record, and no way to notice when it doesn't move. And exception-as-standard: the thing that started as a favor for one client and is now how you do it for eleven, un-priced and un-designed.

Every one of those was contracted rationally. None of them are visible in any number you look at. That's the defining property. Financial debt has a statement. Operational debt has no statement — the only place it shows up is in your calendar, and your calendar looks like it looks because you're busy, and you've always been busy.

How the interest compounds

Debt that only cost what you borrowed would be manageable. What makes this dangerous is that the interest rate rises with the size of the business, and it rises in three distinct ways.

The first is volume. An undocumented onboarding costs almost nothing at two clients a quarter. At two a week, it's a job — your job, permanently, because it's still not written down. The principal never changed. The payment scaled with success.

The second is entanglement, and it's the one that actually kills. Undocumented processes get built on top of. Someone designs the delivery workflow around how onboarding currently works, so now there are two things that depend on knowledge in your head, and the cost of changing either has gone up. Give it three years and you have a structure where nothing can be modified without touching six undocumented dependencies, which is precisely why founders at this stage say things like "we can't change that right now." You can't. You're servicing debt.

There's a compounding effect on the human side too, and it's the one founders feel first without naming. Undocumented work concentrates. The person who knows how a thing runs becomes the only person who can run it, which means their calendar fills with it, which means they never have the hour to write it down, which means they stay the only person. The debt actively defends itself by consuming the capacity that would retire it. That's true whether the person is you or your best operator, and it's why the most capable people in a business are usually the most indebted.

The third is that debt blocks the very thing that would retire it. You can't automate a process you can't describe. You can't hire someone into a role that has no definition — you can only hire someone and then be their documentation, which converts a payroll expense into a new load on you. Operational debt is the reason so many founders hire help and get busier. They took on a person while still owing the process.

Paying it down without stopping the business

The instinct, once you see it, is to declare a documentation project. Block a month. Write everything. This nearly always fails, and it fails for a reason worth understanding: documentation written away from the work is documentation of what you think you do, not what you do. It's also the first thing abandoned the moment a client escalates, which is week one.

The alternative is the rule the book actually gives: build the systems as you do the work, not instead of the work. You don't schedule the paydown. You attach it. The next time you run onboarding, run it — and record it as you go. The next time a decision routes to you, make it, and then write the rule you just used. The cost is thirty minutes on top of work you were already doing, and the payment is permanent.

Prioritize by interest rate, not by size. The debt to retire first is whatever you touch most often and only you can do — that's the highest-frequency, highest-dependency line, and it's usually not the impressive one. It's usually something small and dumb that happens eleven times a week. And accept that some debt should be carried: a thing you do twice a year isn't worth documenting, and doing something manually first is how you learn the nuance that makes the eventual system good. The goal isn't zero debt. It's knowing which debt you're holding, on purpose.

If you'd rather have the ledger handed to you — every undocumented dependency in your business, ranked by what it's costing you — that's what the OPERATE Report ($1,997) produces. If you'd rather have the highest-interest ones retired in a day, that's what Build Days are. Either way, the concept stands without us: on the second occurrence, write it down.

Operational debt is the interest you pay on every shortcut you never wrote down. It doesn't show up on any statement — it shows up as a founder who can't take a week off, and who has no idea when that became true.

ELives under the Execution pillarYour delivery is your marketing.
§ RELATED

The rest of the vocabulary

ExecutionThe Finisher's Trap: Why Finishing Builds Your CageThe Finisher's Trap is the belief that a founder's job is to do more, when the job is to design more. Its anatomy, why it hides, and the way out of it.ExecutionThe Operator's Ceiling: The Invisible Line In BusinessThe Operator's Ceiling is that invisible line between working harder and getting nowhere faster. Why the best finishers hit it first — and how to break it.ExecutionWhen The Founder Is The Bottleneck: How To TellEvery business has a bottleneck. When it is the founder, throughput is capped at one person and every improvement elsewhere is wasted. How to find out.EnablementWhat Founder Dependency Is, And Why It Looks Like SkillFounder dependency is when a business runs on a person rather than a design. What it costs, why it hides, and the three forces that engineer it out.

Naming it is the easy part.

The OPERATE Report finds where this is actually true in your business, across all seven pillars, with a prioritized build order.