Analysis: What Each Maturity Stage Actually Looks Like
The Crawl-Walk-Run framework is easy to understand in the abstract. Most FinOps teams find it harder to apply to their own organization. When asked “where are you on the maturity model?” the instinctive answer is usually Walk, regardless of actual capability level.
This chapter provides the diagnostic lens to assess honestly. It examines each maturity stage in depth: the specific characteristics that define it, the failure modes that keep organizations stuck there, and the concrete changes required to progress.
Crawl: The Reality Behind the Label
Crawl is not the same as having no FinOps practice. Most organizations that are genuinely at Crawl stage have cloud dashboards, someone who looks at the bills, and occasional conversations about costs when a budget alert fires. What they lack is the infrastructure for systematic action.
The defining characteristics of Crawl stage break down into three categories: visibility gaps, accountability gaps, and process gaps.
Visibility Gaps
The 2024 State of Cloud Cost Intelligence Report found that only 30% of organizations knew exactly where their cloud budget was going. The other 70% had a total number but not the breakdown that would allow them to act. When $2 million in cloud spend cannot be attributed to specific teams, projects, or applications, every optimization conversation becomes an argument about ownership rather than a technical discussion about waste.
Accountability Gaps
In Crawl stage, cloud cost is typically owned by a single person or team (often DevOps or a central platform team) who cannot actually control what other teams spend. Engineering teams deploy resources; the platform team gets the bill; nobody in engineering feels direct financial pressure. The person accountable for the cost is not the person making the resource decisions.
Process Gaps
Cost reviews happen when something goes wrong, not on a regular cadence. Budget alerts are set on total spend rather than per-team or per-application baselines. Tagging policies exist in documentation but are not enforced at deploy time.
The Stuck Pattern
Organizations remain in Crawl longer than they need to because the business pain is diffuse. Nobody gets fired when cloud costs grow 30% if revenue is also growing 30%. The reckoning comes later, often when growth slows, when a competitor demonstrates better margins, or when a board begins asking unit economics questions that the CFO cannot answer.
Walk: Active Optimization in Practice
The transition from Crawl to Walk is not a single event. It is a series of capability upgrades, typically spread over six to eighteen months, that collectively shift the FinOps practice from reactive to proactive.
The most reliable signal that an organization has reached Walk stage is this: when a cloud cost anomaly is detected, the team responsible for it is notified directly and expected to act within a defined SLA. Accountability has been distributed.
What Walk Looks Like Operationally
Cost allocation is functional. Tagging coverage is above 80% for all production resources. Cloud costs can be viewed by team, by application, and by environment. The monthly cloud bill is not a surprise to anyone.
Budget controls are active. Teams have defined budgets. Alerts fire when spend approaches those budgets, and the right people receive those alerts. A new instance that would push a team over budget requires a conversation, not just a provisioning command.
Rightsizing is happening regularly. The organization has identified and acted on the most obvious waste: unused instances, oversized VMs, development environments running 24/7. Not everything is optimized, but the largest items have been addressed.
Cross-functional collaboration exists. Finance and engineering have a regular meeting, however informal. There is shared language around cloud costs. Finance is not receiving invoices it cannot decode; engineering is not building in a cost vacuum.
| Capability | Crawl | Walk |
|---|---|---|
| Cost allocation | Total spend visible, no attribution | Spend attributed by team and application |
| Tagging | Policy exists, low coverage | 80%+ coverage, enforced at deploy |
| Budget controls | Total budget alerts only | Per-team budgets with ownership |
| Rightsizing | Ad hoc, triggered by alerts | Regular review cadence, most waste addressed |
| Cross-functional collaboration | Finance reviews invoice alone | Regular joint cost reviews with engineering |
| Savings plans | None or opportunistic | Basic reserved instances for stable workloads |
The Walk Failure Mode
Organizations that reach Walk stage often stall there because the remaining optimization opportunities are harder than the ones they have already captured. The easy wins, the idle instances and the obviously oversized VMs, have been addressed. What remains requires architectural decisions, not just configuration changes.
The team that rightsized 40 VMs last quarter feels like it has done its job. The next opportunity, redesigning a monolithic service so it can run on spot instances, requires engineering commitment and product planning. Without leadership support for that kind of investment, Walk organizations plateau.
Run: Embedded Cost Governance
Run stage organizations look fundamentally different from Walk stage organizations. The difference is not the sophistication of their tooling. It is where cost accountability sits in the engineering process.
At Walk stage, cost reviews happen after deployment. At Run stage, cost is a design constraint that shapes architecture decisions before the first line of code is committed.
Engineering Integration
In Run stage, engineering teams receive cost impact data as part of their normal workflow. Infrastructure changes trigger cost impact estimates. Pull requests that would increase estimated monthly spend by more than a defined threshold require FinOps review. Cost is not an afterthought; it is a gate.
Automated Optimization
The most time-consuming optimization tasks are automated. Unused resources are flagged and decommissioned automatically after a review period. Development and staging environments that are not in active use are shut down on a schedule. Rightsizing recommendations are generated continuously and acted on without manual triage.
Unit Economics
Run stage organizations can answer the question: what does it cost to serve one customer, process one transaction, or deliver one unit of our core business metric? They can answer it for today, and they can show a trend over time. When that cost per unit is rising, engineering and product teams are alerted and expected to investigate.
Forecasting
Cloud spend forecasts are accurate to within 10%. They are based on a combination of historical trends and planned feature development, not just a straight-line extrapolation of last quarter’s spend. Finance can plan against these forecasts with confidence.
The Run Misconception
Run stage is often described as the pinnacle of FinOps maturity. The FinOps Foundation pushes back on this framing. Run stage in one capability does not mean Run stage everywhere. And reaching Run does not mean staying there without effort.
Organizations that achieve Run-level cost allocation may still be at Crawl for AI spend management. A team that has fully automated rightsizing for compute may have no governance over data transfer costs. The model is not a staircase with a top step. It is a continuous improvement framework across 22 distinct capabilities.
The practical implication: organizations should identify the capabilities that create the most value for their specific context and invest in maturing those first. A company where data egress costs represent 40% of the cloud bill should prioritize data transfer governance before rightsizing compute. The maturity model is a tool for prioritization, not a checklist to complete in sequence.