FinOps in Action

FIA - Erik Norman
===

Erik Norman: [00:00:00] it's better to have a slight risk of waste than losing revenue or, uh, customers or, um, damaging your image of your company. tagging is not the goal.

The tagging is a tool.

Intro: Welcome to finops in Action. I'm your host, Alon Arvatz. 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 tip detection and remediation tools that drive action.

Alon Arvatz:Hello everyone and welcome to another episode of finops in Action. Today I have a very, very special guest whom I've been waiting for so much time to get on the show. And finally we got him. He actually has a background as a CTO product manager and a technical product manager will talk about the difference as well.

Later on, he later translated his expertise into finops. He [00:01:00] claims that he hates consulting, but nonetheless, he provides pheno consulting services to small and large companies, and I promise you he has the best horror stories in the pheno industry. I'm happy to welcome lead finops at British Airways.

Erik Norman. Erik, how are you today?

Erik Norman: I am great. Thanks for having me on this show.

Alon Arvatz: Of course, it is all my pleasure and honor. Erik, you have so much experience in finops and beyond. Please share with us and try to be open. What is the one thing you actually got wrong when you started your finops career?

Erik Norman: Yeah, so that one actually was quite a horror story as you said. Um. So we were looking at waste and we found some, uh, volumes and we, uh, tried to find some policies so we could automate it all because I am a fierce believer in automation.

Alon Arvatz: I.

Erik Norman: stumbled upon this and I thought, you know, maybe we should look into it because it's a quick win if we just delete it manually. [00:02:00] was a 9-year-old backup image of an EC2 instance. And I mean, if you think about it, no security patches for nine years. Uh, who would run that in production, by the way? It was not even in a production environment. It was in a staging environment and it had only one tag do not delete. Otherwise. There was no documentation, nothing. Uh uh, we, I spent I think one or two weeks just to find out. Who, who could possibly know about this? And I found no one. Basically, everyone just shrugged their shoulders. I don't know. I don't know. But if it says, do not delete, you should not delete it, right? I asked my manager. And he said, delete it. And I said, yeah, I'm not sure.

You know, it's, uh, I have a bad feeling about this. Um, and he said, no, no, you should delete it. I mean, come on. And I said, no, I don't agree with you. And so we started arguing basically, and tricked him into sending [00:03:00] me, uh, email reprimanding me of not following his direct orders. And then I actually went on and deleted the, uh, image. Okay. And couple of weeks later, um, a Monday morning, my email inbox was full with questions why I had deleted that image. It turned out to be a. Disaster recovery image. So the problem was, um, that the disaster recovery for this legacy application, which could not run on newer EC2 images than nine years old, was undocumented and had no log output whatsoever.

So the support when the, uh, legacy application shut down, simply off basically fell over almost, they run the, the disaster recovery script. And thought everything was okay, but cus customers [00:04:00] continued calling and they run it again and again and again and took them basically like a whole weekend to figure out that there is something missing. And yeah. And so they tried to reach me and uh, I told 'em, Hey, uh, yeah, it was me who deleted it, but check this email from the manager here. And yeah, so. If I remember correctly, we even lost a big customer over this because

Alon Arvatz: Oh wow.

Erik Norman: SLA and uh, the cust Okay. It was the tipping point for the customer.

So it wasn't, this was just, you know, the drop, uh,

Alon Arvatz: And Erik, what is the moral of the story? So obviously have documentation on the resources and tagging properly. If your manager asks you to do something very, very risky, make sure you have his instruction documented. Is there anything else that you feel you learned from this, uh, situation about how to do finops?

Right? Were you supposed to look more for the right person, what you should have done differently?

Erik Norman: [00:05:00] Um, well, I would, uh, should have established the risk better. Because, um, if we don't know what resource we are facing, we have no idea about the criticality. We have no idea about, the business value of that resource. And it's better to have a slight risk of waste than losing revenue or, uh, customers or, um, damaging your image of your company. Right. So we should simply, even if the engineering now says, yeah, nobody knows about it, who would run something that old in production, um, we should simply say, okay, um, let's stay there. The account owner will make a decision.

