Tech debt business case: a one-page template, and how to get it funded

The request is not wrong. Its shape is. "Time for tech debt" sits on top of a decision nobody has stated: what the team stops delivering to pay for this, and who agrees to that. My book Before the Room calls the visible request the tip and the decision underneath the mass. A better slide about the networking layer is still the tip.

The vocabulary hurts too. My book Controlled Change defines architecture debt without the word ugly: "It is a current design property that increases expected future cost or risk." A leader who hears "refactor" hears an engineering preference with no end date. A leader who hears "each release loses two days to manual signing fixes" hears a cost on their own books. And the usual cure fails on its own terms: a separate tech debt quarter, the book says, "often produces a temporary cleanup followed by ordinary neglect." Its alternative is to tie debt to product outcomes, reserve capacity for systemic controls, and fold architecture work into the feature delivery that caused it. That is a case made item by item, which is what the page below is for.

Write the decision as a choice between named alternatives before anything else. Not "address the offline queue" but "whether we spend two engineer-weeks next cycle versioning the offline queue, or keep saved filters on its date". Before the Room's test for that line: "If you cannot phrase it as a choice, you have not found it yet."

Then find who owns it: the person who owns the capacity the decision spends, which is rarely the person who feels the debt most. Put one name in that line. "Leadership" and "the team" are not owners, and a decision without a named owner gets reopened by whoever posts next.

Before the Room lists the last row among the ways its method fails: when everyone you ask points to someone else, that is the finding, and the move is to escalate the missing owner instead of drawing more map. A business case addressed to nobody gets a sympathetic reply and no capacity.

Two cases belong on other pages. If every team has to move off the old code, you are funding a migration, where the cost lands on whoever moves first; the architecture migration answer walks through that shape. If the case has grown into "rewrite the app", rewrite or refactor a mobile app covers that decision and its kill criteria. This page is for the debt one owner can fund.

Controlled Change opens its chapter on the economics of abstraction with a line that works for any debt: "Abstraction is a loan." Borrowing is not the sin: "The mistake is borrowing without naming the return." A debt case reads the same loan from the other end, showing what the team pays to keep it and what it costs to pay it off.

The book's debt record gives the fields: the affected capability and owner, the pressure, the evidence, the interest (the cost paid per change or per period), the principal (the estimated cost to remove it), risk and reversibility, the trigger for action, and the relationship to the roadmap. Interest is the line most cases get wrong. It has to be a rate, not a story: per pull request, per release, per quarter. On mobile, the debt shows up in places your tools already record, so pick the category, then the unit:

Those six come from Controlled Change's list of nine categories; security and privacy, platform, and deprecation debt price the same way. Naming the category tells the owner what kind of risk they are buying down before they read a number.

Then choose which debt to bring. The book's rule: "Prioritize debt that compounds or blocks strategic work." Its fictional reference system, Atlas, weighs an old networking wrapper engineers dislike, which behaves stably, against offline FieldOps queue records with no schema version, which cannot survive a planned payload change and threaten to lose unresolved reports during an upgrade. The portfolio funds queue versioning, old decoder fixtures and recovery UI; the wrapper waits until a provider change creates real pressure. The debt engineers complain about is not always the expensive one.

Be straight about the estimate. Measured interest is evidence; extrapolated interest is an assumption, and the page should say which is which. Before the Room's line applies to every debt case: "A good artifact exposes weak evidence; it does not hide it." An owner who finds one inflated number discounts the rest.

A correct number in the wrong currency still loses. CI minutes mean a lot to you and little to a product lead whose quarter is scored on two launches. Before the Room's chapter on incentives starts from a premise worth keeping: when a competent person resists a good technical proposal, they are often being rational from where they sit. The owner who says "after the launch" is protecting a roadmap commitment, a headcount story or a survivable on-call rotation that your case asks them to spend.

The book's way to find out is a question you do not already know the answer to, asked one on one. Its version is written for a migration and works for debt: "What would this migration cost your team specifically, in the next two quarters, given everything else you are carrying?" Then listen without countering. Controlled Change adds the map of who needs which evidence: product looks at user capability, roadmap, experiment velocity and opportunity cost; leadership and finance at risk, staffing, timeline, vendor and cloud cost. Applied to a debt case, with the numbers left for you:

The strongest version ties the debt to something the owner already wants. In the Atlas case the payload change is the lever: the debt is a precondition for a roadmap item, not a cleanup request. When no such tie exists, the debt may not be worth funding yet, and the right output is a lower rank on your list, not a louder slide.

