Inside Google’s FinOps Revolution: Pathik Sharma on Agentic AI and Cloud Efficiency

Chapter 1 — Intro: Meet Pathik Sharma

Kevin: Hello and welcome back to Unclouded, the Agentic AI FinOps podcast by Cloudgov.ai. I am your host Kevin Rosenquist. Thanks for joining me today. My guest is Pathik Sharma, cloud FinOps optimization lead at Google Cloud. Pathik helped build Google Cloud’s FinOps practice from the ground up and has guided over a hundred companies toward smarter, more efficient cloud spending. He saved organizations lots of money, led some of the biggest FinOps workshops in the world, and somehow still finds time to draw FinOps sketchnotes that make complex ideas actually make sense. So let me introduce him. Hello, Pathik. How are you?

Pathik: Hello. Hello, Kevin. Glad to be here.

Kevin: Yeah, thanks for being here. Excited to chat with you. A lot of companies say they’re doing FinOps, they’ve got dashboards, they’ve got reports, they’ve got alerts, but the costs still get out of hand. Why does this happen? And what separates teams that actually fix it from the ones who just sort of watch it happen?

Chapter 2 — Why FinOps Gets Ignored Until It’s Too Late

Pathik: Yeah. We’re diving right into it and that’s a pretty deep topic. Just as a way of introduction as you mentioned, I’m one of the co founders of the FinOps practice at Google, and we see this time and again that customers don’t take FinOps seriously until FinOps makes them. An example of that could be, I was in a conversation with a CTO and they were like, “Hey, we have a budget in mind for 2025 and we actually spent all of it in the first 6 months.”

Kevin: Oh, what the heck happened there?

Pathik: Right. So they’re like, “Wait, are we wasting money on the cloud? Is cloud being more expensive than what we thought? Are we being efficient in what we do?” All of those questions naturally start to pop up. And I think that’s when we start to have conversation about, “Hey, have you heard about FinOps? Let’s talk more.” So I think that’s one of the early signals that we have found: it’s either the finance team who find themselves out of budget, or usually end of the month you see a huge bill from a cloud consumption perspective and they’re like, “Huh, what did we do in compute last month? Why are we spending all of a sudden twice than we used to?”

Kevin: You said that people don’t pay attention to it till they have to. Is it just because it’s sort of a new concept to wrap your head around?

Chapter 3 — From Data Centers to the Cloud: Why Cost Awareness Lags Behind

Pathik: Yeah, I think if you compare that with traditional data center mindset, right? Where procurement used to be centralized. The team is taking all of the requirements from app and engineering team. They decide how many servers, databases, virtual machines do they need. Everything is kind of vetted out and this whole process takes from 3 months to 6 months to 9 months, and everything is pretty set from that front onwards. And now you have a space, or you own a data center and you run your apps in there.

Versus in cloud, the whole aspect is that procurement is pushed to the edge. So now these engineers with a click of a button can provision a VM within seconds, and that starts charging cost. Now traditionally engineers did not have to think about cost from the get go, from a design perspective, but now they do, right? And because finance now who holds the money, engineering who owns resources, sort of is in the gray area here. It’s like, okay, how do we have a framework where these two teams collaborate together in terms of finding out, hey, how much it’s going to cost and so on and so forth.

So oftentimes it’s not about building the cheapest solution out there. It’s not about cost cutting. But it’s mainly about embedding cost as a metric, just like security, just like reliability, just like making sure that your app works once you release it out there. Cost is just another thing to put into equation for your comprehensive outlook.

Kevin: Okay. And obviously you’ve helped create some AI powered tools for cloud cost management. In your mind, what is that perfect balance between automation and human decision making?

Chapter 4 — Finding the Right Balance Between Automation and Human Control

Pathik: Yeah, I think if you look at this term being used a lot in FinOps, which is crawl, walk, and run, right? You cannot and should not automate everything from the get go, right? You sort of have to build that trust. And the balance is about automating the toil that you have, but then also leaving the decision to the humans.

Chapter 5 — The “Cruise Control” Model for Agentic AI in FinOps

Pathik: So if you think about the evolution of self driving cars that we have now, right? It used to be, the cruise control came into play first, which is you go on a highway, the highways are decently marked, you know the traffic pattern and you put your car on cruise control. So you kind of focused on one specific problem, and then you add a bunch of rules to it and then you sort of semi automated it. Now it doesn’t mean that humans still cannot accelerate or brake even in cruise control. So there is always that, “Hey, let humans overtake from that cruise control.”