Alon Arvatz: Yeah. So in other words, you say, Hey, know your priorities.

Erik Norman: Mm-hmm.

Alon Arvatz: cost optimization, uh, is important, [00:06:00] but, uh, disaster recovery availability, that's more important. So have the right risk assessment.

Erik Norman: Yep, exactly.

Alon Arvatz: Okay. That's a great insight, and I know that you also have a lesson learned that you shared with me in the past around what type of consulting, um, jobs you take and what type you don't, right.

Erik Norman: Yeah. I normally define myself as a contractor. Because consulting is the reasons. There are so many features in PowerPoint and I don't like those consulting gigs where they spend, I don't know, a hundred k and then just get a PowerPoint presentation and nobody's going to act on it. what I love to do is, um, working. Basically as an employee, almost with the responsibility of an employee and, and the loyalty also of an employee. The only thing is that, um, the nature of my work, uh, is such that where I live, I don't find much work. So I have to work across borders. [00:07:00] that's why even opened my consulting company or contracting company be able to work across borders, business to business without the hassle of employment across borders and taxes and such.

Alon Arvatz: Gotcha. And is there a consulting or not consulting job that you wouldn't take? I.

Erik Norman: I would say my red flag, number one, the only one remaining, because I mean, if they ask for, uh, someone like me to come and fix things, then that means they have all the red flags that you would have in a large org, like communication silos, uh, political wars, internal, uh. Office politics and and whatnot. So those red flags I ignore, but I will never again take a job without proper executive sponsorship because yes, you can work your way up, but it takes so long time and you have constantly a target on your back. especially if you're working as an [00:08:00] external, uh, you know. Every time something happens between an internal external, normally it's the external.

It's just, you know, not even contract terminated. That's another thing. You have this beautiful one or three year contract. They just say, Hey, we have no project for you. stays, but we have no project to pay you for. So. That's also these legal loopholes where you ba basically have a nice contract but you don't have a job.

Uh, so no. So I need executive sponsorship, uh, and also in the right position because, uh, it has happened to me now more than once that I've been hired by the wrong team. Imagine being hired to fix reporting, fix, uh, the, the cost data pipelines and, and all of that, not have access to cost data. That maybe is responsibility of another team. So if you are in the wrong team and have your hands tied, and maybe there's office politics, so they're even ghosting you, then yeah, it has happened that it took me almost four months to [00:09:00] get access to data and then I was fired because I couldn't reach my performance objectives. Um, so it sounds ridiculous, but that is what happens oftentimes.

So it's, I've, I've definitely improved my skills at stakeholder management and also at um. Making sure that I get the working conditions right before I start the job.

Alon Arvatz: Yeah, and double clicking on that. Would A CFO buy-in be enough, or you would necessarily look for engineering or IT leadership buy-in as well?

Erik Norman: Um, I would say C-I-O-C-F-O is preferred because they have the hand on the budget. And the side effect of a good finops practice is normally a good cost reduction. So I don't believe in cost optimization as such. Um, if you, for one simple reason, if you tell cost optimization to someone who has no idea what finops [00:10:00] is, all of them think cost reduction and that's it. So yeah, if you only optimize for cost, they would say, shut down everything a hundred percent cost saves. Where's my bonus? So that's not even what the company wants, if you go, then you should follow the value, right? Um, and the value realization could even be increasing cloud cost because you are. Maybe carved to the bone too much, and you have service degradation and failure. So you're losing revenue, you're losing customer and market share because you have unhappy customer. So maybe even increasing cloud costs increases the perceived value, the business value of your cloud, uh, infrastructure.

Alon Arvatz: Yes, that's, uh, very well understood. And Erik, uh, when your profile on LinkedIn read, he doesn't believe in either cost optimization or tagging strategies. Is that what you're alluding to?

