← All resources
Prioritisation guide
12 min read

Stop Asking If Technical Debt Is Good. Ask When You Have to Pay.

Deliberate debt can be rational. Unconditional cost — security, data loss, a corrupted experiment — is not a shortcut. It is a product risk you already took.

Try Ibis Flow free
See prioritisation
The argument is the wrong one. The timing is the decision.

Most teams still moralise technical debt. Engineering calls it reckless. Product calls it shipping. Both sides are answering a question that does not help: is debt good or bad? You already know the answer is 'it depends'. What you do not share is when the bill arrives, and whether you pay it even if the experiment dies.

We already wrote the estimation piece. How to size debt — in the feature, as a backlog item, with SQALE, as an economic case, or as reserved capacity — lives in the June guide. This article starts after that. You can see the item. Now: do you repay it now, only if the bet works, never, or refuse the shortcut in the first place?

A 2026 working paper by Azarang and Azarang Esfandiari gives the distinction a sharper name. Strategic debt loads its expected cost on the success branch: you repay if the hypothesis validates. Toxic debt charges you while you hold it — security exposure, data loss, a learning signal you can no longer trust. The maths in that paper are illustrative. The split is usable on Monday.

Why 'good versus bad' never ends the fight

If the only frame is virtue, engineering loses to the roadmap and then gets blamed for the interest. If the only frame is speed, product ships a liability that does not wait for product-market fit.

Four fights that are really timing fights

The cleanup that has no trigger

A repayment ticket with no owner, no event, and no 'we pay this when X' is not strategic. It is unmanaged. It will lose every prioritisation round because nothing makes it due.

The shortcut that costs if you fail

Skipping encryption, skipping backups, or faking the experiment metric is not a call option. You pay if the bet works and you pay if you kill it. Azarang calls that toxic. Fowler would just call it interest you cannot choose to stop.

Maximum debt at maximum uncertainty

The folk rule says take the most debt when you know the least. That fails when failure redirects — a pivot that reuses the code — and the salvage gap is bigger than the cheap-build discount. You then pay to unwind work that was never going to be thrown away.

Debt as a code-quality score

Li, Avgeriou and Liang's 2015 mapping already showed the literature clustering on code-related debt. A 2024 mapping of technical debt in continuous software engineering (41 studies) found most CSE activities still do not address debt, and none cover the whole cycle. Static analysis will not tell you whether last week's experiment corrupted the learning.

Prioritisation is the missing activity. Not another hour count. A decision about when the cost lands, and whether it lands even if you stop.

Treat debt as a timing problem, not a moral one

Deliberate debt is rational when three things are true: the hypothesis is uncertain, the experiment is cheap, and you can actually abandon the work. Then the extra future cost sits on the success branch. You buy speed now and repay only if the product lives.

Toxic debt breaks that bargain. Security exposure, irrecoverable data, and a metric you taught the team to game all charge you while you wait. They also charge you if you cancel. Those items belong next to other product risks, not in a 'nice to clean up' column.

The June article already said: if you take a shortcut, create the repayment item at the same time. This article adds the missing fields on that item: the trigger, the branch it sits on, and whether failure still bills you.

Write the trigger or you did not decide

Validates. Hits ten paying teams. Fails a security review. The system is scheduled to retire. 'We will know it when we feel it' is how unpaid interest becomes culture.

Four repayment postures you can actually choose

You are always in one of these, even if nobody named it. Naming it is the prioritisation move.

A

Option A: Repay now

The cost is already unconditional, or the area is on the critical path of work you will do anyway. Pay before the next bet, not after.

B

Option B: Repay if it validates

Strategic debt. Write the trigger at the commitment boundary — product-market fit, a signed design, a second customer in the same shape. Do not repay a prototype you are allowed to delete.

C

Option C: Carry until you retire it

The system is short-lived, rarely touched, or already scheduled to die. Interest is near zero. Leave it, and say so in the backlog so it stops returning as a grievance.