To now we are at a point where there are cities like San Francisco and New York and so forth where companies have operated self driving cars beyond what’s available in cruise control, right? It’s a perfect example of that and many others are working towards that. So I think it’s all about crawl, walk, and run in terms of trying to figure out what that balance looks like.

And the recent trend that I am seeing is AI augmented decision making. So automation isn’t just a simple script or a rule that you run. That’s a great place to start. So typically I have non production environments and you have virtual machines running there. How do I turn them off on weekends and start them again on weekdays? Those are simple ones that you can start doing. But then as you get more sophisticated and complex over time, it’s an AI model that specifically says, “Hey, I have analyzed last 90 days of traffic pattern, P99 traffic usage for a workload, and I recommend changing these to a specific machine types or machine shapes which will save you X dollars, but then you will also have a 0.5% performance risk.”

Right? So now you have all the data in place and humans still get to hit approve, but the cognitive overload of trying to find this opportunity is automated. Right? So I think that’s where AI automation and human kind of works well together in trying to find those opportunities and making it more comprehensive in terms of identifying this.

Kevin: What are the dangers of over automating?

Chapter 6 — Dangers of Over Automation and What Can Go Wrong

Pathik: I think ultimately if you think about FinOps, it’s more about the culture than tooling itself, right? So if you think about, essentially at the end of the day, you want everyone to think about operating with efficiency mindset. So I’m taking an example. Let’s say in your house, when you leave the room you sort of turn off your fan and light, and when you enter you turn them back on. The over automation would be like, “Hey, I’m waking up at 8 or 9 in the morning, that’s when the light should, the fan should turn on. And then I go back to sleep at 9, and so everything should be turned off at that point.” One time I’m having a party, and then everything shuts off. It’s like, oh, there’s a disruption there.

So now you over automate it to a point where now you have to go back and manually turn things back on. So I think the same thing applies with cloud as well. One of the risks with cloud though, I think with the party it’s like you interrupted it for a couple minutes and then everything is back on. The problem with cloud is like, now you have automated a script that will shut down an instance that isn’t doing anything. Turns out apparently it was set up for disaster recovery, and now it is turned off. Nobody noticed it. Now there is a failure in one of the cloud regions or failure in the app itself, and now you no longer have that resiliency. You no longer have that high availability.

So now when you try to move the app over to other region, that functionality is no longer working. The end impact is your end users. End users no longer able to use your apps. So I think that’s where over automation can be dangerous.

But then there is also a rule about, hey, if it is a non production environment we could be financially stricter, versus if it is a production environment, how do we make sure that the customer experience doesn’t get interrupted with the automation that we have in place. And kind of test it thoroughly over a period of time before things go into changing the instances.

Chapter 7 — Real World Examples: When Automation Backfires

Pathik: So one example that was very recent, I think one of the organizations, it came into the news that they changed certain lines of database code where AI would kind of change the programming language, and that interrupted the database. Now for an engineer, it’s a database that is disrupted. But it could be, think about an airline that is using the cloud services. Now all of a sudden hundreds of flights are getting interrupted. The folks who are going to be traveling, it’s going to be interrupted. There is a huge butterfly effect at the end of this.

Kevin: Yeah, that’s a good analogy. It’s always good to use an airport, airline one, because everyone can relate to that and it does get messy quickly. So everyone obviously wants to find anomalies early, but it can be difficult. What makes a cost alert actually useful? One that teams trust enough to act on.

Chapter 8 — Detecting Anomalies Before They Burn Your Budget

Pathik: Yeah, I was reading about this in the news. In last couple weeks, one of the houses in our neighborhood actually caught on fire, and it’s pretty devastating for the family if you think about this. Like, you put all of your life savings into a place, you call it home, and then something like this happens. And the root cause usually is, someone turned on the gas burner and didn’t turn it off, or something electrical.

Kevin: Yeah.

Pathik: Yeah. And imagine you, the firefighter tells you about this and gives you a huge bill like, “Hey, here’s $550,000 cost that you have. Now you have to replace your entire living room, kitchen needs to be redone, your roof has to be replaced, blah blah blah.” It’s too late, right?

And I think there has to be some smoke detector in the house, similar to smoke detector for the clouds. So what are those early signals that engineers and organizations can actually rely on? There are a couple ways to think about this. One is putting proactive cost management guardrails. So let’s say if you are using compute and databases and serverless functions, are there appropriate high limit quotas that you have in place? The quotas are so high that it doesn’t interrupt even if there is a surge in traffic, but they also have an upper limit so that it doesn’t go unlimited. Because we’ve been hearing this, that customers running a query on a weekend all of a sudden now costing them $80,000, and nobody looked at it until they come back on Monday or maybe end of the month.

