Technical debt: how to measure it, explain it to non-engineers and pay it down

Every software product carries technical debt. Engineers feel it every day: features that should take a day take a week, small changes break unrelated things, and nobody wants to touch certain files. Non-technical leaders feel it too, but as something vaguer: the team seems slower than it used to be, and estimates keep growing.

The problem is rarely that debt exists. It is that it is invisible, unmeasured and impossible to prioritise against features. This article covers how to make it visible, how to talk about it in business terms and how to pay it down steadily.

What technical debt actually is

Technical debt is the gap between how the system is built and how it would need to be built to support the changes you want to make now. Like financial debt, it has a principal, the work needed to fix it, and interest, the extra cost you pay on every change while it remains.

• Deliberate debt: a shortcut taken knowingly, such as hard-coding a configuration to hit a launch date.
• Accidental debt: design decisions that made sense with what you knew then, but no longer fit the product.
• Bit rot: outdated dependencies, unsupported runtimes and tooling that slowly decays when nobody updates it.
• Missing safety nets: absent tests, monitoring or documentation that make every change riskier than it should be.

Not all of it matters. Messy code in a part of the system that never changes costs almost nothing. Debt only charges interest where you are working, so prioritisation starts with where change happens.

This also explains why debt is so easy to ignore. The principal is visible to engineers but abstract to everyone else, while the interest is paid quietly through slower delivery, more bugs and longer onboarding for new hires. Nobody sends an invoice, so the cost rarely appears in planning discussions until it is large.

How to measure it

No single metric captures technical debt, and automated code-quality scores on their own can mislead. Combine a few signals that you can track over time:

• Change hotspots: files that change often and are complex. Version control history shows where the team spends its time.
• Lead time for changes: how long work takes from start to production, and whether that is trending up.
• Change failure rate: how often deployments cause incidents or need a rollback or hotfix.
• Unplanned work: the share of each cycle spent on bugs, incidents and workarounds instead of planned features.
• Dependency age: how far behind supported versions your frameworks, runtimes and libraries are, especially for security fixes.
• Engineer judgement: a short, regular survey asking which areas slow the team down most. It is subjective but often the most accurate signal.

A quick way to find hotspots is to rank files by how often they change. Pair this with your own sense of which of those files are hardest to work in.

# Files changed most often in the last 6 months
git log --since="6 months ago" --name-only --pretty=format: \
  | grep -v '^$' \
  | sort | uniq -c | sort -rn | head -20

Then keep a simple debt register: a list in your issue tracker where each item has a name, the area it affects, the symptom it causes, a rough estimate of the fix and the business impact. The register turns complaints into decisions.

Review the register on a regular schedule alongside the product roadmap, not in a separate engineering-only meeting. Items that have not mattered for months can be closed; items blocking upcoming work move to the top. The goal is a short, current list that a product manager can read, not an exhaustive catalogue of every imperfection.

How to explain it to non-engineers

Leaders do not need to understand the code. They need to understand cost, risk and options. Translate each debt item into those terms.

• Speak about interest, not cleanliness. Every change to pricing takes about a week because the logic is duplicated in four places is persuasive. The pricing code is messy is not.
• Tie it to the roadmap. Show which upcoming features are slowed or blocked by specific debt, and what fixing it first would change.
• Make risk concrete. An unsupported framework version is a security and compliance exposure, not a matter of taste.
• Offer options, not ultimatums. Fix it now, fix it alongside a related feature, or accept it and live with the cost. Let the business choose with clear trade-offs.

How to pay it down

1. Prioritise by interest. Fix debt in hotspots that sit on your roadmap first. Ignore debt in stable code that nobody touches.
2. Reserve steady capacity. A consistent share of each cycle works better than occasional clean-up sprints that get cancelled when deadlines loom.
3. Fix debt alongside features. When a feature touches an indebted area, include the refactor in its estimate. Leave code better than you found it.
4. Add safety nets first. Tests around the behaviour you are about to change make refactoring far less risky.
5. Replace incrementally. Swap out the worst components one at a time behind stable interfaces rather than attempting a full rewrite.
6. Keep dependencies current. Small, regular upgrades are much cheaper than jumping several major versions at once.

Finally, prevent new accidental debt. Code review, automated tests in CI, clear module boundaries and a habit of recording deliberate shortcuts in the register will not eliminate debt, but they keep it visible and under control.

Key takeaways

• Technical debt has principal and interest; only debt in areas you change charges interest.
• Measure with hotspots, lead time, change failure rate, unplanned work, dependency age and team input.
• Keep a debt register and explain each item in terms of cost, risk and roadmap impact.
• Pay down steadily with reserved capacity and by fixing debt alongside related features.
• Prefer incremental replacement and safety nets over a big-bang rewrite.

We help teams assess and reduce technical debt in production systems through our backend work. If your delivery speed is slipping, let's look at it together.