Measure it before you divide it
Nearly every version of this conversation starts with someone proposing a number — twenty per cent for
tech debt is the folk standard — and the number is almost always guessed. Start instead by finding out
where the team's time actually went last quarter, because the answer is routinely a surprise to the
manager and it changes the argument entirely.
You do not need a timesheet. A fortnight of rough categorisation on completed work, or a label on
tickets that the team applies honestly, is enough to produce something like this:
| Category | Last quarter, measured | What it looks like |
|---|
| Roadmap features | 45% | Committed product work |
| Keeping the lights on | 25% | On-call, escalations, dependency upgrades, access requests |
| Unplanned rework | 15% | Bugs from recent releases, reverted changes |
| Deliberate improvement | 5% | Anything anyone chose to fix |
| Meetings, reviews, hiring | 10% | Including interviewing |
The value of a table like that is not the precision, it is that it reframes the negotiation. Nobody is
now arguing about whether to give engineering twenty per cent for debt; you are showing a stakeholder
that fifteen per cent of the team is already being spent on rework caused by the last three months of
delivery, and asking whether they would prefer to spend some of it deliberately. That is an argument
about cost, and cost is a language product and finance partners already speak.
Publish the allocation as a policy
Once you have real figures, set a split and write it down where the team and your stakeholders can
both see it, with the reasoning attached. A defensible starting shape for a team with an operational
surface — say, roughly half roadmap, a fifth held for keeping the lights on, a fifth for chosen
improvement, and the rest absorbed by everything else — matters less than three properties of how you
express it.
It is a policy rather than a mood, so it does not get renegotiated every sprint by whoever is loudest.
It is derived from measurement, so when someone challenges the improvement slice you can point at the
rework figure it is intended to reduce. And it is explicitly revisable at a stated point, usually the
quarter boundary, which is what stops it becoming dogma when the situation changes.
Say plainly which parts are not negotiable and why. Security patching, dependency currency and
on-call are not an allowance the team is being generously granted; they are the cost of operating
software that is already live, and a quarter in which they are set to zero is a quarter in which you
have borrowed against next quarter at an unfavourable rate.
Contain the interrupts rather than absorbing them
The allocation dies quietly if unplanned work lands on whoever happens to be nearest, because the cost
is then invisible and unbounded. Two mechanisms do most of the work here and both are worth naming in
an interview.
Route everything unplanned through one named person per sprint — an interrupt rota, separate from
production on-call or combined with it depending on volume. That person's planned commitment for the
sprint is close to zero, which is the honest accounting: you have not made the interrupts free, you
have decided who is paying for them and stopped six people being fragmented. It also gives you a
measurement, because the rota person can record what came in, and after two months you have evidence
about which upstream source generates most of it.
Then make the escalation path a decision rather than a reflex. Anything genuinely urgent displaces
something, and the useful discipline is to say what: "we can take this on Thursday, and the reporting
screen moves to next sprint — do you want that trade?" A manager who absorbs every escalation without
naming the displaced work is training the organisation to believe capacity is elastic, and will be
held to a plan that has quietly been made undeliverable.
Debt work has to be argued as delivery cost
The request that fails is "we need a refactoring sprint". It has no outcome in it, it is
unfalsifiable, and it sounds to a product partner like engineering asking for time off. The request
that succeeds names the delivery pain the work removes and gives a way to check it afterwards.
"Every change to the pricing service currently needs a coordinated release with the catalogue
service, because they share a database schema. That is why the last four pricing changes took three
weeks each rather than one. I want three engineers for four weeks to split the schema and give
pricing its own deployment. The check is the next three pricing changes: if they are not landing in
around a week, the work did not achieve what I said it would."
This has three properties the refactoring sprint lacks: a cost that has already been paid four times,
a bounded size, and a falsifiable claim. It also lets a stakeholder legitimately say no, which is
important — sometimes the roadmap really does matter more this quarter, and a manager who cannot hear
that becomes someone whose engineering concerns get discounted generally.
Choosing which debt is worth paying is a separate discipline from arguing for it. The test is whether
the code is imposing an ongoing tax: it is touched often, it causes incidents, it blocks something on
the roadmap, or only one person can safely change it. Code that is old, ugly and stable, and that
nobody needs to modify, is not debt in any sense that should consume your allocation, however much the
team dislikes it. Prioritising by distaste rather than by tax is the commonest way six months of
allocated improvement produces nothing anyone can point to.
The upward conversation
Whatever split you set, report against it in terms your stakeholders care about rather than in
engineering categories. The version that works shows the quarter's outcomes, the operational load that
was carried, and the improvement work with its claimed effect and whether that effect materialised.
Doing this consistently is what buys the allocation its legitimacy: the second time you ask, you have
a track record of an improvement slice that reduced rework from fifteen per cent to nine, and the
argument stops being about trust.
There is a failure mode on the other side worth admitting to. A manager who defends the allocation
absolutely, through a genuine regulatory deadline or an existential customer commitment, is not
demonstrating rigour but rigidity. The right move in those quarters is to suspend the improvement slice
explicitly, name what is accruing while it is suspended, and put the restoration date in writing —
because the difference between a considered exception and a permanent erosion is entirely whether
anyone wrote down that it was temporary.
Do not negotiate a percentage; measure where the time already goes, publish a split with the
reasoning attached, and justify every piece of improvement work by the delivery cost it removes and a
check that says whether it did.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).