FinOps in Action

FIA - Ruby Agarwal
===

Ruby Agarwal: [00:00:00] As an engineer, as a student, you are expected to know your technical skills. beyond the tech stack, it's about systems thinking.

It's about decision-making. It's your... And I don't call them s- soft skills because they're not soft skills. They are critical analytical thinking in a structured way. It's about being able to make decisions.

Intro: welcome to FinOps in Action. I'm your host, Taylor Houck. Each week I'll sit down with FinOps experts to explore the toughest challenges between FinOps and engineering. This show is brought to you by 0.5, empowering teams to optimize cloud costs with deep detection and remediation tools that actually drive action.

Taylor Houck: Hello, and welcome to another episode of FinOps in Action. I am super excited about today's guest. She is an executive whose world is a lot bigger than just FinOps. She runs engineering, and if it [00:01:00] has the word ops in it, think DevOps, DevSecOps, CloudOps, and of course, FinOps, it rolls up into her. Ask her about cost and she'll tell you this: FinOps is not just a cleanup job that you do after the product ships.

It is an architectural decision that you make on day one. She learned this firsthand about four years ago when her team was able to cut cloud spend by roughly seventy-five percent in just two months. Today, she is the VP of engineering at Avaya. Welcome to the show, Ruby Agarwal

Ruby Agarwal: Thank you. Thank you, Taylor. It's really nice to be here, especially with FinOps X happening, what, one week ago, two weeks ago? There were so many different messages coming up on, uh, LinkedIn, if you may, and I wish I was there. I believe you did go there, right?

Taylor Houck: No, Ruby, I, I missed it, uh, because my wife and I recently welcomed our, our first daughter, so I wasn't able to make it. I've been to, [00:02:00] uh, just about every other FinOpsX. But you're right, it is a very hot topic right now, and there's so much going on, especially as the world is changing so rapidly with AI and SaaS spend and all these other aspects.

But before we get into that and get too future-looking, I wanna kinda go back to that project that I had brought up in the introduction where you were able to reduce your cloud spend by 75%. Can you bring us back to where you were in the world at that point in time, and what you discovered when you started pulling back the layers on the cost of your cloud infrastructure?

Ruby Agarwal: Absolutely. So was a project which was multi-cloud, um, multi- multiple layers across the different clouds. Um, it had voice, it had data, it had messaging, like all kinds of, of, uh, capabilities, if you may. It had, uh, compliance. So, you know, when compliance comes in, there's all kinds of different a-aspects that come [00:03:00] into it.

So I was asked to look at... We were in multi-digit, double-digit of dollars spent across COGS and ICE, and I was asked to look into it and see how we can, A, reduce cost. Reduce was the, uh, one of the things, but the other thing was how do we not get there again after we reduce cost? So went in, uh, collected a team of two or three people across the different and we basically cataloged everything. We had a spreadsheet. I wish AI was there at that time, but it wasn't. It's easier today. But we went in and in the Excel, we literally had one row for everything possible, and we followed... We, instead of saying every nitty-gritty, here's this network endpoint that has this much cost associated with it, we went after the big buckets [00:04:00] We said... And then we had separate spreadsheets for COGS and ICE. We did not want to make any mistake on COGS. COGS always followed after the ICE, but we made a list of everything, sugges- uh, went through, okay, this one is, uh, compute We don't need it running twenty-four/seven. For example, in labs especially, we started putting in budget alerts.

We started putting in shut scale down and restart Friday evening, 8:00 PM scale down. Monday morning... Or Sunday evening, 8:00 PM, we brought it up because we had teams across the globe who were using those shared labs. we consolidated in case of, uh, expense, for example. We consolidated activities. Every developer was still thinking about it from the on-prem world.

"I have my own lab," and no, you don't need your own lab. You can share activities. You can do local labs. So there were [00:05:00] several different activities. We went through storage. We went through orphaned disks. We cataloged all of these things and started shutting things down. We went to lower tiers of the database.

