Our first attempt at cost accountability was a 40-tab spreadsheet emailed to engineering managers on the 5th of each month. Open rate, judging by questions asked: close to zero. Our second attempt, a proposal to charge each team's budget for its cloud spend, produced three weeks of arguments about allocation rules and no change in spend.

What finally worked was a showback program: costs shown to the people who can change them, in a form they can act on, with no money moving between budgets until the numbers were trusted. This guide describes it.

Showback versus chargeback

  • Showback reports costs to teams for awareness and decision making. Budgets do not change.
  • Chargeback moves costs into teams' budgets or profit and loss statements.

Chargeback creates strong incentives and strong objections. If allocation is wrong or unclear, every objection is valid. Start with showback, fix allocation until teams stop disputing it, and only then consider chargeback, if your finance model needs it at all. Many companies never move past a mature showback, and that is fine.

Step 1: ownership before numbers

Costs need owners. Before the first report we built a mapping of every AWS account, Kubernetes namespace and major shared resource to a team and a service. Sources:

  • Account ownership in AWS Organizations (account tags).
  • Namespace labels in Kubernetes, enforced by admission policy.
  • Resource tags team and service, activated as cost allocation tags.
  • A small ownership file in the platform repository for exceptions.

Anything unowned goes into a visible "unallocated" line that the FinOps lead chases weekly. Within two months, unallocated dropped from 23 percent to 3 percent.

Step 2: a report that fits on one screen

Each team gets one page per month, posted in their channel and linked from their service catalog entry:

Section Content
Total This month's effective cost, change versus last month and versus three months ago
Unit cost Cost per main unit for their service (per 1,000 requests, per active customer)
Top movers The three resources or services with the largest increase, with a one-line explanation where known
Opportunities Up to three concrete savings actions with estimated monthly value
Shared costs Their share of platform and shared services, shown separately, not hidden

The opportunities section matters most. "Lower requests on search-indexer to match p95 usage: saves about 1,800 USD per month" gets done. "Your compute spend is 41,000 USD" does not.

Step 3: budgets per service, owned by the team

Each service gets a monthly budget proposed by the team, based on last quarter plus expected growth. Budgets are for awareness: crossing one triggers a conversation, not a penalty. Daily budget alerts go to the team channel, so spikes are noticed by the people who caused them, usually within a day.

Step 4: a monthly 30-minute review

FinOps lead, one engineer from each of the top five spending teams, and someone from finance. Agenda: anomalies from the last month, opportunities in progress, upcoming changes that will move costs (launches, migrations, commitments). The meeting ends with at most five action items with owners.

Step 5: celebrate savings like features

When a team cuts its costs, it goes in the engineering newsletter with the number and how they did it. Engineers like solving efficiency problems; they need the problems to be visible and the work to be recognised.

When to move to chargeback

Signals that showback is mature enough:

  • Unallocated cost is under 5 percent and stable.
  • Allocation rules for shared costs have been unchanged for a few quarters without disputes.
  • Teams predict their own costs within about 10 percent.
  • Finance needs per-product margins for business decisions.

Even then, chargeback the parts teams control (their direct resources) and keep shared platform costs centrally funded or allocated with a simple, published formula.

Tooling we used

Nothing exotic. Cost and usage data lands daily in our warehouse from the providers' billing exports. A dbt project joins it with the ownership mapping and produces one table per month per team and service. The one-page reports are generated from that table by a scheduled job and posted to each team's channel, with a link to a dashboard for anyone who wants to dig deeper. Daily budget alerts come from the cloud providers' budget services, routed to the same channels. The whole setup is maintained by one FinOps lead spending part of their week on it. The expensive part was never the tooling; it was agreeing on ownership and definitions.

Measuring whether it works

We track three things: the share of teams that acted on at least one opportunity per quarter, the total monthly value of savings implemented, and the unallocated share. In the first year, savings implemented by teams themselves were larger than all centrally driven savings combined, which was the strongest argument for keeping the program going.

Common mistakes

Mistake Why it hurts Do this instead
Huge spreadsheets Nobody reads them One page per team with actions
Chargeback first Endless disputes about allocation Showback until numbers are trusted
No owners for shared costs Platform waste is invisible Show shared costs separately with an owner
Reports without opportunities Awareness without action Include concrete savings with values
Blame for spikes Teams hide problems Treat cost incidents like any other incident, blameless

A note on tone

How cost is talked about decides whether teams engage. We never present a team's cost as a ranking against other teams, because a data platform will always cost more than a settings service and the comparison only creates resentment. We compare each team with its own past and with its own unit costs, and we say thank you in public when someone finds a saving.

Key takeaways

  • Map ownership before producing numbers.
  • Show each team a short report with unit costs and concrete savings.
  • Use budgets for awareness and fast feedback, not punishment.
  • Review monthly with a small group and few action items.
  • Move to chargeback only when allocation is trusted, and maybe never.

References