Showback Is Not Accountability

Most organizations believe showback creates accountability. It doesn’t. Showback creates visibility—and visibility feels like control. Dashboards appear. Reports circulate. Cost reviews get scheduled. Everyone relaxes. But nothing in the system is forced to change. A dashboard is not a decision.
A report is not an escalation path.
A monthly cost review is not governance. This episode dismantles the illusion. You can instrument cloud spend perfectly and still drift into financial chaos. Real governance only exists when visibility turns into enforced decisions—with owners, guardrails, workflows, and consequences. 1. The Definitions Everyone Blurs (and Why It Matters) Words matter because platforms only respond to what is enforced—not what is intended. Showback is attribution without impact. It answers “Who did we think spent this money?” It produces telemetry: tags, allocation models, dashboards. Telemetry is useful. Telemetry is not a control. Chargeback is impact without intelligence. It answers “Who pays?” The spend hits a cost center or P&L. Behavior changes—but often in destructive ways. Teams optimize for looking cheap instead of being effective. Conflict replaces clarity when ownership models are weak. Accountability is neither of these. Accountability is owned decisions + enforced constraints + an audit trail. It means a human can say: “This spend exists because we chose it, we can justify it, and we accept the trade-offs.”
And the platform can say: “No.” Not metaphorically. Literally. If your system cannot deny a bad deployment, quarantine unowned spend, escalate a breach, or expire an exception, you are not governing. You are persuading. And persuasion does not scale. 2. Why Showback Fails at Scale: Observer With No Actuator Showback fails for the same reason monitoring fails without response. It observes but cannot act. Cloud spend is not one big decision—it’s thousands of micro-decisions made daily: SKU choices, regions, retention settings, redundancy, idle compute, “temporary” environments, premium licenses. Monthly reports cannot correct daily behavior. So dashboards become rituals:

• Teams explain spikes
• Narratives replace outcomes
• Meetings repeat
• Nothing changes

The system trains everyone to optimize for explanation, not correction. The result is predictable: cost drift becomes normalized, then defended. Anyone trying to stop it is labeled as “slowing delivery.” That label kills governance faster than bad data ever could. This is not a failure of discipline. It is a failure of system design. 3. Cost Entropy: Why Spend Drifts Even With Good Intentions Cloud cost behaves like security posture: it degrades unless continuously constrained. Tags decay. Owners change. Teams reorganize. Subscriptions multiply. Shared services blur accountability. “Temporary” resources become permanent because the platform never asks you to renew the decision. This is cost entropy—the unavoidable decay of ownership, attribution, and intent unless renewal is enforced. When entropy wins:

• Unallocated spend grows
• Exceptions pile up
• Allocation models lie confidently
• Finance argues with engineering over spreadsheets
• Nobody can answer “who owns this?” fast enough to act

This isn’t because tagging is “bad hygiene.” It’s because tagging is optional. Optional metadata produces optional accountability. 4. Failure Mode #1: Informed Teams, No Obligation “We gave teams the data.” So what? Awareness without obligation is trivia.
Obligation without authority is cruelty. Dashboards tell teams what already happened. They don’t change starting conditions. They don’t force closure. They don’t require decisions to end in accept, mitigate, escalate, or reforecast. So the same offenders show up every month. The same subscriptions spike. The same workloads drift. And the organization learns the real rule: nothing happens. Repeated cost spikes are not a cost problem. They are a governance failure the organization is tolerating. 5. Failure Mode #2: Exception Debt and Policy Without Teeth Policies exist. Standards are published. Exceptions pile up. Exceptions are not edge cases—they are the operating model. And when exceptions have no owner, no scope, no expiry, and no enforcement, they become permanent bypasses. Policy without enforcement is not governance.
It’s documentation with a logo. Exceptions multiply ambiguity, break allocation, and collapse enforcement. Over time, the only people who understand the “real rules” are the ones who were in old meetings—and they leave. Real exceptions must have:

• An accountable owner
• A defined blast radius
• A justification tied to business intent
• An enforced end date

If an exception doesn’t expire, it isn’t an exception. It’s a new baseline you were too polite to name. 6. Failure Mode #3: Shadow Spend Outside the Graph The most dangerous spend is the spend you never allocated in the first place. Shadow subscriptions, trial tenants, departmental SaaS, “temporary” Azure subscriptions, Power Platform environments—cloud removed the friction that once made these visible. Showback dashboards can be perfectly accurate and still fundamentally wrong, because they only show the governed part of the system. Meanwhile the real risk hides in the long tail of small, unowned, invisible spend. Once spend escapes the graph:

• Cost governance collapses
• Security posture fragments
• Accountability disappears

At that point, governance isn’t a design problem. It’s a detective story—and you always lose those eventually. 7. Governance Is Not Documentation. It Is Enforced Intent Governance is not what your policy says. It’s what the platform will and will not allow. Real governance operates at creation time, not review time. That means:

• Constraints that block bad defaults
• Alarms that trigger decisions
• Workflows that force closure
• Audit trails that prove accountability

Guidelines are optional by design. Constraints are not. If the system tolerates non-compliance by default, you chose speed over control. That may be intentional—but don’t call it governance. 8. The System of Action: Guardrails, Alarms, Actuators Escaping the showback trap requires three enforceable systems working together: Guardrails
Azure Policy to constrain creation: required tags, allowed regions, approved SKUs, dev/test restrictions. Not recommendations. Constraints. Alarms
Budgets as escalation contracts, not FYI emails. Owned alerts, response windows, and defined escalation paths. Actuation
Workflow automation (ServiceNow, Power Automate) that turns anomalies into work items with owners, SLAs, decisions, and evidence. No email. No memory. Miss any one of these and governance collapses back into theater. 9. Ownership as the Real Control Plane Ownership is not a tag. It is authority. A real owner can approve spend, accept risk, and say no. Distribution lists, FinOps teams, and “IT” are not owners. They are routing failures. Ownership must exist at:

• Boundary level (tenant/subscription)
• Workload/product level
• Shared platform level

And ownership must be enforced at creation time. After that, resources become politically protected—and you keep paying. 10. From Cost Control to Value-Driven Governance The goal is not savings. Savings are a side effect. The real goal is spend that is:

• Intentional
• Attributable
• Predictable
• Defensible

Showback tells you what happened.
Governance determines what is allowed to happen next. When ownership is enforced, exceptions expire, and anomalies force decisions, cloud spend stops being a surprise and starts being strategy executed through infrastructure. Final Takeaway Showback is not accountability. It is an observer pattern with no actuator. Until your platform can force ownership, deny bad defaults, expire exceptions, and require decisions with evidence, you are not governing cloud spend. You are watching it drift—beautifully instrumented, perfectly explained, and completely uncontrolled. The next episode breaks down how to implement this system of action step by step.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.