Keeping-the-Lights-On Baseline

A quarterly plan that allocates 100% of capacity to roadmap work is not a plan without maintenance. It is a plan with an unmeasured amount of maintenance hidden inside it. Dependency upgrades, certificate and credential rotation, cloud deprecation notices, security patches, incident follow-ups and support escalations arrive regardless of the plan.

Removing the line removes the visibility, not the work. The roadmap then delivers late and nobody can explain why, which is worse than delivering less on purpose, because it destroys the organisation's ability to forecast anything.

Why it matters

Forecast credibility is the currency an engineering organisation spends when it asks for anything. A team that commits to ten things and delivers six, four quarters running, loses the argument for investment even when the cause is entirely visible in its own history.

Organisations that measure this typically find unplanned and keeping-the-lights-on work consuming somewhere between 20% and 40% of capacity. Reserving that does not change total output, because the work happens either way; it changes whether the commitment was ever achievable.

Implementation patterns

• Derive the number from your own history, not from an industry figure. Two quarters of categorising completed work is enough, and it is the only version of this argument that survives a budget conversation.
• Reserve it explicitly in the plan, as a named allocation rather than as slack.
• Publish what the reservation was spent on each quarter. Without this it is perceived as buffer and reclaimed at the first pressure; with it, a quarter consumed by a forced cloud migration becomes a fact leadership can act on.
• Separate the categories: forced external change (deprecations, patches), internal maintenance (upgrades, currency), and unplanned response (incidents, escalations). They have different remedies and only one of them is reducible by better engineering.
• Fund automation against the largest category when the evidence supports it, which is how the baseline gets smaller rather than merely honest.

Industry example

The practice is common in infrastructure and platform organisations, where dependency currency and provider deprecations are continuous and measurable. Cloud providers have issued deprecation and forced-migration notices continuously since at least 2013, and language runtimes and major frameworks reach end of support on published schedules, so a meaningful share of this work has known dates years in advance and can be scheduled rather than absorbed.

Failure scenarios

• The reclaimed reservation, taken back under delivery pressure, after which the same overruns resume and are again unexplained.
• The zero-maintenance year, which produces an unsupported runtime or framework two to three years later at multiples of the avoided cost.
• Reservation without reporting, which looks like slack and loses the next budget argument.
• A number chosen from a blog post rather than from the team's history, which collapses the moment somebody asks where it came from.

Trade-offs

Reserving capacity makes the roadmap visibly smaller, which is politically costly in the quarter it is introduced. What it buys is forecast accuracy and the ability to have an explicit conversation about deferral, rather than an implicit one conducted through missed dates. Teams that refuse the reservation keep a larger nominal roadmap and a smaller delivered one.

When not to use it

For a genuine, time-boxed push — a funding deadline, a regulatory date, a seasonal peak — one quarter at full roadmap allocation is a legitimate decision, provided the deferred work is written down and scheduled. It is also unnecessary for a young codebase with few dependencies and no production footprint, where the baseline really is near zero. The honest thing to say at the second consecutive full-allocation request is that the bill is now accruing interest, with the deferred list as evidence.

Interview question

Q: Your director wants the whole team on roadmap work next quarter and says maintenance can be absorbed. How do you respond?

What a strong answer covers: agreeing to the goal and disputing the arithmetic, using the last four quarters of the team's own data · naming the categories of unplanned work and which have fixed external dates · proposing a reserved allocation with a published spend report · accepting a single time-boxed exception with the deferred list written down · and offering the reduction path, which is automation against the largest category rather than wishing the work away.

Quick check

Quiz: Why does reserving capacity for maintenance not reduce total output? Because the work happens either way; the reservation only decides whether it was visible in the plan.

Flashcard: What makes a maintenance reservation survive budget pressure? — Publishing what it was spent on each quarter, so it reads as work rather than as slack.