A FinOps operating model and RACI that people actually follow

Quick answer

A workable FinOps operating model assigns decision rights for six recurring decisions: commitment purchases (FinOps decides, finance approves), right-sizing (engineering decides, FinOps recommends), budget setting (finance and engineering leadership jointly), anomaly response (owning team responsible, FinOps escalates), architecture cost tradeoffs (engineering decides, FinOps informs), and chargeback rules (finance decides). FinOps is accountable for visibility and recommendations; engineering is accountable for the spend itself. Blur that boundary and nothing moves.

The most common reason a cost program stalls is not missing data or missing tools. It is that nobody knows who is allowed to decide. FinOps builds a dashboard showing an oversized database; engineering assumes FinOps will handle it; FinOps assumes engineering will act; six months later the database is still oversized and both teams are frustrated. A written RACI fixes this in an afternoon.

The core principle

FinOps owns visibility, analysis, and recommendations. Engineering owns the resources and therefore the spend. Finance owns budgets, commitments, and the accounting treatment. A central team that tries to make engineering decisions becomes a bottleneck and is resented; an engineering organization with no central analysis capability re-derives the same conclusions twenty times. The model works when each group does the part it is structurally best placed to do.

The six decisions

Decision	Responsible	Accountable	Consulted
Commitment purchase	FinOps	Finance	Engineering leads
Right-sizing a workload	Owning team	Eng manager	FinOps
Budget setting	Finance	Eng leadership	FinOps, team leads
Anomaly response	Owning team	Eng manager	FinOps
Architecture cost tradeoff	Owning team	Eng manager	FinOps, architecture
Chargeback / showback rules	Finance	CFO	FinOps, eng leadership

Note where FinOps is accountable: nowhere on this list except commitment execution. That is deliberate. The team that cannot deploy or delete a resource cannot be accountable for what it costs. What FinOps is accountable for is separate: accurate allocation, timely anomaly detection, a maintained commitment portfolio, and recommendations with quantified impact.

Staffing at different sizes

Below roughly 1 million USD of annual cloud spend, FinOps is a part-time responsibility, typically 20 to 30 percent of one platform engineer plus a finance analyst who owns allocation. Between 1 and 10 million USD, one dedicated practitioner is usually justified, since a single 8 percent improvement on 5 million USD is 400,000 USD against a fully loaded cost of under 200,000 USD. Above 10 million USD, a small team of two to four covering analysis, engineering, and finance partnership is normal, plus a named cost champion embedded in each major engineering group.

The embedded champion role matters more than the headcount. A part-time champion per team who attends the monthly review, owns their team's cost view, and translates recommendations into backlog items is what turns central analysis into shipped changes. More on structures inFinOps team structure.

Write down the escalation path

Every model needs a defined answer for what happens when a recommendation is ignored. A workable ladder: FinOps raises a recommendation with quantified savings and effort. The owning team accepts it into the backlog or declines with a written reason. Declines are fine and expected; unanswered recommendations are not. Anything unanswered for 30 days, or any declined item above a materiality threshold such as 5,000 USD a month, goes to the monthly review with both engineering and finance leadership present.

That threshold is important. Escalating a 200 USD per month finding burns credibility. Escalating a 9,000 USD per month finding that has sat untouched for a quarter is exactly what the forum exists for.

Define the service FinOps provides

Treat FinOps as an internal service with commitments of its own: allocation data refreshed daily with untagged spend below a stated threshold, anomalies detected and routed within 24 hours, a monthly cost report per team, commitment coverage maintained within target, and a quantified recommendation queue. Publishing those commitments makes the team's value legible and gives engineering something to hold it to.

Avoid the two failure modes

The first is the cost police: a central team issuing tickets to engineering teams that never asked and have no capacity. It generates compliance theater and no savings. The second is diffuse ownership, where cost is "everyone's responsibility" and therefore nobody's, and no forum exists to make a tradeoff. The RACI plus a standing review forum, discussed in cost review cadence, avoids both.

Give engineering the data at decision time

Decision rights only help if the decider has numbers when the decision is made. Engineers choose instance sizes and storage classes in a pull request, not in a monthly report. Putting cost estimates in the review itself is what makes the model's central assumption true, that the owning team can decide well. C3X prices Terraform changes before merge and posts the delta in the pull request, so the accountable engineer sees the number at the moment they own the decision. See thepull request cost comment workflow.

FAQ

Who should own cloud cost in a FinOps operating model?

Split it. FinOps owns visibility, analysis, and recommendations. Engineering owns the resources and therefore the spend itself, since the team that can deploy or delete a resource is the only one that can be accountable for its cost. Finance owns budgets, commitment approval, and accounting treatment. A central team making engineering decisions becomes a bottleneck and generates resentment rather than savings.

What is FinOps actually accountable for?

Accurate cost allocation with untagged spend below a stated threshold, timely anomaly detection and routing, a maintained commitment portfolio hitting coverage and utilization targets, and a queue of recommendations with quantified savings and effort. It is not accountable for the spend itself, which belongs to the engineering teams that own the resources.

How should a FinOps practice be staffed?

Below roughly 1 million USD of annual cloud spend, treat it as 20 to 30 percent of a platform engineer plus a finance analyst. Between 1 and 10 million USD, one dedicated practitioner usually pays for itself several times over. Above 10 million USD, two to four people covering analysis, engineering, and finance partnership, plus a named part-time cost champion embedded in each major engineering group.

What happens when engineering ignores a cost recommendation?

Define the ladder in advance. FinOps raises a recommendation with quantified savings and effort; the owning team either accepts it into the backlog or declines with a written reason. Declines are legitimate; silence is not. Anything unanswered for 30 days, or declined above a materiality threshold such as 5,000 USD per month, goes to the monthly review with engineering and finance leadership present.

What are the common FinOps operating model failures?

Two. The cost police model, where a central team issues tickets to engineering teams with no capacity and no involvement, produces compliance theater rather than savings. The diffuse ownership model, where cost is everyone's responsibility with no forum for tradeoffs, produces nothing at all. A written RACI plus a standing monthly review avoids both.

How does C3X support the operating model?

Decision rights only work when the decider has numbers at the moment of the decision, and engineers choose instance sizes and storage classes in a pull request rather than in a monthly report. C3X prices Terraform changes before merge and posts the cost delta in the review, so the accountable engineer sees the impact while they still own the choice.

What to do next

Give the accountable engineer the number at decision time. C3X posts the cost delta in the pull request. See the quickstart.