Keeping the Lights On (KTLO): What It Costs and Why It Grows

KTLO: "keeping the lights on". Is the share of IT effort that goes to keeping what already exists working. Patching, monitoring, backups, access requests, password resets, the endless small repairs that produce no new capability and are catastrophic to skip.

The term is usually deployed pejoratively, as the thing standing between IT and the strategic work. That framing is worth resisting. KTLO is not the opposite of value; it is the precondition for it. Nobody thanks you for a quarter of uneventful uptime, and that is exactly what success looks like.

The interesting question is not how to eliminate KTLO. It is why the ratio keeps moving in the wrong direction.

KTLO is a ratio, and most organizations cannot state theirs

The useful expression is KTLO as a share of total IT effort, run-the-business versus change-the-business. Ask most IT leaders for that number and you will get an estimate delivered with a shrug, because time is not tracked against it and the boundary is genuinely fuzzy.

That vagueness is expensive. It means the run cost of a new system is never explicitly priced at approval time, and it means the growth of run cost is never visible as a trend: only as a persistent, unexplained shortage of capacity for anything new.

A rough number produced consistently beats a precise number produced once. Even a quarterly estimate, categorized the same way each time, will tell you the direction.

Why it grows structurally

The pattern is mechanical, and it is nobody's fault.

Every project adds permanent surface area. A project is funded once and run forever. The business case covers build; the run cost lands silently on the same team that was already at capacity. Ten successful years of delivery produce ten years of accumulated run obligation.

Nothing gets decommissioned. Retirement has no sponsor. The system has a small number of dependent users who will object loudly, and no one whose objectives improve when it goes away. So it stays, and it is patched, and it is included in every audit.

Compliance surface expands monotonically. New regulation, new certifications, new audit evidence. None of it is optional and none of it produces new capability.

Estate complexity compounds. Each integration is a new failure mode. Ten systems have forty-five possible pairwise relationships; twenty have a hundred and ninety.

None of these are performance problems. A team working twice as hard experiences exactly the same trend.

The failure mode: cutting the team instead of the work

The standard response to a high KTLO ratio is to reduce the cost of the run, usually by reducing headcount or outsourcing the tier that handles it.

This works arithmetically and fails operationally, because the work did not go anywhere. What actually happens is that the run degrades in ways that do not show up on a dashboard for two or three quarters: patches slip, monitoring coverage develops holes, documentation stops being updated, the person who understood the batch job leaves.

Cutting KTLO by cutting capacity converts run cost into risk, and the conversion is never recorded. It shows up later as an incident with a root cause dated eighteen months earlier.

What actually reduces it

The distinction that matters: doing the same work faster buys you a one-off gain that inflation in surface area erases within a year. Removing categories of work changes the slope.

Eliminate whole request types. Password resets, access requests, software installs, mailbox permissions, VPN troubleshooting. These are high-volume, well-defined, and their resolution is knowable from documents you own. Removing the category is durable in a way that handling it more efficiently is not. Across our platform, roughly 70% of requests are resolved before they become tickets, and Black Angus Steakhouse cut after-hours IT dependency from 90% to 10% this way.

Decommission deliberately, with a sponsor. Give retirement a named owner and a budget. It will not happen otherwise, because the incentives point the other way.

Price run cost at approval. Make every project business case state its expected annual run obligation and who absorbs it. This single change does more for the ratio over five years than any tooling decision, because it makes the trend visible while it is still a choice.

Attack the recurring causes. Problem management is the least-funded ITSM practice and the one that most directly reduces run load. Every eliminated recurring incident removes work permanently.

Automate detection before remediation. Knowing early is cheaper than fixing late, and it is a much smaller change to make.

A reasonable target

There is no universal correct ratio. A regulated bank running decades of accumulated estate will legitimately sit higher than a five-year-old company on managed services.

What is not reasonable is not knowing, or knowing and treating the trend as a fact of nature. If your KTLO share has risen every year for four years and the response each year has been to ask the team to absorb it, that is a strategy, just not one anybody chose.

The organizations that reverse the trend do it by removing work from the system rather than by pushing more work through the same people. That is a slower conversation than a headcount decision and a much more durable one.