FinOps in Action

CEIA - Michael Graff
===

Mike Graff: [00:00:00] this is not really a FinOps thing, but whenever I run across a, a provider that doesn't support, um, IM roles, for example, they're still requiring you to use secret keys.

It's like, come on. You know, what are you doing? You're, you are not with the program here.

taylor-houck_47_05-11-2026_104215: Welcome back to FinOps in Action. I'm your host, Taylor Houck. Today's episode is gonna look a little bit different. Over the past few months, we have been exploring how the FinOps conversation is expanding beyond just finance and into areas like cloud engineering, platform teams, and DevOps. As part of that, we recorded a couple of conversations that took a slightly broader look at how these teams actually influence cloud cost and performance day to day.

So today, we are bringing you a special episode that digs into what changes when FinOps and engineering start working together more closely, and how teams can begin to operationalize cost awareness in a way that fits [00:01:00] naturally into existing workflows. This episode features a slightly different format with Point Five's Co-Founder and Chief Product Officer, Gal Ben-David, stepping in as host

if you are a FinOps leader, this episode will give you a deeper look into how your counterparts in engineering are thinking. And if you come from the engineering side, you'll likely hear some familiar challenges. Let's get into it.

Gal Ben David: Today's guest he is an IT professional with 30 plus years of experience designing, implementing, and operating eye availability infrastructure across storage, compute, network, and security. Mike also has deep expertise in infrastructure, architecture, and strategy with focus on data centers and public cloud. has also led major initiatives including large scale. Virtualization Cloud migrations, data center builds. He also holds multiple AWS certifications and was named today AWS Community Builders [00:02:00] Program in 2021. He's now an infrastructure architecture director, Adobe Laboratories, and he is also a pheno ambassador in the pheno community. Mike Graff welcome to the show.

Mike Graff: Hey gal. Thank you for having me. It's great to be here.

Gal Ben David: Absolutely. So Mike, I will, I will open with my first question. was the biggest or most craziest cost inefficiency you've seen?

Mike Graff: Yeah, I mean, I think there's a couple, um, one is, uh, kind of become more of an obvious one, but at the time when I discovered it, it was less obvious and that was the. We had a environment where, uh, it was a Databricks environment, right? So Databricks, as You know, tends to spin up Alot of EC2 instances in your account for doing processing, and it was pulling its data from S3.

So there was Alot of writing back and forth between the EC2 and S3 and the team that had deployed this, um. Had [00:03:00] not, or was not aware of the S3 endpoint, or wasn't aware of the fact that when you're writing to S3 from EC2, by default, that's gonna be going via the public, uh, S3 endpoint. And so they were racking up tremendous amounts of, uh, internet egress charges right back and forth.

Both directions essentially, um, to the, it was to the tune of like $8,000 a month, right? Of charges. And I happened to upon, upon this just by, uh, discovering it, using some of the tooling that we have internally, um, and reached out to them and figured out what they were doing. And we. Implemented the fix, which is of course to put the S3 private endpoint in, in place.

In, in that scenario, all your traffic is gonna be going private. And this is, this one's kind of insidious because, um, if you're not doing Alot of writing of data to S3, you might not see this or notice it on your bill, right, [00:04:00] because it's. You know, egress charges, You know, unless you're up into the terabytes, it's not usually something that, that hits your bill or,

Gal Ben David: go overlooked easily.

Mike Graff: Yeah. And so, uh, but once you get up into that terabytes or more threshold, then it can become a significant portion of your bill. So it's, it's a little bit hard to detect. Um, but the fix is so easy, right? It's like literally a couple of clicks and five minutes worth of work. And you're off and running and, and saving Alot of money.

So that was an easy win, uh, easy win for us.

Gal Ben David: Absolutely. Absolutely. That's, that's a well known type of inefficiencies where people forget to put an interface gateway, uh, to make this traffic just go inside of ADRs internal network. And that, that's one of the, one of the most typical, uh, annoying. Type of inefficiency, because many people would think, why [00:05:00] isn't that default? Why it even happens in the first place? should I ask to not go through the internet versus to ask go through the internet in some particular ways? I,

