How to identify technical debt that is already affecting the business

“That change is small, why does it take three weeks?”

It’s a question many managers ask their technical team or vendor. Sometimes the answer is a bad estimate. Many other times, the answer is technical debt: past decisions that made the system harder to change, and that now charge interest on every modification.

Martin Fowler describes technical debt with that metaphor: today’s shortcut is a loan, and the extra effort required for each future change are the interest payments. Not all debt is bad; sometimes it makes sense to take it on to meet a deadline. The problem is not knowing how much you have.

Symptoms you can see without reading code

A symptom is not a diagnosis. Two systems with the same symptom can have different causes, and the only way to know is to inspect.

Gather evidence

• Times: how long recent changes took versus estimated.
• Incidents: which errors repeated and how much they cost to fix.
• Versions: which language, framework or plugins you use and whether they are still supported. PHP, for example, publishes which versions have active and security support.
• Deployments: how often and with how many failures. The DORA metrics provide a framework to measure frequency, lead time, failure rate and time to recovery.
• Security: whether there are pending reviews against known risks, like those listed by OWASP.

Consequences and risk

For each identified debt, write its consequence in business language: “each change in the pricing calculator costs twice as much,” “an unpatched version exposes customer data.” Then estimate likelihood and impact. This turns a technical conversation into an investment decision.

Prioritize

1. First, things that are a security or continuity risk.
2. Then, things that block your roadmap initiatives.
3. After that, things that cause repeated errors.
4. Finally, things that are merely annoying.

You don’t need to pay all the debt. Often it’s enough to reduce it in the areas you change most.

Applied example

Limits

This guide helps recognize signals and structure the conversation. It does not replace a technical inspection of the system, and no serious diagnosis should be issued without one.

How to use the downloadable register

1. Record each symptom with its evidence.
2. Indicate whether it was inspected.
3. Write the business consequence.
4. Rate likelihood and impact.
5. Move high priorities into your roadmap.

Criteria for prioritizing

Complete synthetic example

Synthetic example. In a fictitious company, every change to the billing module takes weeks and often breaks something else. The manager records three symptoms with evidence: the last four changes produced production errors, only one person understands the module, and the PDF generation library hasn’t been updated in years.

They request a scoped technical inspection. The report confirms the module has no automated tests and the library no longer receives security updates. Translated to business: each change risks billing errors to customers and the company depends on a single person.

Prioritize: high likelihood and high impact. Add two actions to the roadmap: basic tests for the most-used billing flows and replacement of the library. Document the key person’s knowledge in parallel. Invented example.

Questions for your technical team or vendor

• Which parts of the system are scary to touch and why?
• Which components no longer receive updates?
• How much of the system has automated tests?
• What knowledge exists only in one person’s head?
• What would it cost to do nothing for six months?

How to know if it worked

• Each symptom has evidence and a business consequence.
• High priorities are in the roadmap.
• Critical knowledge is documented.

Plan for the first four weeks

1. Week 1: record symptoms with evidence.
2. Week 2: request a scoped inspection.
3. Week 3: translate findings into consequences and prioritize.
4. Week 4: move actions into the roadmap.

Diagnosis before starting

• List the changes that took longer than expected in the last six months.
• Ask which parts of the system developers avoid touching.
• Check when the main components were last updated.

A second, contrasting example

Synthetic example. A fictitious company suspects technical debt because changes are slow. The inspection shows a reasonably healthy system: the slowness came from unclear requirements. Instead of rewriting code, they improve how change requests are specified. Unlike the first example, the symptom was not technical debt. Invented example.

What to do when something fails

• If the inspection is inconclusive, request concrete evidence for each finding.
• If a fix breaks something else, add tests before proceeding.
• If there’s no budget, prioritize only high-risk items.

How to measure it with your own data

• Record the time between requesting a change and having it in production.
• Count production errors that appear after each change.
• Note how many times the key person is needed to resolve something.
• Check how many components remain without updates.

Collect these data before tackling the debt and repeat them three months later. If changes take less time and cause fewer errors, the investment is working. If they don’t change, review whether the chosen action addressed the real cause or only a symptom.

Common mistakes

• Diagnosing by symptoms without inspecting.
• Wanting to rewrite everything from scratch.
• Ignoring debt until an incident occurs.
• Describing debt only in technical terms.
• Not recording debt that was intentionally taken.

Checklist

• Symptoms with evidence.
• Inspection before diagnosing.
• Consequences in business language.
• Priority based on risk.
• Actions in the roadmap.