August 28, 2025
The FinOps Maturity Model: Is Your Engineering Team Where It Should Be?
8 min read
Cloud costs have become the new language of engineering trade-offs.
Do you optimize for speed to market or resource efficiency?
Do you build redundancy at the expense of cost or find smarter ways to balance both?
These aren’t finance debates anymore; they’re architectural realities. Don’t you think?
The FinOps Maturity Model reframes this conversation. It shows how teams evolve: from just consuming cloud resources, to understanding them, to actively shaping infrastructure that is both cost-aware and performance-driven.
Knowing where your team falls on this curve doesn’t just tell you how well you’re controlling spend, it tells you how ready you are to scale, innovate, and compete in a cloud-first world.
So, with this blog, we aim to decode where your engineering team fits into the FinOps spectrum.
Must read: Decoding the FinOps Framework
What is the FinOps Maturity Model?
The FinOps Maturity Model, as articulated by the FinOps Foundation, outlines an iterative journey: Crawl, Walk, Run. It’s a flexible framework designed to help organizations grow their FinOps practice in scale, scope, and complexity as business value warrants.
As the FinOps Foundation suggests, “A ‘Crawl, Walk, Run’ approach to performing FinOps enables organizations to start small, and grow in scale, scope, and complexity as business value warrants maturing a functional activity.”
This isn’t a one-size-fits-all template where every team has to reach “Run” in every capability. Rather, the Foundation emphasizes that maturity should be driven by outcomes, prioritizing the capabilities that deliver the highest business impact
Crawl → Early stage, visibility-focused. Teams are just starting to measure and report cloud spend.
Walk → Collaboration improves. Engineering begins to take ownership of usage and implements optimizations.
Run → Cloud costs are actively managed in near real-time. Teams make trade-offs between speed, cost, and quality.
Now, let’s break down what this model looks like specifically for engineering teams.
Also read: Platform Engineering Meets FinOps: Building Infra That Scales Without Overspending
Engineering in the Crawl Stage
At Crawl, engineers don’t yet “own” cloud costs, they simply consume resources. Finance might send reports at month-end, and engineers see cloud spend as someone else’s problem. The mindset is: “We just build; someone else pays the bill.”
What this stage looks like in practice:
Engineers spin up test environments or resources without thinking about shutting them down.
Finance runs after teams for explanations when costs spike.
Architecture decisions are made purely on technical feasibility, not financial efficiency.
Cloud feels like a “black box”. Everyone knows the bill is high, but no one knows why.
Signs your team is at Crawl:
No tagging or inconsistent tagging of resources.
Lack of visibility into costs at the service, workload, or team level.
No clear link between architecture decisions and cloud bills.
Optimizations, if done, are ad hoc and reactive (someone panics when the bill arrives).
What engineering should be doing here:
Establish basic visibility: Create cost dashboards by service/team so engineers can see the impact of their work.
Set tagging standards: Apply consistent naming/tagging for projects, workloads, and environments.
Clean up the junk: Start reviewing unused or idle resources (like unattached volumes, zombie instances).
Build awareness: Encourage teams to discuss cloud costs in retros or team meetings.
The goal at Crawl isn’t optimization, it’s awareness. Teams need to start seeing costs and understanding their impact before they can act on them.
Engineering in the Walk Stage
At Walk, engineering starts to take shared accountability for costs. Teams begin to internalize cost as part of their performance metrics, and infrastructure choices are reviewed with efficiency in mind. This is where the cultural shift begins; cloud cost is no longer “someone else’s problem.”
What this stage looks like in practice:
Dashboards aren’t just for finance; engineers check them too.
Teams start asking, “What’s the cheapest way to run this workload without hurting performance?”
Rightsizing becomes part of regular workflows.
Finance and engineering begin speaking the same language when forecasting spend.
Signs your team is at Walk:
Dashboards show cost by product, team, or feature.
Engineers participate in monthly/quarterly cost reviews.
Some automation is in place for rightsizing or shutting down non-prod workloads.
Cost conversations start happening alongside performance and reliability.
What engineering should be doing here:
Automate the basics: Implement scripts/tools for rightsizing, scheduling idle workloads, and enforcing cost policies.
Bring cost into CI/CD: Make cost-impact checks part of deployment reviews.
Collaborate with finance: Forecast spend for upcoming features or projects, ensuring no surprises.
Experiment with trade-offs: Test spot vs on-demand, reserved instances vs autoscaling, serverless vs containerized.
At Walk, engineering teams evolve from being “resource consumers” to “cost stewards.” They don’t just react, they start planning and experimenting.
Engineering in the Run Stage
Run is where engineering fully embraces FinOps as part of its DNA. Costs are not just tracked, they’re forecasted, managed, and traded off in real time. Engineers here know the business impact of their architectural decisions and actively optimize for both performance and profitability.
What this stage looks like in practice:
Comprehensive dashboards and alerts give engineers cost visibility in the same way monitoring tools give performance visibility.
Unit economics are defined: cost per customer, cost per API call, and cost per transaction.
Engineers design systems with efficiency as a core principle, not an afterthought.
Innovation is balanced: “How do we deliver new features while keeping margins healthy?”
Signs your team is at Run:
Teams get near-real-time cost visibility for their services.
Unit economics are established and used to measure efficiency.
Engineers use automation and AI-driven recommendations to optimize.
Cost, performance, and innovation are balanced in design decisions.
What engineering should be doing here:
Own cloud efficiency: Treat cost efficiency as an SLA alongside uptime and latency.
Continuously optimize: Fine-tune Kubernetes clusters, compute, storage, and network usage with automation.
Tie to business KPIs: Connect cost metrics directly to profitability, margin per product, customer lifetime value, etc.
Adopt AI-driven ops: Use anomaly detection, predictive scaling, and ML-based recommendations to stay ahead.
At Run, engineering isn’t just cutting costs; they’re driving profitability. Cloud decisions directly fuel business growth.
Also read: Beyond Cost: The 5 FinOps KPIs Engineering Leads Need to Track
Why FinOps Maturity Model Matters?
Most organizations stall somewhere between Crawl and Walk, and the reason is almost always the same: engineers don’t yet have the right tools, visibility, or incentives to make cost a natural part of their workflow. Finance may be shouting from the rooftops about rising spend, but unless engineering teams see cost data in real time, in the same place where they already live (dashboards, CI/CD, deployment tools), the cultural shift doesn’t happen.
This matters because FinOps is not, and never was, a finance-only initiative. You can’t spreadsheet your way into cloud efficiency. Without engineers at the center, FinOps risks becoming another reporting exercise, lots of charts, very little impact. True maturity only happens when engineers treat cost with the same seriousness as uptime, latency, or security.
The FinOps Maturity Model acts like a mirror for engineering teams:
At Crawl, the question is: “Do we even know what we’re spending, and where?”
At Walk, it becomes: “Are we accountable for the spend tied to our services and architecture?”
At Run, it’s: “Are we optimizing, forecasting, and trading off cost for speed, scale, and innovation in real time?”
Every stage is less about perfection and more about progress. The real win isn’t leaping from Crawl to Run overnight, it’s consistently moving one step forward. Even small shifts, like introducing tagging standards, automating idle resource cleanup, or pulling engineers into cost reviews, compound into major cultural and financial impact over time.
Ultimately, this matters because cloud cost efficiency is not just about cutting bills. It’s about aligning engineering, finance, and business outcomes, so every dollar spent in the cloud directly supports innovation, customer experience, and profitability.
How Amnic Helps Engineering Teams Mature in FinOps
At Amnic, we built our FinOps platform with engineering teams at the center of the experience. We understand that engineers are not just contributors to cloud spend, they’re also the ones who can directly influence and control it. That’s why our platform is designed to fit naturally into engineering workflows, making FinOps adoption smooth rather than disruptive.
Granular visibility: Break down costs at the level engineers care about, whether that’s by workload, namespace, or individual service. This allows teams to pinpoint exactly where spend originates and tie it back to the systems they own.
Custom dashboards: Engineers can create views tailored to their team’s priorities, ensuring they only see the costs that matter most to their projects.
Kubernetes observability: For teams running on K8s, Amnic bridges the gap between infrastructure and spend by mapping pod and node usage directly to costs. This makes resource efficiency crystal clear.
Recommendations: Be it rightsizing instances or optimizing schedules, our recommendations give engineers practical, data-backed ways to cut waste without compromising performance.
FinOps AI Agents: Intelligent assistants that automate monitoring, surface anomalies, and suggest optimizations instantly, so teams spend less time digging through dashboards and more time building.
By meeting engineering teams where they are, whether they’re just starting out with FinOps (Crawl), putting structured processes in place (Walk), or scaling FinOps practices across the organization (Run), Amnic helps them move up the maturity curve faster.
Importantly, this growth happens without creating silos: engineering gains the autonomy to manage their costs effectively, while finance and leadership stay aligned with clear reporting, accountability, and shared goals.
Summing up
The FinOps Maturity Model isn’t just a rigid checklist, it’s a journey of continuous cultural and technical evolution.
For engineering teams, it’s less about hitting milestones and more about building confidence and capability at every step: moving from awareness (understanding where costs come from), to ownership (taking responsibility for the resources they run), to optimization (driving smarter, data-backed decisions that benefit the entire organization).
Every team is somewhere on this spectrum, and the path forward often comes down to three simple but powerful questions:
Where is your team today? Are you just starting to get visibility into costs, or are you already experimenting with accountability and efficiency?
What’s stopping you from taking the next step? Is it lack of data, unclear ownership, or difficulty aligning with finance and leadership?
How quickly could you move ahead with the right tools? Imagine a platform that meets you at your current stage, whether you’re crawling, walking, or running. and helps you accelerate maturity without disrupting your workflows.
With the right FinOps practices and platforms in place, engineering teams can transform cloud costs from a source of friction into a driver of innovation, efficiency, and trust across the business.
[Request a demo and speak to our experts]
[Get yourself a free 30-day trial with Amnic]
[Download our free FinOps resources]
FAQs: FinOps Maturity Model
1. What is the FinOps Maturity Model?
The FinOps Maturity Model, created by the FinOps Foundation, outlines how organizations progress in their cloud cost management journey. It uses a Crawl → Walk → Run framework to describe how teams move from basic visibility (Crawl), to shared accountability (Walk), to proactive optimization (Run).
2. Why does the FinOps Maturity Model matter for engineering teams?
Because engineers directly influence cloud costs through architecture and deployment decisions. The model helps teams understand where they stand today and what steps they can take to build cost awareness into their workflows without slowing down innovation.
3. Do all teams need to reach the “Run” stage?
Not necessarily. The FinOps Foundation emphasizes that maturity should be driven by business outcomes. Some teams may only need visibility (Crawl) or shared accountability (Walk) to deliver impact. The goal is progress, not perfection.
4. What are the signs my engineering team is still at the Crawl stage?
No consistent tagging or naming of resources
Limited or no visibility into cloud spend by team or service
Architecture decisions are made purely on technical grounds, without cost considerations
Optimization is reactive, only when bills spike
5. How can engineering teams move from Crawl to Walk?
Start by building visibility (dashboards, tagging, cost allocation), automating basic cleanups (idle resources, unused volumes), and bringing cost discussions into retros or sprint planning. Collaboration with finance should also begin at this stage.
6. What does FinOps maturity look like at the Run stage?
At Run, engineering teams treat cloud cost efficiency like uptime or latency. They use automation, AI-driven recommendations, and real-time dashboards. Costs are tied to unit economics (e.g., cost per customer, API call), and trade-offs are made consciously between speed, scale, and cost.
7. What stops most organizations from advancing in FinOps maturity?
Common blockers include lack of real-time visibility, poor tagging practices, unclear ownership, and weak collaboration between finance and engineering. Without the right tools, FinOps risks becoming just a reporting exercise rather than a cultural shift.
8. How does Amnic help engineering teams mature in FinOps?
Amnic provides engineering-centric tools: granular visibility by service/workload, custom dashboards, Kubernetes observability, AI-driven recommendations, and FinOps AI Agents. By meeting teams where they are (Crawl, Walk, Run), Amnic accelerates maturity without disrupting workflows.
9. How long does it take to move up the maturity curve?
It varies by organization. Some teams can progress from Crawl to Walk in a few months with the right practices, while reaching Run often requires deeper cultural and process changes. The key is incremental progress, small wins compound into major impact over time.
10. Is FinOps only about reducing costs?
No. FinOps is about optimizing value from cloud investments. It’s not just about cutting bills, but about aligning engineering, finance, and business so every dollar spent in the cloud directly supports innovation, customer experience, and profitability.