We went to lower tiers of some of our messaging bus, for example, where we needed to. was more building that visibility for the team was the step f- first step, and then reach these two, three folks. Like I said, we built a team. We built the visibility. We started the visibility in Excel very quickly, got a Power BI dashboard, if you may, it to all the teams, and suddenly it becomes a fun exercise for everyone to be able to cut down cost because when you see what you are spending, you know that's not the right answer. we went to production, and we went through the same activity on production. On dev, you can say, "I don't need backups every day. I, I don't need three sixty-five days of retention for something." On production, it's different. So we [00:06:00] went through very intentionally across the entire landscape, took the top, I would say, five to seven, um, aspects of the solution that we could actu- where we saw the maximum cost, and then started working down the chain. So that's how we reached there

Taylor Houck: Really, it's just about going through and really understanding why you are provisioned the way that you are and what really the requirements are under the hood and seeing, hey, do these things match up? Can you help give me a, a sense as to the scale of the organization? And can you also speak to how you collaborated with your developers?

Let's put production aside for a moment, but let's say you're going to these, you know, developers, as you're mentioning, they're used to the on-prem world. They have their way of working. When you come in and you are, you know, taking resources away, even if the data suggests that it's not needed, that is still impacting their day-to-day work.

How do you see the best way to work with these engineers to ensure that they come [00:07:00] along for the ride and are a partner in getting to these outcomes that you're looking to achieve?

Ruby Agarwal: Most of the time have seen, um, there's three things that bother developers. A, it will slow me down. Number one, they say it will slow me down if you consolidate or if you take away something. B, how do I continue doing my feature work if I'm gonna spend time deleting something or adjusting something?

That's the second question they ask. Everyone wants to do good. Nobody says, "I want to spend extra money or waste money," right? Um, so going back to visibility, the first thing we did was we built the visibility. It doesn't take that long. You, you know, we're not talking perfect data. You just get the macro level information.

And this is where a lot of people make mistakes. They actually go to the nth degree of detail, and you don't need to. You just get a macro level, one [00:08:00] slider. Nobody has time to re-read through 20 pages of detailed information. One slider with the key aspects. Then you tell them, whatever time you put in it will be tracked, and we will have to figure out and negotiate either with product or leaders, leadership, whichever ways, but you will get time to accommodate, and only the top buckets will be...

And over time, this isn't a do it overnight. This isn't a you did wrong. This is more about making your intentional decisions and taking it forward. And then the next is, well, what if I have to do chaos testing? We'll spin up a lab when you need to do chaos testing. We don't need to have a 24/7 lab if you're not doing it.

If you don't need to do chaos testing every, all 15 days of the sprint, you may need it one day for three hours, for example. We'll build a s- so we built a system in place. We said these labs are for this purpose. Start up, st-shut [00:09:00] down. We had a couple dedicated developers building the tools, so not everybody has to actually go figure out, spend time bringing something up. It was more culture building. It was more training and constant communication that sort of brought the team on board in o- you know, to be able to do this.

Taylor Houck: Yeah. I mean, you spoke about a really big number, right? 75% cost reduction. And to get there, it sounds like it's equal parts, you know, technical expertise of how do we actually get this done? How do we understand the optimal cloud resources or architectures? And also the other part is the people in the process and getting everyone to come along.

And without both of those pieces working together, I'm sure you wouldn't have achieved all the success that you did

Ruby Agarwal: and it isn't just engineers if you think about it, right? You have to talk to your operations people. You have to talk to your finance team. You have to talk engineering, of course, your architects. You have to decide which parts you are intentionally [00:10:00] taking out of the system. So it is cross-collaboration.

We had a very, uh, you know, multi-layer system. We basically said, "Okay, weekly we're sending out your updates." So when people see results, they enjoy it. So we used to send out weekly updates on this is where it is, in addition to the constant, uh, uh, constant, uh, reports being there or the dashboards being there. Uh, one... I remember a conversation with one of the developers. He said, "I used to get this anomaly report on the increase." Now, one particular week, he got the anomaly report on a decrease of a cost, and he was like, "Did we delete something incorrectly?" So

