Skip to content
Open to board advisory and board seats: 2H 2026, then CY 2027-2028.
See details →
Writing

The 70/20/10 Budget Split Is a Story, Not a Number.

Seventy run, twenty grow, ten transform gets quoted like a dial you can turn. It is worth nothing unless you can tag every dollar and defend the tag.

By Michael YorkSeptember 28, 2026 7 min read 1,683 words All postsTable of contents

The 70/20/10 split shows up on the same slide in every IT budget review I have sat through. Seventy percent to run the business, twenty to grow it, ten to transform it. Someone puts the ratio on the wall, compares it to the industry benchmark, the room nods, and the meeting moves on, because the number is clean and it sounds like strategy. Nobody asks the only question that matters: where did that ratio come from, and could you produce it again from your own ledger if I asked you to right now?

Almost no one can. The 70/20/10 split is a story a company tells about the shape of its spending. It is a good story, and a story is not a number you can manage. To manage the ratio you would have to tag every dollar to run, grow, or transform, defend each tag, and re-derive the total on a schedule. That work is the discipline. The ratio is what falls out of it. Most budgets quote the benchmark instead of their own figure because the tagging was never built: it is tedious, contested, and invisible until someone insists on it.

I want to be honest about my seat. I do not own the whole IT P&L. I run security and DevOps, a real slice of it, and I report the return on that slice to a board. I have argued before that IT should arrive at the budget meeting with a P&L instead of a single line, and the run/grow/transform ratio is the one cut of that P&L people quote most and understand least. That vantage taught me the lesson the hard way. When a director asks how much of your spend keeps the lights on and how much builds something new, the answer lives entirely in how you tagged the spend, not in the ratio you cite. Get the classification wrong and every downstream number is confident and false.

The ratio is a benchmark, not a control

Start with where 70/20/10 comes from, because the provenance explains the misuse. The shape gets attributed to a couple of places at once. Gartner has long sorted IT spending into run, grow, and transform: keep-the-lights-on, scale-the-current-business, and bet-on-a-different-one. The innovation-portfolio literature uses the same 70/20/10 proportions for core, adjacent, and transformational investments, and the version of that argument that ran in Harvard Business Review has been quoted in strategy decks for well over a decade. The exact lineage matters less than what the number does once it is in a room. It stops being a description and becomes a target.

A benchmark tells you what a healthy budget tends to look like across a lot of companies. It does not tell you what your budget is, and it certainly does not tell you what to do on Monday. The failure I see repeatedly is a leadership team that adopts 70/20/10 as an aspiration, "we should get transform up to ten percent," without ever having measured where they actually are. They are steering toward a benchmark from an unknown starting point, on a gauge that is not wired to anything. You cannot close a gap you have not measured, and you cannot measure this one without doing the classification work the benchmark quietly assumes you already did.

The dollar has no natural category

The tagging is genuinely hard, not merely neglected. Run, grow, and transform are not properties of a dollar. They are properties of intent, and intent does not appear on any invoice. The same dollar is run to one person and transform to another, and both are telling the truth.

The collisions are everywhere once you look:

  • A cloud account runs production for a service you already sell, which is run, and in the same account hosts the private beta of the thing you hope to sell next year, which is transform. The bill arrives as one number with no line that separates them.
  • A platform engineer's week is maybe sixty percent keeping things alive, thirty percent scaling what works, and ten percent building what does not exist yet. Payroll tags none of it. It books the fully loaded cost to a cost center and calls the matter closed.
  • A single vendor invoice for observability, a data warehouse, or an identity provider is pure run for the team that depends on it and pure transform for the team instrumenting a capability that shipped last month. Same contract, same renewal, two honest categories.

Because the category is intent, there is no join key from the ledger to the taxonomy. You cannot derive run/grow/transform mechanically the way you derive a cost pool from a general-ledger account. Someone has to decide, dollar by dollar or allocation by allocation, against a written rule, at the layer where costs are already being split. That decision is the classification, and it is the part everyone skips before wondering why their ratio is fiction.

