A company of 10 to 200 people practises FinOps by spreading the Framework's capabilities across three roles it already has: an engineering lead, the person who pays the cloud bill, and management. A FinOps function of its own is not a precondition; the FinOps Foundation, whose Framework is licensed CC BY 4.0, describes the practice explicitly as something no single person or team does, but as a change in how existing teams work together. This matters for the bill because in a growing company cloud cost grows with the product, and without named ownership nobody can say which part of the rise is product and which part is waste.

How it works

The Framework distinguishes six core personas: FinOps Practitioner, Engineering, Finance, Product, Procurement and Leadership. It states that personas are stakeholder groups and that in a small organisation one person represents several of them. The split across three roles follows from what each role already knows:

Role in the companyFramework personasBringsDecides
Engineering leadEngineering, Product, usually FinOps Practitioner as wellUsage, architecture, volume drivers such as customers or requestsAllocation structure, technical actions and their order
The person who pays the billFinanceInvoice, cost base, currency, comparison with budgetCost definition, data cut-off, treatment at month end
ManagementLeadership, ProcurementGoals, budget envelope, contractsCommitments, approval limits, accepted variances

The FinOps Practitioner persona is a role in this split, not a position: someone prepares the numbers, keeps the cadence and bundles commitment decisions. In most small companies that is the engineering lead, because they have access to the billing data and to the causes; it can equally be the finance person, as long as usage questions are passed to engineering.

The monthly loop as the minimum

The phases Inform, Optimize and Operate run iteratively according to the Foundation, and the smallest cadence at which all three roles come together is the month, because the invoice arrives monthly. One pass reconciles the total against the invoice, explains the changes from the previous month, compares with budget and forecast, decides on a few actions and checks whether last month's actions are visible in the data. The agenda and templates for it are in Monthly cloud cost review: agenda and templates. Anything that happens more often, such as checking an anomaly, stays with one role and is only reported in the loop.

Which capabilities count at crawl

The Foundation says that every capability can sit at its own maturity level and that Run is not the goal everywhere. For a company without a FinOps team, Crawl means little tooling, basic KPIs and a focus on the low-hanging fruit. Nine capabilities carry the practice at that level: Data Ingestion and Allocation, because without a complete export and an allocation nothing else follows; Reporting & Analytics and Anomaly Management, so that changes reach an owner; Budgeting, so that a total becomes a variance; Usage Optimization and Rate Optimization, as a short backlog and one documented commitment decision; FinOps Practice Operations, which is the monthly loop itself; and Invoicing & Chargeback, at least as a conscious decision for showback.

The remaining capabilities wait until a decision calls for them. KPIs & Benchmarking, FinOps Assessment, FinOps Education & Enablement and Intersecting Disciplines presuppose an organisation that does not exist at this size. Forecasting and Planning & Estimating earn their place once budgets grow markedly or a large undertaking is ahead. Executive Strategy Alignment is met at this size when management sits in the loop. Sustainability and Architecting & Workload Placement follow the product, not the practice.

What it means for your cost

The practice lives in three artefacts, and each is visible in the billing data.

The first is a cost allocation that covers the whole bill. It starts from the structures the providers supply anyway, account, subscription and project, and adds tags only where one structure holds several owners. Allocation coverage is the first KPI of the practice, and unallocated cost stays visible as a line of its own instead of being spread proportionally.

The second is a cost report per owner. It shows the allocated cost, the change from the previous month and the largest line items, in the cost definition finance has fixed, and it goes to the person who creates the resources. A report for management summarises these reports; it does not replace them.

The third is a budget per scope. A scope in the Framework is a segment of spending defined from business context, at this size usually the product, an environment or public cloud as a whole. The budget is the line at which management decides, and the variance against it is what the monthly loop is about. Whether allocated cost is shown to teams or charged to them internally is the choice between showback and chargeback. Chargeback presupposes a cost centre structure; where that does not exist, showback is what remains.

Where it goes wrong

  • One person owns everything. Symptom: the engineering lead prepares the numbers, explains them, decides on actions and implements them, and the loop stops the moment they are on holiday. Cause: the personas were merged into one role instead of spread across three; checking the data, recommending and approving have quietly become one step.
  • Tagging before allocation. Symptom: a tagging standard with more keys than anyone maintains, low allocation coverage and arguments about who backfills the tags. Cause: allocation started from tags instead of from account, subscription and project, which already cover most of the bill without a single tag.
  • Optimising before seeing. Symptom: a commitment that ties money to a load that has shrunk soon after, or a rightsizing whose effect nobody can demonstrate. Cause: the Optimize phase started before Inform had delivered an allocation and a report per owner; there was no baseline to compare against.
  • Reports nobody reads. Symptom: a monthly total report to management that no decision follows. Cause: the report goes to the role that sets the envelope, not to the role that creates the resources, and it asks no question anyone would have to answer.

Sources

Read on 2026-10-15. FinOps Foundation: FinOps Framework, What is FinOps?, FinOps Personas, FinOps Maturity Model, FinOps Domains, FinOps Phases, FinOps Scopes.