Taylor Houck: It almost scares you a little bit

Ruby Agarwal: yeah. So it, it was a fun time.

Taylor Houck: Hey, well,

Ruby Agarwal: Yeah.

Taylor Houck: I, I think that, you know, when you look back at these big cost savings, it's something that a lot of us that have been in FinOps for a while kind of saw, and it's something that I think a lot of us got the kind of got the bug once [00:11:00] we realized those initial cost savings, 'cause it really is fun.

It's a little bit addicting and it's so, like, quantitative and, um, measurable, like the cost savings. And oftentimes, uh, especially a lot of people, it's, it's such a big financial impact that you're able to make that it really gets you excited about pushing forward. But there's also the other side, which is another thing that I alluded to in my introduction, which is that really FinOps at its best is not a reactive practice, right?

It's one thing to be able to say, "Hey, I went in and found all this waste and we cut it out and we reduced cost by X million dollars." But in reality, if you were doing things properly, you wouldn't have gotten to the point where that was even achievable. Can you talk about how today you think about FinOps and achieving and, or, or putting, uh, cost optimization or cost-aware culture into engineering best practices?

Ruby Agarwal: You know, I've been very fortunate that I've worked on projects which I've inherited, like the one that I just mentioned, but I'm also working on projects that are totally new. [00:12:00] And when you start a new cloud project, it's... You don't... Not many people in the industry always get to do those things. So we have what we call Avaya Infinity.

We just launched it a year ago. uh, our COGS model was built before we wrote the first line of code. Point being, we have to be very intentional about managed services we're picking up, how we are sizing our infrastructure, what kind of compute we're bringing, what database tiers we're bringing, what kind of retention are we going to put in our lo-logs is one of the biggest cost, and as we all know, in the um, uh, structure, if you may.

So the whole, uh, security is another one. I don't know, logs and security are probably, uh, d- uh, competing with each other into which one will be more expensive But long story short, [00:13:00] we actually made it very intentional. Our COGS model was defined before, like I said, um, we wrote even a single line of code.

But not only that, we published it with the and we measure it every month. Again, make... Have the visibility, but you also need to measure it, and you also need to sure that anytime anything new is being brought into the system, so the visibility... When you say how did the engineers change? Now it's more like if somebody needs to introduce a new, s- new hardware or a new service within the solution, they actually bring it forward themselves for a conversation before we go ahead and do it. So again, a lot of it is, you know... What I've learned is over time, we've sort of built behavioral change within the team as opposed to just giving them [00:14:00] dashboards and saying, go look at it." So it's become part of... And I'm not going to say 100% of the team is there and the 100% of the people look at it, but there's a subset of people who are always on looking at it, thinking about cost anytime we, let's say, add a new service or, uh, change how things scale, et cetera, et cetera.

Taylor Houck: Can you talk to me a little bit about when you're doing this, when you're looking to introduce a new service or you're building a new feature and you're thinking about the cost element upfront, what are the types of personas that are involved in this? Is it like the cloud architect that's thinking about cost?

Do you have dedicated FinOps personas? Who is it that's in the room bringing that cost lens?

Ruby Agarwal: I would say It's actually multiple people. So it, it start... Depending on where the particular feature or project originated. Not everything originates from, let's say, the architecture. [00:15:00] Uh, sometimes things, uh, originate from even SRE, example. Oh, I need to turn on these specific logs on this system,

Taylor Houck: Yeah

