How do you decide how much of your team's capacity goes to roadmap work rather than keeping the lights on and paying down debt?

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.