FinOps wants to become a discipline, but most teams are still a heroic side quest

An article inspired by Anderson Oliveira and Harry Potter's studios

The context

Yesterday, at the Harry Potter Studio Tour in London, I found myself staring at a marble column in Gringotts Bank.

Not real marble, of course. A fake marble effect, built with an excruciating level of detail, the kind that makes your brain do a little wobble. Someone had invented techniques, materials, and workflows just to make a column look like it belonged in that world.

And the thought that hit me was not “wow, movies are cool”. It was simpler:

This is delegation at scale.

No director, however brilliant, decides how every column looks, how every costume hangs, how every wand feels, how every prop ages, how every set is lit, and how every scene is stitched together. The project is too big. The detail is too deep. The only way it works is with clear roles, clear ownership, and a production system that can coordinate hundreds of specialists without melting down.

Then I came back to FinOps, and I realised we’re still trying to make one person do the entire film.

The heroic FinOps practitioner problem

FinOps fails when it becomes a heroic attempt by one person.

Even when it’s a team, it fails when that team doesn’t have the shiny armour of a mandate: a commission, an objective, an explicit scope, and the authority to build the foundations underneath.

Without that, the FinOps team is left holding a fort. They do their best. They publish reports. They chase anomalies. They nudge engineers. They talk to finance. They try to keep everyone happy. They become diplomats and analysts and project managers and therapists.

It looks busy. It looks brave. It often has very little impact.

Not because the people are wrong. Because the operating model is wrong.

We forgot something obvious: we are not the first initiative in the company. We are just one of many. And far more complicated things have been done before, using methods, tools, and specialisms that already exist.

This is the real lesson of this article

This article is not a sermon about Earned Value Management.

EVM is just the example.

The lesson is this: borrowing existing systems is usually more efficient than trying to force our new, theoretical FinOps systems onto everyone else.

Better still, borrowing systems lets you borrow the people who already know how to run them.

Why dashboards keep failing

Here’s a familiar scene.

A FinOps team is proud of a dashboard. A beautiful dashboard. A dashboard with charts, filters, colours, and just enough numbers to impress other FinOps people.

They show it to leadership expecting fireworks.

Nothing.

I saw this clearly when I was working with the University of California San Diego. We were showing the CIO our newest Kudos dashboard, expecting it to become a daily instrument, something leadership would check, share, and use.

The reality: most people didn’t log in. If they logged in at all, it was once every three months.

So every monthly meeting we restarted from scratch. The dashboard didn’t create decisions. It didn’t create actions. The only people watching it were us, the builders of the dashboard.

That’s not a tooling failure. That’s a decision-format failure.

Most cloud dashboards answer: “Here’s what you spent.”
Executives already have that. It’s called an invoice.

What they need is: what’s good, what’s bad, are we winning or losing, what trade-off do you want me to make, and what happens next?

If you can’t answer those five things, you don’t have a dashboard. You have wall art.

The villain, in plain terms

My villain is the FinOps bubble.

FinOps started (and I include myself here) as people trying to do the right thing in a world where cloud spending arrived through marketing, innovation, and a certain flavour of shadow IT.

But cloud is not like buying servers.

By design, there is no real limit on how much you can spend. The default state is unlimited. That’s not a bug. It’s a feature. And if we’re being honest, cloud vendor systems are designed in their own way to be absolutely logical at extracting as much money as possible from their users. Growth and profitability are the point.

If you treat that environment as if it will self-govern through goodwill and dashboards, you’re playing chess with someone who brought a slot machine.

What “top-down FinOps” changes

Top-down FinOps is not about persuading executives to “care about cloud”.

It’s about recognising that executives already run the company through decision systems, and FinOps must fit those systems.

Upward management should not be about begging for an executive sponsor so they can proxy some of their power to us.

What we want is clarity and delineation.

We want a well-defined sandbox: a clear perimeter in which teams can play without fear, be creative, and build value, while the company remains safe.

A cloud sandbox (the definition I actually mean)

A cloud sandbox is a well-defined perimeter in which you can play without any fear and you can be as creative as you want.

But it is also a boundary. A constraint.

In the old world, constraints were natural. Finance decided a budget. IT bought equipment for five years. Developers built within what existed. If you ran out, the story was simple: “We are successful, we need more capacity, approve more budget.”

Cloud removed that constraint. Engineers became financially unconstrained by default. They can claim it’s because we “adapt to the business”. Sometimes that’s true. Often it’s just drift, optimism, and growth assumptions that never get revisited when the business slows down.

And this matters because the CEO’s job is survival. Endangering survival through uncontrolled spend is not “innovation”. It is negligence with better branding.

The CTO mandate I want to see

A CTO (or someone in their team) should stop hiring one FinOps person and hoping it magically becomes a programme.

A CTO should start a FinOps initiative spanning at least a year, possibly three, with clear objectives, explicit constraints, and the same seriousness as other strategic initiatives.

FinOps is not “a person”. FinOps is a company capability.

