KTLO meaning: what keeping the lights on is, what it costs and why it grows
KTLO stands for keeping the lights on: the IT work that keeps existing systems running. What it includes, how to measure the ratio, why it grows and how to reduce it.
.png)
Key takeaways
- KTLO stands for "keeping the lights on": the share of IT effort spent keeping existing systems running rather than building new capability.
- KTLO is a ratio, not a budget line: KTLO effort ÷ total IT effort. Most organizations cannot state theirs.
- It grows structurally because every project adds permanent run work and almost nothing gets decommissioned.
- Cutting KTLO by cutting the team converts run cost into risk without recording the conversion.
- The durable lever is removing whole categories of work, starting with routine service desk requests.
KTLO stands for "keeping the lights on." It is the share of IT time and budget spent keeping existing systems running, such as patching, monitoring, backups, access requests, password resets and routine repairs, rather than building new capability. It is not waste, but when it grows unchecked it crowds out everything else.
What does KTLO mean?
KTLO (keeping the lights on) describes the ongoing work required to keep what already exists working. Nobody thanks a team for a quarter of uneventful uptime, and that is exactly what success looks like. The term is often used pejoratively, as the thing standing between IT and strategic work. That framing is worth resisting: KTLO is the precondition for value, not its opposite.
The more useful question is not how to eliminate KTLO. It is why the ratio keeps moving in the wrong direction, and what actually reverses it.
KTLO in IT, software and finance
The acronym means the same thing everywhere, but the emphasis shifts with the audience:
- In IT operations, KTLO is "run the business" work: infrastructure, support, security patching and compliance upkeep, as opposed to "change the business" projects.
- In software engineering, KTLO is the maintenance slice of a team's capacity: bug fixes, dependency upgrades, on-call and support for features already shipped.
- In finance and budgeting, a KTLO budget is the minimum spend needed to keep current operations and obligations running before any growth investment.
KTLO examples
| Area | Typical KTLO work |
|---|---|
| Infrastructure | Patching, OS and firmware upgrades, capacity monitoring, backups and restores |
| Service desk | Password resets, access requests, software installs, VPN and mailbox issues |
| Applications | Bug fixes, dependency and library upgrades, license renewals, vendor upgrades |
| Security and compliance | Vulnerability remediation, audit evidence, certificate renewals, access reviews |
| Operations | On-call, recurring incident response, batch job monitoring, documentation upkeep |
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 the growth of run cost is never visible as a trend, only as a persistent, unexplained shortage of capacity for anything new.
How to calculate your KTLO ratio
A rough number produced consistently beats a precise number produced once.
KTLO ratio = KTLO effort ÷ total IT effort × 100
Measure effort in hours, story points or spend, but use the same unit every time. For example, if a 20-person team logs 2,200 of its 3,200 monthly hours to patching, support, recurring incidents and upgrades, its KTLO ratio is about 69 percent, leaving 31 percent for change.
To make it repeatable:
- Define the categories once. Decide which work types count as KTLO (support, maintenance, recurring incidents, compliance upkeep) and keep the list stable.
- Tag the work where it happens. Label tickets, sprint items or timesheets as KTLO or change.
- Report it quarterly. The trend matters more than any single number.
- Track the drivers. Note the systems and request types that contribute most, because those are where reduction will come from.
Why KTLO 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. A 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, is patched and is included in every audit.
Compliance surface expands. 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 45 possible pairwise relationships; twenty have 190.
Vendor price increases land on the run budget. Spending is rising fast: Gartner's July 2026 forecast puts worldwide IT spending at $6.37 trillion in 2026, up 14.2 percent. A meaningful share of every increase goes to renewing and absorbing price rises on software already in place, which is KTLO by definition.
None of these are performance problems. A team working twice as hard experiences exactly the same trend.
KTLO vs technical debt
The two are related but not the same. KTLO is the ongoing cost of running what exists. Technical debt is the accumulated cost of shortcuts, outdated architecture and deferred upgrades. Debt is one of the biggest drivers of KTLO: brittle code, unsupported versions and manual workarounds all raise the run load. Paying down debt is change work that reduces future KTLO, which is why it belongs on the change side of the ledger even though it creates no new feature.
KTLO tickets in Jira and agile teams
Many engineering teams tag maintenance work as KTLO in Jira or their sprint tooling so it can be seen and planned. Common practice is to reserve a fixed share of each sprint for KTLO, label the issues consistently, and review the KTLO share at retrospectives. The tag is only useful if it is applied consistently, so define what counts before you start tracking.
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. 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, and 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.
How to reduce KTLO
The distinction that matters: doing the same work faster buys a one-off gain that growth 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 and VPN troubleshooting are high-volume, well defined and resolvable from documents you already own. Removing the category is durable in a way that handling it more efficiently is not. Black Angus Steakhouse cut after-hours IT dependency from 90 percent to 10 percent 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 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. See how incident, problem and change management fit together.
Automate detection before remediation. Knowing early is cheaper than fixing late, and it is a much smaller change to make.
What is a good KTLO ratio?
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.
Where agentic AI fits
The largest single block of removable KTLO in most organizations is the service desk's routine request load. Rezolve.ai is built to take that category out of the system rather than push it through the same people faster: Agentic Sidekick resolves employee requests in Microsoft Teams and Slack, deflecting up to 85 percent of tickets, so analysts spend their time on the work that genuinely needs them. For the bigger picture, see why L0 and L1 elimination is now the floor for modern service desks.
Last updated on October 30, 2026
Get summary with:
See the agentic service desk in action
Watch Rezolve.ai autonomously resolve real IT and HR tickets: governed, auditable, glass-box.
Frequently asked questions
What does KTLO stand for?
KTLO stands for "keeping the lights on." It is the share of IT effort spent maintaining existing systems and services, such as patching, monitoring, backups, access requests, password resets and routine repair, rather than building new capability.
What does KTLO mean in software development?
In software teams, KTLO is the maintenance share of capacity: bug fixes, dependency upgrades, on-call and support for features already shipped. Many teams tag this work as KTLO in Jira and reserve a fixed share of each sprint for it.
What is a KTLO budget?
A KTLO budget is the minimum spend needed to keep current systems and obligations running before any new investment. It covers licenses, infrastructure, support, maintenance and compliance upkeep.
How do you calculate a KTLO ratio?
Divide KTLO effort by total IT effort and multiply by 100. For example, 2,200 KTLO hours out of 3,200 total hours is a KTLO ratio of about 69 percent. Use the same categories and unit every quarter so the trend is comparable.
What is a good KTLO ratio?
There is no universal figure. A regulated organization with decades of accumulated systems will legitimately run higher than a young company on managed services. What matters is knowing your ratio, tracking it consistently and treating a rising trend as a decision rather than a fact of nature.
What is the difference between KTLO and technical debt?
KTLO is the ongoing cost of running what exists. Technical debt is the accumulated cost of shortcuts and outdated architecture. Debt is a major driver of KTLO, and paying it down is change work that reduces future KTLO.
How do you reduce KTLO?
Remove categories of work rather than doing the same work faster. Eliminate high-volume request types, decommission systems with a named sponsor, price run cost into every project business case at approval, and fund problem management so recurring incidents stop recurring.