Yeah.

get it. How did you detect the problems?

Mike Graff: Yeah, so we, um, we, we were using, and we still use, um, Alot of the AWS provided cloud intelligence dashboards. Right These are these open source dashboards. That, uh, you can deploy in your environments. They, and, and they have specific dashboards around data transfer that allow you to kind of drill into data transfer and, and where it's cost and where it's coming from.

And so we were able to, You know, I was just kind of playing around with it and I'm like, wait, wait a minute. What is, what is this $8,000 in, data transfer charges? That seems very odd. And, um, so that was how, how we detected it. And sometimes that, that, that [00:06:00] actually happens with me. At least. I found that happens quite a bit where you're like poking around, just kind of looking at things and you discover something.

We had another scenario, a little bit different, um, around Nat Gateways, um, where. It was kind of a, it was kind of a funny one, right? Because You know, if you're deploying that gateway, AWS gives you the best practice of like, oh, well if you have multiple availability zones, you need to deploy in that gateway in every availability zone.

So we had an environment where it was, again, I was looking at the data transfer dashboards and I was seeing kind of like Alot of inter AZ traffic, um, in an account. And I was a little bit surprised by that, right? That's not. Uh, normally something you want to see or something that, uh, is kind of normal behavior.

And I dug into it a little bit, started looking at the configuration, and the source of the inter AZ traffic was Nat Gateway, and that was even stranger, right? [00:07:00] So what it turned out was, is that the team. Had done their be, You know, they, they read the best practice from AWS, they had deployed their NAC gateways.

They put one in each availability zone, but they had managed to incorrectly configure the routing tables so that basically they had, um, or I'm sorry, they, they had the NAC gateways. Both naac gateways were deployed in one az, but they had routing tables in both AZs pointing at that, at that both naac gateways.

So they,

AZ.

and you're paying for basically the cross AZ traffic. So again, it was, um, a relatively simple fix. Just delete that naac gateway recreated and the proper AZ fixed the writing table. Um, but again, it was like a couple thousand dollars a month of charges,

Gal Ben David: For

Mike Graff: these instances for no reason. Yeah.

Yeah.

Gal Ben David: That's that. That's by the way, just reminding our listeners that AWS has introduced a [00:08:00] new, uh, uh, a new version of the not gateways that are now, uh, multi az, just for, for people to know that now, not gate, not gateways, can expand to modern, uh, single az. Uh, I, I, I think, and map gateways are a very good example of that, that it seems like ADO s does not provide all the tools to actually help you to know that there is a problem what. What is the problem? For example, not gateways. So you get the metrics of how much data is being processed. get the data of, You know, how much bandwidth or number of requests. You have no idea where they they're coming from, so it's very hard to know. You, you just see like a high level metric.

You have a cross, you are paying for a cross, a Z data transfer. You have no idea where it comes from. So how did You know that you have this problem

Mike Graff: yeah. There, unless you're digging into the, [00:09:00] the charges, the cost charges, and figuring out, well, well, that's, that's kind of odd. Um, the, the, there isn't an easy way to see that these configuration errors are, are more difficult. Um, we had a similar Enter AZ thing where it was Kubernetes, right?

Because Kubernetes, like, by default, it's gonna like send, if your clusters across multiple az, you could end up having lots of traffic across az. And maybe that's, maybe that's what you want, but there's also like a Kubernetes setting you can enable to kind of disable that behavior and save yourself some money.

But unless you're digging into. The details of those charges and looking at, You know, kind of deep diving into it, it's difficult to find it right. Um, and you're right, AWS doesn't necessarily surface that they're, they're getting better. Right. You

Yep.

they introduced, uh, finally introduced that idle na gateway detection thing at reinvent.