Erik Norman: Yes. Yes. Also, uh, tagging strategy. I mean, I know there are even [00:11:00] people teaching tagging strategy classes. is is a tool. There is no strategy. The strategy is for cost allocation or for transparency. That is what you want as a strategy. That's your long term goal. But tagging is just a tool. I mean, if you have perfect, um, context separation by accounts, so you have an account for every kind of environment and application and workload, then you might even not tag one single resources and still be able to per perfectly allocate all costs, right? So in that sense. The tagging is not the goal.

The tagging is a tool.

Alon Arvatz: Yeah, so you're basically saying that it has to be tailored to your organization. Like first, ask yourself, okay, what I want to achieve with tagging. And then build a tagging strategy around that instead of replicating what someone else did in a different organization. Okay. That's very, very helpful. And um, Erik, I know that, [00:12:00] uh, shift left is also a topic that's very, very close, uh, to your heart.

And with that also the role of technical product manager in the shift left, uh, process. Can you share with us what is your vision? How an organization need to do the shift left.

Erik Norman: So let's start. What happens if you don't shift left in finops? Uh, then you will have something running in the cloud, and you will, as a finops practitioner, you will reach out to the operational team and say, oh, okay. You have oversized resources. You have maybe old instance times, and, uh. And that is all.

And maybe some unused re um, unused something or some backups laying around for nine years and stuff like that. Then you just go there and try to reduce waste and you try to, um, retype and recess to make it more efficient. But that brings you only so far and not far at all. So we'll have some cost [00:13:00] reduction.

Yes, you may make it more efficient, but the thing is, The of your cloud solution architecture, um, dictates the costs, right? So if you have the wrong cloud solution architecture for what your business is doing, like for example, think Amazon Prime, uh, Amazon Prime was serverless. When they started, right? Sorry. Amazon Prime video was serverless in the beginning, simply because the scale of their operations. What was better serverless then the user base becomes so big, so they switched over to running a virtual machine instead. And made it more cost efficient. So you see the data access patterns and volume and everything actually dictate should dictate.

That's my hope should dictate, um, the cloud solution architecture because for every data access, um, type. And [00:14:00] volume, you have exactly one most efficient, solution architecture building block. Okay, um, just also tell an example on we can get there. Because if you look at the cost aware product decision, uh, white paper that you find on the finops org website, um, that's if you have very enhanced product teams who can estimate cloud costs, but those are very rare. If you have, for example, just done a data center exit and migrated everything to the cloud, those product teams have no idea how to estimate cloud costs. now comes the, the trick. the simple step is not to ask them to estimate cloud costs, to estimate the usage. They know their user base, they know their licenses, subscriptions that the user pay. They know when they're gonna launch new features and everything, and they, for each feature, they know [00:15:00] exactly or should know exactly what kind of data. Is being, uh, transferred, manipulated, and stored. And by data I don't mean the technical term data, I mean simply as a collection of information. So you could say, if you have something that's an invoice, you need to check simply, how long should I store that invoice in the cloud and when can I delete it?

Right? Or if you have sales data. there's a big difference between transactional data that you just dump somewhere for legal compliance and for an audit, or if you have something that you actually want to analyze and show and, and maybe pick up later. so that exercise is simply to ask these product teams, what kind of information will the user. Basically create, manipulate, store and transfer implicitly, you could do that on a piece of paper. So that [00:16:00] has nothing to do with the technology underneath. It's just simply the kind of data, the kind of information and how often we expect the user to do this, and how many users will we have, right. And think about one example, like that is so important. Let's say we have a web shop, let's say Amazon Web Shop, okay? You have a huge amount of users, okay? But the kind of how the data is created is important. Uh, let's think about orders, right? You can only have one order open at a certain moment as a user, right? And I as a user can only see my own orders. I cannot see the u uh, orders of anyone else. So dictates that We should, for example, not go down the typical roof of a relational database where have one, one big table of all orders. No, they're using I, to my knowledge, they're using something like Dynam dp. So where you have the order [00:17:00] objects under the user. And that is one, uh, big improvement already because then you have all your orders already collected at once.

