The first meeting I ever attended that was called a FinOps meeting was actually a blame meeting. Finance had a bill that was 40 percent over plan, engineering had a list of reasons, and nobody in the room could say which team owned which line of it. We spent ninety minutes arguing about a number that none of us could break apart. That is the failure mode this whole discipline exists to prevent, and almost every organisation discovers it the same way.

What made that meeting useless was not a missing tool. We had cost dashboards. What we did not have was an agreed answer to a much duller question: who is accountable for this spend, and on what evidence. FinOps is the practice of answering that question repeatedly and quickly enough to change decisions before the money is spent.

The definition, and why the wording matters

The FinOps Foundation, which is the vendor neutral body that maintains the framework under the Linux Foundation, defines FinOps as an operational framework and cultural practice which maximises the business value of technology, enables timely data driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.

Read that again and notice what is absent. There is no mention of reducing spend. There is no target percentage. The three things the definition actually promises are value, speed of decision, and accountability. That ordering is deliberate and it is the single most misunderstood thing about the discipline.

Two words in there are doing heavy lifting. Operational means this is a set of repeating activities with owners and a cadence, in the same way that incident response is operational. Cultural means the activities only work if people who do not report to you change how they behave, which is why FinOps programmes fail for organisational reasons far more often than technical ones. The name itself is a portmanteau of Finance and DevOps, and the DevOps half is the part people forget.

You will hear other names for the same thing. Cloud Financial Management, Cloud Cost Management, Cloud Financial Engineering, Cloud Optimization. Treat them as synonyms with different marketing history. The one label to avoid is Cloud Financial Operations, because Financial Operations already means something specific inside a finance department and the collision causes real confusion in meetings.

What FinOps is not

It is not a cost cutting exercise. This is the misconception that sinks the most programmes, because if you launch FinOps as a savings initiative you get one good quarter and then a dead function. The obvious waste gets cleaned up, the number stops moving, and leadership concludes the thing worked and is now finished. Practitioners in the 2026 survey describe exactly this wall: they have hit the big rocks of waste and are left with a high volume of small opportunities that each cost more effort than they return.

It is not a tool you buy. Cost platforms are useful and most mature practices run one, but a tool produces reports and reports do not create accountability. I have seen organisations spend six figures on a cost platform, wire it up beautifully, and change nothing, because the reports landed in an inbox belonging to somebody with no authority to resize anything.

It is not a team that does the optimising. This one is subtle and it is where most new practices go wrong structurally. A central FinOps function that personally resizes instances becomes a queue, and a queue becomes a bottleneck at about the fourth business unit. The function is supposed to make it easy and obvious for the owning team to act, not to act on their behalf.

And it is not only about cloud any more, which is a genuine change in the last two years rather than a definitional quibble. The framework now covers software as a service, licensing, private cloud, data centre, and increasingly the cost of AI services. If your remit letter says public cloud only, expect that to widen whether or not you ask for it.

Inform, Optimize, Operate

The framework describes three phases. They are not a project plan with a start and a finish. They are a loop that different people run at different speeds at the same time, and understanding that is most of what separates a working practice from a stalled one.

Inform is visibility and allocation. Allocation means attributing every unit of spend to a team, product, or customer, which sounds administrative and is in fact the hardest engineering problem in the whole discipline. This phase covers ingesting the billing data, reporting on it, forecasting, and unit economics, which is the practice of expressing cost per something the business recognises rather than cost per instance. Without Inform, every later phase is guesswork.

Optimize is where you find the opportunities, and it splits cleanly in two. Usage optimization means using fewer resources for an acceptable outcome, which is a conversation with engineers. Rate optimization means paying less for the resources you genuinely need, through commitments and discounts, which is a conversation with procurement and leadership. Those are different skills, different stakeholders and different timelines, and conflating them is why so many optimization backlogs stall.

Operate is doing the things and making them stick. Policies, guardrails, automation, and the accountability culture that means a resized instance stays resized. It is the least glamorous phase and the one that determines whether last quarter’s savings survive to this quarter. Note that maturing a capability counts as an Operate action, not only adjusting usage or rates.

flowchart LR
  A[Inform: allocate and report] --> B[Optimize: usage and rate options]
  B --> C[Operate: act, automate, hold the gain]
  C --> A
  A --> D[Forecast and unit metrics]
  B --> E[Prioritised backlog]
  C --> F[Guardrails and policy]
  D --> B
  E --> C
  F --> A

Six principles that settle arguments

The framework lists six principles, and their practical use is not inspirational. They are tiebreakers. When two teams disagree about who should own a cost or how fast data should flow, the principles give you a position that is not just your opinion.

Teams need to collaborate. Business value drives technology decisions. Everyone takes ownership for their technology usage. FinOps data should be accessible, timely, and accurate. FinOps should be enabled centrally. And take advantage of the variable cost model of the cloud.