Ruby Agarwal: So depending on, uh, where the, uh, request originated, um, if it's from the architecture, then they're going through the process and making sure, yes, this is cost, you know, this is cost-efficient. If it's coming from SRE or support teams, they're often not the first ones to think about cost because they're like, "I need all the information I can to troubleshoot faster," right? So in that case, they will ask for logs to be enabled or certain logs to be enabled, and it may come to, for example, the DevOps team, and they're like, "Wait, let's talk about it," right? may be a time where somebody in DevOps team, uh, forgot about it or didn't think it would be high. All these... Then these checks and balances come in play because you'll turn it off in one lab and [00:16:00] then suddenly that lab's cost goes high and you're talking about it.

Or our SecOps team, like we have our entire CISO organization, they may see it in log analytics, for example. So it depends on where the issue or the topic is being originated. In terms of FinOps being... Is there a se- dedicated FinOps person? I do believe there is. There sh- is and there should be at least one or two dedicated FinOps people because there's a day job and the day job and the evening job. And when you are an engineer an engineer in the engineering org, at the end of the day, you are dev- developing software that is actually providing customer value and you're building the product, and if you had to pick between when there's an issue in the field or when there's a deadline that is looming over your head, your first priority is to finish your feature and yes, you may miss.

Even if you got the alert, you may... You'll be like, "I'll look at it tomorrow." So there definitely is a [00:17:00] FinOps. There... A sense of, in my mind, a FinOps person who, whose sole job is to constantly be monitoring, looking at FinO- at the cost across the system and thinking about things. And this person may not even be the person who knows the entire technology or is understanding the full architecture, but they're talking about how am I, uh, t- how am I... Like, A, my en- entire work is looking at the en- the entire spectrum, right? Fin... To me, it's not just the cloud cost that I consider cogs, for example. You may have support, vendor support. We all know Microsoft, Google, we have our support contracts that are high. You, you may be using third-party soft- Where you may be using...

Whatever you're using, all of that together is what your entire COGS model is, for example. And you need to... That person's job then is to make sure we're putting, making sense, [00:18:00] putting it all together, making sense of it and saying, "This is where we need to change," or, "I need more information," et cetera, et cetera

Taylor Houck: Really to just echo back what I just heard from you is that number one, it really is not just one person or one department's job to think about cost. Really, it's everyone working together and that kind of acts as a check and balance such that when one group or organization has a particular incentive or they're really looking to get a feature out, maybe another group is gonna catch on the cost aspect as well.

But then with that, especially I think once you reach a certain scale, having someone dedicated and focused on cost will pay for themselves many, many times over

Ruby Agarwal: Oh, absolutely yes. Absolutely yes

Taylor Houck: I, I kind of want to fall back on something that you mentioned earlier because I think it's important, is when you were talking about laying out, um, the, let's say, opportunities for cost reduction or helping, you know, folks understand the, the [00:19:00] lay of the land and you mentioned, hey, keep things super high level.

It's better to have a one-pager than a 20-pager when you're looking to get people on board. I've heard a lot of people explain this as like the 80/20 rule, right? How do you put this into practice within your organizations, generally speaking?

Ruby Agarwal: so I talked about, let's say, the information together with the, here's where we're spending dollars, here's where we're spending Y dollars, right? As you... And even, like, you go to Azure, you go to GCP, any of those, you don't even have to have an Excel, you can just go to their cost explorers, if you may, and let it show the top, uh...

L-Let it just show your monthly cost, for example, right? Even there, it will show you this is the higher cost. This is 20%, this is 30%, this is 50%, and then other. I would use that same mental model and say, "Don't focus on other first." Focus on those 20, [00:20:00] 30, 50% that was shown over there. Do your daily graph for a month, month.

See which part is, what part in there is consistent e-every day. See what you can bring down on the weekends, et cetera, et cetera. And sometimes cost isn't just... Not sometimes. Oftentimes cost is not just about removing or reducing resources. It's about evolving your system, software, to actually adjust to your traffic patterns, for example, And so there's a, there's a lot that goes into cost optimization. There's a lot that goes into determining you want to focus first. Yes, we will also ultimately get to the lower low-hanging fruits, but first go ahead and focus at the top ones. And like I said, whether you use an Excel, whether you use Power BI or one of these newer tools for your dashboarding, [00:21:00] whether you use a straight Azure Explorer or GCP cost, uh, optimization tools, whatever you're using, just go ahead and look... s-don't look at the other, just look at the top ones and start focusing on that

