How I measure KTLO with a one-question survey

Say you take over a group of teams. In your first week, you hold a 1:1 with every engineer. In each one, you explain what KTLO is and ask one question: how much of your time do you feel goes into it?

You put the answers together, and the number is around 75%.

Three out of every four hours are going into keeping things running instead of building the product.

If your team feels like it’s always firefighting but you can’t say how much, this is how I get a first number, and what I do with it.

What KTLO is

KTLO stands for “Keep the Lights On”: the work to keep systems running, secure, and compliant, as opposed to building the product. I explain it in more detail in my What is KTLO post. For this post, you only need the split:

• Features: building the product.

• KTLO: everything that keeps it running, from incidents and patching to audit findings and compliance gaps.

Which KTLO work matters most depends on the company. A product with little regulation has little compliance work. One in a heavily regulated industry has a lot.

I measure KTLO because I want to maximize the time spent building features. A lot of KTLO tells me something is wrong. It might be how the teams are structured, so they hold obligations they shouldn’t. Or it might be constant firefighting, which usually points to low system quality. To know which, I need a number first.

The survey

When there’s no tracking at all, whether in a small startup or in a big company that never measured it, I start with a survey that asks people how much time they feel they spend on KTLO.

It’s not accurate, and that’s fine. Its purpose is to show me where the team is struggling, not to produce an exact number. I do it in three steps.

1. Explain KTLO first

People can’t estimate something they don’t understand. A 1:1 is a good place to explain it and ask the question right after.

2. Ask one question for a fixed period

For example: “Over the last month, how much of your time do you feel you spent on KTLO?” If you measure weekly, ask about the last week. In the same question, list examples: incidents, audit findings, patching, and whatever else applies in your company.

Some managers split the question into categories and ask for a percentage in each. I find that harder, because people then have to make the numbers add up, and precision isn’t the point.

3. Ask why

Right after the percentage, add a text field: “What makes you feel it’s that percentage?”

This field is the most valuable part. People write things like:

• We had a lot of incidents.

• I spent a lot of time on maintenance.

• I got stuck on a bug.

• I spent two weeks on audit findings.

Read together, the answers show you whether the team is badly structured, holding responsibilities it shouldn’t, or dealing with serious quality issues.

What to do with the number

After the first round, share the result with the team, so everyone can see there’s a real problem.

Then look at the “why” answers for patterns. A very common one is support. Every time something goes wrong, customer support contacts engineers directly on chat, often several engineers at the same time. That creates a lot of distraction.

A process change fixes most of it:

• A service desk. People submit their requests there.

• No support on chat. Be radical about this rule. Anyone asked for help on chat, in the team channel or privately, replies with the link to the service desk.

• A weekly firefighter. One engineer per week starts every morning by going through the service desk and processing the requests.

• A clear SLA. For example, 24 hours: a request submitted in the afternoon is handled the next morning.

Setting up a service desk like this takes a few hours from a handful of people. In my experience, it’s one of the cheapest changes with the best return. The next survey usually shows a big drop, and people confirm it in the “why” field: much less support work. And it’s purely about how you manage a process.

The survey’s limits

The survey is imprecise and emotional. The biggest bias is recency. If you ask about the last month and the team had a terrible week of incidents right before the survey, people will exaggerate. The same week at the start of the month would produce a lower number, because recent pain is remembered more.

What about tickets and AI?

Tagging tickets as KTLO or features sounds more objective. I’ve tried it and didn’t like it. It was bureaucratic and just as error prone: people forgot to tag, forgot to create tickets, or didn’t update the status on time.

Tickets also don’t show how many people work on each one. Imagine two tickets with the same start and end dates, one KTLO and one feature. If three people worked on the feature and one on the KTLO, the real split is 25/75, not 50/50.

Tickets work only if the team is mature and has strong process discipline. I’ve worked with managers who preferred them for exactly that reason. Without that maturity, you get a number as unreliable as the survey, and you lose the “why”, so you still have to talk to people to understand it.

AI changes this a bit. It can read ticket descriptions, fill some gaps, and cross-check other sources like docs, spreadsheets and GitHub to infer how many people worked on something. It can also surface patterns, such as many issues coming from the same source, and suggest what to fix. But it still needs good ticket data. If your data is poor, AI will work poorly too.

So the survey works at every level of maturity. Tooling works only with high maturity, and then it removes the emotional bias and the need to ask people every month.

When KTLO is real and you can’t remove it

Sometimes the number is high and the work is real. In a regulated industry, an audit can leave you with a long list of compliance gaps that must be closed.

First, understand how you got there, because someone made choices in the past that weren’t compliant. Then look for ways to take engineers out of the work. If auditors keep requesting information, build systems that provide it automatically, or that let other functions, like legal, access it without engineering.

If an area still spends something like 60% of its time on compliance, it’s probably too small. Some areas need more engineers because of their obligations. Teams that own core systems with heavy regulatory requirements need more people than teams that mostly build product features.

Finally, choose carefully who does this work. Reactive and preventative KTLO is stressful and comes with hard deadlines. Put very senior or product-focused engineers on it and you’ll burn them out. Engineers who like compliance work, or more junior engineers who are still learning, can thrive there, at least for a while.

The takeaway

If your team feels buried but you have no number, don’t wait for perfect tooling. Explain KTLO, ask one question, and always ask why. The percentage gives you a starting point, and the reasons tell you what to fix. In an upcoming post, I’ll cover how to set a KTLO budget and which levels should worry you.

If you want to go deeper now, my Operational Excellence course covers this in detail: how to measure KTLO, track it as your team matures, and bring it down so your team can spend its time building instead of firefighting.