Still Being Invented: Larry "Fred FinOps" Advey on a Discipline That's Both Too Early and Already Past Cleanup

Walk the aisles at any FinOps conference this year and you will hear two contradictions whispered within ten minutes of each other. One camp insists the discipline has evolved past itself, that the label FinOps is already dated, that the work has moved on. The other camp, quieter, is still trying to explain what a cost allocation tag is to a finance team. Both are telling the truth. The market is running on a maturity spectrum wide enough to hold a seven-year-old allocation practice and a Fortune 100 still onboarding its first cost report, and nobody is comfortable saying so out loud.

Larry Advey has been sitting at both ends of that spectrum for longer than the category has had a name. Director of Cloud Platform and FinOps at CloudZero, FinOps Foundation Technical Advisory Council member, FOCUS maintainer, and the practitioner most conference regulars know simply as Fred FinOps, he was allocating cost across seven thousand databases at Marathon Petroleum in 2012, years before anyone called the work FinOps. His argument is that the discipline is not dying. It is still being invented.

Every community has its landmarks. Some are built from talks, some from frameworks. Larry's landmark is a Fred Flintstone hoodie, and the story behind it starts long before the first FinOps conference badge was ever printed.

The allocation system came first. The label FinOps came later, long before the discipline had a name for what Larry was already doing.

Q: Larry, let's start where everyone does. Who is Fred FinOps?

It goes back to my dad. He called me Fred growing up. When I met my wife, she picked it up from day one and introduced me to her family as Fred. That was eighteen years ago, and I am Fred to her entire family now. The FinOps part came later. I started going to FinOps X and other events and thought about what I could do to stand out and build a brand. I decided to start wearing a Fred Flintstone hoodie. When I was at Twilio, vendors would want to talk to me at conferences, and I would tell them: you will see me, I will be the one in the Fred Flintstone hoodie. People remembered it. I have eight of the shirts now. Coming up on three years in, Fred FinOps is a conversation starter and a reason to inject personality into a space that can otherwise feel like spreadsheets and dashboards.

Q: You have said you were doing FinOps before you knew it had a name. What were you actually doing?

I was at Marathon Petroleum, doing architecture work across data, applications, APIs, gateways, and critical infrastructure for more than a decade. Cost was always in the back of my mind. It is a nonfunctional requirement like any other. Around 2012 I built a system we called Hermes. It was a database tracking and allocation layer across seven thousand SQL and Oracle databases and the servers underneath them. I did not know it was FinOps. Three and a half years ago my director at Twilio sent me a link to finops.org. He had heard about it on a software podcast. I read it and thought: this is exactly what I have been doing. I jumped in, joined a working group, had no idea what I was doing, and forced myself to learn by showing up.

Most practitioners wear one hat and complain about the weight. Larry wears three at CloudZero, and the way he describes them says more about how he sees the discipline than any org chart could.

Platform, internal FinOps, evangelism. Three hats, one operating principle: the work gets better when practitioners teach each other.

Q: You wear three hats inside CloudZero. How do they hold together?

Technically, I am the Director of Cloud Platform. That team covers DevOps, developer experience, and platform capabilities across engineering. The second hat is FinOps. I run FinOps for CloudZero internally. The third is evangelism, which is where the strategic and thought leadership work sits. Evangelism means sitting on the FinOps Foundation Technical Advisory Council, maintaining FOCUS, going to conferences, and spending real time one on one with people who reach out through LinkedIn, the Slack channels, or the FinOps subreddit. In the last six months I have mentored a handful of people from DevOps into FinOps roles. A couple of them landed the jobs. That is the most rewarding part of the work.

Q: The FinOps community gets described as unusually collaborative. Does that match what you see?

Completely. I have tried Twitter, Reddit, and plenty of other technical communities. Most of them can turn on you if you ask the wrong question. I have never had that experience in FinOps. You can ask anything on the Foundation Slack or on a working-group call and someone will answer. FinOps Connect and FinOps Weekly are the same. At FinOps X it feels like Cheers. People know your name, or they know your work, and they are rooting for you. It comes from the fact that FinOps is genuinely hard and nobody has all the answers, so we end up solving it together instead of fighting over it.

There is a fashionable argument on the conference circuit that FinOps has evolved past itself. There is a less fashionable one, usually told more quietly, that most companies have barely started. Both arguments are made by serious people, and both cannot be right unless the market is stranger than either camp admits.

Crawl, walk, run. The market holds all three at once, and the discipline has to serve every stage.

Q: You have heard people say FinOps as it was a few years ago is dead. What is wrong with that framing?

I think it is absolutely false. I have talked to numerous companies over the last several months, startups and large brand-name companies people in this country would recognise immediately, that are still only now getting into FinOps. They are not post-FinOps. They have not started. There is enormous opportunity for people to come in at the ground floor and do this work. The idea that the discipline is finished says more about the speaker's bubble than about the market.

Q: And at the other end of the spectrum, where does the easy savings story run out?