The other thing is the insertion order is very important because you can only work on the most recent order that you have, And if that is closed and you say, I want to work on an order, you will open a new one. Now how can you find the last order? Simply, you go to the list of orders and take the last entry. that is closed, you create a new one. So the insertion order is a very specific aspect of how the data's insert, manipulated and transferred. should dictate the choice of the database and how it's accessed afterwards, because if we didn't do that, then we would have a very heavy query to just identify the last order that they're working on. Right, and that is what I mean is why I would love to have a technical product management team they [00:18:00] can review together with the product teams, their information, their specification about what kind of data is being transferred, right, and how often and volume, and they can basically establish data access patterns. they will then. Build building blocks or create building blocks and decision patterns so that if you create a new application or service or feature, you will simply go the question, is it transactional? Will it be picked up later? Do we need some regulational? Uh, database or is it more analytics? Is it more, um, uh, transactional and whatnot?

And how long do I need to store it? Will it be accessed through analytics platform and reporting later, or is it just dumped for, uh, auditor reason or, uh,

Alon Arvatz: Yeah.

Erik Norman: And I mean, if you build all that, uh, those building blocks, then that means that your solution architecture teams will only pick those building blocks, the approved bonds. And that means that then later you will have the most [00:19:00] efficient architecture possible for each and and service. And you then should go to the exercise and confirm that. So you pick the operations team and ask for performance metrics. You go to the phenoms team and ask for cost and user report and analytics there. And then you go through and kind of, let's call it efficiency review. And once you've completed that cycle once. Then you can enrich the product, uh, teams with cost estimates. 'cause they will tell you what kind of data we'll have and you can reply, this is what it's going to cost even before you have the product.

And it will be basically empirical data showing you how much it'll cost and not just, uh, what finger in the air.

Alon Arvatz: Fascinating. And basically, if I understand correctly, Erik, what you're outlining and if I'm trying to simplify it to say you have the product manager defining what the product should do, what value should bring, taking a product manager breaks it into [00:20:00] building blocks of what, what happens in reality.

Something that is easy to translate into architecture. The cost implications of the architecture. And then the architects bring the cost estimations back to product and tell 'em, Hey, that's how much we're gonna, it's gonna cost. Do you wanna change anything? Are you okay with that? Et cetera, et cetera. Is that

Erik Norman: Yeah.

Alon Arvatz: less accurate?

So basically, the person who needs to do the translation from specs to dollars is the architect. Is that accurate?

Erik Norman: Uh, but I would not leave it with a central solution architecture team there. I've seen that, um, if you ask them to build a hundred products with similar access patterns than depending on which Solution Architect lands with, they will provide a different solution.

Alon Arvatz: Gotcha.

Erik Norman: would rather have, um, some central team that. Is basically product agnostic and just [00:21:00] looks at data access patterns, building blocks, that's it. And they help the product teams to um, you know, have accurate, uh, specifications. And in that team, I would simply pick a couple of senior solution architects and say, Hey, what's the best efficient way to do this?

And this is your work from now on and leave the Junior Solution Architects. You just use those building blocks, right?

Alon Arvatz: Yes.

Erik Norman: that is how I would do it. Um, otherwise we will have fan boys, uh, like Kubernetes fans that use Kubernetes whenever they hear cloud. And I mean, you, you know, it's true. You find that out in the wild. and I mean, if you just talk about AWS, there are over 200 services and there's so many products that just used three of them more or less,

Alon Arvatz: Yes,

Erik Norman: and that's scary.

Alon Arvatz: I agree with you. I agree with you. And Erik, if I take you a bit back, so you obviously, [00:22:00] I won't say against. But you see less value in maybe cost optimization, more value in cost aware architecture. Uh, do you feel that organization needs, uh, both. Do you feel it's like a maturity process? You start with optimization, you move to architecture, or maybe you say job optimization.

