KTLO vs New Development: Finding a Defensible Balance

TL;DR: Keep-the-lights-on work is the rent you pay on every system you have ever shipped. Like rent, it is fine until you realize nobody has checked the bill in two years. Most orgs cannot answer the question "what share of engineering goes to KTLO?" within twenty points, which means their roadmap math is fiction: capacity plans assume engineers the past has already spoken for. The fix is neither a heroic KTLO purge nor a magic industry ratio. Measure it, budget it, and trade it deliberately, with the same discipline you would apply to any other seven-figure-shaped line in the payroll.

What counts as KTLO (and what doesn't)

KTLO - keep the lights on - is work that preserves existing capability without adding any: dependency and OS upgrades, security patching, certificate and credential rotation, on-call and incident response, backup and compliance chores, the quarterly dance with a vendor API that changed under you. The test is simple: if this work succeeds perfectly, the product can do nothing it couldn't do before.

Two boundary calls matter, because sloppy buckets ruin the measurement:

• Bug fixes are not KTLO. A defect fix restores intended capability that was missing: it belongs in a quality bucket. Blending it into KTLO hides your defect signal and inflates the "necessary rent" number with cost that is actually rework in disguise.
• Debt paydown is not KTLO. Refactoring is an investment that reduces future cost. KTLO is recurring; paydown is one-time. Conflating them lets the org feel virtuous about maintenance while never actually reducing it. The difference is the whole point of the interest-versus-principal distinction.

Four buckets - new capability, improvements/paydown, KTLO, unplanned/quality - cover essentially everything and force the honest question each time: did this create, improve, preserve, or repair? (The fourth bucket deserves its own audit: unplanned work is the share of payroll firefighting spends for you, and it hides even better than KTLO does.)

Why nobody knows their KTLO share

Because KTLO is structurally invisible. It rarely gets its own epics; it hides inside sprints as "small stuff," inside estimates as padding, and inside specific people: often the tenured engineer who quietly keeps eleven systems alive, doing glue work's grumpier cousin. No single item is big enough to notice. The sum is enormous.

The industry evidence says the maintenance-class burden is a large minority of everything engineering does. Stripe's Developer Coefficient survey (with Harris Poll; more than 1,000 developers and 1,000 C-level executives) found developers reporting 17.3 hours of a 41.1-hour week on maintenance-class work, and 52 percent naming legacy systems and technical debt as a top hindrance to productivity (Stripe, 2018). McKinsey's CIO survey found 10 to 20 percent of new-product technology budget diverted to servicing the past (McKinsey). Those figures bundle KTLO with debt service (the surveys don't split the buckets the way you should), but they establish the scale: the past has a standing claim on your payroll, and in the Stack Overflow 2024 survey the frustration that claim generates topped the list, named by 63 percent of professional developers (Stack Overflow).

Every one of those numbers is a survey of reported time. That is exactly why they cannot be your number, and why measuring your own is step one.

How to measure your KTLO share

You need weeks, not quarters, and honesty, not precision:

1. Tag the work, not the people. For four to six sprints, classify completed work into the four buckets. Ticket labels get you most of the way; a quick pass over the commit and PR history catches the KTLO that never earned a ticket - the upgrade merged at 9pm, the cert rotation, the "bump deps" PRs.
2. Count the invisible standing costs. On-call hours, recurring ceremonies devoted to system care, and the fractional humans: the engineer who is "10 percent DBA." These never appear in sprint data and are pure KTLO.
3. Price it. KTLO share × team size × fully loaded cost per engineer = the annual rent, in your currency. Illustrative shape only: a 20-person org discovering a third of its time is KTLO is discovering that six or seven full-time salaries are spoken for before the roadmap gets a vote.
4. Split it by system. The aggregate motivates; the per-system split acts. KTLO concentrates: a handful of elderly systems usually generate most of it, and that ranking is your paydown shortlist.

What a defensible balance actually looks like

Here is where you expect the industry benchmark table, and here is the honest answer: there is no credible universal KTLO ratio. The defensible balance is not a number. It is a posture, with three properties:

• It is measured. You can state your share within a few points, with the method disclosed. That alone puts you ahead of most orgs, whose KTLO estimate is a shrug rendered as a percentage.
• It is budgeted, not ambient. Leadership has explicitly agreed "we spend roughly this share keeping the estate alive," the same way the CapEx/OpEx split is an explicit accounting decision. An agreed 30 is healthier than an unexamined 20, because the agreed number can be defended, staffed, and revisited.
• The trend is deliberate. Share creeping up quarter over quarter without a decision is the alarm: it means the estate is aging faster than you are investing in it, and the roadmap is quietly shrinking to pay for it. Context matters. A company with one product and eight years of history should expect a structurally different share than one that shipped its first system last spring. What it should not expect is drift without a decision.

The reallocation argument then writes itself in money: "KTLO on system X costs N hours a month at loaded cost; this scoped investment cuts it by half; payback in four quarters." That proposal competes for budget on equal terms, which is all maintenance work ever needed to win its share honestly.

Shrinking KTLO without turning off the lights

Once measured, the levers rank themselves by return:

• Retire before you optimize. The cheapest KTLO is on a system that no longer exists. The per-system split usually reveals at least one candidate whose care costs more than its use justifies.
• Automate the recurring chores. Dependency bots, automated cert rotation, self-healing checks - one-time principal against a permanently recurring interest payment, the best trade in this entire article.
• Pay down the debt driving the worst rent. The system generating the most KTLO is usually also a debt hotspot; fixing it is a refactoring case with a measurable payback.
• Rotate the burden. Where KTLO concentrates in one person, you have a cost problem and a bus-factor problem wearing the same trench coat. Rotation spreads both the load and the knowledge.
• Know which bucket the work landed in. KTLO share is only as honest as the link between a merged PR and the work it served; when half your PRs link to nothing, the split is a guess wearing a percentage sign.

The door

This one starts with a single sprint retro question: "how much of what we just finished kept the lights on versus moved anything forward?" Tag one sprint, then four, then price the share against loaded cost, split it by system, and put the resulting number in front of whoever owns the roadmap, framed as a budget line that has been spending itself without sign-off for years. KTLO is rent, and rent is negotiable - but only after somebody finally reads the lease.