Taylor Houck: Yeah. And the way that I think this ties to what we were just talking about is that when you have so many different people across the organization that are thinking about cost as part of their job, but perhaps it's not their day-to-day, having them just be aware of these, you know, 20% of things that you should pay attention to as it pertains to cost.

I mean, the example you gave was logging. Hey, we know logging is a big cost for us. So when someone starts asking about new logs or increasing log retention, that cost flag kind of comes into my mind a bit versus, you know, other, let's say, uh, services that are lower on the list where you can be more, let's say, quick with the approval or just spin it up.

That's kind of how this all kind of comes together in my mind.

Ruby Agarwal: I'll... I agree, and I'll tell you something. I've had, um, there [00:22:00] was this team I inherited two years ago, and they were building a prod- they were, they had a pure cloud, um, implementation of a particular, would say, mega service. And there was so much fear put into this team's mind. If they wanted to add anything, any service into the cloud, it was like, "Oh no, we shouldn't do it.

This will be cost. no, we shouldn't do it. This will cost." And the pri- and they would then go and figure out how to build something like that themselves. And I'm like, "You don't do that in the cloud world." It's okay temporarily to increase cost. It's okay to introduce new services that give us value and not have to re-implement all that. is not okay is building something or leaving something out there that we don't need. that was... And I mean, this person is one of our biggest cost [00:23:00] proponents right now, but with a very changed mindset, for example. You do not have to shy away from using the right systems and the right capabilities.

You just have to be on top of it and pick the right ones

Taylor Houck: Yeah, it's not cost that's the enemy, right? That's kind of something I would always bring up to my, my team. It's like, "Hey, if we want to bring cost to zero, we can. We'll just turn everything off," right? But obviously that's not an option because we're getting value out of these services that are running in the cloud.

So if cost itself is not the enemy, what is the enemy? The enemy is inefficiency. The enemy is when you're leaving money on the table. We could be doing exactly what we're doing. We could rec- we could receive the same level of performance, scalability, reliability, security for a lower cost footprint.

That's what we're looking to avoid. We're not looking to gut out costs entirely. We're looking to be efficient with our spend

Ruby Agarwal: Absolutely

Taylor Houck: Uh, I do wanna shift gears slightly, and this is a topic that, uh, I think to some people it's very, very interesting, and it [00:24:00] is operating in highly regulated industries. My understanding is that you at Avaya run in a regulated space.

Does that change anything about how you think about FinOps or managing engineering, uh, uh, projects more broadly?

Ruby Agarwal: At its core, it's almost the same. It's the same principles. What you do need to make sure is you are... You have disaster recovery, you have retention, you have, um, you know, all of the, all of the... All aspects about compliance, you need to have that. This isn't a, like a play project where it's a webpage and a database and you can do things. You really need to have all of your compliance taken care of from a regulated industry perspective. principally it's the same thing, but [00:25:00] otherwise, um, in terms of meeting the compliance or in the, i-in the regulated, uh, environment, do need to make sure that you have, uh, all of these things. way I would a question, like if somebody asked me a question, "Why don't we move this workload, for example, to a cheaper region?" The answer may be it's because of data residency, because it, you know... Or latency or compliance or a customer may want their workloads in a specific region. So we have to go a little bit beyond cost. It's cost within constraints is what I would go for. Often the cheapest option, it's not really a good option if it creates like audit or sovereignty or trust risk

Taylor Houck: It's pretty much exactly what we were just describing, where it's not cost [00:26:00] that's the enemy. And actually when you're operating in these highly regulated industries, you're gonna have a higher floor because as you were just mentioning, sometimes you need HA and DR. And when you're just looking at the raw utilization data, you might see, hey, we have these servers and they're running completely underutilized.