It's a waste of time. Focus on cost away architecture.

Erik Norman: Um, I, I would say it depends where we start. let's take a legacy company, a large one that just migrate to the cloud. have plenty of low hanging fruits, right? Um, the first question I would ask every. Product owner is, do you even still need your product? Right? You just go through just one list of products and ask them, and if you do that, you will see that if you have done a data center exit, there's so many applications no one is even using [00:23:00] anymore, but there's still running.

So you just, we'll find there is either no owner at all, or the owner says, well, honestly, I have one monthly user on it and I think we can turn it off. Uh, and stuff like that. So there are plenty of low hanging fruits that you should always start with, because, how can I say, changing the architecture of all your applications, that will take time. But I would start that process as soon as possible

Alon Arvatz: Gotcha.

Erik Norman: as soon as possible, even if it's a long term, uh, strategy.

Alon Arvatz: Gotcha.

Erik Norman: the other thing is, um, how can I say, which application would you even start with? To analyze the data, access patterns and stuff like that. And I would say there is one rule, and that is the cash cows, like the ones that are generating the most revenues. Leave them maybe in third, fourth, fifth position, but go with [00:24:00] those that still generate enough costs then you go and go to the product team and ask simply what the business requirements are. Okay. Um, you could, even without checking the architecture, having even zero architectural artifacts, can still identify if the architecture is sufficient or not.

Alon Arvatz: Yeah.

Erik Norman: By simply checking, for example, let's say, uh, Spotify. Okay? We have, uh, there must be a license database somewhere, okay? Because you are either a free user or a registered user. So either access Spotify without being registered, right? So if you think about it. And look at the performance metrics of that, um, central licensed database, then you should have one monthly access per user, not more, because they pay monthly.

That's the business requirement. That's how the [00:25:00] business says it. But if you search for music a hundred times a day, you should not have a hundred. Request to the license database, right? So that is already how you really can say, okay, for each, um, feature and service, let's look what the business requirements are and the business, what the business value of it is, and then you can guesstimate what the minimum. Most efficient amount of moves of data is basically how often you transfer is stored, manipulated, and then simply say, okay, let's see how often it happens. Because, uh, if you're just 10, 10 or 20% off, it's good enough, most likely, right?

Alon Arvatz: Yeah.

Erik Norman: But I've seen, uh, cases in the wild where we were 10 million times off the, uh, minimum efficiency.

Alon Arvatz: Yeah. Okay. Very interesting. And I actually wanna show you my perspective about the cost aware [00:26:00] architecture. First of all, I'm all in. On that, like I think it's really crucial and I love the framework you share with us. I think it's very, very helpful. Um, I will say that sometimes I feel that people put too much weight on shifting lift, both from architecture perspective and also from, uh, guardrails to prevent waste for two reasons.

Uh, one, I think it is very, very hard to predict costs. So yes, the technical product manager can make assumptions on how the usage would look like, but honestly, cloud infrastructure is the, the world of unknown. Um, and it's hard to tell how users will adopt a certain feature, and it's also hard to predict how the infrastructure will behave until you see it in product.

So a lot of the things that are hard to predict. On top of that, I think that optimizing existing architecture versus. Rea architecting is typically easier to implement, so it's a lot easier to make a [00:27:00] change of configure. You mentioned DynamoDB. It's a lot easier to create provision capacity or, or change the, the type of the business model there.

Versus moving from DynamoDB to an SQL server, for example. So my, my perspective is that you gotta have both, like you have to have this cost aware architecture, but also at the same time maintain a cost optimization, a program or ongoing efforts and they actually compliment each other versus, Hey, not this Yes, that.

I'm curious what you think about that.

Erik Norman: Yeah, I agree that you need to do both. You cannot just, you cannot do only long-term strategy, and you cannot only do tactical operations to reduce cost. So in the long run, if you want to reach the goal of a certain maturity and and efficiency, need to do whatever you can on all fronts to get there. And, um, [00:28:00] so, and that, but still, I think you still need to follow the value more than the costs.

