playbook.crastinating.pro
ProcessTwo-way doorPublished 29 April 2026 · 4 min

Setting a tech-debt budget

How much of next quarter to spend on debt — without writing a manifesto, and without backsliding the quarter after.

When to reach for this

The shape of the problem this playbook is for.

  • Velocity is dropping and feature work feels slower than it should.
  • The team's 'wishlist' doc has 40+ items and nobody touches it.
  • An engineer has threatened to quit over a specific piece of legacy code.

Signals you're ready

If these aren't true, you're not deciding yet — you're scoping.

  • You can name the top three pieces of debt and what they cost the team weekly.
  • There's a specific feature that recently took 2× longer than estimated because of debt.
  • There's a debt item that, if fixed, would unlock a feature already on the roadmap.

The rubric

Numbered, weighted, opinionated. Walk through them in order — the first decisive answer often ends the meeting.

  1. Decisive

    What's the weekly cost of NOT fixing this — in engineer-hours, in incidents, or in customer-visible bugs?

    If you can quantify it (>2 hours/week, >1 incident/month, >1 customer escalation/quarter), it's a real debt item. If you can't quantify it, it's a preference. Fix the real ones, leave the preferences in the wishlist.

  2. Heavy

    Does fixing this unlock something on the roadmap, or just make the team happier?

    Unlocks something → it's a feature dependency, schedule it as such. Just makes the team happier → still worth doing, but cap it. The two get confused all the time.

  3. Heavy

    Is the budget a number on a spreadsheet or a meaningful slice of the engineer-week?

    Pick a real number (15–25% of engineer-weeks is a sane default for most teams) and protect it. 'We'll do debt when we have time' = 0%, every time.

  4. Tiebreaker

    Will the budget survive contact with the next surprise?

    If the next P1 incident or executive ask will eat the debt budget, you don't have a budget — you have a wish. Either ring-fence it explicitly, or admit you're not doing debt this quarter.

Default pick

When the meeting is going in circles, ship this — and write down what would change your mind.

20% of engineer-weeks for the next two quarters, ring-fenced and reported on like feature work. Pick the top three items. Stop adding new ones until the three are done.

Red flags

Patterns that mean the playbook isn't your real problem.

  • The debt list is sorted by who shouted loudest, not what costs the team most.
  • Nobody can name what was paid down last quarter.
  • The team is using 'tech debt' as the name for work the org doesn't reward.

Real applications

The playbook used in anger — context and outcome.

  • Context
    CI green time at 18 minutes; engineers were batching commits to avoid waiting.
    Outcome
    Two engineer-weeks went into Turborepo Remote Cache + finer task inputs. Green time dropped to 6m40s. Highest-leverage debt fix the team did all year.
  • Context
    A 'big rewrite of the auth layer' on the wishlist for 14 months.
    Outcome
    Stayed on the wishlist. The debt cost was real but bounded; the rewrite cost was unbounded and would not unlock roadmap. Fixed the two specific footguns instead.