 The first thing is to not lose track of all the tools and what everybody's purchasing. I think being very considerate about are we starting to use this resource and where's that catalog eyes, right? Like where can I get an overview of all of the things that we're using, right? A lot of the problems actually with the cloud is people spin things up and later on they lose track of it or there's employee churn or someone gets assigned to a different team and then six months later someone looks at this and says like, do we still need this load balancer, right? It's just like, it's such a trivial resource in every AWS account, right? And you're like, where does it point to? Is that workload still running? Oh, there's some Kubernetes cluster. What is going on there, right? And I think essentially there's a lot of solutions, that help you create this catalog of things that you own in your cloud provider, but also overall like which services are we running? What is part of which service, tagging strategies, right? Keeping that overview is really, really important so that you can actually go over the things that you may not need anymore, right? Because a lot of infrastructure is just laying around producing costs, not actually being used. And that's a big focus of it and obviously very, very important in the Kubernetes space. Every customer I talk to is on a journey to public cloud, some at a much more further stage, advanced stage of adopting cloud, but the reality is almost every one of them is hybrid, right? They've got assets in the data center, they've got assets in cloud. And as they move to cloud, what we see is especially in terms of the cost of operating in cloud, the dynamic changes, right? Because up to now it was all about how do I make sure I plan ahead of my budgeting cycle and make sure that I'm planning for my CAPEX expenditure because I've got to go justify to my CFO that I need to go buy, purchase a whole bunch of hardware, set it up in my data center and then make sure I've got enough capacity, right? So you had dedicated capacity planning personnel that would be responsible for that and determining how to optimize CAPEX. Well, today the world has changed, right? You put it in cloud, guess what? You've got enough resources there, right? So the whole optimization of resources becomes less important. You still have to make sure you've got the right resources and the right place to meet your SLAs. But the problem is how do you make sure you're optimizing the use of those resources, right? Because any cloud provider will give you all the assets you need. The problem is that bill you get at the end of the month, right? You don't want to be shocked. You want to make sure you've budgeted for that OPEX and most importantly that you don't have assets that are idle, that you're not using, that you don't need. So technology that helps you look at that, look at your patterns of usage, understand where there's opportunities for optimization, right? Where you've got idle resources, especially in modern Kubernetes environments. We've embraced Kubernetes in a big way, right? With our own Helix SaaS platform, because ultimately Kubernetes is basically a very scalable architecture, really helps us deal with large volumes of data, managing at scale. But it's also important to make sure you've got the right resources, right? If you don't have the right resources, you've got overallocated resources, especially if you leave it to application owners, they're going to ask for all the resources they want. So understanding trends, understanding where you might have optimization opportunities, both in a Kubernetes environment, both at a cluster, as well as a container level, shifting the mindset from a capacity optimization, capacity planning sort of approach to more of a continuous optimization, continuous cost and budget optimization sort of motion. When you think about cloud and you think about cost, you have to think about it in a few different ways. And it's important not to get tunnel vision in the first, which is that first phase that I spoke about of just moving to the cloud, running more efficient and then optimizing for the cloud. You have to think about it in terms of infrastructure cost in that first paradigm. Second is how is developer productivity and developer time as a cost being incorporated into my cloud strategy? And third and really the future of cost considerations is what are these cloud investments doing to my business in terms of creating differentiated value? I think if you've got a well-rounded perspective and you think about cost in cloud and those three paradigms, you're touching on all the important things that you need to be thinking about when you make these large scale transformations. Don't try to do everything yourself. At the end of the day, you need to figure out what is your core business and stick to that. Best of the things you either collaborate or work with partners, try to deliver a solution, have a better go to market strategy that will always help you achieve your goals faster and in a more efficient way. So that's the usual thing, which I believe sometimes are missed out specifically for startups and some of the small companies. Bigger organizations are very streamlined to give any advice to them. So yeah. The simplest one is to find KPIs that make sense for judging your effectiveness. And it can be a little bit weird because you might not have been tracking some of the information that you need to actually make all that go. And I don't think that having tracked KPIs should keep you from thinking in the terms of KPIs. So for example, I think if you look at your systems and say how many times do I have human intervention in a process? Or how many times does this process fail to complete when I run it? Even if you have trouble coming up with an exact number, I think that you can ballpark in what you want that to be and what it is today. So in some cases, it's an obvious answer. You want zero human interventions. That's not actually even a realistic number. What you want to be able to do is say, all right, I want to go from 10 interventions in these systems to one intervention in these systems. And your teams can actually give you pretty good feelings for how those work, or they can give you a feel for how long a system would go before it needs some type of maintenance or repair, what I would call the half life of your automation. So if your team thinks that they could leave automation in place for six months and not touch it, then that might be a decent goal. It could be that they have to tweak things every week and that's not acceptable. So I think there are very concrete ways that you can talk to a team and find out where they're spending a lot of time and where they think they could improve without even looking at it. I will add one thing that we really started tracking is an interesting metric from a composability and reuse perspective, is we actually provide users of our software with a simple metric of how much of the software they're using is out of the box, meaning straight out of Racken's libraries and how much customers have managed to add or customize. And then they can even look within their own additions to see how much of that is going on. And so our target, just to give you a feel for it, our targets are over 90% of the automation that customers use should be out of the box, standard libraries. Most customers, when they're using things like Ansible or Terraform, writing their own plans, they're down in the 10 or 20% reuse and shared, maybe even lower than that, depending on how things work. And so that type of reuse is really a toil indicator where people are reinventing things or adding components that they have to maintain. And so for us, this KPI of standard libraries is a huge component in success for how well people use automation. My biggest advice is, one is don't just cut costs without the context. You know, this idea of being able to make your service efficient and make your team efficient needs the context of the value that you're paying for. And so one of the metrics I think about is sort of the cost to serve, right? You want to serve your customers at a certain level, but there's a cost associated with that. And if you can get down to those unit economics and truly understand the value, you might be spending a lot of money on cloud, but guess what? All of your customer revenue is dependent on that cloud being up and running. So you can't really just look at it and say, okay, let's cut costs. There are some try-and-true methods and low-hanging proof that you can use, absolutely, reserved instances and other kind of cost optimization techniques, but those have to be put into context. And I think that's my biggest advice is to make sure that you have that context as you're approaching whatever cost-cutting activity you're doing. Obviously, being aggressive about cost-cutting is really important, but at the same time, tempered with an understanding of what's gonna break your business as opposed to just excesses that are unnecessary. Nothing can be changed without a company decision. And if there is a change in culture that is gonna accompany every process that you run, this is something that can really create value, but just buying a tool, just optimizing costs, just firing people is not enough. We're gonna revert to the same kind of old habits. We continue to grow at cloud costs without any experience and whatever. But if engineers understand that cloud costs suddenly has significant meaning and they start to be responsible for what they're doing, and it's really the same with as we construct DevOps just a few years ago, that engineers understand that now operationally they are responsible for their code. So now they're responsible financially as well. And if a company can really get that shift in motion, then tools are gonna help, and companies can be significantly better in what they're doing. But first and foremost, it's a decision that the company need to make, and you need to back it up, you need to change the way that they're thinking about cloud cost and everything will flow from there.