What's going on, guys? Let's do something about this. But then once you, you know, peel back the layer, it says, "Hey guys, this is absolutely

Ruby Agarwal: need death.

Taylor Houck: Required. This is critical. This is

Ruby Agarwal: Yeah

Taylor Houck: do not pass go," right? You know, like we need these HA and DR servers or we need this to be running, you know, in a, a multi-region kind of setup

Ruby Agarwal: Or a specific region for that matter. GDPR, I mean, you talk about it all the Eur- European, uh, um, e- even Canada, Europe, Canada, all of these countries, their rules require that their workloads are running in their region.

Taylor Houck: Yeah. Where all of a sudden, hey, we, we can't run on Spot because

Ruby Agarwal: Yeah

Taylor Houck: cannot afford to have, you know, our, our resources taken away from us without any notice. We-- Maybe you can't run open [00:27:00] source. Now all of a sudden you're having to pay more for your licenses. But this isn't a bad thing necessarily, it's just considerations that you need to be bringing into your decision-making criteria

Ruby Agarwal: yes. And that goes back to our conversation about your first bill... Cloud cost bill will be dependent on what architectural decisions you have made for your projects

Taylor Houck: Absolutely. Absolutely. Now, for the sake of time, we're getting, uh, somewhat close to the close here, Ruby, but I do want to bring up the absolute hottest topic in FinOps, uh, but even more broadly in tech right now, and of course, I'm talking about AI. My understanding is that you actually have recently put some AI agents into production.

Can you walk me through how you're thinking about AI within your organization right now, and where do you think this is going, especially as it relates to FinOps?

Ruby Agarwal: I'll talk about FinOps specifically. So I think of AI in two zones, uh, innovation zone and production zone. [00:28:00] So when I talk about innovation zone, you have to be creative. Curiosity is going to be there, and you're gonna try things. And what is innovation zone? It's you trying out different things, even like all the sort, you may be writing 100%, uh, agentic code, if you may, development. But then that code is going through QA, that code is going through its, um, cycles and then getting to production, and it's like any other code that is being executed there. Once it's in production, it's not touching AI, right? There, you need to control your, uh, and put limits, whether it's individual or group basis, whichever ways, just to make sure that you are not waking up in the morning with 100,000 bill or whatever.

But that's, that's become sort of standard now. Pretty much everybody is taking care of or at least looking into it and, uh, y- you know, investing in AI for their engineers for that matter. But putting caps on what we are spending monthly [00:29:00] or daily or whatever it is. It's the production zone that is very interesting to me.

So you start talking about agents in production. Um, again, different organizations are at different phases of their maturity. For us right now, when we talk about production agents, we've got some production agents, for example, that we're using for DevOps troubleshooting, right? And these DevOps troubleshooting agents, you know, pipeline fails, we have error messages, we send it to our agents.

Our agents are, uh, you know, the agents are trained with cer-certain knowledge base articles and a lot of other things, and they're coming back with, "Hey, here's what the problem is. Here's what your next step is," for example. They're not autonomous yet. I'm not ready for that yet to have them work on my production system. But even for that, let's say that's the one, even for those agents, you have to talk about, um, their security and make sure they're within the region. [00:30:00] But when it comes to cost, they don't have to be the latest models. So for example, for me, I'm not using Claude 4.8 for that, right? I'm using a much simpler... I don't need reasoning over here.

It's trained based on my knowledge base. In fact, I don't need it to come up with all kinds of fluff answers right now. So what I've, what I have done is I'm using a lower cost, earlier model With a lim- with a limit even on that one. And I'm getting very good results from that perspective. M- would I need maybe if for another use case, let's say I'm doing proactive monitoring of one of my workloads that is a call processing workload. Sure, I could have some telemetry sent to another agent and say, "Okay, go apply some reasoning logic to this one." And there, sure, I might use a reasoning AI [00:31:00] agent for... or a model for it. But for these use cases, I don't. So I'm very cautious about what agents I'm using, both from a security and a FinOps perspective.