And um, that's great. [00:10:00] Right? That's, that's awesome. 'cause people deploy Nat Gateways and don't realize that they even have 'em out there, or they detach them from the route tables and they're just sitting there chewing up money. So, yeah,

Gal Ben David: Absolutely.

Mike Graff: it's, kinda like it's a continuous improvement by the cloud providers on their side of the tooling.

And then, You know, you've got third party tooling that kind of fills that gap.

Gal Ben David: you mentioned at the beginning, Databricks. So I would like to dig, dig into it a little bit more. I truly believe that past services such as Databricks, especially. Using data pre X model, where the instances in most times actually run in your environment, poses a very, uh, problematic efficiency experience because you're not always transparent to what happens with your actions.

So for example, you say, yeah, I want Databricks to query and access data in S3 buckets. You [00:11:00] have no idea it's going to incur costs. Different type of costs S3. you are under the impression, as You know, a regular engineer that you pay for Databricks for the amount of resources that you've asked to get provision and stuff like that.

You have no idea. You have actually affected many, the side effects and the blast produce of your actions is getting out of control. you have anything in mind of how you can govern these kind of decisions and make people more aware? Actions when it comes to pass services that actually affect the cloud charges, You know, in.

Mike Graff: I mean, you make a good point. This is an area, uh, a problematic area, right? You know, people don't necessarily directly see what these platforms are spinning up. Um, and you don't, you don't necessarily have great control over it. [00:12:00] Um, and I, I feel like this is another area where there needs to be some kind of maturity from the platform providers, right, to help you.

Uh, be more efficient. Right. You know, I run into this Alot with like, You know, I tell teams, oh, well you should use spot instances, right? For, for, for this workload. This is a perfect workload for spot instances. Oh, well, uh, GitLab doesn't support using spot fleets, right? That like, there are, there are feature gaps that come up, um, with Databricks, uh, You know, uses Alot of S3 and You know, the natural.

You know, you run a cloud efficiency tool in your environment and it's gonna tell you, Hey, you should be using intelligent tiering for that bucket, right? You'd be saving yourself Alot of money. Oh, well, Databricks doesn't necessarily support that. Right? And so you're a little bit hamstrung by these providers because they haven't, they're not taking advantage of all the capabilities of the cloud provider because they're, they're just behind.

Right? From a [00:13:00] technical feature, capability perspective, um. So I don't know that I have a good answer. What I would say is you have to, you have to really beat up your past providers to say, Hey, come on. You need to support this feature that's been around for, You know, four or five years. Right?

It's, it's not like it's a new thing. You know, beating up those past providers is something I love to do.

Gal Ben David: Absolutely.

Mike Graff: And make to make them feel bad, make them feel embarrassed. Like I always, I, this is not really a FinOps thing, but whenever I run across a, a provider that doesn't support, um, IM roles, for example, they're still requiring you to use secret keys.

It's like, come on. You know, what are you doing? You're, you are not with the program here.

Gal Ben David: I, I think this is, this is the second time that you bring not necessarily intentionally of security. Do you think security and cost optimization or cloud [00:14:00] efficiency is anything in common?

Mike Graff: I, I think so. In some ways, like, like the classic way, which is getting people to do something about it, right? As security guy, You know, security teams love to come with a list of like 5,000 things that you need to remediate,

Gal Ben David: Yep.

Mike Graff: And in a way, if you're running one of these FinOps tools in your environment, you might have a similar, very similar list, right?

And getting people to treat those things as priorities. Can be a challenge, right? Because the engineers, they just want to, You know, they've, they've got their direction from their management to deploy and to get the new feature out. And they don't wanna be slowed down by, oh, I need to make this security adjustment.

I need to make this, You know, uh, cost efficiency adjustment. So I think there's Alot of similarities there. And I think there's this also, we both, both in the security community and in the FinOps community, we have this idea of like, shifting left, right? Let's, let's. Get the engineers thinking about [00:15:00] security, thinking about cost as part of their design process, which I think is a really, it's a great concept and I, I do agree that that's a big part of any FinOps program is getting the engineers kind of on board and bought in to thinking about efficiency as part of their design.

