Is your technical debt out of control?

What this talk covers

Every engineering organisation has a version of the same meeting. Engineers say the codebase is slowing them down. Management hears a request for time that produces no feature. A “refactoring sprint” gets negotiated, happens once, and six months later the meeting repeats — same slides, worse numbers. The problem is not that anyone in that room is wrong; it is that technical debt is being discussed as a feeling and managed as an exception.

The webinar makes the opposite case: debt is a normal financial instrument of product development — and like any instrument, it is only dangerous when nobody records the terms. It walks through three moves that turn debt from a recurring argument into a managed portfolio:

Make it visible. A technical debt registry — run like a risk register, with named owners and explicit decisions — replaces “the code is bad” with a list of concrete liabilities the organisation has chosen to carry, chosen to pay down, or chosen to watch. Choosing is the point.

Price it. Every debt item has a principal (what it costs to fix) and an interest rate (what it costs every month you don’t — slower delivery, a recurring defect class, integration pain). Most organisations argue about the principal and never measure the interest, which is exactly backwards: the interest is what you are already paying.

Decide deliberately. Debt taken knowingly, with a written trade-off and a trigger condition for revisiting it, is leverage — it is how products ship. Debt nobody chose is the kind that compounds. The difference between the two is not code quality; it is whether the decision was recorded.

The stakes are 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 — architectural discipline paying out directly in the reuse economics of the whole roadmap.

If you lead an engineering organisation — or you have just inherited one, or two, through acquisition — this is a talk about running technical debt the way you already run financial and delivery risk: on the record, with owners, on a cadence.

Key takeaways

• Technical debt is a governance problem before it is a code problem: the dangerous debt is the debt nobody decided to take.
• You are already paying the interest whether or not you acknowledge the loan — measure the interest first, argue about the principal second.
• A debt registry beats a backlog label: a backlog is where debt goes to be forgotten; a registry is where it goes to be decided.
• “Refactoring sprints” fail structurally: one-off amnesty cannot service a recurring liability. Debt needs a budget line, not a special occasion.
• Deliberate debt with a recorded trade-off and a revisit trigger is leverage; the record is what makes it leverage instead of loss.
• In derivative product families, architectural discipline is not hygiene — it is the reuse economics of the whole roadmap.

Materials

Free, no email gate, no catch — if it's useful, connect on LinkedIn and pass it on.

• The slides from the talk (PDF, 4 MB) — the deck as presented in the live session. Best read next to the recording; the argument lives in the narration.

Work with me

This is the kind of problem I take on as a consultant: platform consolidation after acquisitions, inherited codebases with unrecorded decisions, product families where reuse has quietly stopped paying. If your organisation is having the meeting described at the top of this page, the fix is rarely a bigger refactoring sprint — it is architectural governance.