The 18-month FinOps maturity curve, mapped against real spend data
FinOps maturity isn't linear. It is a series of phase transitions, each gated by an organizational capability that is hard to build and almost impossible to skip. The framing matters because most FinOps roadmaps treat maturity as a slope — more dashboards, more tags, more savings plans, more committed-use discounts. What we see in the actual spend data, across the organizations we have worked with, is different. Organizations sit in one phase for a long time, sometimes years, then transition quickly when a specific organizational capability lands. The phases themselves are not the work. The transitions are.
This piece maps the five phases, the capability that gates each transition, the leading indicators that signal an org is ready to move, and the two transitions where the majority of organizations stall. It is based on the patterns we have seen across roughly forty FinOps engagements over the past three years, weighted toward enterprises spending between twenty million and two hundred million annually on cloud. The shape generalizes outside that range, but the timelines and dollar figures will not.
Phase one is visibility. The organization can answer, with reasonable confidence, what it spent last month broken down by service, region, and account. There is a dashboard. There is a monthly review. Someone in finance owns the report. Most companies reach this within a quarter of getting serious about cloud cost, and the work to get here is largely a tooling exercise. Pick a cost management platform, wire it up to the billing exports, and configure the first round of dashboards.
The stall in phase one is subtle. Teams confuse a dashboard with an operating model. Visibility without an owner who is paid to act on it produces reports, not savings. The dashboard is reviewed in a monthly meeting. The numbers go up and to the right. Nobody is surprised, nobody is accountable, and the meeting becomes a status update. Organizations can sit in this stall for years without realizing it, because the artifact of progress — the dashboard — is still in place and still being updated.
The capability that gates the move out of phase one is not technical. It is the appointment of a named owner with the authority to ask uncomfortable questions across team boundaries. Without that role, no amount of additional tagging or dashboarding will move the org forward. With it, the next phase often unlocks within a quarter.
Phase two is allocation and showback. Spend is mapped to teams, products, or business units with enough fidelity that engineering leaders can be held accountable for the cost of what they own. The dashboard now answers not just 'what did we spend' but 'who spent it, and on what'. Showback meetings become operational rather than informational. Budget conversations start to land in the right room.
The capability that gates this transition is tagging discipline, and the reason most organizations stall here is that tagging is treated as a platform problem when it is actually a governance problem. Buying a better tagging tool will not fix a culture where tags are added at resource creation and never maintained, where the taxonomy drifts because nobody owns it, and where new business units are added to the org chart but not to the cost allocation schema. The fix is rarely a new tool. It is a policy, an owner, and a small enforcement loop in the deployment pipeline.
Even with the policy in place, allocation takes longer than people expect. Three to six months to get to ninety percent allocation coverage. Another quarter to get the last ten percent under control, much of which lives in shared infrastructure that requires a real conversation about how to apportion it. The shared-cost question — how to allocate the data warehouse, the observability platform, the central Kubernetes clusters — is where many organizations get stuck. There is no technically correct answer. There is only a defensible one that everyone has agreed to live with.
Phase three is unit economics. Cost per order, per active user, per inference, per gigabyte processed, per support ticket resolved. The exact unit depends on the business, but the shape is the same: cost is expressed in terms of something the product team already cares about. This is the first phase where FinOps stops being a finance conversation and becomes a product conversation. It is also the first phase where the FinOps team starts to be invited to design reviews instead of being mentioned in cost-review meetings.
The capability that gates this transition is the joining of spend data to product metrics. This sounds trivial and is not. Spend data lives in the billing pipeline, in roughly the shape the cloud vendor exports it. Product metrics live in the product analytics warehouse, in a completely different shape, with completely different identifiers, on a completely different freshness cadence. Joining them reliably requires a data engineering effort that most FinOps teams are not staffed to do, and most data engineering teams have not been asked to prioritize.
Most organizations spend six to nine months in this phase, and a meaningful number never leave it. The ones who do leave it tend to have made two specific moves. They embedded a data engineer in the FinOps team, on a permanent rather than rotational basis. And they picked two or three unit-economic metrics to start, instead of trying to define the metric for every product line at once.
Phase four is engineering-owned optimization. Cost shows up in the same dashboards that engineers already look at. Cost regressions are caught in code review, the same way performance regressions are. The savings work is distributed across teams instead of being concentrated in a central FinOps function. The central team's job shifts from finding savings to enabling others to find them, and the org chart starts to reflect that — fewer central optimizers, more embedded cost specialists in platform and infrastructure teams.
The capability that gates this transition is the integration of cost data into the engineer's normal workflow. Cost has to appear in pull requests, in service dashboards, in incident reviews, in capacity planning conversations. It cannot live only in a separate FinOps portal that engineers visit when they are asked to. Once cost is in the workflow, the social dynamic shifts: optimization becomes part of the definition of done for a feature, not a separate project that gets prioritized against features.
This phase produces the largest absolute savings of any phase, by a wide margin, because it is the first phase where the volume of decision-makers acting on cost is large enough to matter. A central FinOps team of five can find tens of millions in annual savings. A culture where five hundred engineers each shave one percent off their service's cost produces a fundamentally different number.
Phase five is forecast-driven capacity planning. Spend is projected with the same rigor as revenue. Commitments are sized against forward-looking demand rather than trailing usage. Finance and engineering plan together on a quarterly cadence, and the inputs to the plan — feature roadmap, expected user growth, infrastructure efficiency programs in flight — are agreed across the two functions before the commitment decisions are made. Very few organizations are credibly here. The ones that are tend to have a single executive who owns both sides of the conversation, often a CTO or COO with explicit accountability for cloud cost as a P&L line.
The capability that gates this transition is trust between finance and engineering. The forecast requires engineering to make commitments about future efficiency that they cannot fully control, and it requires finance to plan against engineering numbers that come with real uncertainty bands. Either side defecting — engineering pulling the efficiency targets, or finance demanding precision the data cannot support — collapses the model. The trust takes longer to build than the spreadsheet does.
The two transitions where organizations stall hardest are the move from allocation to unit economics, and the move from optimization to forecasting. The first stalls because the data work is unglamorous and there is no single owner — it sits between finance, FinOps, data engineering, and product analytics, and the default outcome of a problem that sits between four teams is that no team owns it. The second stalls because forecasting requires finance and engineering to trust each other's numbers, which is a cultural problem disguised as a technical one. Neither problem is solved by adding more dashboards.
There are leading indicators that signal an organization is ready to move to the next phase. None of them are about the dashboards themselves. They are about the language people use and the decisions they make. Engineers reference cost in design docs without being asked. Product managers can name the unit economics of their feature without looking it up. Finance closes the month using the same numbers engineering sees in real time, instead of waiting for a separate reconciliation. Commitment coverage is decided by a forward forecast, not a trailing average. When three of these four are true, the next phase is within reach. When fewer than two are true, no amount of additional tooling will move the org forward.
There is a related set of trailing indicators that signal an organization is stuck, regardless of what the maturity self-assessment says. The same savings opportunity is identified by a new FinOps hire every twelve months and never closed. The cost-per-unit metric is owned by finance and unfamiliar to the engineers whose decisions drive it. The forecast and the actuals diverge by more than fifteen percent in either direction without anyone treating the variance as a learning opportunity. Any of these patterns suggests the org is not in the phase the dashboard claims it is in.
A small note on tooling, because it always comes up. The choice of cost management platform matters less than most vendors would like you to believe. We have seen organizations get to phase four on the native cloud cost tools plus a serious data warehouse practice. We have seen organizations spend seven figures on a premium platform and stall at phase two, because they treated the purchase as the answer. The platform is necessary; it is not sufficient. The organizational capability is sufficient, and it is the part that does not come in a vendor contract.
The framework is not a maturity score to brag about in a board deck. It is a diagnostic. The most useful question it answers is not 'where are we' but 'what is the one capability we have to build before the next phase is even possible'. For most organizations we work with, the answer is uncomfortable — a hiring decision, an org-chart change, a policy with teeth, a difficult conversation between finance and engineering — and the discomfort is exactly why the work has not been done.
Pick the one capability. Staff it. Give it air cover for the quarter or two it takes to land. The curve takes care of itself once the capability is in place. The organizations that compound on FinOps are not the ones with the best dashboards. They are the ones who were honest about which capability was missing, and who built it before they bought the next tool.
A practical aside on the role of finance in all of this. The phases above describe the engineering side of the curve, but the finance side has a parallel maturity that is rarely mapped explicitly. In phase one, finance treats cloud spend as a single line item in the operating budget, reconciled monthly. In phase two, finance has visibility into the allocation but treats it as informational. In phase three, finance starts to participate in unit-economic conversations and to expect product teams to defend their cost-per-unit trajectory. In phase four, finance is in the design conversations early enough to shape the trade-offs, not just to review the outcome. In phase five, finance and engineering jointly own the forecast and are measured against the same number.
The two sides of the maturity curve have to move together. An engineering organization that has reached phase four with a finance organization stuck at phase two will see its work undone every budget cycle, because the conversations finance is having with the rest of the business are not the conversations engineering is having with itself. The reverse is also true: a finance organization that wants forecast-driven planning from an engineering organization stuck at phase two will not get a forecast it can trust. The most successful FinOps programs we have seen explicitly map the finance maturity alongside the engineering maturity and treat the slower side as the binding constraint.
There is a hiring pattern worth naming. The single highest-leverage hire we have seen in FinOps programs is not a senior FinOps practitioner. It is a data engineer with a serious finance background, or a finance analyst with a serious data engineering background. The role does not have a standard title yet. It sits at the join between the billing pipeline, the product analytics warehouse, and the financial reporting stack, and it is the role that makes the move from allocation to unit economics possible. Organizations that have made this hire — and given the role enough authority to push back on both sides — have moved through phase three meaningfully faster than peers.
A small caution on automation. The instinct, especially in phase four, is to automate as much of the savings work as possible — automated rightsizing, automated commitment management, automated idle resource cleanup. Automation in cost is high-leverage and worth pursuing. The trap is that automation without observability and rollback creates new failure modes. We have seen autoscaling policies aggressive enough to cause cold-start latency regressions that cost more in conversion than they saved in infrastructure. The discipline that has worked is to treat any cost-saving automation the same way the team treats a production change: with a feature flag, an SLO it must not regress, a rollback plan, and a review cadence.
Commitment strategy is the most common source of avoidable loss we see, and it deserves its own discipline. Most organizations buy commitments in a single annual cycle, sized against the previous year's spend, with a flat discount target. The savings from this approach are real but bounded. The organizations that have moved past it run a continuous commitment program — small, frequent purchases sized against rolling forward forecasts, with explicit coverage targets by service and by environment. The savings are meaningfully larger, and — more importantly — the downside of a single bad commitment decision is much smaller, because no individual purchase represents a year of exposure.
A note on the cultural texture of mature FinOps organizations, because the texture is part of what is hard to copy. The most mature organizations we have worked with talk about cost casually. Cost shows up in design docs as a section, not a footnote. Engineers reference cost in slack threads about architecture. The phrase 'we can afford that' carries weight, in both directions. The cultural shift is not enforced from the top; it is the result of years of consistent signal from leadership that cost is a first-class quality attribute, alongside latency, reliability, and security. The organizations that try to install the culture by decree, without the underlying signal, do not get it.
The framework is not prescriptive about timeline. Some organizations move through three phases in two years. Others sit in phase two for five years and then move through the rest in eighteen months. The variable that determines speed is almost never the size of the spend, the complexity of the architecture, or the maturity of the tooling. It is the consistency of executive sponsorship. Programs that survive a change of CFO or CTO without losing momentum tend to be the ones where the sponsorship was institutionalized — in role definitions, in OKRs, in the standing agenda of the operating reviews — rather than personal to an individual leader.
None of this is novel in isolation. The novelty, to the extent there is any, is in the sequencing. The mistakes we see most often are not errors in any single phase. They are attempts to skip phases — to move to forecasting before unit economics are in place, to push engineering ownership before allocation is trustworthy, to declare unit economics victory on top of a tagging schema that is still drifting. The phases do not collapse. The work compounds. The organizations that respect the sequence end up moving faster, not slower, than the ones who try to leap ahead.