It runs out fast. If you have never done workload optimisation before, you can cut cost meaningfully for a year, maybe two. Then you are operating. The capability has nowhere else to go. That is the moment FinOps either becomes a posture, or it pushes upstream into the architecture itself. You have to start asking what the system is built from and why, what the unit economics of the business actually are, and whether the tech stack you have is the right one for the cost per widget you want. Optimisation as a line item has a shelf life. Architecture does not.

Every few years the FinOps tool market goes through a phase of noisy consolidation, and every time it does, the same three questions resurface. What gets absorbed, what survives on its own, and what does a practitioner actually put on their desk the morning after the dust settles.

A toolbelt held together with string is not a platform. The vendors that win will pick a layer and go deep.

Q: There is a lot of talk about consolidation. Where do you think it actually lands?

The space got crowded fast, and competition has been good for everyone. It forced the tools to get better and it forced the hyperscalers to ship capabilities they did not have before. But there is a heck of a lot of overlap, especially in reporting and analytics, and a few recent acquisitions have already started to shake that loose. I expect more. Some of the earlier tools simply could not get past the early investment phase. Others are being absorbed because customers are asking for a single pane of glass instead of a toolbelt held together with string.

Q: When a company sits down to plan that pane of glass, what decision do they actually face?

Build, rent, or hybrid. And the answer depends on leadership and on how important the specific capability is to the business. Companies with strong analytics teams can build. Companies that need to move faster end up partnering and accepting a loss of control. Most end up somewhere in the middle. What I believe, and what I see working, is specialisation. Most vendors, including plenty in our space, try to boil the ocean. They do a little of everything and not much of it well. The ones that pick a layer, the commitment discount companies, the workload optimisation companies, the allocation companies, are the ones doing real work. The interesting question is whether anyone can combine a few of those deep capabilities into a platform without losing the depth that made them worth buying.

The original frame for FinOps was clean: cloud bills, cloud teams, cloud decisions. The frame has been cracking for a while. On-premises estates never went away, SaaS spend ballooned, and AI workloads arrived demanding their own allocation vocabulary. Larry argues the discipline is not gaining a neighbour. It is absorbing the neighbourhood.

SaaS, colo, data centre, AI. The word cloud is getting in the way, and practitioners are already past it.

Q: You have talked about FinOps needing to cover non-cloud estate. What does that actually mean in practice?

It means the word cloud is starting to get in the way. A lot of the companies I talk to, including the one I work for now, are being asked to apply FinOps practices to workloads that have nothing to do with a hyperscaler. That is SaaS, on-premises, data centre, colo, everything. Some of that conversation is happening inside the Technical Advisory Council right now. The framework needs to loosen its grip on cloud as the exclusive scope, because the practitioners on the ground are already past it.

Q: Is the market ready for that expansion?

Not yet. To pull it off you have to understand invoices on both sides, amortise on-premises commitments differently from cloud reservations, and reconcile two completely different cost models inside a single view. ERP systems have the data but they have never had the allocation and unit-economics layer FinOps practitioners need. A few platforms are starting to handle it. Most are not. The companies that figure it out first will unlock a total-cost-of-ownership view nobody has had before.

AI has arrived in FinOps from two directions at once. It is a workload being billed, and it is a capability being sold back to the practitioners managing those bills. Both sides of the conversation are moving fast enough that the discipline has not had time to decide which questions are the important ones.

Ten thousand in savings against hundreds of thousands in customer credits. The math only works when recommendations carry business context.

Q: You have said FinOps for AI smells a lot like SaaS. What do you mean by that?

It means we have been here before. SaaS cost and usage went through a painful maturity curve because the billing model was unfamiliar and nobody had a playbook. AI is going through the same thing now, just faster and louder. The usage patterns are strange, the models are expensive, and the organisations consuming them do not have historical instincts for what good looks like. OpenAI and Anthropic are the centre of that conversation, but every company spinning up AI workloads is running into the same maturity problem. It is not a new category. It is SaaS discipline applied to a new input.

Q: And AI for FinOps? Where is that today?

Interesting, early, and under-trusted. There is real potential for automation, but FinOps decisions are heuristic and high-consequence, and AI is a model-driven black box compared to deterministic code you can troubleshoot. Trust is the bottleneck. If a tool saves an engineer ten thousand dollars a month on an optimisation and it triggers an outage that costs the company hundreds of thousands in customer credits, the math does not work. You cannot unlock engineer adoption on savings alone. You have to tie the recommendation to the business context. What is the cost per widget. What is the risk. What is the unit economic impact. Without that context, the recommendation is just a number on a screen, and engineers have learned not to trust numbers on screens.

FinOps is not finished. It is early at one end of the market and out of easy wins at the other, and the work ahead is no longer about finding waste. It is about embedding economic judgement into the way systems are designed, vendors are chosen, and AI is deployed. The practitioners who thrive in 2026 will be the ones who stop optimising and start architecting.

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