Main idea

Not everything called technical debt is one. Badly structured code, weak architecture, a complexity known for years, a latent risk: these are discomforts. They exist, they weigh, they carry no due date and nobody pays them on any given day.

The debt appears the moment the company decides to pay it down. That decision is what creates the object: it sets an amount — the cost of dealing with it —, a beneficiary and a moment. Before it, there is nothing to record; after it, there is a product topic like any other, comparable to features and arbitrable alongside them.

The usual trigger for that decision is a tipping of costs: the discomfort becomes more expensive to live with than to deal with — because it blocks a strategy, sharply slows the team down, exposes the company to a risk, degrades the quality the customer perceives, or prevents an important product change.

Why it matters

It defuses a conversation that goes in circles between developers and product. As long as debt is presented as a state of the code, it gets discussed in terms of cleanliness, and product has no handle on it. Requalified as a decision to pay down, it gets discussed in terms of cost and becomes arbitrable.

It also explains why debt inventories almost never produce work: they list discomforts, and a discomfort asks nothing of anyone.

Nuances and limits

The requalification has a downside: it gives product the right never to decide, and therefore to let a risk build up until it becomes an incident. Untreated discomfort is not free, it is simply uncounted.

And the tipping of costs is hard to establish before it shows itself — a team slowing down is easier to observe after the fact than at the moment the decision would have to be made.

Open questions

• Which signals announce the tipping of costs early enough for the decision to pay down to come before the incident?