FinOps teams often talk about maturity. Where are we today? Are we at Crawl, Walk or Run? How mature is our allocation? Our forecasting? Our optimisation? Our governance?
These questions can be useful. A maturity model helps an organisation understand where capabilities are weak and where investment may be required.
But maturity can easily become the wrong objective.
A company does not create business value because it moved a capability from Crawl to Walk. It creates value because people can make better decisions about technology spend.
That distinction matters.
The purpose of FinOps maturity is not to score highly against a framework. It is to build the capabilities the organisation actually needs — and make those capabilities part of how Finance, Engineering, Product and Technology operate.
Maturity is a means, not an outcome
Imagine two organisations.
Organisation A has sophisticated cost allocation, detailed dashboards, extensive tagging policies and a central FinOps team producing regular reports.
Organisation B has less sophisticated tooling and imperfect allocation, but engineering teams understand their major cost drivers, Finance can explain material spend movements, optimisation decisions have clear owners and cloud economics are considered during technology decisions.
Which organisation has the stronger FinOps capability?
The answer is not necessarily Organisation A. Technical sophistication and organisational effectiveness are not the same thing.
A capability is valuable when it improves an outcome. Better allocation should improve accountability. Better forecasting should improve financial planning. Better optimisation data should improve decisions about where to act. Better reporting should make material changes easier to understand.
If a capability becomes more sophisticated without changing behaviour or decisions, the organisation may have increased its FinOps maturity on paper without increasing its FinOps effectiveness.
Not every capability needs to reach the same level
One of the most useful ideas in FinOps maturity is also one of the easiest to overlook: maturity should be appropriate to the organisation. There is no requirement for every capability to reach an advanced state.
Consider a relatively stable single-cloud environment. The organisation may not need highly sophisticated multi-cloud allocation or complex unit economics. Basic cost ownership, reliable forecasting and disciplined optimisation may be sufficient.
Now consider a global digital platform operating across multiple clouds, thousands of workloads and hundreds of engineering teams. Its requirements may be completely different. It may need granular allocation, automated anomaly management, sophisticated commitment management, business-linked unit economics, advanced forecasting, distributed FinOps practices and stronger policy and governance.
The second organisation requires greater sophistication because its decisions are more complex.
The goal is therefore not maximum maturity. It is fit-for-purpose maturity.
Start with the decisions that are difficult today
A practical FinOps improvement programme should not begin with "which capabilities can we mature?" It should begin with "which cloud decisions are we struggling to make?"
Perhaps Finance cannot explain forecast variance. Perhaps Engineering receives optimisation recommendations but lacks financial context to prioritise them. Perhaps nobody knows who owns shared platform costs. Perhaps commitment purchases are made without enough visibility into future demand. Perhaps product leaders cannot understand how cloud cost changes as their products scale.
Each problem points towards a capability that needs strengthening. That creates a much clearer relationship between investment and outcome.
Instead of "improve allocation maturity," the objective becomes "give product owners sufficient cost ownership to make informed decisions."
Instead of "improve forecasting maturity," it becomes "reduce financial surprise by connecting the forecast with known business and technology changes."
Instead of "improve optimisation maturity," it becomes "help teams identify and prioritise economically meaningful actions."
The capability now has a purpose.
Tooling cannot create maturity on its own
Another common mistake is equating FinOps maturity with tooling sophistication.
A new platform can provide richer cost visibility, automated recommendations, anomaly detection, allocation capabilities, forecasting and commitment analytics. Those capabilities can accelerate FinOps significantly.
But a tool cannot decide who owns the cost, who has authority to make the change, how an engineering trade-off should be evaluated, which opportunity deserves priority, or how Finance should interpret the result.
Those are organisational capabilities.
An organisation can therefore deploy an advanced FinOps platform and remain operationally immature. Conversely, teams can make strong FinOps decisions using relatively simple tooling when ownership, process and financial context are clear.
Technology enables the operating model. It does not replace it.
Enablement means changing how teams work
This is where FinOps Enablement becomes important.
The objective is not to make every engineer a cloud economist. Nor is it to make every Finance stakeholder understand infrastructure architecture.
Enablement means giving each persona enough capability to make the decisions they are responsible for.
For EngineeringUnderstanding the financial impact of architecture choices, major workload cost drivers, how to evaluate optimisation opportunities, and when cost should influence a technical decision.
For FinanceHow cloud consumption behaves, why cloud forecasts change, how commitments affect financial risk, and how to distinguish cost movement from economic efficiency.
For ProductHow product demand influences cloud consumption, which cost drivers matter, and where relevant unit economics can support decisions.
For Technology leadershipWhere financial opportunity exists, where organisational blockers exist, and which trade-offs require intervention.
Different personas need different knowledge. Enablement should be role-specific, not generic FinOps training for everyone.
Training is necessary — but not sufficient
Formal training has an important role. It can create common terminology, explain FinOps principles and help teams understand their responsibilities.
But a two-hour FinOps workshop does not change an operating model. People need to apply what they learned to real decisions.
An engineer understands cost ownership more effectively when reviewing the economics of an actual workload. A product leader understands unit economics when looking at their own product. Finance understands cloud forecasting when technology plans are connected with a real forecast.
This means effective enablement combines education with practical application and repeatable operating mechanisms.
Training creates understanding. Practice creates capability.
Build FinOps into existing workflows
FinOps becomes sustainable when it stops feeling like a separate programme.
If every cloud financial decision requires a special FinOps process, adoption will remain difficult.
Instead, FinOps concepts should progressively appear inside the workflows teams already use. For example:
Architecture discussions can include material cost implications.
Product planning can consider relevant cloud economics.
Engineering backlogs can include validated optimisation work.
Budget reviews can include cloud demand drivers.
Procurement decisions can incorporate usage confidence.
Technology reviews can include financial outcomes alongside operational metrics.
The exact mechanisms will differ between organisations. The principle is simple: the closer FinOps gets to the point where decisions already happen, the more likely it is to influence those decisions.
Central FinOps should scale through the organisation
A central FinOps team can play a critical role. It can establish standards, provide trusted data, facilitate cross-functional conversations, develop methodologies, support complex analysis, coordinate commitments and identify opportunities.
But if every FinOps decision must eventually return to the central team, the model will struggle to scale.
As capability improves, responsibility should increasingly move towards the teams making the underlying technology and business decisions.
This does not make the central FinOps team less important. It changes its role — from doing FinOps for the organisation towards enabling the organisation to practise FinOps.
That is a much more scalable model.
Measure maturity through outcomes
If maturity is not the goal, how should progress be assessed? Capability assessments still matter. But they should be connected to observable outcomes.
Instead of measuring only allocation coverage, ask whether meaningful cost owners can explain and influence their spend.
Instead of measuring only forecast accuracy, ask whether material variance is understood early enough to support decisions.
Instead of counting optimisation recommendations, ask whether economically valuable actions are being prioritised.
Instead of measuring training attendance, ask whether teams are applying financial context in their decisions.
Instead of counting FinOps meetings, ask whether blockers are being resolved faster.
The question becomes: what can the organisation do today that it could not do reliably six months ago? That is a powerful measure of capability.
Maturity should change as the organisation changes
There is no permanent FinOps end state. A capability that is sufficient today may become inadequate tomorrow.
The company may grow. A second cloud provider may be introduced. A major acquisition may increase complexity. Engineering may decentralise. Cloud commitments may become financially material. AI workloads may introduce new consumption patterns. The business may demand more sophisticated unit economics.
FinOps capability should evolve with those needs. That is another reason maturity should not be treated as a destination. The appropriate level changes with the organisation.
Better decisions are the real maturity model
Ultimately, FinOps maturity can be viewed through a much simpler lens.
Can teams understand the financial consequences of their technology choices? Can Finance explain material cloud movements? Can ownership be established at the right level? Can optimisation compete intelligently for engineering capacity? Can commitments be made with an informed view of demand and risk? Can leadership distinguish productive technology investment from inefficiency? Can the organisation measure whether its actions actually improved cloud economics?
If the answers are improving, FinOps is becoming more capable.
Whether a particular capability is labelled Crawl, Walk or Run is secondary.
Key takeaway. FinOps maturity is useful for understanding capability gaps. It should not become the objective.
Build the capabilities required for the decisions your organisation needs to make. Train people in the context of their roles. Embed financial thinking into existing workflows. Move accountability towards the teams making the decisions. And measure progress through changes in behaviour and outcomes — not maturity scores alone.
The goal is not to become more mature at FinOps. It is to become better at making technology-value decisions.
Nooven helps organisations build practical FinOps capability across Finance, Engineering and Technology — combining targeted enablement, operating mechanisms and hands-on application so better cloud decisions become part of how teams work.