Um, so I think there, there, there's Alot of similarities there.

Gal Ben David: first, I really, I really liked it, but I, I think, I think that FinOps, I think that cloud security and aspects of should be. Like a on top of mind very, very early in the process because it, it, it's much harder fix them after the fact. So how do you encourage your engineers and cost optimization is known to be, uh. Let's say not a top priority for many engineers. do you bring cloud efficiency to their awareness very early in the process? [00:16:00] that a mandatory thing at Toby? Is that something that you, You know. Do sessions, You know, workshops with engineers to raise their awareness to raise their, You know, knowledge. What is Toby doing in that aspect?

Mike Graff: Uh, I, it's definitely not something that's mandatory at this point. Um, we, You know, Dolby's very decentralized in our environment as far as our engineering teams and everyone's kind of doing their own thing. We are more, and, and the FinOps team and the Cloud Center of Excellence at Dolby, we are really just kind of focused on, um, bringing them the tools, bringing them the knowledge, telling them what what's possible and, and.

Encouraging them to take advantage of it. Um, we have, You know, we have a FinOps, a dedicated FinOps person now, and that person is working with each of these engineering teams to review their inefficiencies and [00:17:00] to guide them or, You know, kind of get an idea of when they could be potentially be fixing these things.

Um, it, it is a, it is a mindset thing, right? You know, uh, Warner, Vogel, Warner Vogel's from AWS. Yeah. Not this year, but last year at his keynote, talked Alot about this notion of the frugal architect, right? And I think we need to get engineers thinking that way. How do we get there? It's just a continuous process of education and sharing knowledge and sending people links to Werner's keynote, say, Hey, you should watch this.

Right? It's, it's really good. And, and it gives you some food for thought. Um, but it's, it's still someone on the FinOps side who has to lead those conversations, at least at this point. one of the things I have been talking about is the notion of [00:18:00] the environmental angle, the green angle, right?

I think that that's something that is a lever that can be pulled with engineers because it, it hits closer to home in the sense that, You know, they, hopefully they want to have, You know, a future planet for their kids, right? And they want to have, there needs to be energy available for doing things beyond, um, running AI chatbots, And.

Gal Ben David: completely agree.

Mike Graff: that is something that may motivate them more than saving some company money, right? Because at the end of the day, it's not their money, it's the company's money, but the, the environmental angle of being more efficient and using compute resources, uh, and as efficient a manner as possible, I think will resonate more with engineers.

Gal Ben David: I agree. I agree. I, I think tying some risk factor or emotional factor, cybersecurity has the risk factor and the feel factor because if something bad happens. [00:19:00] It can go really wrong, Yeah.

it comes to cost optimization, it kind of feels like, yeah, on the Wolf case, we are losing a huge coal point's money, is not that bad.

We, we are expensive anyway, but so, so, so trying to tie cost optimization among engineers something emotional is very hard. Because they do not feel really bad to waste company's money. Not to some extent, of course, but when it comes to pollute the earth,

Yeah.

Everybody, not everybody, but many people can definitely relate to. And that definitely speaks to the hearts of many engineers, especially in in, in some developed modern. Uh, uh, uh, economies. So I really like that. So it, it basically takes me back to the, the motivation part [00:20:00] except for, You know, green ops and, and, You know, CO2 emissions. Do you think there is any lever, any, any leverage?

Any, any, any, any motivation that can be, can inspire engineers and influence engineers more? Efficient to, to the cloud environmental to be efficient in the first place. Do you think there is anything else?

Mike Graff: Well, I think if you think about engineers in general and the mindset of an engineer. There is a certain amount of pride in designing something that is as efficient as possible, right? So if you can figure out a way to appeal to that, that's another way to drive that kind of frugal architect idea, right?