Alon Arvatz: agreed.

Erik Norman: And, You could have a team that does cost optimization as such, they go through all the resources, retype and re uh, resize, sorry, and change some configuration to make it more efficient or enable intelligent tiering, enable compression for CloudFront, whatever.

I mean, those are the simple fixes that you could almost automate or have a team just run through and, and, um, requires fairly little human intervention, um, at the same time. If you don't follow the value, then you might go optimizing workloads you don't even need. Or you might optimize workloads that are not responsible for the cost, even if they generate the costs and, and there have a good example of a cloud backend where several finops teams already had [00:29:00] tried everything in the book. Literally like there was a list of, I don't know, 30, 40 items of initiatives they had already done, they were very close to having service degradation of failure constantly, simply because they were so downsized to the very edge. And the challenge here was they had a quite high workload, like for each tenant there were easily like million requests per month. then they had also. Really hard spikes. Um, once a day, more or less, and. So it was very, very difficult to go there. And I basically just, you know, run to my, checklist of things that should be done. And it was done, done, done, done, done, done, done. Everything was done. And I said, shit, how can I, can we improve this here? And then I really start following the money Sorry. So following the value instead of the money. And I started asking about the nature. What are they even [00:30:00] doing with this cloud backend, right? And it was a. Retail backend where they had all the configuration of the stores with the prices, the items, the, the campaigns they could run and all of that. And the business requirements were actually, I had to research almost a month to find them because they were somewhere in a Slack chat. They weren't even central documented as such. Um, and they were simply to have, if there is an update in the cloud backend. the connected shops should also get their updates more or less instantly, as in within reasonable amount of seconds.

Right. And the other thing that was a business requirement is that at the end of the business day, they should upload all their transactional data, as in all the sales transactions they had. there were two problems with this. Um. This is why I say don't follow the only for, don't only follow the cost, but also the value is, [00:31:00] um, the desktop applications, if they are programmed inefficiently, they don't generate costs that you see centrally. They will maybe raise the electricity bill by half a percent at the customers, they won't even notice. But to keep themselves updated, these desktop applications as the backend once per second, is there a change? Right, so that generates per desktop, application, two point something, 6 million requests per month already, right? So you cannot simply downscale the backend if you have like 10 million average requests per tenant. And the other challenge was that were all configured, all the stores were configured to upload their data at the same time. So you have this stampede of requests getting in and I mean, [00:32:00] that generates lots of problems, obviously. So the trick was simply to go from constantly from, from the desktop application was to have a simple, uh, notification queue where the content of the message for that notification was actually the change itself. That already made the, the request per month drop to basically on less than one per average. And also, yeah, simply diversifying the time when they upload the session sections. Actually, we did it once per hour, more or less, slightly randomized so that after an hour of sales transactions, you would upload one block. And it basically reduced the, the cloud and cloud backend to that point that we could downsize this to almost nothing.

And we also managed to consolidate databases, which was they had one database instance per tenant, [00:33:00] stuff like that. So now we could simply go back and have one large, uh, database for all the tenants. yeah, we had a massive cost reduction and that was 98.4%.

Alon Arvatz: Wow. Amazing, amazing, amazing, and a great story as well, Erik, last. Professional question to you, a question I got from someone who knows you very well, and he urged me to ask you, and what he told me is ask Erik that question and then, and I quote, sit, take your popcorn, relax and enjoy the ride. and uh, the question is, what do you think about the iron triangle?

Erik Norman: Um, I find it very useful for short term explanation in project management when somebody has to decide what they should do next. Now the fun thing is, uh, it's even in the finops book as how you should do your project management. If you do something, you should [00:34:00] either go for either, yeah. You know, you have costs, you have, uh, quality, and you have speed.

Okay? These are the three, you cannot have all at once, right? And I disagree so fully with that, you can have all at once. Think about the TPM thing that I explained further before, right? If you have predefined building blocks. Then you can build high quality, efficient, uh, applications very quickly. So you get both the speed, the cost, and the efficiency all at once, right?

