Tech debt loses roadmap fights because it arrives as a feeling and features arrive as numbers. So we put a number on it: the hours per month the debt costs us right now, and the hours the fix would take. Then the debt item goes on the same list as the features and gets ranked by the same rule. Some debt loses that fight honestly, and that's fine. What isn't fine is debt losing because nobody bothered to price it.
Why "we have a lot of tech debt" never wins
Because it's unfalsifiable, and it sounds like engineers wanting to rewrite things. Leadership hears a preference. The competing feature request arrives with a customer name attached and a revenue guess beside it. Given one claim with numbers and one without, the numbered claim wins every planning round, and it should.
The pressure gets worse when the board is pushing for AI. I've written before about boards mandating AI before there's a use-case, and the engineering version of that story is a team asked to bolt an AI feature onto a system whose deploy takes forty minutes and whose test suite is red half the time. The debt is now the thing blocking the mandate, and still nobody has priced it.
How we measure the interest
We treat debt as a loan and measure its interest in engineer-hours per month across four buckets: recurring toil, incident time, friction, and blocked work. Each bucket is a count you can source from a calendar, a postmortem, or a CI dashboard, so the total is a number somebody else can check.
- Recurring toil. Manual steps × frequency. A twenty-minute manual database migration step done three times a week is four hours a month, every month, forever.
- Incident time. Hours spent on incidents where this debt was a cause or made recovery slower. Be honest, and use the last quarter's postmortems as the source.
- Friction. Build and deploy time multiplied by how often it happens, plus time-to-first-merged-PR for a new joiner. A flaky forty-minute CI run at thirty runs a day is twenty hours of engineers waiting, per day, even if half of them context-switch productively.
- Blocked work. Features that can't ship until this is fixed. List them by name; don't estimate their value, just make the dependency visible.
A worked example from an internal system, the deploy pipeline:
| Bucket | Interest | Where the number came from |
|---|---|---|
| Recurring toil | ~8 hrs/month | Manual migration step, three times a week |
| Incident time | ~6 hrs/month | Last quarter's postmortems |
| Friction | ~40 hrs/month | Slow CI run × runs per day |
| Blocked work | 2 features | Named on the card, not valued |
| Total | ~54 hrs/month | Fix estimated at 80 hours |
Payback in about six weeks. Written that way it beat a mid-sized feature in the next planning round, and nobody had to argue about craftsmanship.
What goes on the roadmap card
Write the debt item exactly like a feature card: the outcome in plain language, the cost to fix, the monthly interest, the risk of ignoring it, and an expiry date. The expiry is the part people skip. Some debt is fine forever, because the system it lives in is being retired or barely changes.
For the deploy pipeline the outcome line read "deploys in five minutes, migrations automated," which a product manager can hold in their head without knowing what a migration is. Say on the card when a system is on its way out, and stop paying attention to its debt.
What changed once we did this
Fewer requests to rewrite things, because a rewrite priced honestly rarely wins. The debt that did win was the unglamorous kind: pipelines, flaky tests, a manual step everyone had normalized, a config file only one person understood. Engineers stopped bringing "everything is bad" to planning and started bringing invoices, which product people can argue with.
Working across many client codebases at Shanti Infosoft, the pattern is the same everywhere: the debt that hurts most is almost never the debt engineers complain about most. Pricing it is how you find out which is which, and it's the first exercise we run on a software consulting engagement before anyone proposes a roadmap. If you want a second opinion on your own numbers, book half an hour and bring last quarter's postmortems.
What is the most expensive piece of tech debt on your system right now, in hours per month, and could you defend that number to your CFO?
Sagar Jain co-founded Shanti Infosoft on the technical side. The firm runs a CMMI Level 5 delivery process across a team of 80+ engineers.
Top comments (0)