How do you prioritise technical debt?

Direct answer

What a strong answer covers

How it works

Debt is prioritised like any other work: by cost of carrying it versus cost of paying it. The carrying cost shows up as incidents, slow delivery in the areas the debt touches, security exposure, and onboarding pain, and it can be estimated from incident logs, cycle times, and how often the area changes. Debt in code nobody touches is cheap to keep. The pitch is a measurable outcome, such as fewer pages or a shorter release cycle, and the work is scheduled next to the feature it blocks so the improvement is visible rather than abstract.

Example

A team tracked that 40 percent of their incidents came from a hand-rolled retry layer and that every feature touching it took a week longer than estimated. Replacing it was scheduled before the next integration project that depended on it, with the success metric defined as zero retry-related incidents in the following quarter, which the team then reported.

Common mistakes

• Asking for a quarter of pure refactoring with no measurable goal.
• Paying down debt in a stable module nobody changes because it looks ugly.
• Letting debt accumulate silently instead of recording it where planning can see it.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.