Most IT budget conversations start from the same quiet surrender. Some large share of the spend, and the figure people quote is around seventy percent, goes to keeping the lights on. The only real debate left is how to fund anything new out of what remains. The number gets repeated like a law of physics. Run is fixed, grow is discretionary, and leadership's job is to defend a shrinking discretionary slice against a fixed one that never stops climbing.
I want to take that number apart, because I don't think most of it is fixed at all. Where I sit matters for how you read this. I don't sign the whole IT P&L. I run a real slice of it (security and DevOps at a fintech that serves more than 1,500 financial institutions) and I report the return on that slice to a board. This is analysis from that vantage, not a controller's ruling. But from that seat the run line looks less like weather and more like a stack of choices nobody wrote down, and the way I decompose it works whichever seat you're arguing from.
The run floor is unaudited, not fixed
Here is the sleight of hand. On a spreadsheet, fixed cost and unexamined cost look identical. Both show up every year at roughly the same size. Both answer the question "can we cut this?" with a shrug. But one is fixed because the business genuinely cannot operate without it, and the other is fixed only because no one has opened it up and asked what is inside.
The seventy-percent figure is an average borrowed from analyst surveys, and averages are where accountability goes to hide. Nobody's run line is seventy percent for a reason they chose. It is seventy percent because it was sixty-eight last year, and it climbs a little every year through accretion: a renewal here, a server nobody turned off there, a contractor who quietly became permanent, a platform that was supposed to be temporary and is now load-bearing. Each increment is defensible on its own. No single one is ever large enough to challenge. That is exactly how the number got large, through the absence of a decision, repeated for years.
The good news hides in the same mechanism. Anything that compounds quietly against you can be made to compound quietly for you. A run line that drifted up a point or two a year through neglect can drift back down through attention, and every point you move from run to grow keeps paying out, because you are lowering the floor you build on next year rather than funding a one-time cut. But you can't attack an average. When I look at a run line, I sort every dollar into one of three buckets, and the sorting is more useful than any cost-cut target a finance team could hand me.
Compounding drag and stranded cost, not fixed cost
The three buckets are not equal, and only one of them earns the word fixed.
- Genuinely fixed. The spend the business cannot run without and cannot meaningfully shrink without leaving a market. The core ledger. The regulated data stores. The identity backbone. The minimum staffing to keep those safe and audited. This bucket is real, and you protect it. It is also smaller than the seventy-percent headline implies, usually far smaller than the people quoting the headline believe.
- Compounding legacy drag. Spend that grows every year for reasons nobody actually chose. The system everything integrates against because rewriting it is frightening. The framework two versions past end-of-support that now needs a specialist to touch. The workaround that became the process. This is debt, and its interest is paid in run dollars every quarter, whether or not anyone books it that way.
- Stranded cost. Spend still attached to value that already left the building. The license for the tool you replaced but never cancelled. The environment for the product you sunset. The seats for the team that reorganized eighteen months ago. The redundant capability you pay for twice because two acquisitions each brought their own and neither was ever retired.
What matters is the cost of reclaiming each one. The first bucket you can't touch without giving something up. The second and third you can attack without losing a single unit of capability, because in both cases you have already stopped getting the value. That is the whole argument, and it is why I start here instead of with a cut target. You are not being asked to do more with less. You are being asked to stop paying rent on an apartment you already moved out of.
Decommission on a schedule, not on permission
Stranded cost persists for one boring, structural reason: decommissioning is nobody's job. The person who benefits from turning something off, finance or the budget owner, is not the person who has to do the work of turning it off. That's engineering, and engineering is measured on shipping the new thing, not retiring the old one. So the old thing runs forever. Not because anyone decided it should, but because no one was ever assigned to decide it shouldn't. The default state of any system is "still on," and defaults win when nobody owns the alternative.
The fix is to make retirement an event with an owner and a date, tied to the thing that replaced it. My rule is simple and unpopular: you don't get to stand up the new system until the old one has a retirement date on the calendar and a name against it. Decommissioning becomes a funded line inside the migration, not a cleanup task that evaporates the moment the replacement goes live. That closes the window where stranded cost is created: the gap between "the new thing works" and "someone finally turned the old thing off," which in most shops is measured in years.
The dollars you reclaim this way are the cleanest you will ever move to grow. No capability lost. No new risk taken on. No team asked to absorb more. Do it for a couple of cycles and a second effect shows up worth as much as the money: the run line stops being a mystery. Every system left in it has an owner who can say why it is still on, and "why is this still running" becomes a question with an answer instead of a shrug and a search through the invoices.
The exit ramp is a lever you designed away
Some stranded cost you cannot simply switch off, because a contract holds you to it. Treat what follows as a working understanding rather than accounting advice, since I'm not your controller, but the pattern is consistent enough that I trust it. Stranded run cost is sticky in direct proportion to switching cost, and switching cost is mostly contractual. Auto-renewal that rolls you into a fresh multi-year term before you've looked. Data-egress fees that make leaving expensive on the way out. Professional-services dependencies that quietly wired a vendor into how you operate. None of those are laws of nature. They are terms, and terms are set, or conceded, at signing.
The lever most organizations design away is the exit ramp. They negotiate hard on price and never mention departure, so every contract becomes a one-way door, and every one of those doors is a place stranded cost can accumulate with no clean way out. Negotiate leaving before you ever need to: data portability in a usable format, a defined wind-down period, no automatic roll into a new commitment. The point is not to leave every vendor. It is that the ability to leave is the only thing that makes a stranded-cost conversation real. A vendor who knows you are locked in has no reason to give anything back. Buy the option to stop at the moment you have leverage, which is the day you sign, not the day the renewal notice arrives.
Automate the toil, don't staff it
Not all of the run line is software. A large, under-examined part of it is human toil: the manual, repetitive work of keeping existing things running. Provisioning and deprovisioning access. Collecting the same evidence for the same audit every year. Orchestrating patches. Triaging tickets that are really just the same five questions in different words. Assembling by hand a report that assembles itself everywhere except here. This is labor priced as fixed cost, and it is the run spend people are least willing to name, because naming it sounds like naming people.
It isn't, and the reframe matters. The goal is not to cut the people. It is to stop spending scarce, capable people on work a governed system can do, and move them to the grow side where the business actually needs them. My team built AgentOS, a governed internal agent platform, and the same logic applies to it. The constraint that matters in a regulated shop is that automating run toil cannot mean trading it for uncontrolled risk. An unsupervised agent with real credentials is a new run cost, not a saving. So the automation lives behind a control plane: scoped tool authority instead of broad credentials, an act-or-interpret boundary between deciding and doing, an audit trail so every action is reconstructable, and five guardrail layers between the agent and anything it can touch. The governance is what makes the automation something a regulated business is allowed to run at all.
Framed as a budget move, this one changes the shape of the spend rather than just its size. Decommissioning and contract exits shrink the run line. Automation converts run labor into grow capacity without a layoff. You keep the people and change the work, which is the rarer trade and the one a board is happiest to hear.
Move the money to the front of the house
The run floor is not a fixed cost of doing business. It is an unaudited one, and seventy percent is what an unaudited cost looks like after a few years of nobody opening it. Decompose the run line into genuinely fixed, compounding drag, and stranded before you argue for a single dollar of grow. Attach a retirement date and an owner to everything new you stand up, and fund the retirement, not just the launch. Negotiate the exit before you sign. Automate the toil under real governance, and move the people you free to the work that grows the business.
The line between genuinely fixed and merely unexamined is the one every operator has to draw for themselves, and it is almost always drawn too generously. Open your own run line and the biggest bucket will not be the one you were defending.