The category migrates; the ratio pretends it is fixed

Tag every dollar perfectly today and you are still not done, because the tags do not hold still. Spend moves between buckets over its life, and the invoice never tells you it happened.

The clearest example I have lived is AgentOS, the governed internal agent platform my team built. When we started it, it was transform in the purest sense: a bet with no run-rate, no dependents, and no guarantee it would matter. It sat in the ten percent, exactly where a bet belongs. It is not there anymore. Teams now run daily work through it, so its keep-the-lights-on cost, the control plane and the reliability and the on-call, climbs every quarter, while the genuinely new work has shrunk to increments on top of a platform that now has to stay up. The same system that was transform not long ago is mostly run today. Nothing on any invoice changed. What changed is what the spend is for.

This is the trap in treating classification as a one-time exercise. Tag the budget once, file it, and last year's transform gets counted as this year's transform forever. Your ratio then drifts away from reality in the flattering direction, because the exciting bets from two years ago are still parked in the transform column long after they became infrastructure you cannot turn off. A ratio that is never re-derived measures your memory of your strategy, which is a different and much kinder thing.

Once it is a target, it gets gamed

Then there is the failure Goodhart's law promises and every operator has watched arrive on schedule: the moment a measure becomes a target, it stops measuring. Put "get transform to twenty percent" on the board's scorecard and you have created an incentive that has nothing to do with changing the business. The cheapest way to hit a classification target is to reclassify, not to reallocate.

So a lift-and-shift migration, which is run wearing a nicer jacket, gets relabeled modernization and jumps to transform. A mandatory keep-the-lights-on upgrade becomes a "platform investment." A security control you had to ship for an exam gets filed under grow because it touched a growth-adjacent system. None of the money moved. None of the work changed. No new capability arrived. But the slide now looks like a company investing in its future, and everyone gets to feel good about a ratio that describes nothing. This is why the classification rules have to be stronger than the ratio target. You need someone who cannot be talked into moving a dollar's tag unless the underlying work actually moved.

Build the chart of accounts before you quote the ratio

The fix is not a better benchmark. It is to treat run/grow/transform the way finance treats a chart of accounts, as a governance artifact with definitions, rules, and an owner, and build it before you ever quote a ratio to a board.

Concretely, that means four things. Decide the definitions once and write them down, in enough detail that two reasonable people tag the same invoice the same way. Write down the edge-case rules explicitly, because the edges are where the discipline actually lives: does a lift-and-shift land in run or transform (run, you moved the same capability); does a platform that is half keep-the-lights-on and half new work get split or assigned to its dominant intent (pick one convention and hold it); does a mandatory control count as transform because it is new (no, it defends the present, so it is run). Tag at the cost-allocation layer where the dollars already live, not in a separate spreadsheet that drifts from the ledger the day you save it. And put a single owner on the taxonomy who arbitrates the disputes, because there will be disputes, and a rule with no arbiter is a suggestion.

Do that and the ratio becomes something you can defend under questioning, because the number is a consequence of rules fixed in advance rather than a figure assembled the week before the meeting. Then re-derive it every quarter and report the trend line rather than the target. A transform number slowly climbing while run falls as a percentage is a real strategy signal. A transform number that hit exactly twenty percent the quarter after the board asked for twenty percent is a warning.

Tag the spend, then tell the story

The 70/20/10 split is worth having. Just not as a dial you pretend to turn.

  • Derive your own ratio from your own ledger before you quote anyone's benchmark. The benchmark is a story; your number is the work.
  • Write the classification rules down and put one owner on them, because the edge cases are where the ratio is won or lost.
  • Re-tag every quarter. The category migrates even when the invoice never changes, and last year's bet is quietly this year's infrastructure.
  • Report the trend, not the target, and defend transform out loud before run swallows it.

A ratio you cannot re-derive on demand is not a management number. It is a slide, and slides do not survive the first director who asks where the figure came from.

Budget StrategyIT FinancePortfolio ManagementBoard Reporting