3. FinOps fails when everyone owns cloud costs and nobody owns specific activities

The situation

The FinOps Foundation defines five core personas (Practitioner, Engineering, Finance, Leadership, Procurement) and five allied (ITAM, ITFM/TBM, Security, ITSM, Sustainability). Useful for education. Too coarse for execution.

The complication

40% of practitioners say getting engineers to act is their top challenge (State of FinOps 2026). 52% of engineering leaders say the disconnect wastes money, while 62% of developers want more cost responsibility (Harness 2025). The intent exists on both sides. The structure connecting them does not.

The resolution: RACI for 15 activities across 6 personas

R = Responsible. A = Accountable. C = Consulted. I = Informed. Each activity has exactly one A. This is non-negotiable. If an activity has two accountable owners, rename one to Consulted immediately. Shared accountability produces shared inaction.

Six operating personas

RACI matrix: 15 activities

Three structural shifts

Shift 1: Centralised procurement to distributed ownership. Distribute day-to-day cost ownership to engineering. Centralise commitment purchases with procurement where the financial risk sits. Engineering understands utilisation. Procurement understands contract terms. Forcing either to do the other's job produces worse outcomes than separating the responsibilities clearly.

Shift 2: Monthly review to real-time feedback. Embed cost feedback into engineering tools: Infracost in PRs, Slack anomaly alerts, JIRA cost annotations. 62% of developers want this (Harness 2025). The monthly cost review meeting is where information goes to age. By the time an engineer sees a February overspend in a March meeting, the architectural decision that caused it is three sprints old.

Shift 3: Blame to shared accountability. Showback before chargeback. Transparency before targets. Trust first, then accountability through cost OKRs and architecture review gates. Organisations that skip the trust-building phase and jump directly to chargeback create adversarial relationships between finance and engineering that take years to repair.

New and evolved roles

FinOps Practitioner is now a distinct career path with certification tracks at Practitioner, Engineer, and Leadership levels. Cloud Cost Engineer is a hybrid platform-plus-financial-analysis role emerging in organisations above $20M cloud spend. AI Cost Analyst is the newest addition: 98% of practices now manage AI spend, up from 31% in 2024, and the skills required to govern token-based pricing are different from those needed for instance-based pricing.

What each persona actually does day-to-day

The persona table above defines roles in theory. What follows describes what each persona does in practice during a typical week at a Walk-stage financial services organisation.

The FinOps Practitioner spends Monday morning reviewing weekend anomaly alerts and triaging them into false positives (auto-scaling response to batch processing), expected increases (new service launch), and genuine waste (forgotten load test environment still running). Tuesday is the weekly cost review with engineering leads, where the practitioner walks through each team's spend delta and highlights recommendations awaiting action. Wednesday involves updating the forecast model with actual consumption data and adjusting commitment coverage recommendations. Thursday is tooling work: configuring new dashboards, refining alerting thresholds, or integrating a new data source. Friday is reserved for the monthly governance pack preparation and ad-hoc requests from finance.

The Engineering persona (Platform Eng, DevOps, SRE) encounters FinOps in three places: pull request cost estimates from Infracost, Slack alerts from anomaly detection, and JIRA tickets from rightsizing recommendations. The best engineering teams treat cost tickets the same as bug tickets: they go into the backlog, get sized, and get scheduled. The worst engineering teams treat cost tickets as optional and let them age until the FinOps practitioner escalates. The difference is usually cultural, not technical.

Finance (FP&A, Financial Controller) interacts with FinOps primarily through the monthly governance pack and quarterly forecasting. The most productive finance engagement happens when finance owns the chargeback model design (Activity 7) and challenges the FinOps practitioner on forecast accuracy. The least productive engagement happens when finance treats cloud costs as a black box and simply reports whatever number the FinOps team provides without understanding or challenging it.

Product and Business personas engage with FinOps through unit economics (Activity 14). A Product Manager who knows that their product costs $0.003 per transaction in infrastructure makes better decisions about pricing, feature prioritisation, and architecture. A Product Manager who does not know their unit cost makes decisions based on feature value alone, which ignores half the equation.

Procurement operates on a different cadence: annual or multi-year contract negotiations with cloud providers. The most effective procurement engagement is portfolio-level negotiation (see Recommendation 11 in Section 11). The least effective is per-service negotiation that fragments the organisation's buying power. Procurement needs consumption data from the FinOps practitioner and growth forecasts from product teams to negotiate effectively.

The Executive Sponsor (CTO, CFO, VP Engineering) sets the tone. If the CTO asks about cloud costs in every architecture review, engineering takes costs seriously. If the CTO never asks, engineering optimises for performance and features only. The single most effective executive action in FinOps is asking one question in every architecture review: 'What will this cost per month at steady state?' That question, asked consistently, does more to embed cost awareness than any tool or process.