Because there's a little, I don't wanna say ego, but You know, they, they take pride in designing really efficient code. Like, oh, I can make this [00:21:00] happen, and. X number of lines of I'm not a, I'm not a coder, right? So I, I, but You know, the idea of like, well, I can do this in less lines of code than you. Right. Or, You know, so I think appealing to that and saying, Hey, You know, you could, have you thought about a way to do this via serverless instead of containers, for example?

Yep.

Or have you thought about, You know, could you spend a little bit of time to make this so it works? Uh, and an arm architecture instead of an X 86 architecture. Right? And, and save, because that actually could save you Alot of money. Um, that, or, or getting them to kind of help you when to push back. Um, on the software vendor to say, Hey, does your, does your instance really need to run your software, really need to run on this big of an instance, or could we run it on on less?

Um, so I think that's an angle that can be potentially leveraged is this idea of like, Hey, You know, I know you're all about efficiency. You're all [00:22:00] about making the coolest, cleanest code. Well, let's do the same with the architecture. Let's make the architecture really lean and efficient and, and. And do it that way.

Gal Ben David: Mike, You know what you have reminded me of you, you've probably seen many of those shoutouts when an engineer, a team, made some architecture or application much faster. Not necessarily, You know, uh, after it suffered from some bad performance. But many times we see those shoutouts, hey, we've been able to, uh, uh, uh, rearchitect and improve. X and it, it now runs 10 times, 20 times faster. And

Mike Graff: Yeah.

Gal Ben David: our clients now get the responses with a much lower latency and the P 99 percentile and, and all of that. So performance. For some reason motivates engineer much more than [00:23:00] efficiency. And when I, when I try to think why that happens, think it is much harder to engineers. To kind of correlate the architecture, the application to cost. So whenever they improve performance, you never see on those shoutouts. by the way, we've also cut this application cost by like five times.

Mike Graff: Yeah. I, I think that's totally right. I think that's something in 2026 that our program wants to focus on more is that notion of a shout out and the gamification, You know, we talk about gamification of FinOps.

Gal Ben David: Yep.

Mike Graff: that's something I'd like to see us doing more and not necessarily. Well, I guess it is kind of making a competition between teams.

Like, hey, this business group is, has this efficiency score. Right? And You know, this other team, they, they've got some work to do. Right? And, um, we've, [00:24:00] we've played around with that a little bit, but that's something I'm hoping that in 2026 we can, we can focus a little bit more on. Um, and I do think.

Thinking about like that this team, with this revision of the software or this revision of the architecture, they also are, You know, spending 10% less right. On to make this app work. And I think that's, that also gets into the whole unit economics thing, right? And it's, it's, it's like. Yeah, if you're measuring the cost per transaction, right?

Or, or, or if you're, if you're running like a public store or something and you're doing, doing FinOps and you're measuring what is the unit cost to, uh, do a transaction or ship a widget or whatever, that's scenario where you can get, maybe get people more excited. Right. And we're we're, uh, it's a little bit harder in my environment 'cause we're not necessarily running public facing websites where we're selling things, right?

So Alot of our [00:25:00] cloud workload is more research focused. And so that's a little bit harder to measure unit economics than if you're like a amazon.com or whatever.

Gal Ben David: very cool, very cool. So, so with that in mind, Mike, if you had the opportunity to develop any kind of cost efficiency pH of stool that you can, would it be?

Mike Graff: Alot of the work right now in the FinOps tooling space, of course is focused on ai, right? and when I talk about a, when I talk about ai, I mean AI for FinOps,

Gal Ben David: Yep.

Mike Graff: FinOps for ai, right? So the notion of like, how can we make the tooling more efficient or make the tooling do more of the work?

Um, You know, Alot of the. Alot of the FinOps community out there, and I was, I, we, we were there not, You know, just two years ago. There is no FinOps team. Right. Or it's a team of one. Right. And that person might be, might be [00:26:00] doing something else as their day job. Like, that was me, right. Two years ago. I, FinOps, FinOps wasn't my job description.

