Who owns the bill?

Before the cloud, spending money on computers took a purchase order, a few signatures and a delivery truck. Today it takes one command. Any engineer can start a cluster that costs more per day than their salary, and nobody has to approve it. That speed is the point of the cloud. It also broke the old way of controlling spend, because the decision and the bill are now weeks apart, made by different people.

The engineer decides on Monday. The cost accrues every hour. The invoice arrives next month, lands with finance, and finance has no idea which line belongs to which team, let alone which decision.

FinOps is the practice built to close that gap. The FinOps Foundation, part of the Linux Foundation, defines it as an operational framework and cultural practice for getting the most business value from technology, through timely data and shared accountability between engineering, finance and the business. Most of what follows serves one purpose: getting the right cost data to the person making the decision, while it can still change the decision.

Start with “monthly invoice”, then switch to “daily anomaly alert”. How much did a faster loop save?

FinOps is a conversation between several groups, and the Framework calls the seats at that table personas. The core ones are always involved: the FinOps practitioner, engineering, finance, leadership, procurement and product. Allied personas, such as IT asset management, security and sustainability, join when their area is touched.

The interesting part is that they are all right. Engineering wants to ship and not be slowed down. Finance wants a number it can forecast. Procurement wants a stronger hand with vendors. Each sees a different slice of the same decision, and most bad spending decisions come from one slice deciding alone.

That’s why the first of the Foundation’s six principles is that teams need to collaborate. The others follow from it: business value drives technology decisions, everyone takes ownership of their usage, the data is accessible, timely and accurate, FinOps is enabled centrally, and you take advantage of the cloud’s variable cost model.

Ask “buy a three-year commitment?” and read engineering’s answer next to procurement’s.

The work runs in a loop of three phases. Inform is visibility: costs allocated to the teams that caused them, reports people actually read, forecasts and benchmarks. Optimize is finding better options: cheaper rates through commitments, less waste through rightsizing and scheduling. Operate is making the chosen changes stick, with automation, policies and new habits.

The loop matters more than any phase. You don’t finish Inform and move on. You go round, again and again, each time with better data and a smaller, sharper question. The Foundation stresses that teams can be in different phases for different things at the same time.

Notice how often the loop starts with someone simply seeing a number for the first time. In my experience visibility alone changes behaviour: a team that sees its own bill every week starts asking questions before anyone tells it to.

Step through “idle dev environments”, then “AI spend spike”. Where does each one loop back?

The Framework measures maturity in three steps borrowed from toddlers: crawl, walk and run. Crawl is doing something manually and reactively. Walk is doing it routinely, for most of the estate. Run is doing it automatically, everywhere, with the data trusted by everyone who uses it.

Maturity is measured per capability, not per company. A practice can run at commitments while it crawls at forecasting, and that might be exactly right: the Foundation says plainly that the aim is to invest where the value is, and running everything at run is beside the point.

To make the levels concrete, the Foundation publishes sample targets drawn from its practitioner data. They are examples, not requirements, but they make a useful mirror: how much of your spend has a known owner, how much of your steady usage is covered by commitments, and how far your forecasts miss.

Set allocation to 80%, coverage to 85% and forecast variance to 15%. Which one would you work on first?