Mind the line between translating and spinning. Before the Room describes redesigns that make a trade acceptable to the person paying, such as funding their share or moving them out of the first-mover position, and adds: "None of these are bribes. Each changes the economics so that yes becomes rational." True numbers in the owner's currency do that. Inflated incident risk aimed at a director does not, and it costs you the next case.

Copy the block into whatever your team writes documents in. If each section stays at two or three lines it fits on a page; if it does not fit, the decision is not narrow enough yet. The ask comes first and the no comes last, because the owner should see what you want before they see why.

# Debt case: <the decision, phrased as a choice>

Decision owner:   <one name: owns the capacity this spends>
Decide by:        <date, before planning closes>
Proposed by:
Pays principal:   <team, engineer-weeks>
Pays interest:    <teams paying today, and how>

## 1. The ask
Spend <capacity> in <cycle> to <outcome>.
This moves <named roadmap item> by <time>.

## 2. The debt, without the word "refactor"
Category: delivery | change | reliability | data |
          compatibility | security and privacy |
          platform | knowledge | deprecation
Where it lives: <module, journey or capability>, owned by <name>.
What it does to the product today, in one sentence.

## 3. Interest: what it costs per period
<unit>: <value> per <pull request | release | month>,
        source, date range.
Trend: rising | flat | falling, and why.
Mark every number that is estimated, not measured.

## 4. Principal: what removing it costs
A range in engineer-weeks, and what the range depends on.
The first slice, and what it costs on its own.

## 5. Why now
The trigger that makes this cheaper now or dearer later:
a payload or schema change, a minimum OS bump, an SDK
deprecation, an API version to retire, a roadmap item
that builds on top of it.

## 6. In the owner's terms
What the owner is measured on, and how this case moves it.

## 7. Options
A. Keep paying: interest per quarter, the risk accepted,
   and who accepts it.
B. Full fix: cost, and what moves on the roadmap.
C. First slice: the smallest piece that pays for itself
   or retires the worst risk.
Recommendation, and the trade-off accepted on purpose.

## 8. Evidence it worked
Metric | baseline | target | check date | who checks

## 9. Stop and finish
What pauses the work. Who deletes the old path, and when.

## 10. If the answer is no
Risk accepted by:  <name>, on <date>
Reopen if:         <evidence, not discomfort>
The team stops:    <the interest it will no longer absorb>

Sections 7 and 10 carry the weight. Option A, keep paying, has to be a real option with a real cost, written so the owner could choose it with a clear conscience; without it the case reads as an ultimatum. Section 10 is filled in before the meeting, not after it. If the fix also needs a design doc, write it after the capacity is agreed; this page is the ask.

Here is the page condensed for the Atlas queue. The scenario is the book's fiction; the roles, amounts and timing are mine, invented to show the shape.

The interest is low and the case still wins, on the trigger and the owner's own roadmap. Look for that in your backlog: debt with a date attached.

Timing decides more debt cases than evidence does. Before the Room makes the point about migrations, and it holds for any work that needs capacity: "time the ask to land before planning closes; a yes between cycles often has nothing left to fund it with." Bring the page in the weeks before planning, not to the retrospective after the incident.

Take it to the owner one on one before any group meeting, ask for the objection rather than agreement, and then say the decision out loud:

"The FieldOps queue has no schema version, and the payload change in the release after next puts reports already queued on devices at risk. I have three options on one page. A ships the change as planned and accepts that risk. B fixes the queue and adds recovery UI this cycle, four engineer-weeks, and moves saved filters one release. C does the versioning and fixtures now, two engineer-weeks, and builds the recovery UI as part of the payload change. I recommend C. The decision I need from you by Friday is which risk we carry."

The sentence does not call the code bad, ask for a sprint or argue with the roadmap. It puts a named cost next to a named trade and hands the choice to its owner. If the conversation turns into a fight over the date of the whole project, you are in a scope negotiation, and how to say no to a project as a tech lead is the page for that.

Most debt cases end in neither yes nor no. They end in yes to the first slice, yes next quarter, yes if it rides along with the feature that needs it, or yes with half the people. Before the Room prepares you for it in four words: "Expect a partial yes." In its scene, a reluctant team that agrees to go last, funded and with a readiness gate, is "enough to proceed on." Its chapter on the three moves ends with an engineer whose proposal was approved and its start pushed a quarter: she "won the choice and lost the date."

A partial yes is worth more than it feels, but only if it is real, and the test is capacity with a name on it. Before the Room's description of how funded work slides back fits debt exactly: "the plan says committed and the staffing says spare time." A yes with no engineer and no week attached is goodwill.