D

Option D: Refuse the shortcut

The proposed debt is toxic. Do not take it. Build the smaller safe slice, or kill the experiment. Speed that corrupts learning is not speed.

Option A: repay now

You pay this sprint or this quarter because waiting does not buy option value. The downside is already running, or the next roadmap slice walks through the same mess either way.

When now is the honest date
  • Security, compliance, or data-loss exposure that does not pause if the feature misses
  • A hotspot you will touch on the next three roadmap items — interest is already on the invoice
  • A learning signal you no longer trust: the experiment cannot teach you anything until the instrumentation is honest
Where paying now is cheaper
  • Unconditional cost stops accumulating
  • The next feature estimate shrinks for a reason you can show
  • You stop arguing about a risk everyone can already name
Where 'now' is theatre
  • Paying a prototype you are about to delete
  • A TDR hotspot in code nobody will change this year
  • A refactor with no trigger except taste

Now is for unconditional bills

If cancelling the experiment would still leave you exposed, you are not holding an option. You are holding a leak.

Option B: repay if it validates

This is the real-options posture. You took the cheap path so the hypothesis could be tested. The repayment ticket is created now and dated to a validation event — not to 'later'.

A simple matrix contrasting success-contingent cost with unconditional cost across short experiments and long-lived systems
What the ticket has to say
  • Hypothesis: we think segment X will pay for this workflow
  • Shortcut: one shared table, no separate read model
  • Trigger: first three customers in that segment live, or we drop the workflow
  • Repayment: split the model before we scale traffic or sell the second workflow on the same table
Where the option is real
  • Early product work with a kill switch
  • A spike you are allowed to throw away
  • Debt whose interest is almost only paid if you keep the feature
Where it pretends to be an option
  • No written trigger — 'we will refactor after launch' is a wish
  • Failure reuses the code (a pivot) and you still have to unwind the shortcut
  • The cheap path already corrupts the metric you will use to decide

Azarang's warning, in plain language

The paper's calibrations are not measurements. The usable claim is simpler: if failure redirects rather than kills the work, 'max debt at max uncertainty' can be the expensive choice. Write whether a miss deletes the code or recycles it.

Option C: carry until retirement

Some debt should never be repaid. The system is dying, the module is cold, or the remaining life is shorter than the payback. The decision is still a decision. Record it so the item stops haunting planning.

How to carry it without lying
  • Name the asset and the retirement or freeze date
  • Confirm the debt does not create security, data, or compliance exposure while you wait
  • Close or park the repayment item with that rationale visible to product and engineering
Where carrying is the adult move
  • Platforms already on a kill list
  • Ugly, stable code that nobody touches
  • Experiments you already decided to stop
Where 'later' is denial
  • A retirement date that slips every quarter
  • Cold code that suddenly sits on a new integration
  • Carrying toxic debt because the feature might die — the exposure does not die with it

Park it in public

Hidden 'we will never pay this' is how engineering loses the next argument. Written 'we will never pay this, and here is why' is prioritisation.

Option D: refuse the shortcut

Some proposed debt is not a discount on a call option. It is a cost you cannot put on the success branch. Do not take it. Shrink the experiment until the safe path is cheap enough, or do not run the experiment.

What refusal looks like in a planning room
  • Name the unconditional cost in the same sentence as the shortcut
  • Offer a thinner slice that keeps the signal clean
  • If the thinner slice is still too slow, kill the bet — do not buy speed with a poisoned metric
Where refusal is the product decision
  • Anything that can lose customer data
  • Anything that makes the experiment unable to falsify the hypothesis
  • Anything that creates a security or compliance event while you 'just test'
Where refusal becomes dogma
  • Treating every shortcut as toxic so nothing ships
  • Confusing taste ('I hate this module') with unconditional cost
  • Refusing local cleanup that belongs in the feature estimate — that is the June article, Option A

Toxic is a product word

