What KTLO is and how to win back your team’s capacity

Picture a team where 80% of the time goes to KTLO. Nobody is looking at that number. Nobody even knows it. What everyone knows is that the team is having incident after incident, is always in reactive mode, and is burning out.

The team can’t launch things, and nobody can say why. So nobody does anything about it.

If your team never seems to ship and you can’t explain where the time goes, KTLO is the first place I’d look.

What KTLO is

KTLO stands for Keep The Lights On. I keep the definition simple: KTLO is all the time a team spends on non-feature work. Feature work is launching new features or new products for your users. Everything else is KTLO.

That includes:

• Incidents. The most obvious one.

• Bugs.

• Maintenance. Updating libraries, upgrades, that kind of work.

• Compliance gaps. Fixing what your product needs to meet regulation or pass an audit.

• Manual repetitive work. For example, manual testing before every launch.

• Supporting other functions. Every interruption where someone in the company is stuck and needs the team. A classic: a customer service agent has a user complaining, and an engineer has to look at the database to give them an answer.

• Technical work to scale the product.

That last one surprises people. Many teams put scaling work and tech debt in a separate “investment” bucket. I don’t, and the next section explains why.

Strategic KTLO

Some KTLO is reactive: an incident happens, you attend to it. Some of it is a choice you make now to prevent a problem later, or to pay back a choice you made in the past. I call that strategic KTLO.

Tech debt is often a past choice, made to launch faster. Sometimes the work is a future obligation, like new regulation, or the incident you know is coming. If your app works for 1,000 users and you know it won’t work for 10,000, scaling it now prevents that future incident.

Take a company that launches a new product as a monolith. It’s the fastest way to go to market and test whether the product works.

Say it works really well. Over the years, more and more engineers join that business area, until they reach a point where they can’t work anymore. You can’t fit more engineers into one monolith.

So they split the monolith into microservices. After that, different teams can own different parts of the business, each with their own services. That’s strategic KTLO. It isn’t a feature, but it’s what allows the business to grow.

I group it with the rest of KTLO because it keeps the split clean: features on one side, everything else on the other. Both sides compete for the same engineers.

Two mistakes I see new managers make

Not putting a number on it

The first mistake is not tracking KTLO at all. That’s the 80% team from the start of this post. Without a number, the team just feels that it can never launch anything, and stays reactive.

With a number, you have a metric to work against. You can set a target, plan initiatives to reduce it, and see if they work. And you can use it to negotiate, for example budget for technical initiatives versus product initiatives.

Counting only incidents

The second mistake is categorizing only incidents. Teams that do this fix incidents and still don’t launch anything, because they never think strategically about the other sources of KTLO: the manual tasks, the support requests, the regulatory requests that keep coming.

If you don’t classify all the reactive work, you can’t do anything about it.

How to bring it down

Back to the 80% team. The first step is to measure KTLO and split it into a few big buckets, for example:

• Manual repetitive tasks

• Time supporting other functions

• Bugs

Starting with three is enough. You can make your categories as granular as you want, as long as they’re all non-feature work. Every company is different. In a heavily regulated industry, you’ll have a lot more compliance work than in a product with little regulation. Pick the categories you care about.

Then put a plan against each bucket:

• Manual work. If every launch needs a lot of manual testing, plan to automate it.

• Support. Build self-service, so internal stakeholders like customer support can sort out their requests themselves, without needing an engineer.

• Bugs and incidents. Eliminate root causes. Sometimes that means redoing parts of the architecture so certain issues don’t appear anymore.

In my experience, a plan like this can cut KTLO by more than half within a few months, and you can keep pushing it down over the following year with new initiatives.

Making the case to Product

Your Product Manager or your boss might say you can’t afford months of automation and refactoring because you need features now. In my experience, KTLO has one of the easiest business cases there is, because KTLO capacity translates directly into money and into feature capacity.

Imagine a team of 10 engineers with 80% KTLO. That’s 8 engineers on KTLO and only 2 launching features. If you invest a couple of months in bringing KTLO down to 50%, you go from 2 people launching features to 5, and launching features is what most companies care about. Your argument wins there!

Remember that much of KTLO isn’t optional. You can’t choose not to attend to an incident. If your company’s process says a full regression is mandatory before every launch, you can’t skip it, unless you want to launch bugs. So that work will happen either way. The only question is whether you keep paying for it, or reduce it.

Capacity spent on KTLO is capacity you don’t have for features. It’s a zero-sum game, and once Product sees it in those terms, the conversation gets easy.

My target

The budget I usually give KTLO is 20%.

When KTLO sits that low, I don’t spend much attention on it. For me it means things are running smoothly, and the team’s time is going where it should.

The takeaway

If your team can’t ship and nobody knows why, look at KTLO: name everything that isn’t feature work, put a number on it, and plan it down bucket by bucket. Then use that number to show Product how much capacity they’re getting back.

Next week I’ll share how I measure KTLO in practice.

If you want to go deeper now, my Operational Excellence course covers this in detail: how to build stable systems so your team can focus on building instead of firefighting.