Technical debt is one of those terms that can become too emotionally loaded to be useful. Once that happens, every imperfect system starts to feel like a crisis.
A better approach is to ask more specific questions. Which parts of the system are slowing delivery? Which parts are increasing incident risk? Which parts make onboarding harder or reduce confidence in change? Debt is easier to manage when it is described through concrete consequences.
That framing changes how teams act. Instead of promising to rewrite everything, they can sequence improvements around the places where friction is highest. Small structural changes, if chosen well, often deliver more value than dramatic rebuilds.
From a philosophical perspective, this is really a question about judgment. We never work with unlimited time or unlimited certainty, so the goal is not purity. The goal is to choose what deserves attention now and remain honest about the costs of delay.