Controlled Change gives the reason to slice even when nobody asks: "A migration that consumes all roadmap capacity will be canceled or bypassed." Its legacy migration chapter shapes the work so each wave delivers product capability, reduces measurable risk or improves delivery, and keeps a line for deletion. A first slice that retires one measurable risk is easier to fund twice than a large ask is to fund once.

Then secure it: write the decision down the same day, with what was accepted and what was deferred, and check the signal a week later. Did the engineer start? Did the number begin to move? A case that won approval and then lost its capacity to the next urgent request is the most common way debt work dies.

Sometimes the owner agrees with every line and still says no, because two launches have to land this half. That is a legitimate answer. The case never promised funding. What it buys is a no made by the owner, on the record, against a known cost.

Record the date, who decided, the option chosen and the risk accepted by name. Before the Room's incident chapter has the sentence for a control nobody funded, and it fits debt with almost no change: "if this control is not funded this sprint, we should record that the organization is choosing to accept the recurrence risk." Then write what would reopen it: an incident on the path, the interest crossing an agreed level, the trigger date coming closer, or the next planning cycle.

And stop absorbing it. The common failure after a no is the team paying the principal anyway, in evenings and side branches, which teaches the organization that debt is free. Pay the interest you have to, and let the rest of the cost sit where it was decided.

Escalation is for a decision that cannot close at the current level, not for a no you dislike. An owner who declined with the cost in view has decided, and taking that above them reads as going over their head because it is. Four situations are different, and each is a threshold you can name in advance:

• The interest lands on teams the owner does not run. Your manager can fund your team's time, but the pages and waiting fall on two other teams. Before the Room puts a trade between two teams' priorities with the person who owns both roadmaps, where raising it "lands as leadership, because what you bring is a trade-off, not a person who would not listen."
• Nobody owns the code. Escalate the missing owner, in one factual note, to whoever can assign one. Do not paper over the gap by quietly fixing the code yourself.
• The risk is not one the owner can accept. Security, privacy, safety and regulatory constraints are on the book's list of places to hold the line, because no one you can reach can rightly accept the risk. I would treat a path that can lose user data the same way.
• A trigger you named fires. The vendor cutoff comes closer, the payload change gets a date, the incident you priced happens. The reopen criteria you wrote after the no are your thresholds.

Say the threshold when you hear the no, not when it fires: "Understood, we carry it. If the payload change gets a date before the queue is versioned, I will bring this back to you, and if it still cannot move then, to the director as a priority decision between the two items." Said in calm weather, that is an instrument. The brief itself is in how to escalate as a tech lead.

From the hiring side, "tell me about a time you got investment in technical debt" is rarely scored on the debt. The answers that read as tech lead or staff carry what this page carries: the decision, the owner, the unit, the currency, what the owner actually agreed to, and the signal checked afterwards. A partial yes often makes a better story than a full one, because it shows judgment about what to ask for. Keep the page and the decision record while the work is alive; they are the evidence that answer needs.

The short version fits on a card. Name the decision and the one owner. Price the interest in a unit your tools already record. Say it in what the owner is scored on. Bring three options, one of them keep paying. Give the partial yes a name and a date. Write the no down with its reopen trigger, and escalate only when that trigger fires.

How do I quantify technical debt for a business case?

As interest and principal. Interest is what the team pays per period to keep the debt: CI minutes per pull request, review hours, release slip days, pages, old-version support days. Principal is the cost to remove it, as a range. Use numbers your tools already record and mark every extrapolation as an assumption.

How do I present tech debt to management?

As a decision with a trade, in what the listener is measured on: roadmap dates and experiment velocity for product, on-call load and predictable delivery for an engineering manager, commitments and incidents for a director. Avoid "refactor". Name the debt by its consequence, show three options including keeping it, and recommend one.

Should we run a tech debt sprint or reserve a fixed percentage for debt?

A dedicated cleanup period tends to produce a burst of work and then the old habits. A standing reserve for systemic risks works better, paired with folding debt work into the feature that caused it or needs it. No single percentage fits every team; size the reserve by measured interest, and give each item an owner and a check date.

What is the cost of delay for technical debt?

The interest paid for every period the fix waits, plus whatever gets more expensive once a trigger passes. On mobile the triggers are often concrete: a payload or schema change, a minimum OS bump, a vendor SDK deprecation, an API version you want to retire. After the trigger, old builds and data already on devices are in the way, so the same fix usually costs more.

What do I do if my manager says no to the tech debt work?

Record it as a decision: who decided, the option chosen, the risk accepted and what would reopen it. Stop paying the principal in the team's spare time. Escalate only if the cost lands on teams your manager does not run, nobody owns the code, the risk is one your manager cannot accept, or a reopen trigger fires.