Ask who owns the cloud bill and you'll get a confident answer that dissolves under any follow-up. Finance owns it, in the sense that it arrives addressed to them. Engineering owns it, in the sense that they caused all of it. The platform team owns it, in the sense that they get asked about it.
Nobody owns it in the sense that matters: nobody has an objective that contains the number, and nobody will be asked about it in a performance review.
That's the actual problem. It gets discussed as a technical problem — the wrong instance types, unused volumes, over-provisioned clusters — and those things are all true and all symptoms.
The gap, stated precisely
Two groups, and neither can act alone.
Finance sees the bill in complete detail, to the cent, every month. They cannot change a line of it. Every decision that produced that number — this instance class, this retention period, this many replicas, this region — was made by somebody else, months ago, for reasons finance has no visibility into and no standing to question. Teams who need the cloud bill nobody owns translated into a marketing operating model tend to find the XenGrowth practice useful.
Engineering makes every one of those decisions and typically has never seen the bill. Not out of secrecy; it's just not in anyone's workflow. An engineer choosing a database instance class picks the one that will comfortably handle the load, because that is the question they were asked and the only one they have information about.
Nobody is behaving badly here. Everyone is optimising correctly for the information and incentives they actually have, which is exactly why the number keeps going up.
Four structural features that make it worse
Feature | Consequence | Contrast with a cost that behaves normally |
|---|---|---|
Consumption cost, reported like a fixed cost | Appears as a monthly line rather than a series of decisions | A hiring decision is visibly a decision, with an approver |
Feedback delayed by up to a month | The decision and its cost are never in the same conversation | A failing test tells you within minutes |
Attributed to an account, not a team or feature | No one can be shown their own contribution | Headcount cost is unambiguously attributable |
Denominated in money, not in engineering units | Invisible in every tool an engineer uses daily | Latency and error rate are on dashboards people look at |
The second row is the one that does most of the damage. A month is long enough that the causal link is genuinely hard to reconstruct even by people trying — by the time the bill arrives, four teams have shipped, and untangling which change added the cost is real work that nobody is assigned. On the operations side of this specifically, The XenGrowth resource library is worth reading.
Compare this to how the same organisation treats latency. Latency has a dashboard, an alert, an owner, and a threshold. It is measured in units engineers use, visible within seconds, and attributable to a deploy. Cost has none of those properties, and the difference in outcomes is entirely explained by that rather than by anyone caring less about money than about milliseconds.
Why growth hides the problem for years
There is a specific reason this goes unexamined for so long in companies that are otherwise well run, and it is not negligence. In a growing business, total infrastructure spend rising is exactly what everyone expects to see. More customers, bigger bill. The number going up is confirmation that things are working, so nobody treats it as a signal.
What that framing conceals is the ratio. Spend rising more slowly than revenue is a business improving; spend rising in step with revenue is a business that has stopped benefiting from its own scale; spend rising faster than revenue is a business quietly becoming a worse one while every absolute number on the dashboard goes up and to the right. All three look identical if you only watch the total, and the total is what gets reported.
This is why cost per customer, or infrastructure as a percentage of revenue, is the only version of this metric worth putting in front of anyone. It is also why the problem tends to surface at the worst possible moment — during a fundraise or a diligence process, when somebody outside the company computes gross margin for the first time and asks a question nobody inside has been asking.
Why the usual fixes don't hold
Most organisations respond to a bad bill with a cost-cutting sprint. Someone spends three weeks finding waste, spend drops, everyone is pleased, and eighteen months later the number is higher than before.
This is not because the work was bad. It is because a sprint fixes the accumulated stock of waste without changing the flow that produced it. Nothing about the next hundred decisions is different, so the stock rebuilds at exactly the rate it built the first time. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
The cost-cutting sprint: fixes the stock, not the flow. Reliably regresses
The dashboard nobody looks at: visibility without ownership changes nothing, because looking at it is not anyone's job
The approval gate on new resources: slows delivery, catches the small decisions, misses the retention policy and the access pattern that actually drive the bill
The blanket percentage cut: hits teams uniformly regardless of whether their spend was justified, which teaches everyone to pad rather than to optimise
Hiring a FinOps specialist with no authority: creates a person who can see the problem in more detail than anyone and still cannot change a decision
That last one is worth dwelling on because it is increasingly common. Adding a specialist to a system whose defect is that authority and visibility sit in different places just adds a third person with one and not the other.
What actually changes the flow
Attribute spend to teams before optimising anything. Tag by team and service, and where infrastructure is genuinely shared, allocate by a defensible proxy — requests, storage, job seconds — and say openly that it is a proxy. Ranking correctly matters far more than being accurate
Put the number where the decisions happen. A monthly figure per team, in the channel that team already uses, unprompted. Not a portal they could visit; something that arrives
Give one person an objective containing the number, with the authority to change designs. Visibility without authority produces reports, and authority without visibility produces the current situation
Review cost per customer rather than total spend. Total spend should rise in a growing company, so it is a bad metric that punishes growth and rewards nothing. Cost per customer is the one that says whether the business is getting better
Put a cost line in the design review template. One sentence on how this scales — with customers, with usage, with data, or not at all — moves the conversation from after the bill to before the decision
Say what the saving is worth in gross margin, not in dollars. A dollar figure competes with every other dollar figure; a margin point is a metric the board already watches, and it survives the meeting
The first of those is worth more than the rest combined, and it is the one most often skipped because it produces no immediate saving. Attribution is what makes every subsequent argument possible: without it, cost is a company-wide weather condition, and with it, it is a set of decisions with names attached. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
One caution on the sixth point, because it can be overdone. Translating everything into margin language works precisely because it is unusual, and it stops working the moment it becomes a rhetorical habit applied to any proposal an engineer already wanted. If the saving is small, say it is small. The credibility that makes the technique effective comes from being the person whose numbers hold up when someone checks them, and that reputation takes one exaggeration to lose.
The argument for caring, if you're an engineer
There's a reasonable objection here, which is that this is not your job and taking it on is unrewarded work in an organisation that measures delivery.
The counter-argument is narrow and I think it holds. Infrastructure cost is the largest input to gross margin that engineering controls unilaterally. Gross margin is the metric software valuations rest on, and software businesses are generally expected above roughly 75%. So this is the one line on the P&L you can move without needing sales to sell more, finance to approve anything, or a single other department to cooperate.
There is no other lever like that available to an individual contributor. Most ways of being valuable require someone else's participation; this one requires a query and a conversation.
Who can see it | Who can change it | Who is measured on it |
|---|---|---|
Finance — in complete detail | Engineering — every line of it | Typically nobody |
After a delay of up to a month | At design time, months earlier | — |
Aggregated by account | Decided per service and per feature | — |
In currency | In instance classes and retention policies | — |
Read that table down the third column. Everything else about this problem follows from it, and every technical intervention that ignores it will work for one quarter and then stop.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's growth operations team writes for the teams who have to run the cloud bill nobody owns day to day.
