Navigating the FinOps Landscape: Jason Kelly on the Communication Gap That Separates Good Programmes from Great Ones

Most FinOps programmes today operate on the assumption that the hard problem is visibility. If teams can just see the data, the decisions will follow. Jason Kelly has lived at the scale where that assumption breaks. Managing close to $700 million in annual cloud spend across multi-cloud environments, he has watched organisations surface every metric imaginable and still make the same mistakes. His conclusion is uncomfortable for a tooling-obsessed industry: the biggest challenge isn't data access anymore. It's communication and education. And no dashboard can fix that.

Most FinOps conversations begin with a question about tooling. Jason's begin somewhere else entirely. To understand why, it helps to know where he has been, and what kind of scale teaches a practitioner to stop trusting the dashboards.

Two dictionaries. Two professions. One bridge nobody built.

Q: Jason, thank you for joining us. Could you start by sharing a bit about your background?

Absolutely. Currently, I work at a health data company that handles a massive amount of transaction volume. Before this, I was in consulting with major enterprises, helping them navigate the shift from CapEx to OpEx and modern cloud operating models. Previously, I also worked at Global Tech companies, part of teams when at some point, we were managing close to $700 million in annual cloud spend across large-scale, multi-cloud environments. I've been involved in FinOps since before it was even called that, and I'm a FinOps Certified Trainer.

Q: With such extensive experience, what do you see as the primary challenge in FinOps today?

The biggest challenge isn't data access anymore; it's communication and education. Most organizations can surface costs, recommendations, and usage metrics out of the box. The problem is getting stakeholders to ask the right questions. They often ask the wrong questions, like "What does cloud cost?" when they should be asking about the P&L for specific products or environments and how those tie to roadmaps. There's a significant vocabulary gap between finance and engineering teams that needs bridging. Finance teams often think in terms of depreciation schedules and unit costs from the data center world, while engineering might assume, "we bought it, so we'll use it," which doesn't translate cleanly to elastic cloud resources.

If communication is the bottleneck, the natural follow-up is: how do you actually fix it? Most answers reach for new processes, new committees, new training programmes. Jason looks for a precedent instead, and finds it in a discipline that solved a remarkably similar problem one cycle ago.

The arrow points one way. Towards design, not cleanup.

Q: How do you suggest overcoming this communication barrier?

Education is key. We need to develop a cloud vocabulary of 100–200 words that everyone understands so teams can frame problems precisely and get actionable answers. It's about shifting the culture so that FinOps becomes an ingrained consideration, much like security has over the past decade. We should aim for "efficiency by design" rather than post-deployment cleanup. In practice, that means shifting left: solving cost and efficiency concerns in code, building with cloud-native services, and reinforcing patterns that make systems more resilient and efficient by default. Dashboards alone don't fix this; teaching people how to interpret and act on the data does.

The FinOps tooling market has exploded, and Jason's view of most of it is unsparing. Hyperscalers now ship capable native dashboards for free. Meanwhile, third-party vendors lock customers into rigid frameworks and multi-year contracts for capabilities that mature teams eventually outgrow. His assessment is the kind that vendors don't want to hear, and experienced practitioners know is true.

Dashboards everywhere. Decisions, not so much.

Q: How do you assess the current state of FinOps tools?

The market is oversaturated with duplicative tools. Five could have launched during this conversation. Cloud providers now offer comprehensive native solutions, like AWS's open-source Cost Intelligence Dashboard on QuickSight and GCP's Billing usage and cost insights dashboard in Looker. Azure also provides strong built-in recommendations and FinOps views. Many third-party tools lock customers into rigid frameworks and five-year contracts. They can be fine for small to midsize organizations starting out, but as needs get more nuanced (mapping spend to products, environments, and business outcomes), companies eventually question the value of these expensive "glorified dashboards" compared to investing in engineers who can tailor solutions to their exact questions.

