Debt is not a moral failing. Unmeasured debt is.
Debt is a flow of cost
Technical debt is not simply untidy code. It is any past decision that makes current change slower, riskier or more expensive than it needs to be. Its cost appears as longer lead times, recurring incidents, duplicated work and hesitation around releases.
Some debt is rational. A temporary shortcut can buy learning when uncertainty is high. The mistake is taking the shortcut without recording the condition under which it must be repaid.
Measure the interest
Track where delivery repeatedly stalls. Useful signals include time spent repairing builds, frequency of regressions, change failure rate, dependency age and the number of systems touched by a simple feature.
Translate the technical effect into business terms. A fragile deployment process matters because it delays revenue and increases outage risk, not because it violates an abstract ideal.
Manage a portfolio
Maintain a debt register with owner, impact, evidence and next decision. Address high-interest debt during related product work, and reserve capacity for foundational repairs that never fit naturally into a feature.
Avoid large clean-up programmes without measurable outcomes. Small, continuous improvements linked to delivery are easier to verify and less likely to become rewrites that create a new form of debt.