Technical Debt the Board Can See: A One-Page Register

Boards read balance sheets. They are used to seeing what the company owes, what it costs to carry and when it comes due. Technical debt behaves the same way, yet it almost never appears in front of directors in a form they can use.

Instead it shows up as delays, outages and engineering complaints. By the time it reaches the board it is usually a crisis, not a decision.

A one-page register fixes the visibility problem. It lists the debts that matter, what each one costs every year, what it would cost to exit, and when someone has to decide.

TLDR

• Technical debt is a business liability with a carrying cost, not an engineering mood.

• A board needs a short register, not a backlog of hundreds of tickets.

• Each entry should show the risk carried, annual drag, exit cost and decision date.

• The register turns an open-ended complaint into a dated decision.

• Review it at least twice a year and retire entries only when the debt is actually gone.

What technical debt actually is

The Carnegie Mellon Software Engineering Institute uses a definition written into U.S. law for a Department of Defense study: an element of design or implementation that is expedient in the short term but makes future change costlier or impossible. You can read the SEI's summary of that study.

The key idea is the trade. A team took a shortcut to move faster, and the business is still paying for it. Like financial debt, it is sometimes a sound choice and sometimes not. It is a problem only when nobody is tracking the cost.

The one-page register

Keep it to the debts that carry real weight. Five to ten entries is plenty. For each, answer five questions in plain language. The entries below are illustrative.

System (illustrative)	Risk carried	Annual drag	Exit cost	Decision date
Order system built in 2009	One person knows how to fix it; no vendor support	Two outages a year; slows each product launch by weeks	Rebuild in phases over 18 months	Next budget cycle
Customer data stored in three databases	Records disagree; hard to meet deletion requests	Manual reconciliation each month	Consolidate in one project	Within 6 months
Unpatched reporting server	Known weaknesses, no replacement planned	Extra monitoring and audit findings	Retire after moving two reports	End of quarter

The annual drag column is the one directors remember. It puts a recurring cost next to a problem that used to feel free.

Make every entry a decision

A register is useless if it only records pain. The last column matters most. Every entry needs a date by which someone chooses to pay it down, wrap it, or accept it in writing.

Accepting debt is legitimate when the cost of fixing it exceeds the cost of carrying it. What is not acceptable is leaving the choice unmade. The trust debt and technical debt post covers how the two kinds of debt interact.

Keep it honest

Have the engineering lead and the finance lead fill it in together. Engineers know the risk; finance can test the drag and the exit cost. Neither alone produces a number a board can trust.

Refresh the register twice a year. Remove an entry only when the debt is gone, not when the complaint stops.

Frequently asked questions

How many items belong on the register?

Five to ten. The register is for debts that carry real weight. A long list defeats the purpose of giving a board a short view.

How do you estimate annual drag?

Add up recurring costs the debt causes: outage time, manual work, delayed launches, extra monitoring and audit effort. A rough range agreed by engineering and finance is enough.

Is all technical debt bad?

No. Taking a shortcut to ship sooner can be a sound trade. It becomes a problem when nobody tracks what it costs or decides when to pay it down.

Who should own the register?

A named executive, usually the CTO or CIO, with finance as a co-signer. The board sees it; management maintains it.

A Defensible Next Step

Ask your CTO for the three systems that would hurt most if they failed tomorrow, and fill in one row each: risk, drag, exit cost, decision date. That is the start of a register the board can actually use. Book a Decision-Clarity Call if you want help building it.