Most FinOps programmes are stuck at crawl. Here is how to tell.
Why self-assessment scores inflate
We ask every team we onboard to self-rate their FinOps maturity before we see the bill. The median self-rating is walk. The median actual score, after the assessment below, is crawl-to-walk. Not walk. Not walk-to-run. Crawl-to-walk.
The inflation is not dishonesty. It is definitional drift. Teams interpret walk as 'we have a dashboard and someone looks at it.' The FinOps Foundation defines walk as having allocated costs to teams with accountability, implemented a forecasting process, and completed at least one optimisation cycle across all major service categories. Those are materially different claims.
The self-assessment also suffers from coverage bias. Teams rate themselves on the dimensions they have worked on and omit the ones they have not thought about. The assessment below forces coverage of all six dimensions.
The six dimensions that actually measure maturity
Dimension one: visibility. Can every engineer see their team's cloud costs within 24 hours of incurrence? Crawl: a single account dashboard exists. Walk: per-team cost views with 24-hour lag. Run: real-time anomaly detection with automated alerts.
Dimension two: allocation. What percentage of total spend can you attribute to a specific team, product, or workload? Crawl: below 60 percent. Walk: 80 to 90 percent. Run: above 95 percent with owned shared-services budget lines for the remainder.
Dimension three: accountability. Is there a named engineer on each product team who owns the cost number and is measured on it? Crawl: no named owner. Walk: named owner exists but has no tooling or mandate. Run: named owner, monthly review in team rhythm, cost is a peer metric to uptime.
Dimension four: forecasting. Can the team forecast next month's spend within 15 percent accuracy? Crawl: no forecast, spend is reactive. Walk: rough estimate based on growth rate. Run: bottoms-up forecast by service, reviewed monthly, with variance explanation.
Dimension five: optimisation. Has the team completed a structured optimisation cycle in the past 90 days? Crawl: ad hoc savings when flagged. Walk: quarterly compute right-sizing. Run: continuous optimisation across compute, storage, networking, and managed services with a measured savings rate.
Dimension six: culture. Do engineering teams treat cost as an engineering concern? Crawl: cost is what finance complains about. Walk: cost is visible but absent from engineering vocabulary. Run: cost appears in architecture reviews, PR comments, and on-call dashboards alongside latency and error rate.
How to run the assessment in a day
Morning: pull 90 days of billing data. Calculate the actual allocation percentage from your cost tool. List every product team and identify whether a named cost owner exists and when they last reviewed their number. This takes 3 to 4 hours for a mid-market estate.
Afternoon: run a 45-minute structured interview with the platform lead, one product team lead, and the finance contact who receives cloud invoices. Ask each of the six dimension questions directly. Score each dimension on the crawl/walk/run scale. The interview surfaces the gaps that billing data does not show: the accountability model, the forecasting process, the cultural signals.
End of day: produce a one-page score with six dimension ratings and the top three improvement actions, prioritised by impact and feasibility. The actions are specific to the gaps found, not generic best practices.
"The median self-rating is walk. The median actual score after the assessment is crawl-to-walk. The inflation is definitional drift, not dishonesty."
Danny Zak / FinOps Lead
What the score tells you to do next
Most teams score crawl on two or three dimensions and walk on the rest. The crawl dimensions are almost always accountability and forecasting. Visibility and allocation are the ones teams have worked on. Accountability and forecasting require organisational change, which is why they stay at crawl.
The fix for accountability is naming a cost owner per product team, putting the cost number in the monthly team review, and making FinOps the enabler rather than the enforcer. This takes one meeting to decide and one quarter to embed.
The fix for forecasting is a shared model to start, not a commercial tool. The FinOps team owns the template. Each team fills in their service list, growth rate, and planned changes. Accuracy improves with each cycle. After two to three quarters, the forecast is accurate enough to inform engineering roadmap decisions.
Teams that close the accountability and forecasting gap consistently move from crawl-to-walk to walk-to-run in two quarters. The billing data does not change. The organisation does.