Technical debt is not one backlog. It is a portfolio of constraints with different costs, risks and timing.
A dated component in a stable low-impact service may be tolerable. A fragile integration changed every week may be expensive even when the code appears modern. Treating both as equal produces either neglect or endless cleanup.
What good engineering looks like
Record each material debt item with the business capability affected, failure mode, change demand, security exposure, workaround cost and remediation options. Review the portfolio alongside product and operational priorities.
-
Impact if the constraint fails.
-
Frequency of change around the constraint.
-
Evidence of incidents or delivery delay.
-
Cost and reversibility of remediation.
-
Dependencies that change the timing.
A practical starting point
-
Start with the ten constraints teams mention repeatedly.
-
Attach operational evidence to each.
-
Rank urgency and value separately.
-
Fund one risk reduction and one delivery-enabling item.
The decision to make
The decision is not whether debt is good or bad. It is which constraint deserves investment now and which risk the organisation consciously accepts.