Every FinOps practitioner eventually has to answer a structural question: how do you get teams that don't report to you to do something they were never measured on? The wrong answer is what ruins most programmes. Jason has watched it ruin enough of them to have a strong view about the right one.

The shortest path to engineering buy-in is making them look good.

Q: What strategies do you recommend for collaboration between teams?

For engineering teams, it's about speaking their language (efficiency, fault tolerance, stability) and making them look good, not positioning FinOps as the cost police. There are always engineers who want to do the right thing; they need guidance and the organizational priority to act. Celebrate wins, embed best practices in pipelines, and frame choices as trade-offs that improve resilience and customer experience, not just cost. With finance teams, it's crucial to explain why cloud costs are initially higher (often you're running data centers and cloud in parallel), and show them new possibilities through reports and dashboards that connect spend to product performance and roadmap decisions.

The classic engineering tradeoff applies to cloud economics just as ruthlessly as it does to project management. Leaders who understand this build programmes that earn a seat at the priority table. Those who don't end up firefighting the same cost overruns year after year, because the underlying design never gave efficiency a chance.

Pick two. The third one was never on the table.

Q: Many leaders worry about trade-offs among speed, uptime, and cost. How do you address that tension?

The classic iron triangle applies: you pick two among speed, functionality/agility, and cost. The goal isn't to make engineering obsess over dollars; it's to give leaders clear visibility into the pile of money we're effectively setting on fire with inefficient patterns, and then help teams choose designs that improve reliability and efficiency with acceptable delivery timelines. When efficiency is framed as stability, performance, and fault tolerance, it earns a seat at the priority table. Over time, efficiency by design reduces firefighting, shortens incident windows, and creates headroom for innovation.

The build-versus-buy debate in FinOps is older than the term FinOps. It almost always gets framed as a cost calculation. Jason frames it differently, as a question about organisational maturity, and about what the buying decision actually signals.

Mature teams build what they finally understand. The market never catches up.

Q: How should companies think about building vs. buying tools as they mature?

For small companies, out-of-the-box tools are fine for the first few years. Keep contracts short and lean on knowledgeable FinOps account managers when available because that expertise accelerates learning. As organizations mature and understand their cloud environment more deeply, transition to homegrown solutions tailored to your taxonomy, unit economics, and planning cycles. Tools can exacerbate people problems by further obfuscating issues, so it's essential to build a solid understanding first. I rarely see mature teams that build well in-house want to go back to generic tooling.

The highest maturity state for a FinOps programme is invisibility. Not in the sense of being forgotten, but in the sense of being embedded so thoroughly into how work gets done that teams no longer frame it as a separate discipline. Jason's closing guidance is the kind that tells you immediately whether a practitioner has lived at scale or only theorised about it.

The trophy goes to the team. The practice disappears into the work.

Q: Any closing guidance for teams at different stages of the journey?

Start by aligning vocabulary and questions across finance, product, and engineering. Tie spend to business outcomes at the product or environment level. Embed cost-aware patterns into code and CI/CD so teams don't rely on cleanup cycles. Measure progress not just by savings but by improved reliability, faster learning loops, and clearer decision-making. Ultimately, FinOps succeeds when it fades into how work gets done, when efficiency is part of the design process and teams are rewarded for it. The key is influencing without authority and making other teams look good so the behavior spreads culturally.

Jason Kelly's career has straddled the exact transition the industry is still navigating: from a world where visibility was the bottleneck to one where it's the baseline. In that new world, the practitioners who will matter are the ones who invest in language, culture, and engineering collaboration before they invest in tooling. They measure success not by the savings they report, but by how thoroughly efficiency becomes invisible inside the design process.

For senior leadership, the implication is clear: if your FinOps programme is still measured primarily in dollars recovered through post-deployment cleanup, you are operating a first-generation model. The next frontier is cultural, and the returns compound across reliability, velocity, and cost simultaneously.

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.