The problem with FinOps as a finance function
Most FinOps programs start in finance. A VP of Finance runs the AWS bill, notices it has grown 60% year-over-year, schedules a meeting with engineering leadership, and asks for a cost reduction plan. Engineering leadership delegates to platform engineering. Platform engineering produces a report. The report is reviewed. Some actions are identified. Six weeks later, some of those actions have been taken. The bill grows 15% the following quarter.
This cycle produces incremental improvements at best. The fundamental problem is that the people making the technical decisions that drive cloud cost — which instance types to deploy, how large to size database instances, whether to delete infrastructure after a project ends — are not in the FinOps loop. They receive cost information as a filtered summary, weeks after the fact, in a meeting format that is not part of their normal work cadence.
Where cloud cost decisions actually happen
Cloud costs are determined by infrastructure decisions made in pull requests, Terraform plans, and deployment pipelines. An engineer choosing db.r6g.2xlarge instead of db.r6g.xlarge for a development database is making a cost decision. An engineer provisioning a GKE cluster with min_node_count = 5 when the workload minimum is 2 is making a cost decision. These decisions happen dozens of times per day across a multi-team engineering organization, and most of them are made without any cost context in the decision environment.
Platform engineering is the team closest to these decisions. Platform engineers write the Terraform modules that product teams use to provision infrastructure. They set the defaults that product teams inherit. They operate the Kubernetes clusters that product teams deploy into. They are not the only decision-makers, but they have more leverage over the cost-efficiency of the organization's infrastructure than any other team — including finance.
What the FinOps Foundation maturity model means for platform teams
The FinOps Foundation describes three maturity stages: Crawl, Walk, and Run. Crawl means cost visibility exists at the account or project level, but there is no team-level attribution and no regular cost review process. Walk means team-level attribution exists, teams can see their share of the bill, and there is a regular cadence for reviewing costs and identifying optimization opportunities. Run means cost efficiency is a first-class engineering metric, optimization opportunities are acted on continuously, and forecast accuracy is high enough that budget variances trigger investigation rather than just regret.
The transition from Crawl to Walk is primarily a data infrastructure problem: building the attribution model, connecting billing data to team ownership, and establishing a delivery cadence. Platform engineering is typically the team that builds this infrastructure because they have the access, the technical background, and the organizational context to connect cloud billing data to the resource ownership graph.
The transition from Walk to Run is a culture problem: engineers need to internalize cost efficiency as a quality metric alongside performance, reliability, and security. This does not happen because a finance team publishes a dashboard. It happens because cost data is present in the same tools and workflows that engineers already use to evaluate the quality of their work.
Making cost data engineer-native
Engineer-native cost data lives in Slack, not in a dashboard that requires a separate login. It appears in the sprint review, not in a monthly finance meeting. It shows up as a contextual piece of information alongside performance metrics and error rates, not as a standalone report that requires interpretation.
A weekly squad cost digest in Slack, delivered on Tuesday morning before the sprint planning cycle, puts cost data at the beginning of the decision cycle rather than at the end. Engineers arriving at sprint planning can see that their service's RDS spend increased 28% over the past two weeks. That context shapes the priority they assign to investigating the database query patterns that are driving the increase — not because finance told them to, but because the information is present and relevant.
Budget alert thresholds per team — with alerts routed to the team's Slack channel rather than to a central finance inbox — create accountability without creating bureaucracy. When the Payments team receives an alert that their projected monthly spend has crossed $180K with two weeks remaining in the month, the person who receives that alert is the person with the most context to act on it.
What platform engineering actually owns in FinOps
Platform engineering's FinOps responsibilities fall into two categories: infrastructure cost efficiency (the decisions they make directly, like instance type selection, cluster configuration, and shared service architecture) and cost visibility infrastructure (the systems that give product teams access to their attribution data).
The most impactful platform engineering FinOps actions are the ones with large leverage: setting sensible default instance types in Terraform modules so product teams start from an efficient baseline rather than a permissive one; building cluster autoscaler and node pool configurations that right-size capacity dynamically rather than statically; designing shared service cost distribution models that give product teams honest visibility into the infrastructure they depend on.
These are not finance tasks delegated to engineers. They are engineering tasks that happen to have significant cost implications, handled by the team with the most context to do them well.