If the downside happens even when you stop, it is not an engineering preference. Put it on the same list as the other risks you would not take for a week of calendar time.

Which posture fits the bill you actually hold

Read down the left. The first matching row is the default. Argue from there, not from mood.

QuestionA: NowB: If validatesC: CarryD: Refuse
Is the cost unconditional while you wait?Usually yes — payThen this is the wrong postureOnly if remaining life is tiny and exposure is noneIf you have not taken it yet — refuse
Does failure delete the code?Rarely the reason to pay nowYes — this is the home of strategic debtOr you already decided to delete the systemIrrelevant if the shortcut is toxic
Will failure recycle the code (pivot)?Price the unwind now if it is already in the wayWeak — salvage may wipe the discountOnly if the recycled life is still shortIf recycle plus shortcut corrupts learning — refuse
Is the system already dying?No — do not repay a corpse unless it is toxicNo trigger will fireYesStill refuse new toxic shortcuts on a dying system
Can you write a trigger this week?The trigger is 'already due'Required, or it is not an optionThe trigger is the retirement dateThe trigger is 'do not start'

Is the cost unconditional while you wait?

Now

Usually yes — pay

If validates

Then this is the wrong posture

Carry

Only if remaining life is tiny and exposure is none

Refuse

If you have not taken it yet — refuse

Does failure delete the code?

Now

Rarely the reason to pay now

If validates

Yes — this is the home of strategic debt

Carry

Or you already decided to delete the system

Refuse

Irrelevant if the shortcut is toxic

Will failure recycle the code (pivot)?

Now

Price the unwind now if it is already in the way

If validates

Weak — salvage may wipe the discount

Carry

Only if the recycled life is still short

Refuse

If recycle plus shortcut corrupts learning — refuse

Is the system already dying?

Now

No — do not repay a corpse unless it is toxic

If validates

No trigger will fire

Carry

Yes

Refuse

Still refuse new toxic shortcuts on a dying system

Can you write a trigger this week?

Now

The trigger is 'already due'

If validates

Required, or it is not an option

Carry

The trigger is the retirement date

Refuse

The trigger is 'do not start'

Decision rules for the planning room

If the condition is true, pick the posture. Do not reopen 'is debt good'.

  • If the downside happens even when you kill the experiment — security, data loss, a metric you can no longer trust — then treat it as toxic. Repay now or refuse the shortcut. Do not file it as strategic.
  • If the expected cost sits only on the success branch and you can actually delete the work, then create the repayment item with a validation trigger. That is strategic debt.
  • If failure will recycle the code rather than delete it, then do not apply 'max debt at max uncertainty'. Price the unwind before you take the shortcut.
  • If you cannot write the trigger this week, then you do not have an option. You have unmanaged debt. Either pay it, refuse it, or write the trigger.
  • If the system will die before the interest matters and the debt is not toxic, then carry it and say so in the backlog.
  • If a static-analysis score is the only argument, then you are still in the June article. Estimation is not prioritisation.
  • If the area is on the next three roadmap items, then 'later' is already now — the interest is in those estimates.
  • If stakeholders reject repayment, then name the trade in their language: slower next bets, a dirtier experiment, or an exposure that does not wait for launch.

Sources and their limits

Pay on the branch where the cost actually sits

Good versus bad is a stalled conversation. Success-contingent versus unconditional is a prioritisation conversation. Write the trigger. Write whether a miss deletes the code. Write whether you pay even if you stop.

Do that in the same backlog as the feature work. Debt that only lives in a static-analysis dashboard will lose to every roadmap item, including the ones it is already taxing.

If you cannot say when you would pay, you already decided not to. Own that, or change it.

How to estimate technical debt — the five methods Choosing a prioritisation technique When green tests are not the job

Make the repayment trigger visible in the backlog

Ibis Flow keeps rationale, risk, and order in the same conversation as the feature work — so 'we will pay it if it validates' is a recorded decision, not a hallway promise.

Start free trial
See prioritisation