Short answer
Technical debt is not code being old or ugly; it is the business impact of structures that slow change, increase outages or tie knowledge to one person. Express debt in terms of business impact, document each finding with an example and pay it down in small steps alongside product work.
Express debt through business impact
An old library or a long file is not automatically the most important problem. Slower delivery, repeated incidents and critical knowledge held by one person have more direct business effects.
Inventory and prioritise
Attach evidence, the affected workflow, frequency and estimated remediation effort to each finding. Security updates, data-loss risks and missing tests in frequently changed modules can have different priorities.
Connect improvement to product work
Adding tests and simplifying a module already due for change may be more practical than a large cleanup project. Break architectural improvements into small, verifiable stages.
Track the result
Deployment frequency, change-related failures, recovery time and task completion time can be useful measures. The goal is to understand maintenance burden rather than score individual team members.
When it is reasonable not to pay the debt
Not every piece of technical debt has to be paid. Fixing a module that rarely changes, causes no trouble and will soon be retired often does not repay the investment. Priority is set by change frequency and error cost together; frequently changed and costly-to-get-wrong areas come first.
A practical evaluation exercise
Choose a module that repeatedly complicates recent changes. Link waiting time, rework and incidents to those tasks. Make a narrow improvement, then compare effort and defects on a similar subsequent task. Record the business effect and uncertainty instead of assuming that a broad refactor will automatically pay for itself.
Frequently asked questions
Two questions we are often asked on this topic.
How is technical debt measured?
There is no single number. Indicators such as change lead time, errors after changes, rollback frequency and completion time of specific jobs are tracked over time. The aim is not to score the team but to see whether the maintenance burden is falling.
Should I run a separate project for the debt?
Mostly no. Adding tests and simplification to a module that is about to change is more practical and less risky than a separate large clean-up project.
