- A board weighs the roadmap, not the code. Debt described as code sounds like a request to tidy up.
- Describe it as what each month of waiting costs: features that slip, people tied up, risk carried.
- Then put questions to the board that only the board can answer.
Most product leaders have sat through the same moment. The engineering lead has prepared a slide on technical debt. It lists old libraries, warnings, parts of the product nobody wants to touch. The slide is accurate. The board listens politely, nods, and moves on to the next item. Nothing changes, and the debt is back on the agenda next quarter, a little heavier.
The slide did not fail because it was wrong. It failed because it answered a question the board was not asking.
A board does not fund code
A board is there to weigh the business: where it is going, what it can afford, and what could stop it. A count of problems in the code does not speak to any of those. It sounds like housekeeping, and housekeeping can always wait one more quarter.
That is the trap. The debt is real, but it is described in the language of the people who live with it, not in the language of the people who decide. The board hears a request to tidy up. What it needed to hear was a choice about the roadmap.
So the work is translation. The debt stays the same. The words change.
Describe it as the cost of waiting
Our view is that debt is best explained by what each month of waiting costs. Not what the code looks like, but what the business gives up while it stays as it is. Three costs tend to cover it.
Features that slip. Most roadmaps have items that keep moving to a later quarter. Ask your team which of them are late because of the debt. Name them. A feature the sales team has promised is a cost a board understands at once. “This module is hard to change” is not.
People tied up. Somewhere in your team there are people whose weeks go to keeping old parts running. They patch, they work around, they answer the questions only they can answer. That time is not going to the roadmap. Say who they are in terms of roles, and what they would be building otherwise.
Risk carried. Some debt is quiet until the day it is not. A platform past the end of its support, a part only one person understands, a release the team is afraid of. Describe what could break, who would notice first, and what it would mean for customers. The board’s job includes deciding which risks to carry. Give it the chance to make that decision on purpose.
None of these needs a formula. You do not have to put a number on a month of waiting to make the point, and an invented number does more harm than good: the first question about it unravels the rest. Use the facts you have. Name the features, the roles and the risks. If your finance team can put a figure on any of them, let them, and let them show where it comes from.
Questions to put to your board
A good debt conversation ends with a decision, and a decision needs questions. These are questions only the board can answer, which is exactly why they belong in the room.
- Which of the features on this roadmap are we willing to see slip again?
- Which risks are we choosing to carry, and for how long are we comfortable carrying them?
- If the people tied up on old parts were free, what would we want them building?
- What would make us regret waiting: a customer we lose, a requirement we cannot meet, a person who leaves?
- Do we want to pay this down alongside new work, or set the new work aside for a while?
The last question matters more than it looks. Many boards assume the only options are to ignore the debt or to stop everything and fix it. Neither is attractive, so they choose to ignore it. Putting a third option on the table, steady repair alongside the roadmap, often changes the answer.
What this conversation is not
It is not a request to rebuild the product. Sometimes a rebuild is the right call, and sometimes changing the product where it stands is. That is a separate decision with its own questions, and we have written about it in Rebuild or refactor? A decision guide. The conversation here comes first: whether the cost of waiting is worth acting on at all.
It is also not a promise that the debt will be gone. A product that is alive carries some. The aim is a level the business has chosen, not one it drifted into.
Lifting the conversation
When debt is described as code, it stays an engineering problem that the board tolerates. When it is described as the cost of waiting, it becomes a business choice the board owns. That shift is the whole point. You are not asking for permission to clean up. You are asking the board to decide which features, people and risks it is willing to keep paying for.
Lift your eyes from the list of problems. Bring the board the roadmap it is protecting, and show what waiting does to it. The decision will be clearer, and it will be shared.
If the answer is to pay the debt down while the roadmap keeps moving, that is the situation described in Pay down technical debt while features keep shipping.
