The term tech debt has become a stumbling block for engineering teams. It's often used to describe a backlog of work that slows down feature development, increases support costs, and threatens system stability. Yet, when developers bring these issues to stakeholders, the work remains deprioritized. This is because the term positions engineering work as backward-looking cleanup rather than forward-looking value creation. It's defensive and ambiguous, guaranteeing that the work never gets prioritized.

The metaphor of tech debt is problematic because it's too vague to be actionable. When someone mentions tech debt, they could be referring to intentional tradeoffs made under time constraints, unanticipated consequences of reasonable decisions, or outright mistakes. This ambiguity makes it impossible to have productive conversations about what needs to be done. Additionally, the metaphor obscures actual costs and consequences, making it difficult to communicate the urgency and accountability needed to address these issues.

To break this cycle, developers are encouraged to replace the term tech debt with more specific categories when talking to stakeholders. These categories include Corrections for problems causing immediate harm, Optimizations for improving efficiency and cost, and Re-Alignments for unlocking future capabilities. By using these categories, developers can communicate the business impact of their work more clearly, making it easier for stakeholders to understand and prioritize the necessary changes.