It's just something I, I got passionate about and I did Alot of work kind of on the side right. Until I was able to get the. The, the idea of a program off the ground and get it funded and, and now we've got a person doing it. But I think, um, all the tools need to be thinking about how they can automate things, make it more kind of self-driven.

Right? That it's Alot of work for the FinOps person to be interacting with every single engineering team out there, right? So how can we make the tool do some of that work? And I. I, I don't have any idea how that would actually work other than just conceptually the idea of it. Right. Um, but this notion of like, okay, I'm going to, I'm gonna have a FinOps agent,

Yep.

right.

That is kind of going out there [00:27:00] and, um, identifying these things and communicating with the different engineers. In a friendly way. Right? Uh, 'cause we don't want to, we don't want to, we don't want shame. We don't wanna name and shame. We want to, we want to collaborate, right? So how can these tools, um, help with that?

Gal Ben David: I can totally relate to that, I think. I think it goes well with the trend of replacing tedious tasks and jobs with AI agents, which are now much more mature than before, and can definitely those tasks from. You know, the people that are currently being tasked to do that. You, you've, you've also mentioned that you, out of passion was kind of intrigued to do s but that wasn't your job role. And I always was very curious what people think about platform engineering and FinOps because we, we [00:28:00] speak in a very. Similar language with platform engineering. Eventually it's about enablement, enabling the engineering teams to be more efficient, do their job faster with less with less mistakes, whether those are security mistakes, performance mistakes, or efficiency mistakes.

So do you think eventually cost efficiency a practice? That is part of platform engineering. Do you see any trend towards this direction or you think FinOps can coexist with platform engineering as a.

Mike Graff: Well, I think it could be either, right? I mean, I think we, we, what we just talked about, we talked earlier about that kind of the shift left idea, right? So if you're a, a good architect, a good platform engineer, costs should be one of the dimensions that they're looking at when they're, when they're designing, right?

Um, and [00:29:00] if we think about platform engineering as a way to, um. Make it easier for developers to, to do their work and not have to be thinking about tooling. Right. I think that's certainly an area where FinOps could become just another part of that platform team. Um, we don't have a platform team at Dolby, right?

So I don't, I can't speak about platform engineering too much, but, You know, my feeling about platform engineering is, is that, um, we wanna avoid people reinventing the wheel. Right. And we want to give people a defined set of tools to work with. Um, one of the challenges that you face when you don't have a platform team is you might have a duplication of tools, right?

You might have every team coming up with their own logging solution, right? Is that, is that cost efficient? [00:30:00] No. Right? It would be more cost efficient if everyone used the same. Logging platform, whatever it is. Um, 'cause you get efficiency of scale, you get, You know, maybe a single contract you can negotiate or if you're building it yourself, it's just like, it's more efficient that way.

So, um, that is by having a platform engineering team and by standardizing things, you're gonna be saving money, in my opinion. Right. So yes, I do think that is a, a potential trend. At the same time, FinOps is kind of moving, like if you look at what the FinOps Foundation talks about, right? It's moving beyond just cloud, right?

And it's moving to like, um, SaaS and, uh, data center and uh, things like that, right? Um, which are maybe fall outside the realm of platform engineering, right? Managing your SaaS, uh, maybe that is, or [00:31:00] that isn't part of your platform engineering team. I'm not sure. Right. But that's, so I think both there's the opportunity for both ways, right?

You could say, okay, FinOps is now gonna be part of platform engineering and it's just another person on the platform, engineering team that's focused on that. Or it could be, no, FinOps is, I don't know, could be underneath the ci, the CFO, or it could be, uh, in the finance department, or it could be another function within it.

Gal Ben David: So with with, with that direction, again, something that I've been thinking about for quite some time, you believe there is a room for a new role? Very similar to the, the, the same time that DevOps was starting to develop something like. Cloud efficiency engineer, someone that is basically responsible for the cost optimization efforts.