So Iron triangle, sorry, debunked, uh, it's very helpful as an explanation tool, but uh, you should definitely not use it to prioritize the tasks if you want. Go for a radar chart instead,

Alon Arvatz: Okay.

Erik Norman: where you basically have your points and grow your capacity or maturity on multiple levels, uh, at once. Yeah.

Alon Arvatz: Yes. Okay. That's a great insight as well. One of many that we got on the show today, [00:35:00] and Erik, I particularly like the shift left framework and the fact that you talk about cost optimization from value perspective. I think when people talk about, hey, look at the business value and not only the cost, they usually talk about, hey, show the organization what value they get from the cloud.

And not only how much they spend on the cloud, but I think you take it to a whole new level. You're saying, Hey, when you understand the value, be better. When you understand the business model, you understand what the users at the end should experience. That can also drive significant optimizations. So I think that's an amazing insight, and I'm not gonna let you go.

Erik, before I learn about you personally, a little bit more, and first and foremost, you live today in. Theno area in Italy, right?

Erik Norman: Yes.

Alon Arvatz: I'm not a big accent expert, but I don't think that you have an Italian accent. I wonder how you gotta Italy.

Erik Norman: Uh, we cannot change that immediately if you want [00:36:00] people. Yeah. So, uh, my parents are Swedish and I live in the German speaking part of Italy. How could you not spot that?

Alon Arvatz: No, I, I suspected German. I, I was sure it's not Italian.

Erik Norman: Yeah. So, uh, I live in the PO that was Austrian until World War I. So, um, there are German schools here. I grew up speaking Swedish at home. They sent me to German speaking school, Italian as a second language school, and then I picked up English later on.

Alon Arvatz: And how did you get to Italy?

Erik Norman: My parents moved here before I was born, so I am born here. I have Italian passport, everything Italian except my name in my face,

Alon Arvatz: Gotcha. Okay. That's nice. is.

Erik Norman: by the way. Um, you told me before something about how I look at value. Something I forgot to mention before is I even help managers report their own value better.

Alon Arvatz: Oh,

Erik Norman: Because what I've seen, um, a friend of mine, he. Was hired to reduce cost of [00:37:00] the company. Okay. Which is for me, also one of the red flags.

Alon Arvatz: okay.

Erik Norman: And the fun thing is the, uh, usage.

They had a huge success with this company, and the usage went up by, I can't remember, 78%. Okay? And the cost stayed the same. He was fired because he didn't reduce the cost.

Alon Arvatz: my God.

Erik Norman: And another thing that I've learned, uh, so that is how I have learned also from security people how they. Report the importance of security teams because if they just pop there, uh, and that's another friend of mine who did that once. Um, he just thought, wow, a large org Fortune 500 zero security incidents in one year.

So that's a major achievement in anyone's security career. the issue was. Um, he got fired because they thought, oh, why do we need you? We had serious security incidents. what he learned in that moment, you should [00:38:00] report on how much, uh, problems you have avoided

Alon Arvatz: Yes.

Erik Norman: by investing that much in security. Also, if you. As an IT manager, just report your budget, right? So let's say that you're spending 12 million at the, at the moment, in the room say, oh, 12 million, that's a lot. Can we cut that? Maybe 20%, 30%. if you

Alon Arvatz: Okay.

Erik Norman: that we are driving a hundred million revenue. And we're spending 12 minutes on it and we have an growing customer base and to continue to deliver our services, I need maybe three, 4 million more just, you know, to keep up with the operations and everything. but we will double our revenue. Then they say, Hey, hey, give that month some money. Right? But if you just report your costs then, and don't report what value you're bringing to the table again, then that's why I think it's. Think about, there is no [00:39:00] mention of cost in the finops definition.

