Engineering Meets FinOps ft. Matan Ben-Ishay, Credit Karma | Ep #70 ft. Matan Ben-Ishay, Credit Karma | Ep #70
FIA - Matan Ben-Ishay
===
[00:00:00]
Matanmatan_1_07-21-2025_103918: by not calling it finops, like we're basically saying every engineer is expected to do finops, right?
Alonalon--arvatz_2_07-21-2025_133910: so basically finops is a responsibility. It's not one person's role.
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 naturally into existing workflows. This [00:01:00] episode features a slightly different format with Point Five's Co-Founder and Chief Product Officer, Gal Ben-David, stepping in as host to interview Matan Ben-Ishay, a previous FinOps in Action guest.
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.
Alonalon--arvatz_2_07-21-2025_133910: Hello everyone. Welcome to another episode of FinOps in Action. Today I have a very special guest and a very, very good friend just like me. He's originally from Israel and moved to the U.S. His journey for finops actually started at EY. Where he consolidated companies around cloud adoption. Back then, he already realized the challenges around cloud cost management and got really passionate about the space.
At some point, he joined Credit Karma to lead finops, and today he's FP&A [00:02:00] engineering at Credit Karma. I'm happy to welcome Matan Ben-Ishay. Matan, how are you doing today?
Matanmatan_1_07-21-2025_103918: I am doing good. Thanks, Alon. It's, it's great to be here. Excited to be here and thank you for having me.
Alonalon--arvatz_2_07-21-2025_133910: Thank you for joining us and let's get straight to business. Matan, what is the one thing that you got wrong when you started your finops career?
Matanmatan_1_07-21-2025_103918: Yeah. Um, that is a () great question. Obviously I got a lot of things wrong I think, through my career, but I think, um, one of the things that I realized early in the journey, and I think a lot of people still do that mistake today. Maybe I do it sometimes, it's sort of failing to understand incentives. I feel like a lot of time you have misaligned incentives across the different org that you work with.
Um, so like a good example would be early in my career, I would come from like the finops lens of trying to find efficiency and cost optimizations. And we would come to the groups that are actually developing the product or working on launching something new. Know, [00:03:00] being optimized will not be top of mind for them.
Maybe they had a different incentive in mind, maybe it was more on reliability, maybe it was about velocity and you know, moving to speed, launch that feature. And sometimes it was like really hard to get them to do things in a more cost, uh, conscious, cost efficient way. Because for them it was like, yeah, that's not our priority right now.
We're trying to get, you know, something out the door. And that's like most important for us.
Alonalon--arvatz_2_07-21-2025_133910: I'm just really, really curious about what is your conclusion for that? Like is your conclusion that okay, incentives are misaligned and we have to live with that, or we need to find a way to align incentives?
Matanmatan_1_07-21-2025_103918: Yeah, I think, I guess it's both. I think on a one side, sometimes if you don't have the incentives aligned, I think. That's more of a strategic, like, acknowledgement that that's okay. I think to some extent we see that today in like the ai, um, environment. A lot of the companies are trying to move fast, right?
They're not moving with like the [00:04:00] necessarily cost optimized, cost conscious way, but they're trying to to be first, right? They're trying to make sure they're, they're launching things and getting, you know, things, um. To a place where they can meet the, their, their audience and, and they're not thinking about, okay, how can we do it in an optimized way?
They just don't want to be left behind. They don't wanna be the blockbuster of like the ai, um, era. Right. Um, so I think sometimes it's okay that you don't have, you know, uh, aligned incentives, uh, if you are conscious about it. Um, then sometimes it's something, yeah, you have to find a way to resolve, you know, maybe. If you start with velocity first you agree that, you know, after you launch a product, then you come back and you try to do things more efficiently, right? You can revisit things maybe. Um, and I've seen a lot of companies do that, right? They, they focus on launching first and then they come back and they try to optimize. And that's maybe a point where some [00:05:00] companies make the mistake and then sometimes they don't wanna break things, right? They already have something out there, and now they're not gonna try to optimize. That's. Like another mistake I see a lot of companies doing.
Alonalon--arvatz_2_07-21-2025_133910: Okay. You brought you a lot of very, very, uh, interesting points. Uh, let's touch them one by one. And you mentioned the fact that sometimes there are some areas where you wanna just run and build to make sure you're not staying behind. AI is typically the ultimate example because we're all scared about AI replacing us, or, or AI being leveraged by our competition and, and, and, you know, getting ahead of us.
Uh, so I wonder. What is your approach here? Like do you say, okay guys, listen, it makes sense. You shouldn't worry about cost. Go run, build your things. We'll figure out, uh, finops later on, or from your perspective, Hey, let's find a way to actually take this into consideration already now, even though we have to run really fast.
Matanmatan_1_07-21-2025_103918: Yeah, that is a very [00:06:00] good nuance because if you're doing your planning right, I think if you wanna move fast, right? You do some planning and you wanna make sure you're, you're doing that in a way that makes sense, right? So like, you don't wanna be fully speed without having some thought into, okay, what am I doing here?
Is it's sustainable from a cost perspective, from a resource perspective, right? and so I think that is a very, something that you should keep in mind in your planning process. but then again, I think there's always room for optimization, right? So like, even if you launch things, I think, and you want to, you know, prioritize speed right now, or I can tell you at Credit Karma, we really focus on the member.
A lot of the times we launch things or we create new things that are bringing benefit to member and sometimes we know it might not be the most efficient on our side at first. We really, you know, prioritizing the member. Um, and so we're always aligning that maybe after we're launching this, if this is a good feature for the member, it's helping them make some financial progress, which is what a [00:07:00] company does. Um, and then we revisit that and try to do things more efficiently and making sure we're sort of cleaning shop to make sure things are running more smoothly. Um, I would say also on incentives, there's also, you gotta make sure that you're. through the right like motion as far as, um, creating that incentive for others to, to be cost optimized.
Right. Um, and I think there's a lot of ways to do that.
Alonalon--arvatz_2_07-21-2025_133910: So share with us Matan. Don't leave it all to yourself.
Matanmatan_1_07-21-2025_103918: Yeah, no, I'm, you know, as we're talking, I'm trying to think, and I think the best way is probably, you know, finding a way to give credit. To the folks that are doing the optimization, and if they're launching something, you gotta make sure, okay, if they have an OKR or a deadline, then there is something that you can, you know, input in there that gives them credit for doing it the right way. Right. [00:08:00] I know from friends of mine heard in the past that a dollar of revenue goes farther than a dollar of cost, right? You celebrate the revenue wins. You don't necessarily celebrate some of the cost savings. But if you can find a way to give. Whoever's doing the optimization, whoever's leading it, uh, some credit, um, in front of their manager or some other way.
I think that goes a long way, at least from what I've seen in my experience. Um, the other thing I would say is, and this I've seen work, um, across different companies really well, is giving him, um, sort of a problem, um, to solve. So when you think about it, it is, I remember coming to engineers and, you know. I do not have an engineering background. And I was like, Hey folks, you can do this more efficiently. And they would take this as a challenge. Oh, that guy came and showed us, we can do something more efficiently. We'll find a better way to do it. Right? Um, and I, I found that a lot of engineers are like, yeah, let's, let's find a, a way to solve this.
Let's, let's treat it as a puzzle and try to find a way [00:09:00] to make this, um, work in a way that saves us resources and saves us costs, right? Um, and so I found that really helpful a lot of times as well.
Alonalon--arvatz_2_07-21-2025_133910: That's very interesting. And can you give us maybe a couple of examples of how you acknowledge a specific, uh, engineer or specific engineering team about their cost optimization work?
Matanmatan_1_07-21-2025_103918: Yeah. Um, yeah. I will say one thing. I think I am part of the finance org, so that sits separately from engineering, and I think one of the, the good things is. There's a different aspect of of getting credit between orgs, right? Like when the finance partner comes in and tells the engineering org, Hey, that engineer or that manager did something that's really, um, thoughtful, right?
That was really cost optimizing. Their manager would take it in a different way, versus it would come like within the engineering org. I think a lot of times you gotta call out engineers for doing the right things. You gotta [00:10:00] find the right forum for it. find the right forum, which they would feel mostly, you know, good about whether it's like a staff architect kind of forum or is it with their leadership. There's different kinds of ways that you can give them credit. and I think engineers, this goes a long way. the one thing I would say, you gotta be careful is. Not putting a lot of pressure or a lot of focus on one team that's doing a lot of optimization, because then you could create like in a case where now it's expected that team to come with more and more optimizations and what happens, at least what I've seen is a lot of companies have a lot of different groups that can work on optimizations and they end up only having one group that's sort of focused on optimization and a lot of the other engineers. Are sort of not working on optimizations and they don't learn a lot of the best practices that are part of the finops I would say
Alonalon--arvatz_2_07-21-2025_133910: Okay, so [00:11:00] basically don't go to the easiest path, but make sure you tackle various engineering, uh, teams.
Matanmatan_1_07-21-2025_103918: yeah, make sure you're, about it long term, right? Like you
Alonalon--arvatz_2_07-21-2025_133910: Yeah.
Matanmatan_1_07-21-2025_103918: you setting best practices if you work on optimization with one team. Then you learn something. Right? I can remember a specific case where we were doing some pipelines with certain type of machines. We moved to a more efficient machines. Um, the billing did not change, right? But we were doing it with a more efficient machines, so the pipeline took less time. So at the end of the day, that came into a less cost for us. That was a great learning, and it only happened with one team. But then, okay, now I had to go and teach that or share that with other teams. you have to go through all these hurdles, right? showing them that it works, right? Uh, testing all of that. Whereas, you know, if you're able to influence the entire org, [00:12:00] basically you can empower every team to do the same thing by themselves instead of having to go team, by team, by team and, you know, implementing this new capability that you found, right?
This new optimization that you found,
Alonalon--arvatz_2_07-21-2025_133910: Cool. And if I understand
Matanmatan_1_07-21-2025_103918: I.
Alonalon--arvatz_2_07-21-2025_133910: you correctly, you're basically saying sometimes in the shorter term. You can see more savings from a specific team, but you have to look for the long term and make sure that all the teams are on board, because that's the only way to see more results for the long term. Is that accurate?
Matanmatan_1_07-21-2025_103918: Yeah, exactly. When you think about scale, right? Like
Alonalon--arvatz_2_07-21-2025_133910: I.
Matanmatan_1_07-21-2025_103918: You're gonna scale, you're gonna have more engineers in your, in your org, you're gonna have newer people, right? Um, and you wanna make sure you're setting the best practices right around governance. Data retention, for example, right? If you're making sure that everyone does it when they launch a new data bucket, then when new people come in, then that knowledge gets transferred.
Instead of you having to go and find new buckets where someone didn't [00:13:00] put retention policy, right? If you're not creating that governance, those best practices, then that engineer that you didn't, you know, tell him to do some retention policies, he will eventually become an engineering manager. And he would not care about retention policies and his engineers would not care about it. And so there's a trickle effect here, right? Like you gotta make sure your influence, um, and you're thinking long term. So this is exactly what you're talking about, right? How do I do this long term, right?
Alonalon--arvatz_2_07-21-2025_133910: Very interesting. And you also mentioned mentioned that in a Credit Karma finops, uh, lies within the finance organization. Uh, I think if you look at the industry, um, the trend right now is to actually move finops to engineering. And when you describe that, you also mentioned that advantage of coming from finance because then, for example, acknowledgement of good work.
By engineers is, is being more respected or appreciated? I wonder if you see more advantages to having pheno having [00:14:00] finops under financing. Specific
Matanmatan_1_07-21-2025_103918: Wow. That is, that is the question we're going through. Um, because I,
I,
I wanna be honest, like the finops practice within Credit Karma is finance, procurement, and engineering capacity, right? Like there's all these teams that work together
Collaborate together and it works for Credit Karma. I think, um, yes, a lot of the finops practices usually set on engineering. Um, and I think that has a lot of advantages, right? That has a lot of technical aspects to it that I think are very, helpful. I think what works for Credit Karma specifically, um, is we're able to influence things in a different way. so I think. Yes, being part of the finance org allows me and my team to be more objective, to be more, um, independent in our thinking as we work with engineering.
Right. So [00:15:00] I would say there's a different, um, perception of if there's some feedback coming within the engineering org. Let's say the fit ops team sits under the engineering org. They find something to optimize. They surface it up right to their leadership. Um, if it's not a priority for engineering, then you know, it's easy to shut that down. if it's coming from finance, right, we report to the CFO, it's a different, it's a different org. We're independent. able to be more critical, um, and provide feedback a way that maybe, you know, this is not gonna be so easily shut down. By leadership within the engineering org. Right. And I think we do a really good job at this, at Credit Karma of being, just being able to collaborate. And I think it's not all about feedback, it's about opportunities. Um, and the other thing I would say about it, from like a company standpoint, right? Like obviously you're managing company, [00:16:00] so finance org might have more view into like bigger strategic And so our ability to sort of help engineering navigate some of the cost challenges, some of the cost optimizations, um, it is probably bigger. Um, 'cause we're able to see like the, the bigger picture, right? We're able to see their entire company's financials we're, we know what our, um, our goals are, right? Where do we wanna put more emphasis at this point? Is it revenue, is it cost, is it more engagement? Those kind of things. And we're able to translate that. Through the feedback and through how we work with engineering to help them focus on the right things at the right time.
Alonalon--arvatz_2_07-21-2025_133910: And in essence what you're saying is that there is actually a healthy tension between the organizations. So it's not always about how do I make you run aligned and on the same page and, and part of the same team. It's also how I can also create. [00:17:00] A certain, uh, healthy tension that will able to drive action and not brush off cost initiatives.
Matanmatan_1_07-21-2025_103918: Yes, yes. It's definitely, uh, a healthy tension. But let me also caveat, there's, um, disadvantages to it obviously. lot of, uh, companies have the finops under the engineering org because the ones that could also take action. What I feel like, um, is something that from a finance perspective may be harder to do is, taking action to some extent. So like we have to work with the capacity team for them to take action, right? So we have to, it goes back to the IGN incentives. We have to find the right incentives to get them to act on it. Uh, because there's no way for us to tell them, Hey, go do that. Right? They don't have to listen to us.
They don't report to us. Um, and so obviously, you know, with, with finops sort of being, I would say partly in finance, there's an advantage, but also a, a big disadvantage. [00:18:00] Okay.
Alonalon--arvatz_2_07-21-2025_133910: Okay. Very interesting. And I'm also very curious about the fact that you're not calling it, uh, finops at Credit Karma. Uh, is that an issue for your perspective? Do you have intention to try and name it finops or it doesn't matter, like it's all the same, whatever you'd call it?
Matanmatan_1_07-21-2025_103918: I think good question. Uh, we don't call it, we call it finops practice, but like there's not one
team. maybe not to put an emphasize like there's one team that's working on it and
expectation that one team solves all the problems and find optimizations. We're trying to make sure it's, it's, it's it's a total credit karma. Uh. I would say goal to be more efficient with your resources and deliver to members, but at the same time be more, uh, cost conscious and focus on, on, on our goals. to some extent, I think by not calling it finops, like we're basically saying every engineer is expected to do finops, right? to some extent.
Alonalon--arvatz_2_07-21-2025_133910: Yeah, so basically finops is a responsibility. [00:19:00] It's not one person's role.
Matanmatan_1_07-21-2025_103918: Exactly. Exactly. We don't wanna be, I think in a place where we say, um, someone did something in a not efficient way, let's bring in that team to help. Right? We wanna make sure every engineer has good finops uh, fundamentals, right? Someone. even a new engineer coming from either straight out of, you know, college or from a different company, we wanna make sure they are aware of how we do things here, right? Like you cannot just create that new resource without going through the right channels and making sure you're, you're detailed about your work. If you. If you're opening a new, again, data bucket, I go back to that example because I think it's something we struggled with before. If you're opening a new project, you gotta make sure you're putting, you know, retention policies, you're putting the right guardrails to make sure that three, four months down the line, someone from my team doesn't go and [00:20:00] ask someone, Hey, what is that?
Do we even need that? Right? We wanna make sure that there's clear, guardrails and I think we hold everyone to a high. It's a high bar of like finops,
Alonalon--arvatz_2_07-21-2025_133910: Interesting. And Matan, when you talk about the guard rails, are you talking about guardrails? To prevent waste? Are you talking about guardrails to prevent, uh, spending over a specific budget? What do you mean when you say guardrails?
Matanmatan_1_07-21-2025_103918: I think when I say guardrails, I'm more meaning like, um. Let's say you, you wanna try a new open, a new project, right? Uh, guardrails would be used, the machine type that mostly use at Credit Karma, right? Because we're, uh, heavily using, uh, commitment, use discounts, right? Which is gcps cut equivalent of our eyes for Ws. So we wanna make sure that we're, you know, um, making that efficient. So we wanna make sure people are launching things in, in the machines that are. Part of [00:21:00] our fleet, instead of just using like new machines, if we don't have guardrails, if we just say, Hey, engineering can go and spin up whatever resource, whatever VM they want, then we sort of become in a place where we have all this, uh, like broad band of machine types.
And I think over time that's something that we've noticed is harmful because it's harder to manage. You have to manage the commitment separately most of the times. Um, and it's something that is sort of hard to control. And I'll also say that, let's say that happens at a certain point, right? Um, if you look six miles down the line, look a year down the line, um, we often find ourselves looking at our fleet and then seeing some new machine type that maybe we didn't pick up because it was like so small. Because someone created that a year ago, and now we're trying to figure out, okay, who created that? Why did they create that? Do they still need it? Right? [00:22:00] It's, you talk about waste from a resource, but this is like waste of time for us, right? Not just resource, right.
Going back and trying to figure out things.
It's like you were to think about it before, right? You could avoid that waste ahead of time,
right? Then at that point we were like, okay, we need a company, maybe like 0.5, maybe some of our internal tools to go and figure out is this waste? Um, right. And then how do we, uh, remove it?
Alonalon--arvatz_2_07-21-2025_133910: And that's such a good point that waste is not only cloud cost waste. Waste is also time off, engineers time with the fitness practitioner. And when you build all the operations around cloud cost optimization, this is an important waste to take also into consideration
And, and Matan. I'm curious, um, do you feel that the one day we'll be able to prevent waste out there or we'll always have to do some optimizations in the environment post-deployment?
Matanmatan_1_07-21-2025_103918: Yeah. [00:23:00] Um, is a great question. I honestly don't know. We talk about a lot of ais, right? Like there's a lot of talk about quantum computing and all that stuff, and.
Alonalon--arvatz_2_07-21-2025_133910: Yeah.
Matanmatan_1_07-21-2025_103918: You know, maybe at certain point there's something, there's maybe a, a platform that's automated. It helps you identify things before, to your point, they're being deployed. I would say, I don't know if that's today. Maybe that's a, that's something we're gonna go to, but for sure today a lot of waste and I think there's a lot of waste that don't even realize. Right. and maybe I'm touching on some things that 0.5 is doing, but. If a lot of, of the ways that I'm thinking is, we're doing things in a certain way. We know it's not waste because we're doing it that way. It's cost efficient, but maybe there's a way outside of what we know to do it right. It's more of like, how do you shift from one service to another, uh, in a way [00:24:00] that it gets you the same thing. But yeah, maybe it's it's less costly to you, right. Those are what I would call a not so easy, waste, uh, to some extent that you're not even aware of. Right. Um,
before, like there's a way like, you know, um, there's waste that you know of, right? And you're okay with, right? when you think about different things, like maybe let's say a backup region, right? essence, if you have a backup region that's not, you're not using as an active site, right? It's more passive and you spin up the resources then. Technically that's a waste, right? Because you're not using it, but it's something you're conscious about and you're okay with. the waste, I'm more, um, I would say it's not in my, uh, visibility at this point is waste that is doing things a certain way. for example, I mentioned the, the pipeline that we've, um, optimized before, [00:25:00] right? We are doing things in a certain way and now it'll be more technical. GCP data flow. There's like different pipelines that you do, and the cost is fixed no matter what machine you use, right? there is no incentive for you to go with, uh, some of the cheaper machines.
You could go with a more, uh, heavy machine that could do the work in faster. at the end of the day, it just, the pipeline will take, you know, a shorter time and you'll save costs by doing that. But it's not because you change anything, it's just choosing a different machine type. That is something that of the, the system picked up as waste, but it's just something that we said, Hey, let's try to think, make things more efficient. Look at it. And we realized, hey, we're not getting charged by the machine. We're getting charged by the hour. Right? And so let's find a way to use that and find, cost reduction there.
Alonalon--arvatz_2_07-21-2025_133910: Yeah, make total sense. And I can tell you that I personally like to make a [00:26:00] distinction between like more tactical architectural waste to more strategic architectural waste. So tactical can be, Hey, you didn't architect the storage of this, uh, bucket in the right way, or You put this resource in this region should be in other region, the strategic.
Ways says, Hey, you should actually move from Kubernetes to serverless or from this machine type to machine type that is completely different. And this is something more strategic that I think it's actually very hard to predict what will be the effect of that. And it's very hard to make a decision without doing some testing with real life, uh, usage.
Matanmatan_1_07-21-2025_103918: Yeah. No, I like the way you framed it. That's exactly, that's exactly right. Um, and also I feel like. more strategic ones is where people would be more concerned about breaking things. Right. It's
working, why break it? Um, so yeah, I, I totally see that. Um, that's a really good, um, breakout of that too.
Alonalon--arvatz_2_07-21-2025_133910: Cool. [00:27:00] Thanks. And you mentioned using GCP. I'm actually not sure I had many. GCP guests so far. And I'm curious, how does it feel, uh, as someone that is part of the FinOps community, do you feel that you get less, uh, uh, support or you have less resources? Because GCP has a smaller market share?
Matanmatan_1_07-21-2025_103918: uh, my relationship with GCP is love-hate. Um, I think, um, I love what GCP is doing with visibility, giving and, and details and, but it's exactly like you said. Yeah, the community is much smaller, so I think the resources out there are not as. Developed as what I've seen for Azure and AWS a lot of, I would say the, the best practices are things that, um, we sort of picked up along the way and we came up with ourselves internally. [00:28:00] And I think from my knowledge in a WSA lot of things have been external, right? Uh, what other companies are doing and being able to implement that. Um. But I do see, think that, you know, GCP is making a lot of strides towards, um, being like AWS, right? It's like being able to share and build the community.
And I think GCP is also trying to do that. Like within, like internally, they're not trying to go outside, they're trying to, they have their own fan ops practice and they're trying to, to expand that and share some knowledge. Um, and I also wanna say that they're very receptive to feedback. not necessarily, you know, something they would act on.
Right. But they do listen and I think my interaction with GCP has been very positive in them okay, that doesn't work. Maybe we can help you find a different way to do things. So I think the support they've been given is, is sort of different from what I've seen at AWS, [00:29:00] maybe because they're still that growth mode of like trying to get more clients, right. And so they've been more. Um, more attentive to customers. At least that's my experience,
Alonalon--arvatz_2_07-21-2025_133910: Very interesting. And Matt, I actually wanna pivot to another topic that I really, really wanna cover with you before we're running out of time, and that's around commitment management. Just because you share with me some of the advanced stuff you've been doing at Credit Karma. And I think it'll be very beneficial to our listeners that to hear more about it.
So how do you manage commitment?
Matanmatan_1_07-21-2025_103918: Yeah. Okay. Commitments is one of my, um, favorite topics. Um, when you think about companies in general, I think commitments and sort of talking about Rise or cut is sort of the main for companies and the main cost. We really focus on forecasting long term, right? We're trying to forecast at least three years out,
uh, because, you know, those commitments, the three year commitment are the ones [00:30:00] that have, the most cost benefit. and the way we manage it, we really try to forecast three years out thinking, okay, what service is coming? What service is going? The growth rates, right? Like what machine types and what machines we wanna to see in our future. and even if we release some capacity, can other services step into that capacity? But to talk more about the process, I think this is a really good place where the capacity planning team, uh, engineering and finance, uh, collaborate really well in order to get us to a place where every single decision is taken. Uh, sort of a 360 view when we'd make the decision, because we look at not just like what is more reliable, what is more, um, you know, better from a capacity standpoint, but also from like a cost perspective. Um, you, we have this, you know, break even point that we talk [00:31:00] about, if you have a new service coming in, does it make sense to have it on demand or do we purchase Skype for it based on. How much time we expect it to go on, right? There's a breakup breakeven point where the cost is okay. If you think it's gonna go in for, for, for let's say nine months or 10 months or something, maybe at that point, it's worth, like, if you're thinking ahead of time, let's just spy cut for three years, right? It's the same cost. And if that service after nine, 10 months decides to stop, then maybe there's other services that could step into that capacity. So at the end of the day. making sure there's velocity in your business, but you're also being, um, cost conscious and making sure that you're, you're doing things in a way that saves the, the company money. Um, I think our, our practice around like the forecasting is really, um, I think it's really developed. I think there's always room for improvement, but I think we've really made a lot of. Strides with it, [00:32:00] especially since I, you know, I remember my old days, um, like back, like 10 years ago trying to figure out, okay, how much our eyes we need to, to purchase to different companies that I was working with. Um, today, you know, it is a much more advanced and, and to some extent a much more complicated, um, environment
Alonalon--arvatz_2_07-21-2025_133910: Understood. That's great. And I have one more question that will be, I think, an amazing segue to the personal part of the episode. And this is a question that we actually got from one of your colleagues in engineering, and what he recommend us to ask you is, how do you apply the principles of finops to managing the chaos of having three kids?
Things like optimizing bedtime routines or resource allocation during snack time. I.
Matanmatan_1_07-21-2025_103918: Oh wow. Yeah. Okay. That is, that is a, let me think about that. Uh, um, and I [00:33:00] do have to say that you have four, so let me know your thoughts. Um, I will say, uh oh, efficiency for sure. Um, governance. Yeah. I would say efficiency first. I think. well I gotta hear about your stories, but I think my wife and I, you know, with three kids we try to be efficient.
So if, if one's helping the kids with showers, the other one's making dinner. Um, and we're trying to be very, I guess there's no downtime to some extent. We try not to be on our phone through the day and, uh, and making sure we're using the time wisely. so maybe that is efficiency. Um. I would say governance because we're very known around our circle of friends and being like having strict rules around like bedtime, right?
So 7:30 PM kids are in bed. We read a story by quarter to [00:34:00] eight. Eight like lights out because like mom and dad need their time, right? Need to go back to work. Maybe, maybe you need to, to do some exercise or, or you know, learn something. So. We have like clear rules, I think. Um, so maybe that's the governance piece. Wow. That is such a interesting question, but I'd love to hear your take on it.
Alonalon--arvatz_2_07-21-2025_133910: Yeah, so I have all optimizations. I do one that I'm trying, one initiative that I'm trying to run, uh, lately is to have my oldest kids read books to my smaller ones,
Matanmatan_1_07-21-2025_103918: oh wow. Wow.
Alonalon--arvatz_2_07-21-2025_133910: this way it keeps both of them busy and I can go and do other stuff.
Matanmatan_1_07-21-2025_103918: When you think about it, that's actually automation, right?
Alonalon--arvatz_2_07-21-2025_133910: automation. Let's scale. That's scale.
Matanmatan_1_07-21-2025_103918: yeah. It's like when you think about it, you could do things in a certain way. Like you could, you could go reach the shelf and get your kids a glass and [00:35:00] fill it with water and give it to them. You can brush their teeth or you can teach them, right?
And then you're basically automating it once they figure it out and they can do it by themselves. then. Wow, that's, I've never thought about it this way, so
Alonalon--arvatz_2_07-21-2025_133910: Yeah. You need some, you need some older kids to do it. But once they get the right age, that's definitely a doable and recommended.
Matanmatan_1_07-21-2025_103918: Yeah. I love that. I'll definitely, uh, well, I hope my wife won't listen to this podcast, but I'll definitely, uh, think about that. Yeah.
Alonalon--arvatz_2_07-21-2025_133910: Okay, great. And let's learn. Let's learn about you more on the personal level. And first of all, is there a book or a movie that really influenced you and you would like to recommend?
Matanmatan_1_07-21-2025_103918: Uh, a book or a movie. Um. I really liked the, um, co Monte Cristo. Um, I think the film and the book, it's a different versions, but I think film was really one of the, the movies that I've seen multiple [00:36:00] times because, um, it, it's a lot about revenge and how to let go and to let go. Part is what I, I try to practice right through the day, through work.
Through work, being with the kids, right? There's a lot of like. that you're like, okay, you're getting to, to the end of the day and you're like, need to let go. So it's about letting go, right? Just being able to breathe. I think that's why that, that movie always resonated with me, right? Like being able to let go of like, okay, it doesn't matter how angry you are from different things, just trying to move on and, and, you know, focus on life and the, the things that are important in life and not, um. The things that have made you angry Right. Or, uh, pissed you off. So moving forward,
Alonalon--arvatz_2_07-21-2025_133910: Yeah, and that's an amazing message to any parent out there.
Matanmatan_1_07-21-2025_103918: oh yeah, totally.
Alonalon--arvatz_2_07-21-2025_133910: Let it go. Let it go. They'll grow. They will be fine. All good.
Matanmatan_1_07-21-2025_103918: Yeah. Everything, [00:37:00] everything heals or mostly everything heals. Um, I'll be fine. Yes.
Alonalon--arvatz_2_07-21-2025_133910: Okay. And what do you like to do outside of work?
Matanmatan_1_07-21-2025_103918: Outside of work. So with the kids, we love to travel and, you know, um, do some hiking. I recently took on biking. Uh, so if anyone is in the Bay Area and wants to go for a bike run, hit me up. yeah. And then obviously learning, keep learning. I think that's one of the things that, um, I tell my kids all the time. Never stop learning. Always try to find new things to learn and never feel, never stay in sort of your comfort zone. Um, always try to go and learn new things. It doesn't hurt, right? There's always an advantage of learning new things.
Alonalon--arvatz_2_07-21-2025_133910: I am absolutely with you. Getting out of your comfort zone is one of the most important principles for growth. No doubt about it. Cool. Matan, I'm sure that. All our listeners really enjoyed the conversation a lot from you. A lot. [00:38:00] You shared tons, tons, tons of best practices and details and examples, and I'm sure they're all grateful.
I'm personally very grateful if they wanna reach out and learn more from you, what is the best way to do that?
Matanmatan_1_07-21-2025_103918: hit me up on LinkedIn. I'm happy to talk anything. Finops, cloud, um, engineering, everything you wanna talk about finance. So, yeah, uh, feel free to reach out. I'm trying to be, as helpful as I can and, and, you know, connect with whoever I can just to learn more.
Alonalon--arvatz_2_07-21-2025_133910: So guys, you heard him hit him on LinkedIn and hit him hard and learn as much as you can because as you can see, he has amazing experience. Matan, thank you so much for joining us today.
Matanmatan_1_07-21-2025_103918: Thank you, Alon. It's been great. Uh, enjoyed talking to you, so thank you.
Alonalon--arvatz_2_07-21-2025_133910: It was all my pleasure. I also wanna take the opportunity to thank our listeners for joining us every episode. I hope we learn something new. I hope you had, uh, some fun. Don't forget to tell about the podcast To your friends, Matan, thank you again for joining [00:39:00] us. This has been another fascinating, fun episode of FinOps in Action.
See you next time.
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.
Creators and Guests
