What is KTLO?
KTLO stands for Keep The Lights On. In software engineering, it refers to the maintenance, support, and operational work that keeps existing systems running without adding new capability. Bug fixes, security patches, dependency updates, infrastructure upkeep, on-call incident response: if the work preserves the current state rather than advancing it, it is KTLO.
The term was popularized by Gartner in the context of IT budget allocation but has become a standard framing across engineering organizations for discussing how capacity is divided between innovation and operations.
How to Measure KTLO
KTLO has no single universal formula, but most teams calculate it as a percentage of total engineering effort:
KTLO % = (time or effort spent on maintenance / support / incident work) / (total engineering capacity) x 100
Inputs vary by method: some teams tag Jira tickets with issue types (Bug, Tech Debt, Maintenance, Infra); others use code-level signals from version control. The most reliable approaches combine both.
Three sub-categories typically make up KTLO:
Reactive work: incident response, hotfixes, and emergency tasks triggered by outages or production failures.
Planned maintenance: scheduled library updates, security patches, and infrastructure tasks that are predictable and can be sprint-budgeted.
Strategic debt reduction: deliberate refactoring of fragile areas to reduce future KTLO load. This is where the real leverage sits.
How Hivel measures KTLO
This metric appears alongside New Work % and Rework % so leaders see the full allocation picture in a single view. For Jira-based investment tracking, the Investment Profile screen allocation tab shows effort breakdown by issue type and epic, letting teams quantify KTLO by sprint and compare it against feature work.
How to validate your KTLO in Hivel
- Open the Hivel Investment Screen navigate to Investment → Product and Allocation.
- Apply filters for: Work Type = KTLO
- Review the effort distribution to validate whether KTLO work aligns with the Maintenance % seen in the Coding breakdown.
See how Hivel tracks KTLO and coding allocation across your engineering org →
KTLO vs Technical Debt
KTLO and technical debt are related but not the same. Technical debt is the accumulated cost of shortcuts taken during feature development: suboptimal code, missing tests, fragile architecture. KTLO is the ongoing work required to keep systems operational regardless of debt level.
High technical debt inflates KTLO, because poorly written code generates more incidents and requires more patching. But even a clean codebase has KTLO: security updates still need applying, dependencies still need upgrading, and infrastructure still needs maintenance. Reducing technical debt lowers KTLO burden over time. They move together, but they are different levers.
Why KTLO Matters for Engineering Teams
Most engineering leaders undercount KTLO until it is too late. Product managers build roadmaps assuming 100% engineering capacity for new features. When KTLO grows quietly to 35-40%, those roadmaps become fiction. Deadlines slip, engineers context-switch between firefighting and feature work, and morale takes the hit.
The math is unforgiving. One team documented a drop from 30% to 16% KTLO after systematically measuring and attacking it. The result was the equivalent of unlocking an entire engineering team's capacity without hiring anyone.
KTLO is also an AI litmus test. As AI coding tools accelerate net-new code generation, the ratio of KTLO to new work becomes a leading indicator of whether AI is actually improving delivery or quietly increasing the maintenance surface. Higher output without maintenance discipline creates more code to maintain, not less.
Hivel surfaces Maintenance %, New Work %, and Rework side by side so engineering leaders can see capacity allocation patterns, not just isolated code metrics.
"The only tool our entire leadership team actually trusts"
