A while back I had a great conversation on the FinOps on Azure podcast with Frank Contrepois about top-down FinOps — how organisations that start with an executive mandate tend to approach cloud cost management differently than those that grow it organically from the engineering side. It was a conversation that stuck with me.
Recording: https://www.youtube.com/watch?v=W05lMKfGAUg
Then a few weeks later I was driving home from the pub, and for some reason the TV show Silicon Valley popped into my head. Specifically the middle-out compression algorithm — Richard Hendricks’ controversial, nobody-believes-it-can-work idea that turns out to be the thing that changes everything.
I won’t pretend I had a Richard moment (if you’ve seen the show, you’ll know exactly what I mean and why I’m relieved). But I did think: actually, that’s what FinOps looks like in most organisations. It starts top-down or bottom-up, but the moment a FinOps practitioner enters the picture, it very quickly becomes something else entirely. It becomes middle-out.
What is Bottom-Up FinOps?
Bottom-up FinOps is the engineer-led story. It usually starts with a surprise. A platform team opens the monthly invoice and the number is significantly higher than anyone expected. Someone starts digging. They tag a few resources, build a Cost Management dashboard, and realise the problem is bigger — and more distributed — than they thought. They write a doc, raise it with their manager, and gradually the savings evidence bubbles upwards through the organisation.
The defining characteristic of bottom-up FinOps is that it starts with data and tooling, not with a mandate. Nobody told the engineer to do this. They did it because they’re the ones closest to the problem and they care about doing things properly.
The limitation is equally defining: an engineer can optimise their own estate. They can right-size the workloads they own, clean up the orphaned resources in their subscription, and maybe even influence the team next to them. But they cannot force another team to change its deployment patterns. They cannot renegotiate the EA agreement. They have no lever on the business unit that keeps spinning up production-scale environments for proof-of-concepts. Without organisational authority, the initiative will plateau.
What is Top-Down FinOps?
Top-down FinOps is the CFO or CTO story. Cloud costs hit the P&L in a way that triggered a conversation in a board meeting, or an auditor flagged it, or someone ran a benchmark against industry peers and the number looked embarrassing. The result is a mandate: we need to reduce cloud spend by 20% this year.
Someone gets appointed — sometimes a dedicated FinOps hire, sometimes a finance analyst seconded to the IT team, sometimes a platform engineer who drew the short straw. They have authority. They have a target. They have a exec sponsor they can point to when engineers push back.
The limitation is the mirror image of bottom-up. This person has authority but no relationships. They arrive into a complex organisation where engineering teams have their own priorities, their own OKRs, and a healthy wariness of anyone who turns up with a spreadsheet and a mandate to change how they work. Authority without trust moves slowly. And moving slowly when you have a year-end target to hit is how FinOps hires burn out.
“Authority without trust moves slowly. And moving slowly when you have a year-end target is how FinOps practitioners burn out.”
The Middle-Out Moment
Here’s what I think actually happens. Whether the initial trigger is top-down or bottom-up, the moment a FinOps practitioner — a real one, not just someone handed a cost dashboard — arrives in the organisation, the dynamic changes. Almost immediately, they find themselves doing something that is neither top-down nor bottom-up. They’re working in both directions simultaneously, across multiple teams, on multiple timelines, with multiple definitions of success depending on who you’re talking to.
That is middle-out FinOps. And I’d argue it’s the only model that actually works at scale.
In the show, the middle-out compression algorithm was controversial because nobody could quite believe a small team working from the middle could outperform the giants who owned the top and the bottom of the stack. FinOps practitioners will recognise that feeling immediately.
What Middle-Out Actually Looks Like
The FinOps practitioner in middle-out mode is running several conversations at once, none of which wait politely for the others to finish:
None of these conversations happen sequentially. The FinOps practitioner is not finishing the engineering conversation before starting the procurement one. All of these are in motion simultaneously, each moving at its own pace, each requiring a different vocabulary and a different frame.
The Squeezed Middle Problem
A common thing I hear from FinOps practitioners is a variant of: “I’m being pushed from above and pulled in six directions below, and I don’t know which one to focus on.”
The executive wants the number to move. The engineers don’t want another process imposed on them — they’re already juggling a sprint backlog, a production incident backlog, and a growing list of technical debt. The finance team wants reports in a format that makes sense to them, which is rarely the same format engineering works in. Procurement wants a 6-month usage forecast that no one in engineering will commit to.
This is the squeezed middle, and it’s not a sign that FinOps has failed. It’s a sign that FinOps is actually working — because the alternative is a FinOps function that only talks to one of these groups, which means it isn’t really doing FinOps at all.
The practitioners who navigate this well tend to do two things. First, they get very clear on what each stakeholder actually needs from them — not what they say they want, but what would constitute success in their world. Second, they become ruthless about prioritisation. Not every needle needs to move this week. Which one, if it moved, would have the biggest downstream effect on the others?
Does Middle-Out Scale?
I think middle-out is a permanent operating model, not a transitional phase. But what it looks like changes as the organisation matures.
In the early stages — the FinOps Foundation’s “crawl” phase — the FinOps practitioner is actively brokering every conversation. They’re the ones running the cost review, writing the tagging policy, building the showback reports, sitting in the procurement meeting. The centre of the middle-out model is genuinely centralised.
As the organisation matures towards “walk” and “run”, the centre shifts. The FinOps practitioner’s job becomes less about doing the work and more about establishing the infrastructure — the processes, the tooling, the shared language — that lets each team do their own FinOps. The middle-out model doesn’t disappear; the centre becomes thinner, and the edges get stronger.
At genuine FinOps maturity, the “middle” is mostly a coordination function — making sure the edges are speaking the same language, aligning on shared objectives, and raising flags when a local optimisation in one team creates a cost problem in another. That’s still middle-out. It’s just quieter.
Moving Many Needles
We talk a lot in FinOps circles about “moving the needle” — as if there’s one lever, one metric, one conversation that needs to happen. The phrase implies a single direction and a single stakeholder.
Middle-out FinOps is the recognition that your job is closer to air traffic control than to sprinting. You’re not racing towards one finish line. You’re coordinating multiple aircraft, on different flight paths, at different altitudes, all of which need to land without hitting each other.
The organisations that build sustainable FinOps practices are the ones that accept this. They hire for it — for people who can context-switch between a conversation about unit economics with a VP and a conversation about Kubernetes node pools with an SRE. They build for it — tooling that gives every stakeholder the view they need without requiring a FinOps analyst to produce bespoke reports for each one. And they measure for it — tracking progress across multiple dimensions, not just the headline spend number.
The organisations that struggle are the ones that keep trying to make FinOps simpler than it is — appointing someone with a single mandate, measuring success on a single metric, and then wondering why the savings don’t stick after the first quarterly review.
Middle-out is harder to describe in a strategy document than top-down or bottom-up. It doesn’t have a clean origin story — no single budget breach that triggered it, no single executive mandate to point to. It emerges when a good FinOps practitioner arrives, starts having the right conversations, and gradually makes themselves indispensable to enough parts of the organisation that the function becomes genuinely embedded.
That’s not a weakness of the model. That’s exactly how sustainable change works.