Chapter 9 — Building Early Warning Systems for Cloud Cost Spikes

Pathik: So how do you put those guardrails in place, which are typically quotas or any sort of policies that helps you cap the usage. The second place is cost anomalies. So this could be things like, “Hey, we’ve seen your BigQuery usage for the last 6 months, and all of a sudden you are spending twice as much today as you would have spent any other day.” That’s an early signal or a smoke signal that the teams are being indicated to look into.

Now, it may be perfectly fine. There might be a surge in traffic like Black Friday, Cyber Monday, or something like that. In that case you can completely ignore it. But in cases where it’s not, then teams can actually be slightly more proactive in taking control of that. So I think having those thoughtful policies in place is going to be very helpful, both from a proactive cap perspective as well as from a reactive consumption perspective.

And if you look at, if you operate on any cloud providers, they have cost anomaly detection out of the box. Google Cloud has one. All you need to do is take some time, configure it, set up the alerts so that you start getting those alerts easily. And then as you go into the deeper science of like, “Hey, what’s an anomaly? I want to customize it to my needs and based on how I operate,” we have our professional services team in FinOps who can actually help customize it as well. But I think the idea is that you have those things in place. A lot of times when I go to my customers, cost anomaly detection has been there in console for a year. How many of them actually use it? How many of them have configured it? And even after configuration, how many of them actually go back and make something good out of that? I think that’s the place where there needs to be some governance in place.

Kevin: I think it might be difficult for big companies to build FinOps habits that actually stick. Are there simple ways leaders can make cost awareness part of the culture without slowing down innovation?

Chapter 10 — Why Culture, Not Tools, Drives FinOps Adoption

Pathik: Yes, this is a very big topic. And I think there have been a few things that people have tried and hasn’t been very successful from a FinOps perspective. One of the things when I entered into a room, CIO was like, “Hey, build me a tool that does FinOps and we would be good.” And I was like, “Nope, that’s not how it works.” You can have a treadmill at home but you cannot expect everyone to be healthy, right? Unless people know how to use it.

Kevin: Exactly.

Pathik: So I think tooling doesn’t solve that problem. The other thing was, “Oh, okay, if tooling doesn’t solve this problem, we need people to solve this problem.” So then people started creating centralized FinOps, which is great. I think everyone should have a centralized FinOps. It could be half a person. It could be a team of 20. Depending upon what makes the most sense from a capability perspective.

But then they started over relying on their FinOps team to do FinOps. It’s like, no no no, hold, that was not the whole goal. The whole goal was the FinOps team to empower others to do FinOps. The FinOps team is bringing you the data so that everyone can make those decisions. It’s ultimately everyone’s job to do FinOps. It’s not just the FinOps team.

Chapter 11 — Embedding Cost Into Design Reviews and Developer Workflows

Pathik: So I think that’s where culture comes into play. What are some of the simple ways where this can be incorporated, to your point, without slowing down innovation? In the design phase, especially large customers, they have architecture review boards. Can cost be embedded as a metric there? You’re already talking about high availability, you are already talking about scalability, you are already talking about disaster recovery. Cost is just another metric that you would incorporate as part of the design principles, so that when these architectures are being reviewed, you know how much they are going to cost once they go into non production, production and so forth. That’s one simple way.

The other way would be put cost in developers’ path where it is possible. Let’s say developers day in day out check in their code in GitHub, and every time they do, imagine a bot telling them that, “Hey, this change that you are making is going to increase your cost by $5,000 next month.”

Kevin: Right. It doesn’t mean that shouldn’t do it. It’s just bringing that awareness.

Pathik: Make sure you know that that’s what’s going to happen. Exactly. Right. So you’re putting that cost in the path of the developer. And then also I think OKRs. Google has objectives and key results at the beginning of the year, so that every single team within Google, maybe cloud, YouTube, Chrome, operates to achieve those. Organizations should have FinOps OKRs in their goals as well.

Chapter 12 — Turning FinOps from Cost Cutting to Value Creation

Pathik: So that way engineering teams are spending some point of their sprint in resolving those technical debts, in identifying opportunities where they could be efficient in how they deployed. Because a lot of times, you deploy an app, you overprovision it because you are not sure what the baseline traffic is. But there is opportunity for you to come back after a month, revising how much user traffic did your platform serve and the infrastructure that was provisioned under the hood. Is it overprovisioned? Can we right size it? Are there things that are running idle, orphan, doing nothing, providing no business value? How can we go back and fix that?

