KTLO vs feature work: measuring your engineering investment mix
Every engineering organization spends its capacity on a mix of activities: keeping existing systems running, improving what already exists, building new things, and making the team itself faster. The balance between these is one of the most important strategic facts about your org — and one of the least visible. "How much of our capacity goes to keeping the lights on versus building the future?" is a question most leaders can only answer with a guess. Measuring your investment mix turns that guess into a number you can manage.
What is KTLO?
KTLO stands for "keep the lights on" — the unglamorous but essential work of keeping existing software running. Bug fixes, incident response, dependency upgrades, operational toil, and routine maintenance all fall under KTLO. It produces no new capability; it preserves the capability you already have.
A little KTLO is healthy. Too much is a warning sign: it usually means accumulated technical debt, fragile systems, or under-investment in quality that is now taxing every future quarter. When KTLO quietly climbs, your capacity to build new things shrinks even though headcount stays flat.
A practical four-way split
Binary "KTLO versus features" is a useful start, but a four-category model captures the real trade-offs better. Delimetrics uses:
- KTLO — maintenance and keeping existing systems healthy. Bugs are automatically classified here.
- Improve things — enhancing existing functionality, paying down debt, refactoring for quality.
- New things — building net-new features and capabilities.
- Productivity — investment in the team's own velocity: tooling, automation, developer experience.
This breakdown maps to how work actually gets discussed in planning, and it surfaces the categories leaders most often under-fund — improvement and productivity — which tend to get squeezed silently when delivery pressure rises.
Measuring it without new process
The mix only matters if it is measured from real work, not from a planning slide that drifts from reality within a sprint. The way to do that is to classify work in Jira and read the actual delivered mix.
In Delimetrics, each issue carries a work-type classification (read from a Jira Cloud custom field), and bugs are automatically counted as KTLO so you do not have to tag the obvious cases. The investment mix dashboard then shows the delivered split per team and compares it against per-team targets you set.
Targets matter as much as the actuals. A 30% KTLO figure is neither good nor bad in isolation — it is good or bad relative to what you intended. Setting an explicit target per team turns the mix from a passive report into an active management tool.
What the numbers tell you
Once you can see the mix per team and over time, patterns jump out:
- Rising KTLO on a team usually signals mounting tech debt or operational fragility. It is an early indicator that a team is heading toward a maintenance trap.
- Zero improvement or productivity work over several quarters predicts future slowdowns — the team is borrowing speed from the future.
- A mix far from target is a planning conversation: either reality needs to change, or the target was wrong.
- Divergence between teams tells you where to rebalance. One team drowning in KTLO while another ships only new features is a reallocation opportunity.
Using the mix in leadership conversations
Investment mix is one of the most board-legible engineering metrics there is, because it speaks the language of allocation rather than the language of velocity. Saying "we are spending 45% of capacity keeping existing systems alive, against a 25% target" frames a debt problem in terms any executive understands. It also connects naturally to the financial story — the same work-type classification that drives the mix also informs which work is capitalizable. See how that flows into CapEx versus OpEx, and how delivery health shows up in DORA-style delivery metrics.
Getting started
- Agree the four categories and what belongs in each. Keep the rules short.
- Add a work-type field in Jira; rely on automatic KTLO classification for bugs.
- Set a target mix per team based on its mandate — a platform team and a growth team should look different.
- Review the delivered mix against target each quarter and treat large gaps as a planning trigger.
Key takeaway: the KTLO-versus-feature balance is a strategic fact you are probably guessing at. Classify work in Jira, compare the delivered mix to explicit per-team targets, and you convert a guess into a metric you can steer.