This week’s newsletter was difficult to write. I was not particularly inspired and kept circling the same idea: I spend a lot of time talking about “visibility theater,” but I have not really offered a clear path forward. So instead of forcing a topic, I decided to ground this in experience.

I have led Infrastructure and IT teams in both the data center era and the cloud era, across DevOps, SRE, and Platform Engineering. Regardless of the environment, one responsibility remained constant: cost.

In the data center, it was CapEx. In the cloud, it became OpEx. In some cases, it extended into SaaS and broader IT spend. The context changed, but the expectation did not. Manage costs, improve efficiency, and build trust through results.

Over time, that translated into millions of dollars in savings.

But it was never just about reporting or identifying waste. It was about creating a system where better decisions were made consistently and actions took precedent. Ultimately, it was a system where cost was not just measured, but influenced decisions.

Before getting into what worked, it is worth grounding this in how the industry currently frames the problem based on recent articles I have read.

A common industry perspective, reflected in recent writing from CIOPages, frames FinOps as a structured system for IT budget optimization. The model is straightforward. Establish visibility into spend, allocate that spend to teams or products, identify optimization opportunities, and introduce governance to guide behavior. It is a logical progression and, at a surface level, aligns with how most organizations approach cloud cost management today.

What is more interesting is what the framework is trying to accomplish beneath the surface.

It is attempting to move cost from a reactive exercise, typically owned by finance, into a continuous system that engineering can operate within. Instead of reviewing spend after the fact, the goal is to create a loop where usage, ownership, and financial impact are consistently connected.

In practice, most organizations can stand up the early stages without much friction. Visibility improves quickly. Allocation follows with enough tagging discipline. Optimization becomes possible once patterns are understood.

Where things tend to break down is governance.

That is where ownership must be clearly defined, tradeoffs must be made, and behavior actually needs to change. Without that, the system remains intact but underpowered. It explains spend, often in great detail, but does not consistently influence it.

This too was my experience.

If the CIOPages perspective represents how FinOps is supposed to work, a more critical view was raised in this InformationWeek article and introduces a harder question.

What happens when the structure is in place, but the outcomes do not follow?

Many organizations already have what looks like a complete FinOps system. There is visibility into spend. Costs are allocated across teams and services. Budgets are set and alerts are configured. In some cases, there are even dedicated FinOps teams responsible for overseeing all of it.

And yet, despite this, spend continues to grow, often without a clear connection to business value.

This is where the idea of a “cloud control placebo” starts to resonate. Not because the tools or practices are inherently flawed, but because they create the appearance of control without necessarily changing behavior.

Visibility, on its own, does not drive action. Allocation does not guarantee ownership. Even well-defined optimization opportunities do not get executed unless someone is accountable for making the tradeoffs.

In that gap, FinOps becomes observational.

It provides clarity into what has already happened, sometimes with impressive precision, but remains removed from the decisions that determine what happens next. The system works, but only within the boundaries it was designed for.

And those boundaries often sit downstream of the decisions that matter most.

This is where my experience diverges from both the ideal framework and the critique.

The work is not in the dashboards. It is in how you operationalize change.

It starts with creating a consistent cadence around cost. Not just reporting it, but explaining it. Trends, deviations, and decisions should be visible and understood across engineering, finance, and product. The goal is not to review numbers, but to create shared context.

From there, progress needs to be demonstrated. Not in theory, but in action. A simple, structured approach works best:

Early wins are important. They build credibility and create momentum. They show that that the FinOps framework is not just a reporting function, but something that can drive tangible outcomes.

Over time, that momentum allows you to push deeper.

Conversations shift from obvious inefficiencies to more meaningful tradeoffs. Architecture decisions start to include cost as a first-class consideration. Ownership becomes clearer at the service or product level. Eventually, you can begin to reason about unit economics in a way that is grounded in reality.

That progression does not happen because of a dashboard. It happens because of sustained, visible execution.

This week, I shared a practical framework you can begin to apply immediately. In the coming weeks, I’ll go deeper into specific actions and patterns that help drive real progress.

None of this is overly complex. But it does require consistency, conviction, and a deliberate effort to build trust across engineering, finance, and product teams.

That trust, combined with sustained execution, is what ultimately allows you to move beyond cost reporting and into something more meaningful: clear business value and well-understood unit economics.

In this week’s main piece, I walked through how FinOps frameworks are structured and where they tend to fall short in practice. The gap often shows up in governance and ownership. Underneath that, there is a more fundamental issue.