Like Kubernetes, if people are using Kubernetes engine, they’re very familiar with the concept of bin packing. Sizing tends to be one of the places where it can get really inefficient really quickly.

So I think ultimately how do we bring cost into the path of a developer and kind of get that cost conscious practice. And then the other side of the coin is every conversation that you have, you are bringing in efficiency and value in your conversation. Your app could be costing $5,000 more next month. That’s not bad if it grows your user base by 30%. Right? Now all of a sudden you are changing the narrative from cost cutting to more about how do we run efficiency at scale, and then how do we tie it back to the business value. Growing the users, making customer experience better, processing more transactions, whatever it is that you are doing from a platform perspective, that’s where efficiency and value comes into play in your conversation.

Kevin: Do a lot of companies in your experience have issues getting their finance and tech teams to sort of speak the same language, if you will?

Chapter 13 — Bridging the Gap Between Finance and Engineering

Pathik: That we have seen quite often. And this could have happened because of the “us versus them” philosophy, which is FinOps initiative is treated primarily driven by finance, and they may be looked at as cost policing.

Kevin: So now engineering teams are like, “Here they come, here they come. They’re going to make us, they’re going to tell us that we can’t do something again.”

Pathik: Yep. You cannot provision that GPU now, you know it’s costly. So I think that definitely creates an environment of, trust is missing piece there. And it could worsen in worse situation. Think about that as blame or judgment. Like, I was looking at this fitness tracker app. Imagine if your fitness tracker app is telling you, “These are how many steps you did NOT take, Kevin.” Like, it’s judgmental, right? Like, that doesn’t create that collaborative, “You’re pathetic.”

Kevin: Maybe I would, maybe I need that, I don’t know.

Pathik: So I think that’s one of the philosophies. Okay, how do we bring in that shared responsibility, accountability so that finance team and tech teams are working together? And then there is always, “It’s not my job, I don’t have time,” right, when it comes to FinOps. So how do you figure out executive buy in? How do you make sure that you have the right OKRs in place? How do you make gamification, some fun into this?

Chapter 14 — Making FinOps Collaborative and Even Fun

Pathik: Instead of it being a boring task of doing your taxes by your own, like, can you make it a competitive sport? Like a hackathon, where we are trying to bring in efficiency, increase inference, decrease the inference cost, yet process more transactions? Like, that’s an interesting engineering problem and a finance problem to be solved for. How can we collectively come together in one table and solve for it?

So I think that’s where it is very important for finance and engineering and product teams to be at the same table. And one thing that I often hear from our customers is like, “Okay, so where should FinOps team report into? Is it finance? Is it tech, is it product?” And I think regardless of where it does, all three leaders have to have a seat in the table in terms of guiding and driving your FinOps strategy forward. Otherwise, there is always going to be “us versus them,” “this is not my job,” “I don’t have time.”

Kevin: You mentioned the gamification. That’s a good segue. I wanted to talk about your FinOps sketchnotes that you do, that have gone somewhat viral, I believe, too. You kind of make this stuff look fun. Why do you think visuals and creative storytelling work so well in a field that’s obviously primarily spreadsheets and charts?

Chapter 15 — The Story Behind Pathik’s Viral FinOps Sketchnotes

Pathik: So, you mentioned viral. It’s actually interesting because I would try to post something on LinkedIn and I would crave for the likes and I would crave for the impressions. But very very often, you crave for something and you don’t get that, right? You’re like, “Okay, what’s missing?” And one time, my niece is 4 years old, and I was being told to read some stories with her. And I was looking at the books, and it was so elaborative. It was so amazing. The stories were simple but it was still very catchy and I enjoyed it, and my niece Zeve, she enjoyed it as well.

And I was like, work should be fun. And that’s how the idea of sketchnote came into play. And I was like, if I can boil down FinOps into the most simplistic term, define what the problems are, define what the challenges are, but then also tell people how to do that. Because I think a lot of times people say, “You know, FinOps needs collaboration, FinOps needs executive buy in, FinOps needs to be a centralized function within your organization.” But like, how do you do that?

And I think that’s where I was working, in terms of expanding that with my own team. And I think one after the other, the ideas came into the spark, the spark came into the visuals, and we started drawing sketchnotes left and right. So one of the sketchnotes that we have is, you mentioned about proactive policies, right? Like how do you think about that, defining your policies, implementing it, automating it, and putting that entire on a one page sketchnote. It was definitely challenging, but then at the same time it’s also very informative. Things like heavy topics like getting value from your AI investment. How do you think about that framework that is applicable to an S&P 500 but at the same time a company next door which have started last month? So how do you resonate to both of those audiences with that single sketch?

