Operational Debt:
The Interest You Pay on "We've Always Done It This Way"

Most owner-operators know the feeling but have no name for it. The business is bigger than it was. Revenue is fine. And yet everything takes longer. A quote that used to go out same-day now takes three. A new hire who should be useful in a fortnight is still asking questions in month two. Nothing is broken. The business has simply become heavy.

With no name for that weight, it gets blamed on growth, or the team, or the software. It is usually a debt the business has been quietly servicing for years.

Every Business Runs on Decisions Nobody Remembers Making

Pick any process and trace it backwards. There is the spreadsheet between two systems because the proper integration would have taken six weeks and you needed numbers by Friday. There is the approval that routes through one person because they once caught an expensive mistake. There is the folder structure that made sense when you had eleven clients.

Every one was a decision, and most were good ones. Almost none was ever revisited, because nothing forced a revisit. Over enough years, a business ends up running on rules nobody wrote down and nobody can now explain.

What Technical Debt Actually Meant

That accumulation has a name in another industry, and almost everyone who borrows it gets it wrong. Ward Cunningham coined "technical debt" in a 1992 conference report on a financial software product, the WyCash Portfolio Management System: "Shipping first time code is like going into debt ... Every minute spent on not-quite-right code counts as interest on that debt."

Popular usage flattened that into "we cut corners, we will fix it later", and Cunningham objected to exactly that reading for years. A lot of bloggers, he said in a later interview, had "confused it ... with the idea that you could write code poorly with the intention of doing a good job later". What the debt actually was, in his words: "If we fail to make our program align with what we then understood to be the proper way to think about our financial objects ... we were going to continually stumble over that disagreement, and that would slow us down, which is like paying interest on a loan."

Swap "financial objects" for your own business and the point holds. The debt is not sloppiness. It is the distance between how the thing was built and what you have learned since. You were right once, then you outgrew being right.

The metaphor works outside software because the idea underneath it was never really about code. Steve Blank made the move more than a decade ago with "organizational debt": the people and culture compromises made to just get it done early on. His subject is people; this one is the work itself.

Operational Debt, in One Paragraph

Operational debt is the accumulated gap between how your business runs today and how it would run if you designed it now, knowing everything you now know. It lives in workarounds, undocumented steps, manual bridges between systems, exceptions only one person understands, and processes built for a company that no longer exists. The principal is not the problem. The interest is: the extra minutes, questions, approvals and rework, charged every time the work runs.

Why It Accumulates: Every Workaround Was the Right Call That Day

The month-end workaround saved the close. The exception saved the client. The manual step exists because the alternative was a six-week build you could not justify that quarter. Each was a loan taken at a sensible rate.

What makes it debt rather than a mistake is that the conditions changed and the arrangement did not. That workaround was priced against four people and nine clients. You now have twenty-two people and ninety clients, and it still runs four hundred times a year.

Which is why "we've always done it this way" is hard to argue with. It is usually true, and it usually worked. The person defending it is defending a correct decision, against a business that no longer exists.

Where the Interest Actually Shows Up

The principal is invisible. The interest is not, once you know where it gets charged.

• Onboarding that never gets shorter. Every undocumented exception has to move from one head into another, and it repeats for every hire. If ramp time has not improved as your team has grown more experienced, you are watching interest payments, not a hiring problem: one of the quieter reasons a business doing everything else right stops scaling.
• One person who cannot take a holiday. The clearest measurement comes from software, not small business, so treat it as an analogy. Researchers analysing 133 popular open-source projects on GitHub found 46 percent had a "truck factor" of one, a single contributor whose departure would stall the project, and another 28 percent at two (Avelino, Valente and Hora, 2017). Those are code repositories, not companies, but the question transfers: if one person left this quarter, which processes stop?
• Reporting lag. A number that should be one click is a two-day assembly job, so it gets pulled quarterly and decisions get made on a stale picture. McKinsey Global Institute's 2012 study The Social Economy estimated that the average interaction worker spends nearly 20 percent of the working week searching for internal information or tracking down colleagues who can help.
• Quality drift. Where no process is defined, output quality tracks whoever is doing the work that day, so standards stay personal instead of institutional.

