Technical debt: naming it, tracking it, negotiating it

Ward Cunningham coined "technical debt" to describe a specific, deliberate trade-off: shipping a quick, imperfect implementation now to learn something real from the market sooner, with a clear intention to go back and rewrite it properly once that learning has happened — a genuine loan against future velocity, taken on knowingly, in exchange for speed today. The metaphor's financial framing was precise on purpose: like real debt, it's not inherently bad — it can be a reasonable, even smart, tool — but it accrues interest, and interest compounds if the principal is never paid down.

In current everyday usage, "technical debt" has drifted into a catch-all for "code we're not proud of" — messy code from rushed work, code that was simply written poorly, code that's aged badly as requirements shifted around it. That drift matters practically: not everything called technical debt was actually a deliberate trade-off, and conflating "a knowing shortcut with a plan to revisit it" with "we didn't know better at the time" or "we were careless" obscures what's actually owed and why.

Martin Fowler's well-known refinement of the metaphor sorts debt along two axes — deliberate vs inadvertent, and prudent vs reckless — precisely because "we knowingly took a smart shortcut" and "we didn't know any better" and "we knew this was risky and did it anyway" are three very different situations that all get flattened into the same phrase in casual use, even though the right response to each is different.

Technical debt's defining trait, compared to almost any other kind of backlog item, is that it's invisible to the people who'd naturally prioritize it — a Product Owner and stakeholders see feature velocity slowing down over time, without a direct, legible line back to why. A slower-shipping codebase looks, from outside engineering, like the team just got less productive — not like the predictable, compounding interest payment on unaddressed shortcuts. This asymmetry (engineers can see the debt directly; the people who prioritize the backlog usually can't) is the actual root cause of debt going unaddressed, more than any individual person being unwilling to prioritize it.

The practical fix for that invisibility is refusing to let technical debt exist purely as tribal knowledge or a private "someday" list — it goes on the backlog as real, visible, estimated items, described in terms of concrete impact rather than abstract code-quality language:

The second version gives a Product Owner what they actually need to make a real trade-off call — not "this code isn't nice," but "here's the recurring cost of not doing this, expressed in the same terms (bugs, risk, velocity) as everything else competing for the same sprint capacity."

A team that presents debt work purely as "we should pay this down because it's the right thing to do" is asking a Product Owner to deprioritize a feature stakeholders are actively asking for, based on an argument with no concrete, comparable cost attached — a genuinely hard sell, and often, correctly so from the PO's side, since "the right thing to do" isn't obviously more valuable than a feature a customer is waiting on. Framing debt in terms of its measurable cost (velocity lost, bug rate, onboarding time for new engineers, incident frequency) gives the Product Owner an actual trade-off to weigh against feature work, using the same currency — instead of asking them to take engineering's word for it on faith.

Some teams reserve a fixed portion of every sprint (commonly cited around 20%) specifically for debt paydown, rather than relying on it winning a case-by-case priority fight against every new feature request. This isn't a magic number — it's a structural acknowledgment that debt paydown, argued feature-by-feature against a Product Owner's immediate priorities, predictably loses almost every single time, because a concrete feature request is legible and urgent in a way that "prevent bugs that might happen next quarter" rarely is on any given day. A standing allocation removes that recurring fight entirely, rather than trying to win it repeatedly.