How I measure KTLO with a one-question survey

In my first week at N26, I had a 1:1 with every engineer in my three teams, fifteen people in total. In each one, I explained what KTLO was and asked one question: how much of your time do you feel goes into it?

When I put the answers together, the number was 78%.

Almost four out of every five hours were 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 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 video game company has little compliance work. A bank 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. At N26 I explained it in the 1:1 and asked 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 the number led to at N26

After the first round, I shared the result with the team so everyone could see we had a real problem.

One of the issues we found was support. Every time something went wrong, customer support contacted engineers directly on chat, often several engineers at the same time. That created a lot of distraction.

So we changed the process:

• A service desk. People submitted their requests there.

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

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

• A 24-hour SLA. A request submitted at 3 p.m. was handled at 9 a.m. the next day.

Setting up the service desk took one morning of work from me, one engineer, and the product manager.

Two months later, the survey showed KTLO down from 78% to 45%. People confirmed it in the “why” field: they had much less support work. It was one of the cheapest changes we made with the best return, and it was purely about how we managed 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 tried it before the survey 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 bank, 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. In a bank, the teams working on the ledger need more people than the teams working on sign-up, which 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.