A shortcut buys speed today by borrowing against tomorrow. The principal is the mess you left behind; the interest is that every future change in that area is a little slower — and it compounds, quietly, until a team is sprinting flat out just to stand still. That's the mystery of velocity grinding to a halt with no single culprit. Modelled as a loan, "tech debt" stops being a vibe and becomes a number leaders can reason about: what you borrowed, the rate you're paying, and the moment repaying becomes the smart move.
You took a shortcut. Now choose your strategy and watch two futures diverge. Keep borrowing stays fast at first, then decays toward a crawl as interest compounds. Pay it down costs you a dip now while you refactor — then runs faster forever. Drag the sliders and find the point where repaying starts to pay for itself.
The word "debt" makes people hear "mistake". But a loan isn't a moral failing — it's leverage. Used well, debt lets you reach something sooner than you otherwise could. The question is never "is there debt?" It's "did we borrow on purpose, do we know the rate, and is there a plan to repay?" Here's how this lens differs from the two it's most often confused with.
Treats every shortcut as sloppiness to be ashamed of. It moralises the mess instead of pricing it — so the deliberate, repaid shortcut and the rotting accident get the same shrug, and nobody can tell smart leverage from a genuine trap.
Treats a shortcut as a loan with a principal, a rate and a repayment date. It turns "we should clean that up sometime" into numbers: how fast velocity decays, how much you've lost, and when repaying pays for itself.
That tool is about the pile: hacks stacking up faster than you clear them, and how to manage the stack before it tops out. It's the game of what to tackle and when.
So when is a shortcut smart leverage, and when is it a trap? Same act — borrow speed now — but the two could not be more different.
| Good debt — smart leverage | Bad debt — a trap | |
|---|---|---|
| Intent | Deliberate, eyes open. You chose to borrow. | Accidental, or borrowed in denial that it's debt at all. |
| The rate | You know roughly how much it'll slow you, and where. | Interest accrues invisibly. Nobody's tracking it. |
| Repayment | There's a trigger or a date: "refactor after launch". | "We'll clean it up later." Later is never scheduled. |
| Blast radius | Contained. The shortcut is walled off behind an interface. | Spreads into everything it touches; copied everywhere. |
| What it bought | A real, time-boxed win: a deadline hit, a bet tested. | Nothing you needed — just haste, or not knowing better. |
| The maths | Interest stays cheap relative to the advantage you gained. | Interest already exceeds whatever the shortcut ever saved. |
Fowler splits debt on two axes: was it taken on deliberately or inadvertently, and was the call prudent or reckless? The four cells need completely different responses. Read each situation, place it in the quadrant, then see what to do about that kind of debt.
Tap the quadrant you think it belongs in.
You've seen every one of these. What separates them isn't whether debt was taken on — it's whether anyone kept servicing it. Each card is the same act of borrowing, with a different relationship to the interest.
A hard-coded shortcut shipped for a Friday demo. It "worked", so nobody touched it. Three years on it sits under the checkout flow, and every new feature has to route around it.
The interest
A team hard-codes the payments logic to ship an MVP and test demand. They write down exactly what's faked and why, with a ticket titled "repay once we have PMF".
The interest
A decade of "just this once" shortcuts on the core platform, each shipped knowingly, none ever repaid. The compounding finally arrived all at once.
The interest
The most common loan of all. Not reckless in the moment, not really deliberate either — just deferred, again and again, until "later" quietly becomes never.
The interest
The hard part isn't spotting debt — it's the habit around it: borrowing on purpose, pricing the interest before it compounds, and scheduling the repayment while it's still cheap. That's the work we do with the engineering leaders and teams we coach: turning "tech debt" from a vague anxiety into a line item they can plan, defend, and pay down deliberately.
Talk to us about coachingBorrowing isn't the sin — leaving the loan unserviced is. A deliberate, contained, repaid shortcut is leverage. Judge debt by whether anyone is paying it down, not by whether it exists.
Velocity doesn't fall off a cliff — it erodes a few percent at a time. By the moment it's obvious, the balance is already huge. That's why teams grind to a halt with no single change to blame.
Make debt a line item: what we borrowed, roughly what it costs us per sprint, and the trigger to repay. A number and a date beat a vibe — that's the whole difference between leverage and a trap.