TL;DR: Split ownership by decision type: a small central platform owns visibility, standards, tooling and commitment purchases (reserved capacity, savings plans), while product teams own their architecture choices and the bill lines those create. Every rupee of spend has exactly one named owner, and efficiency reviews run on unit economics rather than absolute totals.
How to approach it
Reject the binary. Explain the risks of concentrating all decisions centrally or leaving all decisions to individual teams, then propose responsibilities suited to this organisation. The test for any split is whether it puts each decision where the knowledge to make it already lives, which is what keeps velocity and accountability from trading against each other.
A strong answer
Risk of excessive central control. A central team can lack the context to judge a workload. It mandates rightsizing that breaks batch jobs, files tickets nobody prioritises because the costs land on someone else's dashboard, and becomes the team engineers route around. Cost awareness decays into a quarterly compliance theatre.
Risk of uncoordinated local decisions. Teams can miss aggregate commitment opportunities, duplicate shared tooling and optimize their own bill at the expense of shared infrastructure. Central visibility and purchasing coordination help address those gaps.
The split that works divides decisions by knowledge location:
| Decision | Owner | Why |
|---|---|---|
| Visibility, allocation, tagging standards | Central | One pipeline, one truth |
| Commitment purchases (RIs, savings plans) | Central | Portfolio view, aggregate bargaining |
| Architecture and scaling choices | Product teams | Only they know workload shape |
| Service selection (managed vs self-hosted) | Team, with central review | Local expertise plus guardrail |
| Efficiency targets and reporting | Joint | Unit metrics negotiated per service |
Make ownership literal. Every major spend line carries a named owner and appears on a dashboard that person sees without asking. Unattributed spend is itself a metric, tracked as a percentage against an agreed target and baseline, because it measures allocation coverage as well as ownership discipline.
It is worth being concrete about why that percentage is the first thing to fix. On a $2M monthly bill, 15 percent unattributed is 2,000,000 × 0.15 = $300,000 a month that no team can be asked about, and it is not distributed evenly: it concentrates in shared clusters, data transfer and the accounts nobody claimed during a migration. Every unit-economics conversation downstream inherits that uncertainty, so a team shown a cost per thousand requests can reasonably argue the number is wrong by whatever share of the unattributed pool is theirs. Driving the figure from 15 percent to 3 makes every other number in the model defensible, which is why allocation coverage comes before efficiency targets rather than alongside them.
Run the rhythm monthly, lightweight. Each team reviews its unit economics (cost per thousand requests, per customer, per model training run) against its own trend, not against other teams, because workloads differ fundamentally. Central publishes fleet-level movements: commitment coverage, discount realisation, top movers. Escalation happens on anomalies, not on rankings; league tables teach gaming faster than they teach efficiency.
The cultural piece is the actual answer. Engineers respond to cost visibility the same way they responded to latency dashboards once upon a time: when the number is theirs, near their other metrics, reviewed by their own lead, behaviour shifts without memos. The central team's real product is that visibility plus the purchasing leverage no individual team can get; everything else belongs to the builders.
What interviewers probe next
"How do you stop central becoming gatekeepers?" Write down decision rights. Central enablement provides dashboards and defaults; finance or delegated owners approve commitments, while mandatory budget or risk controls have an explicit exception path. Teams retain routine architecture decisions inside those constraints.
"What about engineering time as a cost?" Price the effort and expected savings lifetime. At an illustrative loaded $10,000 per engineer-month, three engineer-months cost $30,000; net savings of $2,000 per month give a 15-month simple payback after delivery. Over 24 months that is $48,000 of undiscounted savings before the initial effort, leaving $18,000. Over six months it does not pay back. Include maintenance, opportunity cost, savings confidence and the company's required return before deciding.
"How does this survive reorganisations?" Keep a stable service identity, but update its accountable team and cost-center mapping with effective dates. Check unassigned services during the handover and preserve historical allocation; reorganizations still require migration and review.
Common mistakes
Announcing a mandate ("all teams cut 20 percent") with no baseline or unit metrics, guaranteeing arbitrary cuts in whatever is easiest to see.
Buying commitment portfolios without usage data, locking three years of spend onto yesterday's architecture.
Treating FinOps as a phase that ends. Usage, architecture and prices change; revisit allocation and efficiency decisions as those inputs move.