June 18, 2026
Multiple Versions of the Truth
This post is part of my Medium blog.
There's a moment in every FinOps leader's career when you realize something uncomfortable. More than one team views itself as the authoritative source of financial data for cloud spend. They are usually on different sides of a proposal, and they don't agree.
This happens whenever the stakes are high enough to matter. When the stakes are low — monthly optimization reviews, reserved instance coverage, the usual — everyone's happy to share a single set of numbers. But when a big decision is on the table, when real money or headcount is in play, you start seeing multiple versions of the truth emerge. And they're not just different in the details. They tell different stories.
Same number, charted by different teams — and no reconciled line among them. (Image Assist by Anthropic)
The pattern shows up everywhere once you know to look for it.
The team responsible for building and running your data centers wants to build more data centers. Their analysis of the alternatives — cloud, colocation, hybrid — consistently shows that self-managed infrastructure is the right call. The methodology is sound, the inputs are reasonable, and the conclusion protects their charter. It's not dishonest. It's that no team analyzes its way out of its own existence.
The team you're paying to manage databases doesn't want to migrate to a managed PaaS offering. They'll produce a total cost of ownership analysis that captures every migration risk, every edge case, every unknowable future dependency — and somehow the PaaS option always comes out worse, because the whole model assumes the worst-case outcome for support.
The team building a platform capability that needs headcount to survive will model a "build" scenario with generous assumptions and a "buy" scenario with punishing ones. Not because they're manipulating the numbers — because that's how you see the world when your team's future depends on which answer comes out ahead.
This is not a pathology. It's rational behavior from teams operating in their own interest. The problem is when those analyses arrive at the executive table with nothing to distinguish them — no shared methodology, no independent validation, no published baseline — and the decision gets made on whoever told the most convincing story.
Here's what makes this complicated: the modeling itself is useful. You want teams to think through their scenarios. You want engineering to model what happens if you invest in optimization. You want the platform team to map out what PaaS migration actually costs. You want finance to run the numbers on committed spend versus on-demand.
The issue isn't that multiple teams produce multiple projections. The issue is what happens — or doesn't happen — after.
If there's no process to validate those projections, to establish a shared methodology, to reconcile competing assumptions and publish a canonical version, then what you have is a market for narratives. Every team brings their best story. The one with the most credible presenter or the most sympathetic framing wins. That's not analysis. That's persuasion wearing analysis's clothes.
This is why the reporting structure of a FinOps function matters more than most people think. It's not an org chart detail. It determines whether anyone in the organization has the standing to say: this is the validated number, here's how we got there, and here's what it means.
FinOps shouldn't sit inside the engineering org. That's where it often starts — a few people who understood the cloud APIs and got pulled into cost work — but if FinOps reports to engineering, it's analyzing the same org that controls the spend. The hard questions about engineering efficiency become questions about your boss's boss's decisions. That's not independence. That's a conflict of interest with a Confluence page.
FinOps shouldn't be part of any cost center it needs to analyze. The value of a functioning FinOps team is precisely that it doesn't have a dog in the fight. It can look at the data center team's TCO model and the cloud team's optimization projections and the PaaS migration proposal and say, with credibility, here's what we think is actually true and why.
But organizational independence is only the foundation. It doesn't matter where FinOps sits in the org chart if there's no process. The work is building the validation and publication process — the shared data definitions, the agreed methodology, the regular cadence where projections get tested against actuals, the published baseline that everyone works from.
Without that process, every team keeps its own books. And everyone gets to be right.
The real question in any high-stakes spend decision isn't "what do the numbers say?" — because the numbers will say different things depending on who ran them. The question is: who in this organization has the position, the independence, and the process to publish a validated version that everyone agrees to reason from?
If the answer is nobody, you're going to make a fifty-million-dollar decision based on whoever made the best case. That might work out. It also might not, and you'll never really know which analysis was right, because there was never a process to find out.
I wrote about competing versions of the truth during an acquisition — and the team that has to cut through them — in Redundant.
In Redundant, the first book in The Condition Set trilogy, Rob Coleman runs the FinOps review that names the waste nobody wants to hear about. The numbers don't change. The question is who they get used against.