Beyond the Dashboard: Rick Triana on the Real Work of FinOps

Ask most people what FinOps does and they'll say it saves money. Ask Rick Triana and he'll tell you that's the problem. Rick got into cloud financial management at Amazon before FinOps had a name, an acronym, or a Foundation. He moved through consulting, leading maturity assessments and standing up centres of excellence, before stepping into in-house practitioner roles. Along the way he became a FinOps Certified Professional, a FinOps Certified Instructor, and an active contributor to the FinOps Foundation, the global body that sets the standards the field runs on. His career has evolved the same way the discipline has: away from cost cutting, toward something harder to measure and more valuable.

Outside of work, Rick has logged over 400 scuba dives across a decade, including live-aboard expeditions on the Great Barrier Reef in Australia, where a week on a boat means five dives a day and very little else. Divers know that what you see from the surface and what you encounter at depth are entirely different worlds. Rick brings the same instinct to FinOps: most organisations are managing cloud spend from the surface. What the discipline actually demands, he argues, sits much deeper than a dashboard.

FinOps runs on influence, not authority. Every recommendation requires persuasion.

FinOps is an unusual discipline. The team that practises it does not own the infrastructure, does not control the engineering roadmap, and cannot force anyone to act on its recommendations. Engineers have to change how they build. Product teams have to reprioritise. Finance has to adjust its models. Nobody is required to listen. Everything runs on influence. That is the starting condition for every FinOps practitioner, and it is also why, according to Rick, culture is not a secondary concern. It is the primary one.

Q: You've practised FinOps in consulting and in-house. What is the biggest thing that separates a programme that works from one that stalls?

It's the cultural adoption. That's actually the difference between a successful and a failed FinOps programme. A lot of executive management hears the term FinOps and is generally supportive. But many times leadership is operating under the myth that FinOps is all about cost optimization and saving money. That's a problem, because FinOps teams cannot directly take action on the recommendations they surface. You have to work with engineering and business teams to realise any cost efficiency. And for that to happen, executive management needs to be deep enough in their support to rearrange priorities, to make teams carve out time and get involved. Without that, you have recommendations and no movement.

To lead FinOps effectively, you have to influence without authority. That takes a different skill set than most technical disciplines require.

Q: You've said that soft skills matter more than technical skills in FinOps. Most people would expect the opposite. Why?

There's persuasion, to get an engineer to act on your recommendations. There's presentation and communication skills, to tell leadership why we should prioritise certain activities. FinOps crosses every team in the organisation: finance, engineering, product, executives. None of them report to you. So you have to bring people along. That requires a completely different set of skills than reading a cost dashboard. I will argue that your soft skills, in many cases, are more important than your technical skill when it comes to FinOps or any of the intersecting disciplines.

Cost efficiency and cost optimization are not the same thing. The metric matters.

Most executives who fund a FinOps programme expect it to reduce the cloud bill. That is the wrong expectation, and it creates a problem that follows the FinOps team for years. Without the right framing at the top, every conversation about cloud spend becomes a cost-cutting conversation. Rick's own career arc tracks this shift in thinking directly, from his early days at Amazon to where he stands now.

Q: Your definition of what FinOps is trying to achieve has changed over the course of your career. What changed, and why does it matter?

When I first got into it, it was all about cost optimization and saving money. My entire focus has changed to cost efficiency and maximising the value of the cloud. What you're really trying to do is make every dollar efficient. That might mean the bill is going up, but you're more efficient than ever. The problem is when executives only care about savings, because that doesn't translate to the kind of support you actually need to run a real programme. You need leadership deep enough in their understanding to reprioritise teams and invest in the activities that create long-term value, not just the ones that generate a savings report next quarter.

Guardrail the cause. Don't just fix the symptom on repeat.

Most FinOps teams start the same way: they go after waste and house-cleaning. It is the right move early on. The effort is low, the risk is low, and the savings are immediate. It justifies the team's existence and builds executive credibility. The trap is what happens next. Many teams never leave this stage, clearing the same categories every quarter without ever addressing why it keeps coming back.

