What distinguishes a FinOps practice that works from one that produces reports nobody acts on?

What distinguishes it

1. Engineering owns the numbers, finance provides the data. A practice run entirely by finance produces reports engineers do not read, about a system finance does not understand. The team that creates cost must own reducing it.

2. Attribution exists and is enforced at resource creation. Untagged resources blocked or automatically flagged. Without attribution, cost is one number nobody owns and every subsequent control is impossible. This is the prerequisite, not a later refinement.

3. Cost appears where engineers already look — in their own dashboards, daily, alongside latency and error rate. A separate monthly report in a separate tool is a report nobody acts on, however good it is.

4. Unit economics rather than absolute spend, so the goal does not conflict with growth. Cost per request, per user, per gigabyte processed — with a trajectory target such as "unit cost declines 10% year on year", which teams can design against.

5. Automated reclamation rather than tickets. Unattached volumes, idle load balancers, orphaned snapshots, non-production environments running overnight. Tickets do not get closed; automation does.

6. Cost as an input to design review, catching the expensive decision before it ships.

The signals that it is not working

• Cost reduction happens in sprints and reverses within two quarters.
• The main artefact is a monthly report.
• Nobody can attribute a meaningful share of spend to a team.
• Optimisation targets the largest line item rather than the fastest-growing one.
• Engineers experience the practice as an audit rather than as information.
• Reliability degrades as teams cut headroom to improve their number — the most dangerous signal, and the reason cost targets must be paired with reliability targets.

The cultural point

The most effective intervention is usually making the number visible to the person who created it, at the time they created it — a cost estimate in a pull request that adds infrastructure, a dashboard showing a team's own trend, an alert when a service's cost per request changes materially.

Reports describe the past to people who cannot change it. Feedback at the point of decision changes the decision, which is where all the leverage is.