Why Nobody Pays It Down

The standard advice is "document your processes". It is not wrong, it is useless: every leadership team already knows it and still does not do it. The question worth asking is why competent people reliably do not. Three structural reasons, none about discipline.

It has no owner. Every other significant cost belongs to somebody. Operational debt is created by everybody and owned by nobody. Finance sees a slow close. Operations sees a workaround. Sales sees a quote that takes three days. Each is looking at the same debt from a different side and calling it something local, so nobody assembles the pattern. The damage lives in the space between departments, which is precisely the space nobody has been given.

It has no line item. It is not an expense of its own, just a distributed drag on the expenses you already pay. A bad software contract shows up as a number and gets renegotiated at renewal. A bad process costs more and appears nowhere, so nothing in your reporting creates pressure to reduce it.

Each individual piece is too small to schedule. Any single instance costs somebody twenty minutes a week, and twenty minutes never wins against a client deadline. The debt only becomes urgent in aggregate, and aggregate is the one view nobody has. So it stays unpaid until the week it blocks something large: a system change, due diligence, a key person leaving, a growth push the operating model cannot absorb.

None of that is a failure of will, which is the encouraging part: fix the structure, not the people.

The Tell: "Well, It Depends Who Is Doing It"

One diagnostic costs nothing. Ask somebody to explain how a job gets done from start to finish, then listen for the moment they say "well, it depends who is doing it".

That is the sound of interest being charged. The process does not exist as a process. It exists as three or four private versions in three or four heads, and the business pays the difference.

The neighbouring phrases are just as diagnostic. "I would have to ask Priya." "Officially yes, but what actually happens is." "We tried that once." Each marks a place where the operating model lives in a person rather than in the business. Count them over a normal week. You are measuring how much of your company walks out if that person takes another job.

How to Audit It Without Stopping the Business

Not a documentation project. Those die by week three. Two focused weeks and one spreadsheet get most of the value.

1. Pick the five to eight flows that touch money or customers. Quote to cash. Lead to first meeting. Order to delivery. Month-end close. Onboarding.
2. Walk each one with the person who does it, not the person who owns it. The gap between their two descriptions is itself a finding.
3. Log the exceptions, not the steps. Record four things only: where this depends on one named person, where information gets retyped, where somebody waits on somebody else, and where the answer changes depending on who you ask.
4. Attach two rough numbers: how often it runs, and how much time the friction adds. "Weekly, about twenty minutes" turns an annoyance into an annual figure.
5. Sort by what it blocks, not by size. The biggest item is rarely the one worth touching first.

You will finish with fifteen to forty items. That list is the value: an unnameable heaviness becomes a finite, sortable set.

Which Debts to Pay Down, and Which to Carry on Purpose

Do not try to clear it. A business with zero operational debt has spent its scarcest capital, management attention, on tidiness rather than customers. The goal is servicing the right loans.

Pay down whatever blocks a move you are trying to make in the next twelve months. Hiring five people makes onboarding debt expensive. Opening a second location makes anything requiring one named person's judgement expensive. Preparing to sell makes anything a buyer would price as key-person risk expensive. Buying software makes the data debt expensive: software makes a defined process faster and an undefined one more costly, which is why bad CRM data is usually a process symptom.

Pay down anything where one person's absence stops revenue. That is a risk question, not an efficiency one. You are not buying back twenty minutes a week, you are buying back the ability to survive a resignation letter.

Carry the rest deliberately. The manual step that runs twice a year and takes an hour is a sensible debt to hold for good. Write it down as a decision, review it yearly, and stop feeling guilty. The difference between debt you carry and debt that carries you is whether you chose it.

A business does not become heavy all at once. It becomes heavy one sensible decision at a time, with nobody in the wrong. Naming the weight as debt is what makes it manageable, because a debt can be scheduled, prioritised or knowingly kept. "We've always done it this way" offers none of those options.

Most teams can run that audit themselves, and should. It gets harder when the debt spans functions that do not talk to each other. That is where an outside read earns its fee, the everyday work of management consulting and our operations practice.

FAQ

*Published by EncubIQ Consulting | Last Updated: July 2026*