Technical debt is often managed as a collection of tickets that compete unsuccessfully with product features. The backlog grows, engineers repeat that the system is fragile and leadership struggles to distinguish urgent risk from general dissatisfaction.
This model fails because technical debt is not one type of work. It is a portfolio of liabilities with different costs, probabilities and strategic effects. Managing it well requires classification and investment decisions, not a periodic appeal to "spend twenty per cent on tech debt".
Name the consequence
A debt item should describe the cost it creates. Does it slow every release, increase incident probability, prevent a product capability, create security exposure, depend on unsupported technology or concentrate knowledge in one person?
"Refactor the checkout service" is an implementation proposal. "Checkout changes require three days of regression testing and fail twice as often as other services" is a decision-ready problem. The second statement can be compared with other investments.
Separate debt categories
A practical portfolio might distinguish:
- Operational risk: weaknesses likely to cause incidents, data loss or prolonged recovery.
- Delivery friction: repeated manual work, slow tests, brittle environments and unclear ownership.
- Strategic constraint: architecture that blocks a planned market, product or scale requirement.
- Compliance and lifecycle: unsupported runtimes, expiring contracts, licences or regulatory gaps.
- Maintainability: complexity that raises change cost or knowledge concentration over time.
These categories support different decisions. Operational risk may justify immediate remediation. Delivery friction may be best addressed incrementally. A strategic constraint should be sequenced against the roadmap that makes it relevant.
Quantify without pretending to know the future
Exact financial estimates are rarely possible, but relative evidence is valuable. Record incident history, hours lost, affected services, deployment delay, support burden and the number of upcoming initiatives exposed to the problem.
Use ranges and confidence levels rather than invented precision. A debt item with high impact, repeated evidence and a clear remediation path should outrank a theoretically severe concern with no plausible trigger.
Choose a treatment
Not every debt item should be repaid. Leaders can remediate it, contain it, accept it for a defined period or retire the affected capability. Sometimes the correct decision is to stop investing in a low-value system and isolate it until replacement.
Every accepted item needs an owner and review trigger. Acceptance without a date, threshold or accountable person is simply neglect expressed politely.
Fund debt through the work it affects
Some remediation belongs in dedicated platform or reliability investment. Other debt should be included in the feature that encounters it. If a new commercial capability depends on changing a brittle subsystem, the enabling work is part of the feature cost, not an unrelated engineering preference.
This makes trade-offs visible to product leadership and prevents delivery plans from assuming that old constraints can be ignored.
Report movement, not backlog size
A growing debt register may indicate better discovery rather than declining quality. Track exposure instead: critical unsupported components, recurring failure modes, hours lost to friction and strategic initiatives blocked. Show which risks were reduced and which were consciously accepted.
The objective is not zero technical debt. A company that takes no debt may be moving too slowly. The objective is an understood portfolio aligned with business appetite.
When technical debt is described through consequences, evidence and treatment choices, leadership can govern it like any other investment. It stops being a vague argument between engineering and product and becomes a disciplined conversation about risk, speed and future options.