Q: You see a lot of FinOps teams stuck in a cycle of chasing the same waste over and over. What breaks that cycle?

Before you delete anything (the unattached volumes, the underutilised resources, the aged snapshots), you need to understand how you got there. Because if you don't learn what caused it and put guardrails in place, you're just going to be dealing with the same stuff a year from now. You could get stalled into perpetually operating in waste reduction if you don't understand the root causes and prevent them in the first place. That's what buys you time to work on the higher-value things.

Q: How do you get engineers to actually build those guardrails rather than treating it as someone else's job?

The lazier the engineer, the better the engineer. If there's a repetitive task, an engineer is going to get disinterested in doing the same thing over and over again. So what they do is they script and automate it. That's exactly what you need. Favour the proactive and preventative over just identifying and remediating. Once you start doing that, you stop manually chasing the symptoms and start building governance. That's the beginning of your shift left.

Map what you have before you buy what you think you need.

With the governance foundations in place, most FinOps teams turn their attention to tooling. The commercial FinOps tool market has grown significantly over the last several years: broad platforms, point solutions, governance tools, cloud-native options from the hyperscalers themselves. With dozens of overlapping solutions, making sense of what covers what is a real challenge. Before buying anything, Rick runs a specific exercise that most teams skip.

Q: You've developed a specific approach to evaluating tooling before you procure anything. Walk us through it.

A lot of companies think you buy one FinOps tool and you're done. But if you find a tool that does everything, there's a good chance it doesn't do everything well. What I've done is take an inventory of every tool already in the environment, including BI tools like Tableau and Power BI that people wouldn't normally call a FinOps tool. Then I map each one against all the capabilities in the FinOps Framework. That tells me exactly where my gaps are. Then I can make a targeted decision: I have coverage here, I have a gap there, I need a point solution for this specific problem. Most companies skip that step and buy a headline tool, then discover the gaps later. And for high-maturity companies, I think all the tool vendors of FinOps solutions can do better. That's actually the reason companies start building their own solution: the market isn't addressing their needs, and their requirements are specific enough that they have no choice.

Q: At what point does the economics of buying tooling stop making sense, and the build argument becomes stronger?

Most vendor models are priced as a percentage of your cloud spend. And generally, cloud bills are going to keep growing no matter how successful your FinOps team is, because what you're trying to do is make every dollar efficient, which might mean the bill is going up. So at some point, these tools become very, very expensive for what you get. You're paying a growing percentage of a growing number for a tool that still doesn't solve your hardest problems. And your own engineering resources are now at run level. They understand exactly what you need and could come up with a better solution in-house than going out and procuring one. That's when the build decision becomes not just technically better, but economically obvious.

AI workloads are arriving fast. The spend curves are not predictable.

AI has arrived in enterprise infrastructure, and it is arriving fast. For most organisations, AI workloads are not yet a major line item. For Rick, that is exactly the point. The teams that will be caught off-guard are the ones that are not modelling AI spend as a financial risk right now, before the bills land.

Q: You've described AI as a specific concern for FinOps practitioners. What's the risk you're seeing?

I see AI as a runaway freight train heading towards your cloud bill, with the potential of exploding it exponentially. That keeps me up at night. A lot of the conversation around AI is either uncritical enthusiasm or fear about job losses. What I do see, though, is a cost curve that organisations are not taking seriously enough. AI workloads are compute-intensive, they scale fast, and the bills are not always predictable. If FinOps teams are not building models and guardrails around AI spend now, they are going to be reactive when it hits.

Q: You've used AI tools for several years in your own work. Where do you draw the line between useful and risky?

I use AI for things I already know, to make me more productive. I get really annoyed when it gives me answers that I know from my expertise are obviously wrong. Those are hallucinations, and I've encountered real ones. So I am both a skeptic and a proponent. I use it predominantly to generate content I need to generate, in a quarter of the time it would take me otherwise, and to validate things I think I know but want to confirm. The thing I worry about beyond the cost risk is this: if you automate everything, you start degrading your own skills. You're ceding the things you're smart about to AI and becoming less capable over time. My next step is more automation, around MCP servers and report generation. But you do it with your eyes open.

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.