Do you think there is room for that role in big organizations like sre?

Mike Graff: If we talk about like what we're doing here in my, [00:32:00] in my day job, I think that's kind of what that person is like. His, his title is like FinOps analyst, but he's basically a cloud efficiency engineer, right? Because you, you need to have, to be good at FinOps, you need to have a, a solid technical background or my, in my opinion, a, a, a, a basic technical understanding of how these.

Cloud technologies work and, and what are the levers you can pull, but you also need to be able to, um, speak to the business. Right? And, but I come at it very much from a technical side, right? So, um, I know in Alot of companies, FinOps has, has more been like, oh, this is a finance person who is now focused on cloud, right?

Um, but I think you need to have somebody in that FinOps team that is very technical. Right, because that's how you talk to engineers. You need to get down to those technical details. So I guess the answer is yes.

Gal Ben David: it reminds me of DevOps like a few years ago. It [00:33:00] felt like there are two different DevOps engineers once that came from it. Background and ones that came from engineering background. When you spoke with the IT people, you would've gotten answers. They, they, they've been thinking like, like the kind of answers that are more leaning towards it. Perspective, but then want to get some different answers. How are we going to architect our elastic search cluster? Or how can we handle a, a high availability, uh, uh, a kind of, You know, cluster with this particular constraints. you were kind of looking for the more architect, engineer type of person. So I feel FinOps is kind of diverging into two, very similar to DevOps directions. One [00:34:00] is leaning towards the FinOps perspective, the finance. Perspective, and one is lean towards the engineering perspective of cost optimization, which sometimes is a side effect of the same effort, but from a different perspective.

So, okay, this is how, how much we spend, we've done the chargeback, the show backs, but. We want to save money now, we need an engineering effort. We need to

Yeah.

what is causing us to waste money. How can we fix it? How can we like, maintain the downtime, the, the, the same, You know, constraints, architectural constraints, and save the money.

So. This, this is why I, I, I kind of think that there will be, in the future, a a definition of either, You know, a FinOps engineer or You know, a cloud efficiency engineer that will definitely be more recognized as an engineering persona, not a [00:35:00] finance persona.

Mike Graff: Yeah. I

Gal Ben David: do you

Mike Graff: that's right. I do. I think it's gonna be more in probably start in larger organizations that can have. Multiple people, right? Like, like we were talking about before, it may be in these smaller team, smaller companies or smaller environments, there may not even be a FinOps function at all.

Right?

Yep.

But, And so how does that get off the ground? Well, maybe it's somebody from the finance side who's like. The CFO goes, that person says you need to get control of this clouds, You know, get control of this cloud spend. So that's, maybe that's where it starts. Okay. And then, okay, maybe I can figure some of this out, but at some point I'm gonna need to recruit an engineer to help me, uh, with the technical side of things.

Or it could be that it's gonna be, like we said before, shifted left and it's gonna be each development team. It's gonna have somebody who's like, like a FinOps champion, right? Who's an an engineering [00:36:00] persona, but who's focused on the efficient cost efficient design, right?

Gal Ben David: Yep.

Mike Graff: it could be, it could be in a centralized FinOps team.

It could be decentralized in each of the engineering groups. Uh, could be somebody on the platform team wherever they sit. I think, I think you're right, that there. To be really successful, you're gonna need to have somebody who has that deep technical expertise.

Gal Ben David: My last question before I'm going to wrap up. This, this show, this really good episode. I, I believe many people that are probably not part of, You know, the FinOps practice and want to get into this practice would really, uh, uh, like to hear your, You know, recommendation or, You know, tip. So what tip would you give to yourself few years ago or to someone who wants to get into FinOps and cloud efficiency engineering?

Mike Graff: I mean, I would start with getting involved with the Enos Foundation, [00:37:00] right? Um, the Enos Foundation is. I always describe it as like a tribe. Right. It's like a tribe where everybody knows what you're talking about and is very passionate and they wanna share. Right. It's, it's one of the most sharing communities I've ever been, been involved with technically.

