Why the monthly-report model structurally fails
A monthly report answers 'what did this cost' long after the only people who could have made a different choice have moved to other work. It creates awareness without creating leverage — nobody is positioned to act on the information at the point it would matter.
The fix isn't a faster report. It's moving the same information several weeks earlier, to the pull request or the architecture review, where a different decision is still cheap to make.
Tagging is a data model, not an afterthought
Cost allocation tagging retrofitted after the fact is always incomplete and always political — nobody wants to own the untagged 20%. Treat the tagging schema as a first-class part of the platform's data model, enforced by policy-as-code at deploy time, not requested politely in a wiki page.
Without enforced tagging, every other FinOps practice downstream — showback, chargeback, unit economics — is built on a dataset nobody fully trusts.
Unit economics over aggregate spend
Aggregate monthly spend tells you almost nothing actionable; cost-per-transaction or cost-per-active-user tells you whether the platform is becoming more or less efficient as it scales. Engineering teams respond to unit economics because it's a signal about their own system's design quality, not an abstract finance metric.
This reframing is what turns FinOps from a compliance exercise finance runs on engineering, into a design input engineering runs for itself.
A cost signal that arrives after the decision was made is not FinOps. It is an invoice.MNB Cloud Practice
Key actions
- Surface cost impact in the PR, not the monthly report
- Enforce tagging by policy-as-code at deploy time, not by request
- Track cost-per-transaction, not just aggregate spend
- Give engineering teams ownership of their own unit economics