Chapter 16 — How Creativity Helps Teams Understand Complex FinOps Ideas

Pathik: I think that’s where it started to become more fun for me, and obviously it has its inherent challenges that comes with it as well. But then the next thing I know is when I post it on LinkedIn, I’m sort of getting a lot of positive sentiments from the community. They say they love it. They are providing me more feedback on what else should I be thinking about. Many have told me that they have incorporated that as part of their training and education curriculum. They’re asking me for the full set of like, “Hey, can you send me all of the sketchnotes? I want to print it out, send it to my app team so that they can put it on their dashboards” and stuff like that.

Kevin: That’s cool.

Pathik: That really kind of drove. I was like, “Okay, that’s amazing.” The likes and the impressions were one thing, but then if people are telling me this on private messages on LinkedIn, I think that makes a huge deal. So yeah, that was sort of how the whole project came around. And I was looking at it a couple months ago. It has more than a million impressions now. So you sort of, you know, you do something that people like, you’re going to get what you want.

Kevin: Look at you. You’re huge. You’re big time.

Pathik: Well, now I need to go figure out something else.

Kevin: Yeah, keep the momentum going. Keep the momentum going. Yes. Let’s wrap up with some rapid fire questions for you. I’ve got some things that I’m going to give you a sentence, I want to see if you can see how you would finish it. Okay. All right. So finish this line. FinOps becomes truly effective when…

Chapter 17 — Rapid Fire Round: Myths, Metrics, and the Future of FinOps

Pathik: When your teams start to work together and take FinOps as a team sport.

Kevin: How about this one? The biggest myth about cloud cost optimization is…

Pathik: Is that your tooling solves all your problems. It’s not really the tooling. It’s mainly the culture.

Kevin: Yeah. Yeah. You mentioned that earlier. Yeah, that makes sense. I liked what you said about that, because you can have the tools in place, but if they’re just there, they’re not doing a whole hell of a lot of good.

Pathik: Exactly. Yep.

Kevin: All right. One metric every team should care more about is…

Pathik: Unit metrics. We haven’t spoken about this, but I think ultimately tying down your cloud cost to the business value, right? Like cost per transaction, cost per user served, cost per item sold, for airlines cost per seat sold. I think that’s essentially what’s driving their margins, keeping their stakeholders happy, and it also identifies if your customers are happy with your products. So I would say unit metrics is the most important metric.

Kevin: A book, documentary or podcast I would recommend about AI and FinOps would be…

Pathik: We are working on a book which is going to be published in a few months from now. So I would, you know, be biased and recommend that to read. But I think that there is also a fantastic book on FinOps written by J.R. Storment. I think that is a very good read which kind of provides the agnostic way of thinking about FinOps. But hey, when my book is out there, you know, that would be the next best recommendation.

Kevin: There you go. We’ll have you back on and we can talk about your book when it comes out.

Pathik: Yeah, absolutely. Would love to do that.

Kevin: All right. Now here’s my favorite one to finish us out. By 2030, AI will…

Chapter 18 — By 2030: AI and the Human Side of Better Decisions

Pathik: By 2030, AI will provide a lot of intelligence that human can use to drive better decisions. I think this is true for FinOps, but this is also true for every single aspect of life. From crunching the data to getting pros and cons, to living a healthier life. I’m into pickleball these days, and my knees hurt. So now I’m using AI to build myself a stronger, healthier form so that I can play pickleball longer and have more fun. And I think to your point, right? AI will provide that information for me to drive better decisions on supplements that I should take, on better food habits that I should have, on exercises and stretching and all that kind of stuff.

Kevin: Yeah. My knees hurt just when I wake up in the morning.

Chapter 19 — Closing Thoughts and Outro

Kevin: All right. Well, Pathik, thank you so much for being here. Really appreciate your insight. And yeah, let’s have you back on when the book’s out and we’ll chat about that.

Pathik: Absolutely. It was fun. Thanks, Kevin.

Kevin: All right. Well, that’s it for today’s episode of Unclouded, the Agentic AI FinOps podcast by Cloudgov.ai. If you started thinking about how your cloud costs run themselves, not just track them, check out Cloudgov.ai. It’s where Agentic AI meets FinOps, turning insights into action before waste ever happens. Thanks again to my guest today, Pathik Sharma of Google. Until next time, stay unclouded and stay curious.