FinOps gets introduced as cost management, which makes it sound like procurement with a dashboard, and that framing is most of the reason engineers tune it out.
Here's a better one. Every significant thing an engineer does has a feedback loop except this. That's the entire problem, and every practice in FinOps is an attempt to build one.
The comparison that makes it obvious
Put cost next to latency. Same organisation, same engineers, roughly the same level of care — and wildly different outcomes.
Property | Latency | Cost |
|---|---|---|
Time to signal | Seconds | Up to a month |
Attributed to | A deploy, a service, an endpoint | An account |
Measured in | Units engineers reason in | Currency |
Visible where | A dashboard people already watch | A finance report engineers never see |
Has a threshold | Yes, with an alert | No |
Has an owner | Yes, usually named | Usually nobody |
Read that table and the outcome stops being mysterious. Nobody cares less about money than about milliseconds. It's that one of them has six properties that make it actionable and the other has none of them.
Give cost the same six properties latency already has and most of the problem solves itself. That's the whole discipline, and it explains why cost-cutting sprints regress and instrumentation doesn't.
Why the monthly report doesn't count
Most organisations believe they have visibility because a cost report exists. It doesn't work, and it's worth being precise about why rather than concluding people are lazy.
Meyer et al.'s instrumented study found developers switching activity every 0.3 to 2.0 minutes outside planned meetings. A signal that arrives weeks after the decision, in a document nobody has a reason to open, competing against a day fragmented at that scale, is not a feedback loop. It's an artifact.
There's a second failure underneath it. Even if somebody reads the report, a month is long enough that the causal chain is genuinely hard to reconstruct. Four teams shipped; several things changed; working out which change added the cost is real investigative work that nobody is assigned. So the report gets read, the number is noted, and nothing happens — not from indifference, but because the report contains no actionable claim. XenGrowth's work on go-to-market systems writes about cost optimization as an operating problem rather than a build problem.
The practices, in the order they actually work
Order matters here more than in most disciplines, because each step is close to useless without the one before it.
Attribution. Map spend to teams and services. Tag what you can; where infrastructure is genuinely shared, allocate by a defensible proxy — requests, storage bytes, job seconds — and say plainly that it is a proxy. It only has to rank correctly, because every useful action comes from the ranking rather than the absolute figures
Visibility where the work happens. A per-team figure arriving unprompted in the channel that team already uses. Not a portal they could visit — something that shows up, in the same way an alert does
Ownership. One person with an objective containing the number and the authority to change designs. Visibility without authority produces reports; authority without visibility produces the situation you already have
Design-time estimation. A line in the design review template asking how this scales — with customers, with usage, with data volume, or not at all. This is the step that stops new cost being created, and everything above it only manages cost that already exists
Unit economics. Cost per customer, per tenant, per transaction. This is the metric that survives growth, and it is the one that tells you whether the business is improving
Most teams start at step four or five because those are the interesting ones, and it fails, because you cannot estimate what you cannot attribute and you cannot compute cost per customer from a bill that arrives as one number.
What attribution looks like when nothing is separable
Step one is where most teams stall, and the objection is always the same: everything is shared, so attribution is impossible. One cluster, one database, one bill, and no honest way to say which portion belonged to whom. Faced with that, teams either build nothing or embark on a quarter-long cost-allocation project that produces its first number after the pricing decisions it was meant to inform have already been made.
The way through is to give up on accuracy deliberately. Pick something you already measure per tenant that plausibly tracks consumption — requests served, rows scanned, storage held, background job seconds — and split the shared bill in proportion to it. Nobody should book the result in the accounts and you should say so every time you present it. What it gives you is an ordering, and an ordering is enough for every action that follows.
The reason that is enough: the decisions this unlocks are all comparative. Which tenants cost disproportionately more than they pay. Which service grew its share fastest this quarter. Whether the top decile is expensive because of a pricing gap or an access pattern. None of those questions needs a precise figure, and all of them are unanswerable without a rough one. An afternoon's allocation that ranks correctly beats a quarter's engineering that arrives late and answers a question nobody is still asking.
It also has a political advantage worth knowing about. A number presented as approximate invites correction rather than defence, so the team whose service tops the list tends to respond by improving the allocation rather than by disputing whether they should be measured at all. A number presented as exact invites an argument about the methodology, which is an argument you will lose because the methodology genuinely is approximate.
The metric that isn't total spend
A mistake worth naming because almost every organisation makes it: watching total infrastructure spend.
In a growing company, total spend rising is what everyone expects to see. More customers, bigger bill. So the number going up reads as confirmation that things are working, and nobody treats it as a signal — while the thing that actually matters is invisible. The XenGrowth resource library goes further into the operations side of this.
The ratio is what carries information. 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 getting worse 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 also why the problem tends to surface at the worst moment. Nobody inside computes gross margin weekly, so it goes unexamined until a fundraise or a diligence process, when somebody outside the company computes it for the first time and asks a question that has never been asked internally. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
What it isn't
Two clarifications, because the discipline attracts a particular kind of overreach.
It isn't minimising spend. The correct level of infrastructure cost is not the lowest achievable one — a company that under-provisions to protect margin and drops requests at peak has converted a gross margin gain into a churn problem, which is a worse trade. FinOps aims at spend being deliberate, not at spend being small.
And it isn't a replacement for architecture. A meaningful share of any bill is set by decisions no operational practice can recover — per-tenant floor costs, per-tenant scheduled work, cross-region chattiness, unbounded retention. Those need a design change, not a rightsizing exercise, and a FinOps function that keeps trimming around an architectural ceiling will plateau and then be judged to have failed. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
Anti-pattern | Why it fails | What to do instead |
|---|---|---|
Annual cost-cutting sprint | Fixes the stock, not the flow. Regresses in 18 months | Change what happens at design time |
Dashboard nobody opens | Visibility without ownership | Push the number; give it an owner |
Blanket percentage cut across teams | Punishes teams whose spend was justified | Cost per customer, per team, compared over time |
Approval gate on new resources | Catches small decisions, misses retention policy | Estimate at design review, not at provisioning |
FinOps specialist with no authority | A third person who can see but not act | Authority to change designs, or don't hire |
Watching total spend | Rises with growth, so it signals nothing | Infrastructure as a percentage of revenue |
The career argument, finally, and it's the reason to learn this rather than wait to be asked. Infrastructure sits in cost of goods sold, above the gross profit line, and it is very nearly the only item on a profit and loss statement that engineering can move without anyone else's cooperation. Sales cannot reduce your egress bill. Finance can ask about it and cannot change a retention policy.
There is no other lever like that available to an individual engineer. Most ways of being valuable need someone else's participation; this one needs a query, a proxy you can defend, and the willingness to send the result to somebody who owns a price.
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, who work on the commercial side of this covers the go-to-market side of cost optimization, which this piece deliberately leaves alone.
Start with attribution this week, even a crude one. Everything else in this post is downstream of being able to say which team, which service, or which customer the number belongs to.