And capabilities are built like programmes.

The missing capability: programme management inside FinOps

Here’s the part I think we’re only just starting to learn.

FinOps is missing project and programme management capabilities.

Not as a “stakeholder”. Not as someone you occasionally inform. As an allied persona. A real part of the delivery engine.

Because coordination is full-time work.

Right now we overload the FinOps practitioner. We ask them to do cost truth, modelling, education, stakeholder diplomacy, governance design, prioritisation, action tracking, escalation, and sometimes the emotional labour of convincing everyone that this matters.

Most FinOps practitioners do not come from a project controls background. They come from engineering, operations, analytics, procurement, finance. They’re brilliant at FinOps content. They’re not necessarily trained to run cross-functional delivery at scale.

So we end up with part-time delivery management, which is another way of saying: delivery doesn’t happen.

This is why borrowing matters. When you borrow a proven management system, you don’t just borrow a set of metrics. You borrow a set of roles and a coordination method.

Harry Potter, mapped to FinOps (yes, I’m going to milk this)

Executive Producer: the executive. Sets the direction, funds the thing, owns the risk.
Producer: the programme manager. Runs sequencing, timing, and coordination.
Director: the FinOps lead. Holds the narrative of “what good looks like”, and keeps the story coherent.
Screenwriter: the framework. The structure of scenes, the order, the logic.
Concept artist: senior engineers. They turn intent into viable designs, standards, and patterns.
Crew: engineering teams, finance partners, procurement partners, platform teams.
Editor: product ownership and leadership triage: cut what doesn’t matter, keep what moves the story forward.

Today, FinOps often tries to be the director, producer, and the entire crew, while also being asked to write the script in real time.

No wonder we burn out. No wonder we get dashboards that nobody reads.

Where Earned Value Management comes in (the example, not the religion)

This is where I like Anderson Oliveira’s work on FinOps EVM.

It’s not because EVM is magical. It’s because it’s familiar.

EVM is a project management control method that connects plan, actual spend, and delivered value. It gives you a language executives already understand: planned value, earned value, actual cost, and the indices that show whether you’re earning value efficiently.

Anderson’s twist is the important FinOps move: tie “percent complete” to unit economics, so “earned” reflects value, not effort.

That matters because it turns cloud conversation from “did we spend more or less than last month?” to “are we earning what we planned for what we spend?”

Now the real payoff: once you adopt something like EVM as a decision tool, you can onboard programme management into FinOps delivery without asking everyone to learn a new FinOps dialect.

You’re using a language they already speak.

From dashboard to decision brief

If you want to change behaviour, stop shipping dashboards and start shipping decision briefs.

The executive-friendly output is one page:

1. Intent (one sentence)
2. The sandbox (what’s in scope, what’s out)
3. Plan vs actual vs earned (however you measure earned)
4. What’s good, what’s bad, what changed
5. The trade-off options (A/B/C)
6. One decision request, one owner, one next step

That’s it.

If you can’t point to the decision, you are not doing executive communication. You are doing analytics theatre.

And this is where top-down FinOps becomes real: executives make trade-offs, accept constraints, and create the perimeter in which the levels below can execute safely.

What “good” looks like in six months

Good looks like this:

FinOps is treated as a standard long-term initiative, not a person.
There is a brief. There are objectives. There is a cadence. There is an executive sponsor because the programme requires one by design.
Procurement is brought back in with real alternatives and a seat at the table, not only a contract-signing cameo.
Finance is not watching from the sidelines: they have a way to make savings show up in the P&L, because that’s the only place executives truly believe they exist.
A programme manager is running the choreography: updates, sequencing, dependencies, and delivery tracking.
FinOps leads are the experts and narrative holders: they set the order of execution, define what “earned” means, and translate cloud reality into decision language.
Engineering managers execute within constraints that are explicit, not implied.

This is not bureaucracy. It is maturity. It is the compounding of knowledge, skills, and capabilities into something that makes the company shine.

A firm critique of cloud, while we’re here

Cloud removed constraints. Leadership now has to find new ways to reapply constraints that are smarter than the old ones.

And we need a dose of humility: cloud doesn’t need more dashboards, it needs humility.

Also, let’s be honest about another uncomfortable truth: cloud is still an experiment, service by service. Some services are mature commodities. Many are not. Every new service is a product at a particular stage of maturity, and whoever adopts it is experimenting too.

If we treat experimentation as production, we get financial risk disguised as innovation.

That is not a technical problem. It is a leadership problem.

Closing

The real upgrade is not EVM. The real upgrade is delegation at scale.

Stop building FinOps as a one-person film studio. Stop hiring heroes and hoping for miracles. Start funding a programme with a mandate, a sandbox, and a delivery engine that matches the size of the risk.

Borrow the systems that already work. Borrow the roles that already exist. Then let FinOps do what it is meant to do: help the company make better decisions about money and cloud, before the invoice becomes the strategy.

“Cloud removed constraints. Leadership’s job is to replace them with better ones.” - Frank Contrepois