Taylor Houck: I think it's so easy to get caught up on this because oftentimes, especially-- And we're getting to the point where these capabilities have been amazing for some time, but especially like, I mean, in AI, the world is changing so fast. I mean, even if you just go back to, let's say, Q4 '25, Q1-- uh, Q4 2025, Q1 of 2026, the capabilities were so new.

You're coming up with all these amazing new use cases, right? As you mentioned, let's create this agent to help with our DevOps processes. And when you're testing it, it just kind of makes sense to the human mind, let's throw the most powerful model at it and see how it does. Now, lo and behold, it does pretty well.

Okay, this is working. This is great. But you never went back and reevaluated, did we really need that most powerful model? And people also don't, I think, always understand the differences in cost between these models. I No, mentioning like the most powerful Opus model. [00:32:00] I think that's 15 times more expensive than like Haiku, as an example.

By the way, Haiku in itself is even more expensive than some open source models that you could run,

Ruby Agarwal: absolutely.

Taylor Houck: So the, the, the difference in cost is even greater than like, I think a lot of us that have been around the FinOps space, we're used to like different types of different kind of cost structures and the hourly billing rates, and there are some pretty big differences.

But the differences in model costs can be even greater. And then there's also, you know, within these models, you have different models that have a different, you know, ratio of input

Ruby Agarwal: absolutely

Taylor Houck: cost. Now, what's your use case? Are you using a lot of input? Are you using a lot of output? You really have to understand how you're using the model to know what's the right one.

Ruby Agarwal: Not only that, you also have to think about, do I need to use the model every single time? Oftentimes, because AI is the hottest new thing, you're like, "Oh, I'll just throw this question to AI." Uh, this... Maybe it's just a standard automation,

Taylor Houck: And it's, it's like I've seen so much where [00:33:00] you can... You know, let's say you're using AI to build this agentic system. Well, it could turn out that all of the steps in that system are deterministic, okay? So you can use AI to build a deterministic workflow. Now your AI costs are only in the design

Ruby Agarwal: stages. Exactly

Taylor Houck: and the build phase.

On the run phase, you're actually not incurring any AI costs, perhaps it's just like serverless or, you know, invocation functions and things like this

Ruby Agarwal: I am seeing that use case a lot more where people are confused about, "Oh, I could just throw this to AI." And I'm like, run it a few times, get your prompt, get your deterministic workflow, and then build that into the product."

Taylor Houck: 100%. Now where, you know, uh, where do you see this going, right? Because, uh, these capabilities are not slowing down. When you think about what, I, I'm gonna say FinOps, but also more generally, since you manage the entire engineering function, engineering best practices, engineering processes. If you play us forward [00:34:00] another six, 12, 18 months, what do you see coming that maybe, uh, some of our listeners might, might not be seeing?

Ruby Agarwal: I do believe that it's hard to say, by the way. Things are moving so fast. It is very hard to say where

Taylor Houck: I know all AI predictions it is okay if they don't come true.

Ruby Agarwal: Yeah

Taylor Houck: operating on what we know today in June of 2026

Ruby Agarwal: it's very hard to say where we would be in 6 months or 12 months. FinOps space or any other space I think it will all be about operational intelligence. There'll be a lot of data coming out of different systems. There'll be a lot of signals. How we use that signal to make decisions, the, companies that are actually focusing on that are the companies that would be successful.

The age of dashboards, that's gone. What is going to be there is about critical [00:35:00] decision-making based on the data and using AI for that decision-making, as it comes through. I don't believe that, uh... I don't, I don't know. We'll, we'll have to see how it goes in, let's say, the next, uh, next, uh, six to 12 months.

