How do you identify, prioritize, and pay down technical debt?

Question

Accepted Answer

**Technical debt** is the gap between how the code is and how it should be, taken on (deliberately or not) to move faster. Some debt is fine; the job is to manage it, not eliminate it. The key is prioritizing the debt that actually *hurts*.

## Prioritize by impact, not annoyance

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## A concrete example

A fragile module that breaks on every release and blocks the team weekly is worth fixing. An ugly-but-stable utility that nobody touches is *not*, even if it offends you. Refactoring it is vanity, not value.

## How to fund the work

Pure "debt sprints" rarely get approved. Better tactics:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Why it matters

Unmanaged debt compounds: velocity quietly drops until the team can barely ship.

But chasing every imperfection wastes time on debt that doesn't matter.

A TL's value is knowing the difference and making the case to leadership in *business* terms, not just engineering ones.