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

When I joined one of my teams, 80% of its time was going to KTLO. Nobody was looking at that number. Nobody even knew it. What everyone knew was that the team was having incident after incident, was always in reactive mode, and was burning out.

The team couldn’t launch things, and nobody could say why. So nobody did 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.

Here’s an example. The first time I launched an investments platform, we chose to build it as a monolith. It was the fastest way to go to market, and I wanted to test whether the product worked.

It worked really well. Over the years we put more and more engineers into that business area, until we reached a point where we couldn’t work anymore. We couldn’t fit more engineers into that one monolith.

So we decided to split the monolith into microservices. After that, we could put different teams on different parts of the business, each with their own microservices. That was strategic KTLO. It wasn’t a feature, but it’s what allowed us 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 was the 80% team. 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 we went from 80% to under 20%

On the 80% team, we started measuring KTLO and split it into three big buckets:

• Manual repetitive tasks

• Time supporting other functions

• Bugs

I started with only these three. You can make your categories as granular as you want, as long as they’re all non-feature work. Every company is different. If you work in a bank, you’ll have a lot more compliance work than in a video game company. Pick the categories you care about.

Then we put a plan against each bucket:

• Manual work. We had to do a lot of manual testing before every launch, so we planned to automate all of it.

• Support. We planned a self-service platform, so internal stakeholders like customer support could sort out their requests themselves, without needing an engineer.

• Bugs and incidents. We planned to eliminate root causes. We had to redo parts of the architecture so certain issues wouldn’t appear anymore.

In about four months, KTLO went from 80% to around 30–35%. Over the rest of the year, we took on more initiatives, and it went below 20%.

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 of the 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%. On that team, after the first year, it settled between 15% and 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.