Like, like I mentioned, uh, like you mentioned at the top, I'm involved with community builders. I do Alot of, uh, kind of cloud work in general, and that's a great community as well. And there's Alot of sharing there. But with, with the FinOps Foundation and the community around the FinOps Foundation, um, there's just a desire to bring everybody up, right?

So I feel like that's a, a great place to start, uh, if you want to get involved in this, uh, field. Um, just a great place to get to know people and, and learn the, the basics, uh, of FinOps.

Gal Ben David: I, I cannot agree more. This is one of the most welcoming community I've ever seen,

Yeah.

from cybersecurity, which should [00:38:00] be a very welcoming community and is not as much as FinOps. This is definitely one of the, the biggest strength of, of the FinOps organization.

Mike Graff: Do you think that the se it is the security thing is because there's this kind of, this mindset of trust no one,

Gal Ben David: Me, I,

Mike Graff: that's why

Gal Ben David: I hope not, you must trust someone, at least the vendors or other practitioners. But, but AB absolutely. You, you, you would never get that kind of an experience any other community, maybe with the platform engineering community or the Kubernetes community, I think the pheno organization, organization is second to none like. You go to Phoenix X or to some meetups and you just feel like people want to share,

Mike Graff: Yeah.

Gal Ben David: to help, and it's, it's second to none again, really that.

Mike Graff: Yeah. It's all about, it's, it's all about learning, right? It's just like, um. [00:39:00] Um, I've run a couple of FinOps meetups here in the Bay Area and, You know, it's just everyone wants to learn and wants to share, right? And that's the, the fundamental thing. And, uh, they do a really good job of kind of laying out the, the, the full landscape of what a good FinOps practice looks like.

At the same time acknowledging that, um, we all can't be. Expert experts at this, right? And that, that would be my final piece of advice is, um, just start somewhere, right? You, you go to these FinOps conferences and you see the people on stage and you think, oh my gosh, they're, they're amazing. Look at all the great stuff they're doing.

But it all starts somewhere. It starts with like poking into that data transfer dashboard and or, and figuring out, Hey, what's going on here? Right? Just getting those, those wins chipping away at the low hanging fruit. Um, that's how you get started and it, it kind of builds on itself. The momentum builds, right?

You, you have [00:40:00] that first victory, you get excited and, okay, let me, what else can I find? Right? And you start tracking how much you're saving and you, you're building a dashboard and you get, you just builds that excitement. Um, so just, just get started. Talk to people, You know, and figure out where you can start.

Gal Ben David: Absolutely. I, I will also add to that, that FinOps value is very tangible as opposed to cybersecurity. Not every time you, you stop a breach, Hey, I've just figured out we've had a fraud orders in this app. No, most times you are just. You know, fixing potential holes. And when it comes to cost optimization, you are coming back with, this is how much I saved. Look the before metrics, the after metrics. This is what I've been able to accomplish. That's very satisfying experience, and this is something that, again, similar to performance. This is something is very hard. Start [00:41:00] with you. You. You can show success very fast and can grow from that with the traction and the appetite of your organization. Mike , I'd like to thank you for coming to the show. I would also like to thank the audience for listening.

Mike Graff: Hi. I appreciate you having me on. It was a great conversation. Thanks so much.

Gal Ben David: Thank you Mike and everyone again, if you have any, any person that you think can listen to this show, free to just share this with your friends. Thank you for listening and bye.

taylor-houck_47_05-11-2026_104215: That's a wrap on this special episode of FinOps in Action.

If this episode resonated with you, we would love to hear your perspective. And if you haven't already, be sure to subscribe so you don't miss upcoming episodes. We've got more conversations lined up with leaders across FinOps, cloud, and engineering who are all tackling these challenges from different angles.

Thanks again for listening, and we'll see you next time on FinOps in Action.