A mature FinOps practice can still be useless to leadership

Building my workshop on FinOps governance for AI and cloud infrastructure forced me to think again about FinOps maturity.

I think we still measure it too much from inside the FinOps tribe, which means we are often marking our own homework. That is useful up to a point. But maturity alone is of no use to leadership if it does not connect cloud economics to strategy and decision making.

What was interesting while building the workshop was going back through some of my earlier articles and realising that the pieces were already there. They just were not connected yet. AWS sells to the tribe, not the board and Why most FinOps savings barely register in the boardroom were both pointing at the same problem from different angles.

A practice can look mature to itself and still remain hard to read for the people who control capital, risk, and priorities. That is the gap I am interested in.

This is why I would now describe the problem differently. FinOps maturity is usually framed as a question of internal progress: better allocation, better reporting, better optimisation loops, better commitment management, better process, better tooling, better adoption. All of that matters. None of it is trivial. But most maturity models still describe the inside of the practice.

They tell you whether FinOps is becoming more capable in its own language. They do not help leaders allocate capital, make decisions, and take risk. They do not connect with company strategy.

Leadership does not need FinOps to look mature. Leadership needs FinOps to show the path to value and the decision points along the way. Then FinOps should show the results of the chosen paths and allow for correction.

A FinOps team can improve allocation, forecasting, commitment coverage, and reporting cadence and still fail to change the quality of executive decisions. The team sees more detail. Leadership still sees noise. The practice becomes internally sophisticated and externally weak. That is not because executives are uninterested. It is usually because the practice is still speaking in a dialect optimised for the tribe.

Inside the tribe, a discussion about utilisation, commitment coverage, anomaly management, or reporting maturity makes sense. Outside the tribe, the real questions are different:

• What is the company trying to achieve?
• What intent is this technology meant to serve?
• What value is being protected or created?
• What risk is increasing or decreasing?
• What trade-off are we making?
• What decision becomes easier because this practice exists?

If FinOps cannot answer those questions clearly, maturity alone does not travel very far.

This is one reason I keep coming back to Top-Down FinOps. I do not think the next leap comes from more internal complexity. I think it comes from better translation between strategy and execution.

That translation has to move in both directions. From the top down, leadership intent has to survive contact with engineering. Priorities, constraints, and economic boundaries have to be turned into something teams can actually act on. From the bottom up, the financial and operational reality of cloud has to become readable in a form leadership can trust. Not just dashboards. Not just cost movement. Not just savings claims. Something that helps them govern.

This is also why the workshop mattered. As soon as I started shaping material that had to make sense beyond practitioners, the weakness became obvious. It is relatively easy to build content that looks mature to a FinOps audience. The tribe already knows how to recognise maturity in its own language. It is much harder to build material that stays true to the complexity while becoming useful to leadership, because leadership is not looking for maturity signals. It is looking for decision signals.

A mature FinOps practice should not only optimise cloud usage. It should make cloud economics legible enough that leadership can act with more coherence. It should help connect spend to value, commitments to risk, and engineering choices to strategic intent.

Otherwise we are still improving the inside of the machine while asking the rest of the organisation to trust that it matters. That is not nothing. But it is not enough either.

It is also why FinOps so often feels like a fight for survival. If the practice cannot connect clearly to strategy, decision making, and value, it keeps having to justify its own existence from inside the tribe.

If FinOps wants to matter more, maturity cannot remain an internal mirror. It has to become a bridge between the people who see the details and the people who carry responsibility for the consequences.