Most teams never clearly define the metric they are trying to improve.

They track spend. They review trends. They may even identify waste. But there is no single, agreed-upon measure of success that ties activity to business impact. Without that, FinOps becomes directionally helpful but operationally weak.

Yet, defining a metric sounds simple, but this is where most organizations stall.

It is not enough to say “reduce cost.” That creates local optimization and often the wrong behavior. Teams cut spend without understanding the impact on performance, reliability, or growth. It is also not enough to just track total cloud spend. That number moves, but it does not explain anything.

The metric needs to connect cost to something meaningful.

Start simple. For many teams, that may be something like cost per service or cost per environment. It does not need to be perfect on day one. As the program matures, the metric will evolve with it. In SaaS businesses, this often progresses toward cost per customer, cost per transaction, or cost per feature delivered. In AI systems, it may become cost per interaction or cost per inference. Those are more advanced states, and trying to start there can slow you down.

What matters more than the specific metric is how it behaves. Regardless of where you start or where you end up, it should be:

If those properties are in place, the metric will improve over time, and more importantly, it will start to drive better decisions.

With the metric in hand and leveraged, things begin to change. Reporting becomes more than a summary of spend. It becomes a way to evaluate decisions. Optimization is no longer about finding waste in isolation, but about improving the efficiency of the system as a whole. More importantly, ownership becomes clearer.

Teams can see how their decisions impact the metric. Tradeoffs become explicit. Conversations shift from “why is spend up?” to “what changed in the system, and was it worth it?”

This is where FinOps starts to move beyond Visibility Theater. Not because of better dashboards, but because there is now a shared definition of what good looks like. And that is what allows the framework described earlier to actually work.

Without a metric, FinOps reports on activity.

With a metric, it starts to influence outcomes.

AWS — AWS added scheduled email delivery for Billing & Cost Management Dashboards, making recurring cost reporting easier for finance and engineering teams.
https://aws.amazon.com/blogs/aws-cloud-financial-management/automate-aws-cost-reporting-with-scheduled-dashboard-email-delivery/

Google Cloud — Google Cloud updated billing administration so users with the right Cloud Billing permission can manage payment profile information directly in the billing console. https://docs.cloud.google.com/billing/docs/release-notes

Azure — Microsoft’s current Cost Management + Billing hub remains the main source for the latest Azure capabilities across budgets, anomaly alerts, reservations, savings plans, and cost allocation. https://learn.microsoft.com/en-us/azure/cost-management-billing/

Alibaba Cloud — Alibaba Cloud’s latest billing materials highlight real-time spend visibility, cost distribution, and improved bill analysis/export options for better reconciliation. https://www.alibabacloud.com/help/en/user-center/bill-view

Tencent Cloud — Tencent Cloud is steering long-running CKafka workloads from hourly billing to yearly/monthly subscription for more predictable cost control. https://www.tencentcloud.com/ind/document/product/597/68858

ServiceNow AI pricing change takes on enterprise ROI struggles — ServiceNow introduced new AI-inclusive pricing tiers, a useful signal for how major vendors are trying to simplify AI licensing and make spend more predictable.

• FinOps can manage AI computing costs, experts say — Good read on how FinOps is expanding beyond cloud into AI, SaaS, and licensing governance.

• IT’s budgetary nightmare: Tech buyers face AI pricing variance — Highlights the growing problem of opaque and variable AI pricing, especially as vendors move beyond classic seat-based licensing.

• Google launches Gemma 4, an enterprise-grade open source AI model set — Relevant from a licensing perspective because it underscores the growing role of open-source AI models and the governance tradeoffs versus commercial software.

• As AI drives up memory costs, is it time to rethink your device strategy? — Useful ITAM-adjacent read on how AI demand is pushing up hardware costs and why enterprises need tighter lifecycle management, procurement discipline, and asset optimization.

Company: CloudXray AI

Category: Managed Services & Consulting

What They Do: FinOps Consulting & Advisory Services; Owners & maintainers of the single largest FinOps company directory (finops.cloudxray.ai)

Why It Matters: Companies still need guidance on implementing FinOps and understanding the landscape of companies that exist

If you cannot map spend to a team or product, nothing else in FinOps matters. This is not a tooling problem. It is a data and structure problem. Here is how to fix it.

This is where cost per customer, transaction, or interaction becomes possible. But you cannot skip the earlier steps. They are foundational.

Most teams try to optimize cost before they establish ownership. That is backwards. First, make sure every dollar has a name attached to it. Only then can you expect behavior to change.