Two of those are in productive tension and that tension is the design of your operating model. Ownership pushed to the edge says the engineering team that provisioned the resource is accountable for its cost. Central enablement says a small central function should still own the practice, the standards and specifically the rate side, because commitments and discounts benefit from economies of scale that no single team can reach. The resolution is that engineers own usage and the centre owns rates. Get that boundary wrong in either direction and you either build a bottleneck or you get twelve teams each buying their own reserved capacity badly.

The accessible and timely principle is the one people underrate. Monthly cost reports are close to useless for behaviour change, because an engineer who sees in March that a March decision was expensive has already moved on to other work. Fast feedback loops produce efficient behaviour, and slow ones produce reports nobody opens. If you can only fix one thing in your first quarter, shorten the loop.

Who actually does FinOps

Not one person, and not one team. The framework names several personas: executives, engineers, FinOps practitioners, operations, finance, and procurement. Each has a different job in the loop, and the practitioner role is best understood as translation. You turn a billing line into something an engineer recognises as their service, and you turn an architectural choice into something a finance business partner recognises as a forecast.

The structural pattern that dominates in practice is centralised enablement with federated execution. Sixty percent of surveyed practices run centralised enablement and another 21 percent run hub and spoke, so roughly four in five sit in one of those two shapes. Team sizes stay small even at very high spend: organisations managing more than 100 million dollars a year average somewhere in the range of eight to ten practitioners plus a handful of contractors. That is a deliberately lean number. Central teams scale through embedded champions in each business unit, not through headcount.

If you are the first FinOps hire somewhere, that ratio is the useful part. Your job is not to review every workload. It is to make one person in each engineering group care about cost, give them the data to act, and get out of their way. Recruiting those champions is the highest return work in your first ninety days and it is almost entirely a relationship exercise rather than a technical one.

State of FinOps 2026, the sixth annual FinOps Foundation survey. Sample sizes vary by question, between roughly 520 and 700 respondents. Figures are self reported by practitioners.

Is saving money the point?

No, and I want to be precise about why, because this sounds like the sort of thing consultants say to avoid being measured. Savings are real and you should absolutely bank them. The problem is that savings are a terrible primary metric because they are self limiting. Every dollar you remove makes the next dollar harder to find, so a function measured only on savings is measured on a curve that flattens by design and then gets questioned in its second year.

The alternative measure is efficiency against something the business is doing. Cost per active customer, cost per transaction, cost per model inference. Those unit metrics can improve while total spend rises, which is the normal condition of a growing company and the only framing in which a cost function survives a growth year. That is unit economics, and it gets a full part later in this series.

There is a live example of this in the survey data. Many organisations now report being asked to self fund AI investment out of optimization savings. Framed as cost cutting, that is a squeeze. Framed as value, it is a portfolio decision: move spend from a low return footprint to a higher return one. The work is identical and only one framing gets you invited to the architecture review.

flowchart TD
  A{Can you attribute this cost to an owner} -->|No| B[Fix allocation first, nothing else works]
  A -->|Yes| C{Does the owner see it within days}
  C -->|No| D[Shorten the feedback loop before optimising]
  C -->|Yes| E{Is the resource sized for real demand}
  E -->|No| F[Rightsize, this is usage optimization]
  E -->|Yes| G{Is the rate the best available}
  G -->|No| H[Commitments and discounts, centrally]
  G -->|Yes| I[Measure cost per business unit of value]

Fix allocation before you optimise anything

Here is the recommendation for this part, stated as plainly as I can. Before you buy a tool, before you write a policy, before you touch a single instance, find out what percentage of your cloud spend you can currently attribute to a named owner. Not a rough sense of it. The actual number, this week.

If that number is under about 80 percent, allocation is your entire job for the next quarter and everything else is premature. You cannot forecast what you cannot attribute, you cannot hold anyone accountable for a cost they do not recognise as theirs, and any savings you produce will be uncontested precisely because nobody owns the thing you changed. Every advanced capability in this series, forecasting, unit economics, anomaly detection, chargeback, sits on top of allocation and inherits its accuracy.

It is unglamorous work and it will not impress anyone in month one. It is also the reason the second year of a FinOps practice either compounds or collapses. I have never seen a mature practice that skipped it and I have seen several stalled ones that tried.

Next in this series is why cloud cost behaves differently from every other IT cost you have managed, which is the mental model that makes the rest of the framework make sense. The full sequence lives on the Cloud FinOps guide.

Open your cost console today and pull the share of last month’s spend that carries an owner tag. Whatever that number is, write it down. It is the baseline for everything that follows.

References

• What is FinOps, FinOps Foundation
• FinOps Phases: Inform, Optimize, Operate, FinOps Foundation
• FinOps Principles, FinOps Foundation
• State of FinOps 2026 Report, FinOps Foundation

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts