Beyond Housekeeping: Ben de Mora on Human-Centric FinOps, Real Unit Economics, and the AI Wild West

Most of the FinOps conversation happening right now is trapped in the housekeeping layer: rightsizing, commitments, rate optimisation, waste hunting. Ben de Mora has been quietly arguing for years that this isn't the work. It's the cleaning service. The real work, in his telling, is something most tools don't do and most programmes don't attempt: connecting cost to business outcomes in a way that lets leadership ask the only question that actually matters. He has watched the discipline evolve from panicked reaction to transformative capability, and his read on where it's stuck right now is the kind that makes vendors uncomfortable.

On video, Ben appears framed by a row of guitars, a reminder that before the Solaris, the Oracle data centres, and the FinOps career, there was a decade of blues. He will tell you the guitars mostly stay on the wall these days. What he will not tell you, but what the backdrop quietly suggests, is that the instinct behind both crafts is the same one: learning what makes a system resonate, and where the noise creeps in.

Six guitars, one recording setup, and a decade of blues. The instincts carry.

Q: Ben, to start, could you introduce yourself and share how you found your way into FinOps?

I'm Ben de Mora, and I've been working in the FinOps space officially since 2019. Over the years, I've worn a few hats: helping the FinOps Foundation build instructor programs and training, working with consultancies, and building FinOps practices at various companies as a hands-on practitioner. Today, I'm focused on developing strategic FinOps consulting services and working closely with clients.

Before FinOps, I was an engineer, an operating system specialist for Solaris and Linux prior to a data center engineer at Oracle. My background in enterprise engineering and systems thinking for large, complex environments turned out to be a great foundation for FinOps.

What excites me most is seeing how the discipline has evolved. It started as a panicked reaction to "Cloud is really expensive. What do we do?" and has grown into something transformative. Done well, FinOps reveals how a business truly operates and empowers people across different roles to improve outcomes using data. At its core, it's about people, relationships, and collaboration, which is why I see it as a human-centric discipline.

Ask a developer why cloud is better than on-prem and you'll hear about speed, agility, and elasticity. Ask a finance leader why their cloud bill grew forty percent year over year and you'll hear silence, followed by blame. The gap between those two answers is the ground FinOps has to hold, and the reason, as Ben tells it, that it can't just be another engineering practice.

Cloud removed the friction. What it didn't remove was the need to ask the right questions.

Q: You call FinOps human-centric. How is that different from disciplines like DevOps or DevSecOps?

DevOps and DevSecOps are engineering practices. They live in the engineering space. Finance needs to know they exist, and Product groups may benefit, but they don't have to engage deeply. It's largely self-contained.

FinOps is different because cloud changed the game. The speed of deployment removed the old friction that masked organizational misalignment. In the on-prem world, six months to order and rack hardware forced planning and collaboration. Today, you can spin up a VM before finishing the sentence. That instant gratification is powerful, and risky. Like an Amazon impulse buy, it feels good now, but a week later you wonder if you needed it.

Cloud makes it easy to skip hard questions: Do I need this? Is it fit for purpose? In the old model, big upfront costs demanded diligence. Now people say, "I'll turn it off later," but later rarely comes. Meanwhile, costs tick up. £250 a week doesn't sound like much until it's hundreds of workloads, every week.

The result? A disconnect between "I want it now" and "What value does it deliver?". Businesses see the bill growing faster than expected and default to "make it cheaper." But cost without context is meaningless. FinOps brings engineering, finance, product, and leadership into one conversation about value, not just spend. That's why it's fundamentally human-centric.

Every executive presentation on cloud efficiency eventually reaches for the same slide: one number, usually a dollar amount, divided by one unit, usually a transaction. It's what leadership asks for, it's what vendors promise, and it lands cleanly in a board deck. It is also, in Ben's experience, where the conversation most often goes wrong.

The slide everyone asks for. The one that hides where the money actually goes.

Q: When you sit down with organizations and ask whether they're getting value from the cloud, is there a "secret sauce" for measuring operational and cost efficiency?

There's no universal blueprint. Every business has its own delivery model, demand patterns, and constraints. But there is a universal idea I push hard: understand your delivery metrics and your unit economics over time.

Unit economics gets thrown around a lot, but the moment someone tells me "our unit economics is five widgets per dollar" and hands me a single number, I know they're not looking deeply enough. Take an airline booking company that tracks "cost per ticket booked" and divides last month's cloud bill by total tickets. Sounds neat, until you factor in demand variability. People don't book evenly across hours, days, or seasons. At peak, your infrastructure might be highly efficient, four cents per ticket. Off-peak, if you don't scale down, you might be paying three dollars per ticket. That variance matters.

So I want to see not just the average unit cost, but how it moves over time. "Ten cents per ticket, plus or minus 50% over a week" tells me you're somewhat elastic, but not fully. Then dig deeper: where's the rigidity? Maybe your front-end scales beautifully, but your database is a static, expensive backend. Maybe your stack just sits there, day and night, regardless of traffic. That's where engineering effort should go.

This logic applies everywhere, whether you're booking tickets, processing video, or delivering roadside assistance. The essential questions are: What do we deliver when customers show up? What do we leave running when nobody's there? How do those states differ over time?

Answering that is hard work. It demands context: your architecture, demand patterns, and business priorities. But that's the path to real efficiency.

Most FinOps programmes are measured on savings. It's what leadership funds them to do, it's what quarterly reviews are built around, and it's what the vendor tooling is designed to surface. So when an organisation is still reporting the same kind of savings in year seven that it reported in year one, that should probably trigger a question. To Ben, it triggers a diagnosis.

Cleaning services are valuable. They are also not strategy.

Q: What foundational steps must an organization take before it can measure unit economics effectively?

You need spectacularly clean, sensible cost and usage data. That means keeping house really well.

Notice I haven't talked much about waste, rates, or commitments. That's because they're not the heart of FinOps. They're housekeeping. Deleting obvious waste, turning off idle resources, rightsizing, and buying commitments are table stakes. They're valuable and relieve short-term budget pressure, but if that's all you do, you'll be stuck doing it forever.

Think of it like paying a cleaner. If you never learn to tidy for yourself, the moment you stop paying, the mess returns. A lot of FinOps tooling and "cost-out" work is like that: cleaning services, not strategy. Useful, but it doesn't change how the business thinks about and uses cloud.

Walk the floor at any FinOps trade show and you will see variations on the same slide: a cost chart, a rightsizing list, a commitment recommendation, and a satisfied-looking ROI figure. Every vendor's demo hits the same beats. Ben has been inside enough of those rooms, and enough customer environments, to know what those slides consistently fail to show.

Numbers without stories. Dashboards without decisions.

Q: Most of the tooling market seems to live in that housekeeping space. What's your view of the current vendor landscape, and what's missing?

Most vendors focus on dashboards, "quick wins," rightsizing lists, and commitment recommendations. Useful, but there are two big gaps.

First: Business context. Tools give you numbers, not the story behind them. You get a rear-view mirror without the why. A spike in spend looks like a disaster, until you know you streamed the Super Bowl and made a fortune. A perfectly optimized workload looks great, until you discover it supports a product nobody wants. Data alone is a narrow slice. We need tools that connect cost to business outcomes so you can ask: "How healthy is my cloud business proposition?", not just "Am I leaving VMs on?"

Second: Integrated modeling. Cloud cost = usage × rate, but tools treat these as separate levers. Usage engines assume commitments won't change; commitment engines assume usage won't change. Then they show "savings" from both, even though you can't realize both sets simultaneously. What's missing is scenario modeling: "If I achieve part of your rightsizing recommendations, what should my commitment profile look like, and when do I break even?" That's the next frontier: tools that move beyond housekeeping to strategic insight.

The loudest claim in cloud economics right now is that AI will transform how organisations manage spend. The quietest admission, among practitioners who have actually looked, is that cost management has not yet figured out how to measure AI. Ben is one of the few willing to say so out loud.

Everyone is measuring AI. Almost nobody is measuring what matters about it.

Q: And then, there is the AI disruption. How does AI change the FinOps and unit economics conversation?

With traditional cloud workloads (say an airline booking system), you can tie resource usage to customer transactions. A customer follows a known path, services run, a ticket pops out, and you can reasonably say: "We earned this much and spent that much."

AI breaks that logic. There are countless variables you don't control or even see: Which provider? Which model? Has it changed since yesterday? What's in the hidden system prompt today? Those prompts are huge and evolving, and complexity brings unpredictable side effects. I've seen the same prompt produce brilliant output one day and gibberish the next. Yesterday's good prompt might fail tomorrow.

Model choice adds more uncertainty. Different models have different reasoning and hallucination profiles, yet most users just pick the latest and biggest, often the worst fit. Then there's user behavior: people anthropomorphize AI, assuming it understands intent and context. Non-experts burn through tokens chasing the right answer, generating floods of irrelevant output.

So when you ask: "What's the unit economics of my AI usage?" traditional ROI logic falls apart. At best, you can track crude metrics like "tokens per dollar," but more tokens (or cheaper tokens) don't guarantee more value.

I'd love to be proved wrong, but today, measuring AI ROI accurately is close to impossible.

Most disciplines accumulate jargon as they mature, and FinOps has had an unusually productive five years: unit economics, allocation, shift-left, anomaly detection, effective savings rate. Ben believes all of it exists in service of a single, older question that does not require any of that vocabulary to ask.

The oldest question in business, rediscovered at the end of every FinOps conversation.

Q: To close, if you had to boil all of this down, what is the core question FinOps should help answer?

For me, it comes back to a very old, simple business question: "Am I making any money from this, and could I make more?"

Everything else (unit economics, elasticity, context, tooling, AI, commitments versus usage) exists to help you answer that better. If all you ever do is housekeeping, you spend your life polishing things without asking whether they deserve to be polished.

FinOps, done well, moves you beyond "make the bill smaller" and toward proving and improving the value of what you're doing in the cloud.

Ben de Mora's argument is the hardest one to accept because it implicates both the vendors selling FinOps tools and the practitioners running FinOps programmes. If the work you're doing is housekeeping, call it housekeeping. Don't pretend the rightsizing list is strategy. The organisations that will matter in the next phase of the discipline are the ones that invest in business context, unit economics over time, and honest conversations about whether the cloud workload they just optimised is actually generating value.

For senior leadership, the question Ben plants is uncomfortable and inescapable: if your FinOps programme is disbanded tomorrow, would anyone in the business be able to tell you whether cloud is making money? If the answer is no, the programme hasn't started yet.

The perspectives expressed reflect the interviewee's personal experience and views. Cloud Value Lab publishes practitioner-led thought leadership at the intersection of FinOps, GreenOps, and AI Economics.