"Technical debt is a governance problem, not a code problem"

Every engineering organisation has a version of the same meeting. The engineers say the codebase is slowing them down. Management hears a request for time that produces no feature. After some negotiation a "refactoring sprint" is granted. It happens once. Six months later the meeting repeats, with the same slides and worse numbers.

Nobody in that room is wrong. The engineers are right that delivery is degrading. Management is right that "the code is bad" is not an investable proposition. The meeting fails because both sides are discussing a symptom.

The debt is not in the code

Technical debt is usually defined as shortcuts in the code. That definition points at the wrong layer. The code is where debt shows up — the debt itself is the sum of architecture decisions your organisation made implicitly.

Schedule pressure is the standard villain in debt stories, but pressure does not create debt directly. What pressure removes is the moment where a trade-off gets recorded. A team under deadline couples two components that should have stayed separate. That may even be the correct call — shipping matters. The damage is not the coupling; it is that nobody wrote down that the coupling was chosen, what it costs, and what future condition should trigger revisiting it.

Eighteen months later, nobody remembers a decision was made at all. The coupling is just "how the system is". New work routes around it, which is how one implicit decision breeds five more. That is the compounding mechanism — and it is a records problem, not a craftsmanship problem.

You are already paying the interest

Debt has a principal — what it would cost to fix — and interest: what it costs you every month you do not. Interest shows up as slower delivery on anything touching the affected area, a recurring class of defects, integration pain, and the onboarding drag of a system nobody can explain.

Most debt arguments are about the principal, which management correctly reads as an expensive proposal with an uncertain return. The stronger argument runs the other way: measure the interest, because you are paying it right now, in currency management already tracks — lead time, defect rates, integration effort. A liability with a measured monthly cost is an investment decision. "The code is bad" is a complaint.

Why refactoring sprints keep failing

The refactoring sprint is a structural mismatch: a one-off amnesty applied to a recurring liability. It treats debt as an anomaly to be purged instead of a balance to be serviced. The sprint pays down whatever principal fits in two weeks, changes nothing about how new debt is taken, and leaves no record — so the balance quietly rebuilds and the credibility of the next request erodes with it.

Compounding is easiest to see in product families. In one radio product family I worked on, a platform strategy held roughly 95% of the software common across more than ten shipped variants. That number was not hygiene or luck — it was the direct output of debt being taken deliberately: boundaries chosen on purpose, exceptions argued and agreed, trade-offs revisited when conditions changed. Full disclosure: little of it was written down — it lived in the heads of a genuinely good team. That is the expensive version of the discipline, and it works exactly as long as those heads stay in the room. Writing it down is how the same discipline survives growth, turnover and acquisitions. The same portfolio without that discipline forks a little with every variant, and the divergence itself becomes the debt — multiplied by the roadmap.

What governance changes

If the dangerous debt is the debt nobody decided to take, the fix is to make deciding cheap and visible:

Record decisions when they are made. A lightweight architecture decision record — a page, not a ceremony — capturing the trade-off, the cost, and the condition under which it should be revisited. Debt taken this way is leverage. It is how products ship on time. The record is what makes it leverage instead of loss.

Keep a registry, not a backlog label. Debt items need owners, a priced interest estimate, and an explicit standing decision: pay down, accept, or watch. A backlog is where debt goes to be forgotten; a registry is where it goes to be decided. (That registry deserves its own post — coming next.)

Budget the interest. A standing allocation for debt service, reviewed on the same cadence as roadmap planning, replaces the hero sprint with something management recognises: portfolio maintenance.

None of this requires better engineers. It requires the same thing every other liability in the company already has — a ledger, an owner, and a review date.

If your debt conversation is still engineers versus management, you do not have a debt problem yet. You have a visibility problem, and that one is cheaper to fix.

I gave a full webinar on this — making debt visible, pricing it, and paying it down deliberately: watch it here.