Alon Arvatz: Yeah, no, I agree. And I think one way to look at it is really okay, how much u the usage was increased in comparison to the cost. Uh, there is also another lens you can take, and I think you alluded to that when you gave the security example, is that you can communicate what problems. You help, uh, avoid or, or prevent, and in the finops or cost optimization, uh, world.

So you did 1, 2, 3, 4, 5 actions of optimization. You can measure how much cost avoidance or savings, however you wanna call it, was created thanks to these actions. So document it, translate it into actual doors that were saved, and then you can come at the end of the year. It looks the cost stay the same, but the savings were whatever, $2 million.

And that will thanks to the cost optimization program. So that's another way to look and communicate it. Um. Great. Another great insight by the way, [00:40:00] but Erik, you obviously really experienced, really passionate about finops, but what do you do for fun? I'm sure you have something beyond finops that you do to have some fun.

Erik Norman: Well, um. I love hiking, so I live in a very beautiful place on earth. I live in the Alps in the northern Italy, so Dolomites are not that far. and also, yeah, I just go outside and I can walk up to the mountain basically directly. Uh, that's also why I want to live here and work else.

Alon Arvatz: Oh.

Erik Norman: So I love the place where I actually stay.

So hiking. Yes, definitely. I love walking. I also love cooking. I'm a foodie at heart. And, uh, yeah. What else? Um, I love British Crime Series. I

love British tv.

Alon Arvatz: Oh wow. Really a Any, anyone specific you would like to recommend us to watch?

Erik Norman: Uh, for example, the fall line of duty. It's [00:41:00] very intense also, but I mean also the calmer ones that are, to say they are more real. If you look at AmErikan tv, it's oftentimes everyone is either super beautiful or super ugly. There is no people in AmErikan TV anymore.

Alon Arvatz: Yes.

Erik Norman: also exaggerated and polished.

But in, in, in British TV you often find people that have, you know. That look like people on the street and you just picked them and made them actors. That's how they look

Alon Arvatz: Yes. They, they're called, they're real people. Yes. Yes. They're real people, real people. Cool. Um, so I have now a new show that I need to watch. That's great. British Crime series. That's cool. Great. Um, Erik, thank you so much for everything you shared. That was absolutely incredible. It's really evident that you have tons experience and all the insights are backed by [00:42:00] experience and stories and evidence, so it gives us a lot of enforcement, so that's great.

I'm sure. People would love to reach out, ask you more question, maybe hire your services at some point. Not consulting services, finops services. So what's the best way to reach out to you?

Erik Norman: Uh, they can find me on LinkedIn. I'm very active there and I'm always open for chat.

Alon Arvatz: Yes.

Erik Norman: And by the way, I read one very good sentence today, and that is if I can give you advice. It's not because I'm smarter than you. I've just been through more shit than you.

Alon Arvatz: That's always true. That's always true, and even if you don't wanna reach out to Erik, I recommend to follow him on LinkedIn. Because he said he is very active and he has great insights. He shares there, and some of them are very provocative. That's always great to challenge your assumptions when it comes to finops.

So personal recommendations, uh, coming from me. Erik, thank you again for sharing it. As I said, [00:43:00] like the optimization through value. I loved it. And also I'm sure that all our listeners learned a lot from your framework for shift left and, and the way you think about things. And I'm sure they'll remember it because they all came along with horror stories that I'm gonna remember until the end of my life.

thank you so much, Erik for joining us.

Erik Norman: Thanks for having me. This was fun.

Alon Arvatz: Uh, it was fun for me too, and I'm sure it was very, very fun to our audience that Lisa, uh, to us once again, thank you for joining again. Don't forget to tell your friends about Fops in action and also subscribe to our, uh, blob fops in action.com. Erik, thank you again.

This has been another fun, fascinating, interesting episode of Ops in Action. See you all next time.

Outro: That wraps up another episode of finops in Action. Thank you for joining. For show notes and more, please visit finops in action.com. This show is brought to you by 0.5, [00:44:00] empowering teams to optimize cloud costs with tip detection and remediation tools that drive action.