Here's a scene you have lived through.
It's Thursday. The release is Friday. Someone senior asks whether the database migration can wait one more sprint.
It can. It always can. It has waited eleven sprints already.
Nobody in that room is a villain. The feature is real, the customer is real, the date is real. But notice the asymmetry that nobody planned: the feature is defended by a date, and the migration is defended by a person. Dates do not get tired. People do.
So let's talk about the engineering investment mix. And we'll arrive at the conclusion that its value has very little to do with the numbers you pick, and almost everything to do with the fact that a number is not a person.
Here is the one I most often put in front of clients:
| Bucket | Share | Rule |
|---|---|---|
| Feature delivery | 50% | accept |
| Keep the lights on & support | 20% | minimize |
| Platform engineering | 30% | constrain |
Three buckets, three numbers, three verbs. Let's take them apart.
A number is a lightning rod
Start with why this is an alignment tool before it is a planning tool.
A developer who says I don't think we should skip this is making a personal claim. Personal claims are settled by seniority, by who slept better, by who has the political budget to spend this quarter. And people will spend that budget maybe twice before they quietly stop.
A developer who says this would put us under 30% on platform this quarter is making an organizational claim. The disagreement stops being about them.
That is the whole mechanism, and it is worth stating plainly:
People will externalize pressure put against a rule. They will not reliably externalize pressure put against themselves.
Pressure does not disappear because you wrote a policy. It has to go somewhere. Without a mix it travels through your people, and it earths itself in the quietest one on the team. A published mix is a lightning rod: it gives the strike a path to the ground that does not run through anybody's spine.
The second effect is smaller but nicer. Once a mix exists, "can we squeeze this in?" has an answer that is not yes or no, but yes, and here is what falls out. Trade-offs become visible instead of being absorbed.
What the three buckets mean
Feature delivery is work that changes what the product does for someone outside engineering. A new capability, a new integration, a new screen. Visible from the outside, and usually the thing that got funded.
Keep the lights on and support is work you would still be doing if the roadmap were empty tomorrow. Incidents, on-call, customer-reported bugs, dependency upgrades, CVE patching, answering why did this invoice not go out. It keeps yesterday's promises alive.
Platform engineering is work that changes how cheaply everything else can be done. Architecture, infrastructure, CI, the test harness, the core domain model, developer experience. Nobody outside engineering asks for it, and everybody outside engineering benefits from it. That combination is exactly why it loses every unstructured negotiation.
One line to keep: KTLO is the cost of your past, features are the value of your present, platform is the price of your future.
Accept, minimize, constrain
The verbs matter more than the percentages, because the verb tells you what to do when a bucket comes under pressure.
Accept feature delivery. This is the point of the company. You are not trying to shrink it and you should not feel clever about doing so. It gets the largest slice, without guilt. The 50% is not a target you chase – it is what the other two rules leave behind.
Minimize KTLO. This is the only bucket where lower is unambiguously better and there is no floor worth defending. Every hour here is rent on a decision made months ago. You will never reach zero, but a quarter where KTLO rises is a signal, not a scheduling accident – it is the earliest honest warning of decay an engineering organization produces.
Constrain platform engineering. Constrain means bounded on both sides, and both sides are doing work. The floor exists because this is the bucket that loses every Thursday. The ceiling exists because engineers given an unbounded mandate will happily rewrite the world. A floor is a promise. A ceiling is a leash. You want both.
It's a programmer's responsibility to introduce quality to the code. If you don't devote a bit of time for that, nobody does.
The rule is right about the responsibility – if a programmer does not devote a bit of time to quality, nobody does. But left there and nowhere else, it is also a trap, because a responsibility that lives only in one person's conscience is a responsibility that gets negotiated away one Thursday at a time. A floor does not replace that responsibility. It gives it somewhere to stand.
The golden rule of project management says you may fix scope, time and cost, but never all three at once. A mix is that same admission, made once in a calm month rather than badly, at 4pm, every Thursday.
And there is a price attached to getting the third bucket wrong. In the health checks I run, development work in a codebase with no sustained platform investment carries a technical debt multiplier somewhere in the 1.5x to 2.0x range, depending on the type of work. You do not avoid paying for platform engineering. You only choose whether to pay for it deliberately or at a markup.
So where do bugs go?
This is the question that comes up first, every single time, and it is the one worth getting right.
Fixing bugs goes into KTLO and support. Not platform engineering.
I know the temptation. Bug work feels technical, feels like maintenance, feels like the opposite of shipping features – so it drifts toward the platform column. Resist it, for one reason:
If bugs live in the platform bucket, a bad quarter of firefighting looks identical to a healthy quarter of modernization. You hit your 30%, you report green, and you modernized nothing. The mix now actively conceals the thing it was built to protect.
Here's the test I use. Call it the cheaper-next-time test:
If this work is done well, does the next piece of work get cheaper?
Fixing a null check makes nothing cheaper – that's KTLO. Fixing the reason null checks keep appearing in that module makes everything after it cheaper – that's platform. Upgrading a library because a CVE landed is KTLO. Upgrading the same library because it unblocks a framework version you need is platform. Same command in the terminal, different bucket, because the intent differs.
Yes, this is gameable. Any categorization is. The defence is not a better taxonomy – it's that the categorization happens out loud, in front of the team, at the moment the work is picked up, rather than by a manager reconciling a spreadsheet three weeks later.
Mixes in the wild
Mine is not the only one, and it is worth knowing the neighbours.
Google's 70/20/10, popularized by Eric Schmidt, is the ancestor of all of these: 70% to the core business, 20% to adjacent bets, 10% to transformational ones. It is a portfolio rule rather than an engineering mix, but the shape is the same.
Google's SRE 50% cap is my favourite, because it ships with a consequence. SRE teams cap aggregate operational work at 50% of their time, and overflow above the cap is routed back to the product development team that produced it. Most mixes are aspirations. That one has teeth, and it is the difference that matters. A mix without a consequence is a wish.
LinearB's Investment Strategy slices finer – New Value, Feature Enhancements, Developer Experience, KTLO, and an Inefficiency Pool – and publishes benchmarks: roughly 55% new value for elite teams, 15% developer experience, KTLO held near 10%.
Jellyfish's Resource Allocations uses Roadmap, KTLO, Support and Infrastructure.
Across the industry, reported KTLO commonly lands in the 20–40% band depending on system age and incident rate.
Look at those together and something jumps out. Everyone agrees, roughly, how much belongs to features – somewhere between half and two thirds. Nobody agrees on what to call the remainder. The disagreement in this field is not about how much to invest in the future; it is about how many names the future needs.
Four buckets, five buckets
So is there a four-item split in the wild? There is – Jellyfish is the clean example, and LinearB goes to five.
When is splitting worth it?
Split KTLO from support when the two move independently. Support scales with your customer count; KTLO scales with your system's age. Fused into one bucket, you cannot tell a growth problem from a decay problem – and those have opposite remedies.
Split new value from enhancement when you need to know whether you are still acquiring customers or only retaining them.
Add a compliance bucket in a regulated sector. That work is non-negotiable, it is lumpy, and hidden inside KTLO it quietly distorts every other number you own.
But every bucket you add costs you a conversation at its boundaries. Three buckets have three boundaries to argue about. Five have ten. That growth is quadratic, and it is paid in meetings.
So the rule of thumb is: add a bucket only when you already know the decision you would make differently if the numbers separated. If splitting KTLO and support would not change what you do next quarter, you have bought yourself ten arguments for nothing.
The same discipline applies to changing the numbers. Revisit the mix quarterly, and let the argument happen there – in a room set up for it, with the quarter's evidence on the table. The point was never to end the argument. It was to move it somewhere it can be won on merit.
To sum it up in a few points
- Pick the numbers, publish them, and put them where the arguments actually happen. The numbers matter less than their existence.
- Accept feature delivery, minimize KTLO, constrain platform engineering – with a floor and a ceiling.
- Bugs are KTLO, never platform. Use the cheaper-next-time test: does the next piece of work get cheaper?
- A mix without a consequence is a wish. Decide in advance what happens when a bucket is breached.
- Add a fourth bucket only when you can name the decision it would change.
Next Thursday, someone will ask whether the migration can wait one more sprint.
The answer is not yours to give any more. It belongs to a number the whole room agreed to in a calmer month – and that number does not get tired, does not sleep badly, and has no political budget to run down.
Let it take the strike.
That's it for today.
References
- Eliminating Toil – the 50% operational cap, in the Google SRE book
- The 70-20-10 Rule of Innovation – Viima's write-up of the Google portfolio model
- Investment Strategy – LinearB's five-category split and benchmarks
- Resource Allocations – Jellyfish's four-category framework
- Beyond KTLO: How Engineering Leaders Navigate Time Allocation – The New Stack, on allocation in practice
