Every IT budget conversation I have watched go badly went badly for the same structural reason: the function showed up as a single line, and a single line permits exactly one conversation — make it smaller. The CFO has no lever for "spend the same money on better things." They have a lever for headcount and a lever for a percentage cut, and once a quarter they pull one. That is not a finance failure. It is what happens when a function that touches every part of the business presents itself as one undifferentiated cost.
I do not run the whole IT P&L. I run security and DevOps, which is a real slice of it, and I report the return on that slice to a board. That vantage is enough to see the pattern clearly. The problem is almost never the size of the number. The problem is that the number arrives with no P&L behind it and no price list in front of it, so nobody — including the people spending it — can say which dollars bought resilience, which bought growth, and which bought nothing anyone would miss. Give the function a P&L and a price list and the argument changes. The CFO stops negotiating headcount and starts negotiating value. That is the whole move, and everything below is how I would build toward it.
Give it a P&L: the translation layer between the invoice and the business
A P&L is not a bigger spreadsheet. It is a translation layer that turns what you bought into what the business got. The discipline that does this well already exists and has a name — Technology Business Management, the TBM taxonomy — and its whole contribution is a set of layers that let a single dollar be described three ways at once: as the vendor invoices it, as engineering runs it, and as the business consumes it.
The mapping is mechanical once you commit to it:
- Cost pools. The rawest layer — labor, hardware, software, cloud, facilities, outside services. This is how the invoices and the payroll actually arrive, and it is where most IT budgets stop.
- Towers. The engineering view — compute, storage, network, data platform, end-user services, security. This is the layer where an infrastructure leader already thinks, and the first one that means anything to the people doing the work.
- Applications and services. The things the business asks for by name — the decisioning service, the data pipeline, the identity platform, the internal agent platform. A cost that cannot be traced to a service is a cost nobody is accountable for.
- Business capabilities. The top layer, and the only one the CFO actually cares about — onboarding an institution, decisioning a request, serving an account, closing the books. This is where technology cost meets business value, and the layer almost every mid-market IT shop never builds.
Most organizations have the first two layers and stop. The bottom two are where the P&L lives, and finance cannot build them for you — they require someone who knows which invoice line powers which service. That someone is in IT. It is the most valuable financial artifact IT can produce, and it is almost never on the roadmap.
Showback before chargeback, and maybe instead of it
Once the mapping exists, the temptation is to weaponize it immediately — to start billing business units for what they consume. Resist that. There are two moves here and they are not the same. Showback makes consumption visible to the people who drive it; chargeback moves the money. Showback changes behavior; chargeback changes budgets and starts fights.
Showback is where the value is, and it is almost free of political cost. When a product owner can see that their feature drives the bulk of the data-transfer bill, or that a dashboard nobody opens is running a warehouse cluster around the clock, the behavior changes without anyone sending an invoice. The visibility does the work. I have watched a single cost-attribution view end an argument that a year of budget memos could not, because the memo asks people to trust a number and the view lets them see their own name next to it.
Chargeback is a heavier instrument and it fails in a specific, predictable way: the moment IT bills a business unit, it demands the right to buy the service elsewhere, and now you are running an internal market you did not staff for and cannot win on price. Chargeback is defensible when consumption is genuinely elastic and a business owner can act on the signal; it is destructive when it turns a shared platform into tolls that push teams toward shadow IT. My default is showback everywhere, chargeback only where the consumer has a real decision to make. In a lot of shops the honest answer is showback forever.
Unit economics per capability, not per cost center
Here is the number that changes the conversation, and almost no IT function can produce it on demand: what does one unit of a business capability cost to deliver? What it costs to onboard one more institution, to decision one more request, to serve one more account for a year. That is unit economics, and it is the language the rest of the business already speaks. Every other function can state its cost to serve; IT usually cannot, and that inability is why it gets managed as overhead.
We serve more than 1,500 financial institutions, and the framing that matters is not the total infrastructure bill — it is the cost to serve one institution, and the slope of that cost as we add the next thousand. A capability whose unit cost falls as volume grows is a scaling asset the CFO should be funding harder. A capability whose unit cost is flat or rising is a candidate for re-architecture, or a signal that the business model has a ceiling. You cannot see any of that from a cost-center total — only when spend is allocated down to the capability and divided by the units it produces.
The clearest version of this I have actually built is inside AgentOS, our governed internal agent platform. Because every agent runs through a control plane, the platform can attribute cost per agent, per team, and per task rather than presenting one aggregate bill that nobody can act on. That attribution is not an accounting nicety. It lets a team see the unit cost of an agent's work and decide whether it is worth it — the same showback discipline, applied to a capability that would otherwise be the most opaque line on the invoice. Build the attribution into the platform and the unit economics fall out for free. Bolt it on afterward and you spend a quarter reverse-engineering a bill.
Run, grow, transform — the split the CFO actually needs
A single IT number hides the one distinction that should drive every funding decision: how much of this keeps the lights on, and how much of it changes the business. Gartner's run/grow/transform split is the cleanest way I have seen to force it, and the ratio between the three is a sharper strategy signal than any roadmap slide.
- Run is keep-the-lights-on — the spend that, if it stopped, would break something already promised. It should be relentlessly driven down as a percentage over time — which is exactly what FinOps and platform consolidation are for.
- Grow is spend that scales the current business — more capacity, more capability, more of what already works. It should track the business, and its unit economics should be improving.
- Transform is the bets — the new capability that has no run-rate yet. It is the smallest number and the one the board should be most curious about — the only line buying a different future rather than defending the present one.
When IT is one line, run swallows everything and transform quietly starves, because keep-the-lights-on always feels more urgent than a bet. Splitting the number makes the starvation visible, which is the first step to funding against it. The other thing the split surfaces is the capital-versus-operating question, and here I will be careful about my lane. I am not your controller. But the shape matters: under the internal-use software rules — ASC 350-40 — some development-stage costs can be capitalized while planning and post-launch costs are expensed, so where a given transform bet lands changes how it hits the P&L this year. That is a conversation to have with finance early, not a surprise at close. Reason about the shape; let the controller rule on the specifics.
Spend as an investment thesis, not an insurance premium
The cost-center frame has a poisonous corollary for my part of the world: security gets sold as an insurance premium, a grudging payment against a bad day. I have argued elsewhere that this framing loses the budget conversation, and the P&L view is why. An investment has a thesis and a return. An insurance premium just has a price you try to minimize. If every IT dollar carries a thesis — this buys throughput, this buys a new capability, this buys a measurable reduction in expected loss — then the CFO is finally arguing about whether the return is real, instead of whether the team is one head too large.
For the risk side of the ledger, the honest way to state a return is in loss-exceedance terms, not fear. The FAIR model — Factor Analysis of Information Risk — exists precisely to express a control investment as a change in the probability and magnitude of loss, in dollars, which a finance committee can weigh against any other use of capital. It will not give you false precision, and you should not pretend it does. But a defensible range beats an adjective, and "this control reduces our annualized loss exposure from roughly this to roughly that" is an investment thesis. "We need it for security reasons" is a line item waiting to be cut.
The price list is what makes all of this operational. When a service catalog carries real rates — this is what a managed environment costs, this is what a new data pipeline costs to stand up and to run — business owners can make their own tradeoffs instead of routing every decision through a budget fight. A price list turns IT from a gatekeeper into a menu, and a menu is a far stronger position than a line item, because it invites the customer to spend more on the things that are worth it.
Start with the map, defend with the value
You do not need a TBM platform or a reorg to start — you need the discipline, and it fits in four moves.
- Build the bottom two layers. Map spend down to services and then to business capabilities — that mapping is the P&L, and only IT can produce it.
- Turn on showback before you touch chargeback. Make consumption visible to the people who drive it, and let the visibility change behavior before you move any money.
- Publish a unit cost and a price list. Pick the two or three capabilities that matter most, compute the cost per unit, and put rates in front of the business.
- Split run from grow from transform, and defend transform out loud. The ratio is your strategy; the bets are what the board should be asking about.
Do that and the next budget conversation is a different conversation. Not "cut ten percent," but "which of these returns do we want more of." I am still building toward the full version of this in my own slice, and I would rather compare notes than pretend it is finished. If you have run showback or chargeback in a mid-market shop — where it changed behavior, and where it started a fight you regretted — leave a comment. I read every one, and the failure stories are the ones I learn the most from.
