Searches for "technical debt" have grown by over 35% in the past two years, driven in large part by UK engineering teams inheriting legacy systems built under deadline pressure and now struggling to maintain or extend them. The term gets used loosely in Jira backlogs and sprint retrospectives, but most developers have never seen a precise definition, let alone a systematic strategy for dealing with it.
This guide covers what technical debt actually is, where it comes from, how to measure it, and the practical strategies that work in real UK product teams. It draws on Ward Cunningham's original metaphor and Martin Fowler's quadrant model, then connects them to day-to-day decisions you can act on this sprint.
TL;DR
Technical debt is the implied cost of rework caused by choosing a faster, easier solution now instead of a better one. Like financial debt, it accrues interest over time.
Fowler's four quadrants split debt into reckless versus prudent and deliberate versus inadvertent, and each quadrant needs a different response.