It's going to be about, I would say, cost discipline. Like, if we talk about cost discipline, it's going to be more important because at this point we see intelligence scaling faster than governance, and we'll have to be very, very intentional about how we use this int- intelligence

Taylor Houck: Ruby, it's gonna be amazing to watch it all play out. I know you're gonna be right in the, uh, the epicenter of it. Uh, I'd be keen to have you on in another couple, couple quarters to see, uh, if we could reflect on what we [00:36:00] talk about now and, and run it back. But, um, really have appreciated your, your perspectives and, and with your experience and all that you've been through in not only managing FinOps, but also entire engineering practices.

It's such a valuable perspective that I think that all of our listeners should really, uh, appreciate and listen to. But before I let you go, I kind of want to give our listeners an opportunity to learn from you, but not just about FinOps or technical aspects or specific to engineering, but more so on the career side.

I, I think, um, the opportunity to learn from someone who has kind of risen through the ranks of an engineering organization and, um, seen so many different, let's say, technological shifts. Like, although, of course, you have not been through the entirety of the AI wave as we were just predicting in the future, but you've seen other waves come and go, I mean, cloud being, uh, one example of that.

If you were to, you know, give advice to a younger version of yourself who was starting their career in the, the 2020s or let's say one of our [00:37:00] listeners today that's in the earlier stages of your career, what advice would you, would you give to them as they embark on this journey?

Ruby Agarwal: I would say build the skills beyond the tech stack. So, um, actually did a re- s- uh, session recently for, um, for a group of young students in Ghana, and, uh, this was basically about building your skills beyond the tech stack. As an engineer, as a student, you are expected to know your technical skills. beyond the tech stack, it's about systems thinking.

It's about decision-making. It's your... And I don't call them s- soft skills because they're not soft skills. They are critical analytical thinking in a structured way. It's about being able to [00:38:00] make decisions. Um, it's about, um, being able to articulate communication, for example. Being able to articulate what you are about to present. Those are the things that are going to take you forward, and connection building. I wish I knew that one, or I had focused on that one in my early career.

Taylor Houck: I know that you work a lot with, uh, with students and hearing about how you were giving a session in, in Ghana. I'm, I'm keen to hear some more about, about that. Can you tell us a little bit about some of these, uh, extracurricular activities you do to, to give back in your communities?

Ruby Agarwal: Sure. Uh, I've just recently started. This isn't very-- It's been a year, maybe a little more than a year. Um, there's a couple of organizations that I'm attached with. Um, one is Upwardly Global, the other one is braven.org. Um, they have, for example, Braven has twice a year, in the months of [00:39:00] October and March, they do mock interviews for students all over the U-US, different schools, Delaware State University, San Jose State University, et cetera. And so every week, four day, four weeks in a month kind of thing, they have mock interviews, and there'll be, like, three students that we do 20 minutes of mock interview, preparing them to go in the world. So actually-- And some of them, I'm connected on LinkedIn with them. It's very nice to see their journey from the time I met with them. So that's something that I do. I'm actually similarly looking into United Way. I've been in touch with the lady right now, um, trying to, um, do some coaching on AI or even AI mentoring for some underprivileged communities. So that's something that I'm starting to get into.

Taylor Houck: Ruby, I think that is so important and the world is lucky to, to have you and, uh, to have the opportunity to learn from you, and even just coming on this [00:40:00] podcast is a, a great example of that. So really, thank you so much for, uh, coming on the show

Ruby Agarwal: thank you. It's, it's been a privilege for me being here,

Taylor Houck: Amazing. And thank you also to our audience. If you got something out of today's conversation, which I'm sure that you did, please share this episode with someone who needs to hear it. This has been another amazing episode of FinOps in Action, and we'll see you next time

Outro: That wraps up another episode of Fit Ops in Action. Thank you for joining. For show notes and more, please visit fit ops in action.com. This show is brought to you by 0.5, empowering teams to optimize cloud costs with deep detection remediation tools that actually drive action.