Episode Transcript
[00:00:00] Speaker A: Today we have Eric Norman, the FinOps lead at British Airways. Eric, how are you doing?
[00:00:05] Speaker B: Great. Still recovering a little bit. I got some cold and flu over the holidays but you know, shit happens. But, but otherwise, no thanks, I'm fine. And thanks for having me again.
Always great to see you.
[00:00:18] Speaker A: Yeah, always great to talk to you, man. And you know, holidays are a tough time for, for our health and for our boys and for our, I think for our weight as well.
But, and you know, it's, it's going to be fun to, to discuss with you because today we are going to frame it, you know, around context. And I think context is one of the most, you know, important things in, in phenoms these days, especially to, you know, to get people around the practice and to buy leadership and buying from, from our C suite. So, you know, to, to kick things off. You know, what exactly is context driven finops? And you know what? Why does it matter?
[00:01:02] Speaker B: Well, I think it is one of the most important aspects in any discipline that is cross departmental because without the context we might use the same words that have different meanings with different stakeholders.
And with stakeholders, I don't only mean Personas, I mean really stakeholders within a certain company because if you have certain processes that have a certain name in one company, the same name might be different in another company.
So it's not that if you go from one company to the next that you can assume that the same terminology means the same thing again.
And it's all about driving that context awareness in all conversations.
[00:01:54] Speaker A: Yeah, and you know, we are talking about this, building this awareness, but to build that, like how a team should go about assessing, you know, the context for finops.
[00:02:07] Speaker B: Well, normally they have their own context, which is their team. So they have their background, let's say it's an engineering team, so they know what risk means for an engineer.
So if now they talk to somebody from finance, then risk means something completely different.
And so in that sense, I think it is often the bridge between these teams is often the FinOps team and they should be aware of these contextual differences between teams.
And this means they need to provide a new context for these conversations.
So when they bridge these conversations between engineering and finance, for example, they should make sure that both understand what they're saying when using these words.
So that creates a new context. Right. So within context of a FinOp stakeholder meaning, we agree on that, we use certain words in a certain way and that is again a new context. And if you don't consider these contexts, then you lose a Lot of information on the way or you have large disconnects or large misunderstandings that you won't fix.
[00:03:28] Speaker A: Yeah, definitely. I think that what you said is pretty interesting because we always talk like talking the right language for the different Personas and adapt and all that. But what you're saying is like, okay, let's build a common context and then in that common context we adapt for each of them and we build something. So the communication is pretty clear, Right. And maybe to illustrate this, can you walk us through a situation where the finops like standard practice failed because of the context, it wasn't understood or wasn't fit for the case?
[00:04:06] Speaker B: Well, I won't tell you which project it is because I cannot share. Of course I can talk about it without naming names.
So I was hired to build a FinOps platform and I tried to convince, but the thing is this is a normal non tech company and I tried for weeks and months to convince them that building your own FinOps platform doesn't make sense. Right.
So the ROI is very low and so on. And we were almost at a point at discussing this to almost shouting at each other like you have been hired for this. They told me do it right. So they were really insisting on I should build this platform or help them build this Philips platform.
And I was really saying no, why should we do this? This is nonsense. And it took us several weeks to figure out that within that specific company a platform is not necessarily a software, a platform for them are the platform teams are providing services through third party companies and third party tools and own tools or glue code or whatever. But foremost the most important thing they do is to provide documentation on how to use it and how to onboard.
So their platform is actually a collection of documents on for example how to use the FinOps tool, how to get access to the FinOps tool, or also how to create a new AWS account if you need it. Right.
So there is was nothing like a traditional sense of a platform.
But since they are used to using platform in this special way, I thought they wanted to build a really proper platform on their own, which obviously wouldn't make sense. So it took us several weeks actually to figure out this disconnect.
[00:06:22] Speaker A: That's crazy and that's very related to what you talk about context. So just to dig a bit on this because I found it pretty interesting. It's like the idea was to try apply, let's say more of what now is called like platform engineering kind of system where you have like a central base with documentation, templates and all of that so people can reuse but apply it more of on a finops or is it different to what I just said?
[00:06:51] Speaker B: This is more or less just a central hub for all documentation regarding finops tooling.
And also there might be some ETL pipelines involved in the background which are simply documented there so that the, let's say consumers of anything finops know that it doesn't happen by magic, but somewhere there's a pipeline that gathers information from one tool and injects it to another tool or into a data lake or something like that.
So it's definitely not a traditional platform engineering platform.
[00:07:26] Speaker A: Okay, okay, okay. But this, it's a very interesting approach and you know, it's something that I haven't heard of in FinOps and I find like from my experience in, in DevOps, let's say which platform engineering was very into very like, although with differences, very, very useful approach. So you know, to avoid that, that situation, like to avoid this losing several weeks into that. What, what you would have done before if you could go back and do this assessment better.
[00:08:02] Speaker B: Well, it's fairly easy. I would have made sure that my context is the same as the other people's context and I should have made sure that my interpretation of the specific word platform was actually platform.
I tried, I think I'm fairly sure I tried to get to, how can I say, to be sure we are agreeing on what we mean by platform. And I think they simply were so used to using platform in that sense they didn't think about it. So for them it was platform.
So yes, sure, we're talking about platform.
And I said well if we're talking about platform then it doesn't make sense. And they told no, no, no, we are talking about platform and it makes absolute sense.
[00:08:52] Speaker A: So that's like same word for two people. It's totally different thing, right?
[00:08:58] Speaker B: Yeah. And that, I mean even led me to creating a now manually created, but a glossary which is context specific.
So that means for every entry, like for example risk, I provide a terminology that says in the context of this, it means this. So one entry in the glossary has several meanings depending on the context.
[00:09:30] Speaker A: Yeah, like, like in language.
[00:09:32] Speaker B: And I think I can anticipate a little bit of here I am helping a FinOps, sorry a AI for FinOps platform by curating their content and I've convinced them to create a context aware ML platform. So basically what happens is if somebody uses a prompt and the context isn't clear, the AI has been instructed to make sure that the context is clear to avoid misunderstandings.
[00:10:07] Speaker A: Yeah, no that's, that's very interesting and it's one of the things like I have to say that I use you know, a lot to do for the business and for, for everything and you know, refining that context and you know, making it aware and make it efficient and that it, and let's say it knows the, where it comes from and what's the context of what you are asking for is super, super crucial for making like you know, AI efficient in terms of the outputs you get.
So yeah, I think that's super interesting stuff but they want to move on to a bit more step by step thing. So let's say that we are a team, we are in a finance team now and let's say we have figured out this first step which is like okay, we know the context now how does the context driven finops differ depending on the size? Because we have people is listening from a startup or for a mid size or for a large enterprise and context is super different if you have worked in all those types. So once we understand the context, how does it change between these types of companies?
[00:11:19] Speaker B: So in principle there is no difference in the approach but in the intensity or amount of work required.
So I'll recover the word I said before about bridging conversations. Right, Bridging departments with these conversations.
So typically the larger the organization, the further apart are the stakeholders and the bigger and stronger the bridge must be.
In a startup, people developing the product and maybe running them might be the same person.
So little effort needs to be done to make them understand themselves.
But in any documentation about processes and so on, you should always make sure that the context is clear and that the. Let's say that the target reader has been at least defined but otherwise, I mean the process is the same. You need to make sure that the stakeholders understand each other. It's simply that in smaller companies they are closer. So you need less effort to bridge these gaps.
[00:12:33] Speaker A: Yeah, and I think it's also why I think that can be applied to almost any type of practice. Like not only phenos but almost everything.
[00:12:44] Speaker B: Like anything that's cross department, right?
[00:12:47] Speaker A: Yeah, it's way more difficult to. Because you have way more layers normally like depends on the company instruction and all of that but you have way more layers to deliver a message.
So you need it first to be super clear.
Two to be communicated like a lot more to it reaches, you know, it's like you have a lot of people to reach so you need to communicate a lot More and three to make it like simple so that is easy to understand. Like it's not the same to you know, when you are, you know, talking, let's say not talking to yourself but you are understanding something and when you're trying to explain to someone else, it's like you need to simplify things and to make it super clear so that the message is understood. So as much people you deliver this message, the more let's say simple or the more clear it needs to be to deliver that to, to their people. So you know, very interesting, very interesting analysis that you, that you just made and you know, can you give us, let's say one specific finops practice that you think it changes between being in a startup or being in a large org that you know, you think it's super different from one to the other size of companies.
[00:14:04] Speaker B: I would say the biggest change that you see is how easy it is to hide in a large organization. Organization, yeah.
And with that I talk about accountability.
So if you've done any large migration to the cloud or from the cloud or whatever data center migrations, you will realize there are plenty of applications that nobody even knows who they belong to.
So there's plenty of that as a large problem.
You can obviously have that in a startup that somebody tries something and forgets to delete it from the info infrastructure and then it just keeps running or just keeps generating costs, you have that as well. But the, how can I say how much it changes across the size is exactly this. The accountability is much more difficult to achieve in a large organization.
And the transparency also.
And the further away the teams are from each other, the more difficult it becomes also to make the first step into collaboration, let's say for example, I join a new large organization, they haven't done anything finop so far. They just migrate to the cloud. And there are teams in there that probably even don't know that they should own certain applications because before they didn't care it was just running in the infrastructure. Why should now care that they are in the cloud? Because cloud is just on somebody else's computer. Right? So yeah, you see this disconnect. And the thing is what happens if you try to reach out to these teams?
Then you have this natural reaction of help.
Now somebody's going monitor us, they're going to evaluate us.
They don't know the metrics, they don't know are they the good guys, are they performing badly? They have no idea. So they have almost this panic reaction to no, no, no, no, no, you cannot Talk to us or you should not talk to us. We, we won't share any information. They want to be left alone because they don't know if they are going to make, how can I say, a good impression or a bad impression. I've even heard excuses like GDPR that I should not look into cost data because of gdpr.
And then you really, it's like okay, so the challenge here and which is the biggest difference between small organizations or small startups and large enterprises is how you convey the message of you want to look into certain stuff.
[00:16:50] Speaker A: That's very insightful. I haven't thought.
Well, I had to be honest. I had some issues about access data when, when I tried to, you know, investigate finops on, on some companies. But it was like yeah, I never thought about like yeah, ddpr. I was like, yeah, because you come.
[00:17:10] Speaker B: There with good intentions. So one part of your brain says that whatever you ask all the others are going to interpret it as good intentions.
[00:17:20] Speaker A: Yeah. And also because you know, let's say that you are, let's say a white hot security guy and you are doing like that and they were saying like yeah, you cannot access that data because it's you know, GDPR protected. I was like how I'm going to protect you from breaching let's say GDPR if you don't let me access. You know, it's like, doesn't make any sense.
Okay, that's a super cool analysis. And you know, talking about mistakes or issues. What do you think is the biggest mistake you have seen like teams make when, when they are trying to, to actually implement FinOps?
[00:18:01] Speaker B: Say it's, I would call it imposing finops on, on everyone. Okay.
[00:18:06] Speaker A: Yeah.
[00:18:07] Speaker B: Because we are, you know, we are fairly passionate about our jobs. We know that if teams would apply certain changes that we recommend even with not only I'm, I don't talking about recommendations about. Right. Sizing or anything but also to become more transparent in the reporting and all of that. And there are plenty of advantages to be had. Right.
But if we impose it as such then we can come across as, how can I say, as not considering the challenges they are already facing.
The typical ones are the operation teams. They are typically stretched thin.
They're running large amounts of infrastructure and they don't want any bells to go off during the weekend if possible. Right?
[00:18:57] Speaker A: Yeah.
[00:18:57] Speaker B: So if we go there and say hey, if you start cost aware thinking and this and that then their own reaction will be then I will have more alarms during the weekend.
So what I try normally to do is I try to, rather than spamming out knowledge, insights, information, recommendations and so on, I try to invert the finops flow.
As in make every documentation as available as possible. Almost like in self service finops if you need something, access to reports and stuff, just have a page with all the links that you need there you can access it. Then obviously you need executive buy in and so on. You need to drive somehow the importance of if we do some budget cuts for the cloud spend, then there should be a round mail that says and next year or next quarter we're going to look into some optimization.
So they should have the motivation to go to the FinOps team and ask for advice instead.
How can we even get to know our costs? Where are they? Like and then you point to the, Here is the onboarding page. Oh, thank you. And then you already build some because you already help them. Then you build that, how can I say this trust and this collaboration and these relationships you have with these teams and then you help them more and more. But when they come to you.
But if you try to brute force finops into a large org, you need like a five times bigger finops team and it will take probably as twice as much time.
[00:20:39] Speaker A: Yeah, that's like very interesting because normally it's like you know, people talk like doing one practice or the other, one thing or the other optimizing, more optimizing length, focusing on one thing and the other and this was very, you know, very different and I think more comes from a more let's say experience side that you have come from rather than okay, this is the theory, this is what the things normally happen and you know, it's very insightful and you know.
[00:21:14] Speaker B: I'm curious, let's see, do you think for the FinOps team themselves, what do you think the main advantage of this approach is?
[00:21:24] Speaker A: So for doing like, for not let's.
[00:21:27] Speaker B: Say imposing phenoms but rather reactive instead of proactive.
[00:21:34] Speaker A: So I would say is like people would probably be more let's say involved in the process or what you said. So like if you do it pinups people or no the, the rest of the stakeholders.
So the, the way that you say it and you know, correct me if I find this to be wrong but from, from what I understand and from what you say, it's like you know, you have, you make it like okay, here's what you provide tools, you provide the ability, you, you enable, you empower the rest of the, of the, of the organization to embed finops in their practice. You're not in self imposing but rather you know, they embed it so it's part of the. You embed it into their normal workflow so that they can apply it directly and you don't have to like do this and write this. So you enable. And that's how I understood it for, especially for large sources like you have phenos people that are, let's say the ones that curate the one that understand the whole thing and they enable the rest of the company depending on the department like finance, procurement, engineering with the right tools for the right people so that they can enable, they can apply finops on their different cycles because their cycles are different. So that's, that's my, my take on.
[00:23:00] Speaker B: This in the right direction. But you don't know why that's my take on you. So let me add one more, repeat one more word flow.
So we have inverted the flow.
So when people reach out to you and ask you for information and you only talk to those, almost 100% of your work time will be invested in people who are willing to listen.
If you try to reach everyone in the organization and only 10% are interested in what you have to say, then only 10% of your work time will be conversations with people who want to listen.
[00:23:43] Speaker A: Yeah, but don't you think like for a starting up a practice like a, you know the case that you just said, you know, no phenoms whatsoever, don't you think you need to balance that like between talking to the people that are interested? Because I think those are like your champions, your leverage that you need to, you need to pull so that finops works in the company but also doing some like, you know, like you know, spreading the word and see what it is general awareness.
[00:24:12] Speaker B: But yes, but that could be also a newsletter inside the company or also one presentation at a all hands on meeting, you know, then you have your five minute spot and you say something like hey, we know there are going to be some budget cuts on a cloud spend next year.
If you want to have some help on how to figure out how to achieve that, here are my contact details. Done.
Yeah, you lay out the problem for them and you are going to help them with that problem.
[00:24:48] Speaker A: Yeah, I would agree on that as well. You need to do a kind of word spreading because otherwise no one is going to know about your existence.
But on that from there you get the interested people. I can say that from the topics that all the talks and all of that my company has gained from years I only say was Interested in like 3, one was Dota. One was Google Cloud and the other one was, the last one was finops. And whenever there was a finops thing or whatever I just, you know I researched like finops in the intranet or something around or cloud cos or whatever. So that, and those people I think are the, you know, what you, what we said the leverage that you need and you probably can find it with, with that you just need to at the beginning I think it's more like you know, awareness and then not, not let's say pursue them or like yeah, go behind everyone and go behind the larger levels. It's like you know, the, the champions will build and we'll try to build finops from, from the, let's say from the bottom so that the, the practice sticks in, in the company and you know, talking about the thriving and you know, making FinOps succeed. So what we from the FinOps role, what separates people that really consistently stick into FinOps role and can grow their career in FinOps to the ones that are struggling to find a role or struggling to find the right place for their practice?
[00:26:28] Speaker B: I'm not sure about finding roles because that's not really, how can I say my focus because also myself sometimes between projects it takes more time for me to find the new role I would like.
Definitely not trying to dish out any recommendations here but I think within an organization those who can, how to say, make their career in FinOps, I would say the big difference is and I will, I know I will put it back to the context to understand what context you're in and what context you want to be in in your next role.
For example, you yourself have worked or are interested in finops now for some time. Right.
Was there already an existing finops practice at your company?
[00:27:23] Speaker A: No. Or it was very early I would say when I started early.
[00:27:28] Speaker B: Now imagine it wasn't the course by the way.
And now imagine that you have somebody else with a similar amount of experience that worked in a well established finops practice and just you know, joined a running organization and everything was laid out. So there's a huge difference in experience between starting finops and joining something at a high maturity level and making it run.
So one is more almost like a controlling experience, the other one is really like a founder experience.
So I see there, there is a really big difference on and there depends. For example, if you have five years in FinOps and you are say oh I want to become a FinOps lead, then if you don't have any experience in kickstarting a FinOps journey, you will have a very hard time if you land in an organization that wants to, you know, spearhead a new FinOps initiative or start really from scratch.
So your question itself basically who will thrive and who will struggle depends on the context they're currently in and the context they will be in the next role.
Yeah. So I say if you want to learn how to kickstart a Finops journey, then join an organization where they are about to start finops from scratch.
That will give you a huge amount of experience.
But any experience you have from a well oiled machinery at high maturity levels won't really be helpful. They will actually work against you at the moment because you're used to having good reporting data quality, you're used to that. If you reach out to people, they will reply and so on. So for example, just for fun, when I do interview questions or stuff like that, most of the people that I know and even the seasoned ones, they don't pass my first question if I am interviewing for a FinOps lead.
And that is what to do in the first couple of weeks because they're so used to have access to people information and documentation so they skip the whole part of even finding out who to talk to to maybe find out who you should ask the question to and then maybe also find out when to ask this question because maybe there's something more important going on than finops.
So it's a huge, huge, huge difference between starting a Finops journey and joining later on.
[00:30:11] Speaker A: Yeah, I think, yeah, that totally relates on I think can relate a lot with business.
Like it's not the same to build something like, you know, from scratch and you know, from the first one to have a, you know, start in a business that has already all the systems, everything in place, all it's working and it's like, yeah, that's the easy part. Like when you are, you know, working from scratch and building it all yourself or with, you know, with the help and then you are seeing the evolution of it. You have suffered all the evolution, you know all the stages and since you know all the stages you have, let's say all the experience in your head to say like okay, what's the context of these companies? These are, you know, a retail company so the finance focus on one thing or I recall the Ryanair's case is like they are obsessed with the margin. So like the minimum change in the margin is like something that very affects but some other companies is more, it's not the right context for them. So you know, when you have built something from, from scratch.
I think you'll be, you know, I totally agree on, on that, on that comment that you, that you made and for people, let's say people that are in different contexts but they are new to finance or they are starting to build a practice maybe in the company. Now that a lot of companies are building, what do you think are three misconceptions that they could avoid that you see very frequently in the ecosystem.
[00:31:40] Speaker B: I would say one particularly is that it is an engineering challenge to start with and therefore almost delegate to engineering all this responsibility and accountability. It's almost like going to operation theme and saying can you make this cheaper?
And so I would say that is will bring you only the low hanging fruits and will run out of opportunities after some time.
So I would say the biggest misconception here is that the engineers actually decide the cost structure they do, but it's because they're filling gaps that somebody else left in the documentation or specification.
[00:32:39] Speaker A: I would agree.
I normally like, because I come from the engineering side, I take both things on this. But I also agree that you are making the decision based of what you know. But if you don't have all the context, you are doing things that is affecting other things that you really don't know. So.
[00:33:03] Speaker B: Familiarity, because you have always built the systems in a certain way and for most cases it's good enough. But I mean, let's talk for example, for any. You mentioned retail, let's take a retail application. Okay.
So for example, it's a good thing to enable compression, right? For anything, cloud backend or websites and so on.
Compression is a good thing, right?
And I say not necessarily.
It depends how your API is built, how your application is built.
Because if you have, let's call it a thin client so that every user interaction goes to our cloud backend, then you have plenty of mini interactions.
So very small payloads and many interactions. If you turn on compression, the compression library that's also sent as a header or as part of the content will be bigger than the payload itself.
[00:34:11] Speaker A: Yeah.
[00:34:12] Speaker B: So actually made it worse. So you have more volume that you're pushing through and you're also adding some compute time to compress and decompress.
So in that sense, if you don't know what you're sending across, then you should not make decisions about the architecture.
Yeah, that's for example, talking about compression, there is a couple of things that are very interesting.
Apart from that I learned about this new JSON alternative. It's called Token Oriented Object Notation. So Tune and it's basically much more compact than JSON, but has exactly the same information. So it has an encrypt or sorry and a parse and encode or stringify or whatever. Yeah, yeah, yeah. And so it does the same as JSON, but it reduces the volume by between 20 and 50%.
So you could simply use another content format.
But also one other thing is it depends on the scale that you're running. Let's say that you have an intranet application for your orders that run from the desks in the shop. Okay. Or a counter in a airport terminal. Right.
Now the thing is, if you have a limited amount of connected clients, you could run stateful compression, if you know what that is.
So for anyone who don't know who that is, it means that basically both the client and the server send the first message uncompressed and learn at the same step to improve the compression over and over. And most importantly, the dictionary, the compression dictionary is not part of the transmission.
So even for short, as in a low payload interactions, even if frequent, that works wonders. You can reduce the volume by 80% easily compared to normal compression.
[00:36:26] Speaker A: Yeah, no, that's.
[00:36:27] Speaker B: But obviously that means that on server side you have more memory consumption because you need to hold all the compression dictionaries there. And also the API must be built for that. You know how many interactions that are and that you have like connection sessions for each connected client and so on. So. But if there is someone who says this is the amount of data, and by data I mean collection of information.
So I'm not talking about tech necessarily, I'm just talking about information. And you say whether it's transactional, whether it is a stateful API or stateless API, if there's somebody who defines this on a product level, which then goes into the solution architectural team, again, they will be able to make those decisions based on that kind of information. But if you just say build me a web shop, then you will make the usual three decisions and leave out any potential optimization. From the design point of view, that's very.
[00:37:40] Speaker A: Intelligent and I can relate a lot to that because sometimes, especially in the architectural side, when you are a more high level, you don't take prior or you evaluate certain things, I.e. build website and you say, you know, if your standard practice is microservices or whatsoever, are you sure? Like given the context of the tool and given all the possibilities that you can do, is this the best I think or is just the standard way that you know, and it's like, yeah, this is the way that we do it, we do it this way, let's do it this way. Because everyone knows how to do it. And it's like, yeah, maybe just a monolith with some autoscaler would have worked fine.
[00:38:21] Speaker B: Or even a fan of monolithic actually to start.
[00:38:25] Speaker A: Yeah.
[00:38:26] Speaker B: If you build a modular internally, you can split out any module, so to say into microservice whenever that is required. Because of the scale.
[00:38:37] Speaker A: Definitely.
And even you can then granularize it even more and make it serverless so that it can be divided into functions if you like. You already made it. The only thing is the, the split edge is need to be done, but it doesn't have to be like, okay, let's build an orchestrated thing for number one thing. So I also love the modular model.
[00:39:02] Speaker B: If we go down this rabbit hole for a sec.
So for example, if you think about the lambda functions and you think about a web server that has an API, you have paths and handlers.
You could actually transform back and forth serverless to a web server with almost no code changes if you structure your project accordingly.
[00:39:27] Speaker A: I can say that I have done that and it was fairly like when I developed a serverless application a long time ago for app production.
We were basically doing the same that I was doing to develop Python web servers but for lambdas. And I was like, okay, this is the same thing. I just need to import some AWS library to do this right. But I think it was very interesting and moving back to the phenom Scarriers because I think it's a topic that interests a lot to people and we have this job channel that people are very interacting on and there is a lot of interaction. So I want to make some projections now that we are starting the year and everything is projection and see what one big misconception.
Okay, yeah, please go ahead.
[00:40:19] Speaker B: Entering finops.
You don't need a technical background.
[00:40:24] Speaker A: Yep.
[00:40:26] Speaker B: You need to be able to ask the right questions. Yes.
But yeah, I would say the best way of optimization is training.
Give your engineers time to upskill. Ask them the right questions, give them the right information, as for example, of what kind of data will flow through the applications and leave it to them to come up with the most efficient solutions. So the misconception I find very often, even the seasoned practitioners is that say, oh, I come from finance, I cannot talk to engineering because I have no technical background.
But it's not your job to tell them how to do their job better.
They won't like you for that even if you had a Technical background, trust me, you need to ask them the proper questions that they will then resolve and answer. Right?
[00:41:21] Speaker A: Yeah, I totally agree and I think like with roles like any business or management role or let's say leadership and in this case especially finos where you treat with a lot of things that you may not know, like to the point of, you know, mastery, let's say finance or engineering, you may come from different market, you just need to, you know, point right and do the right question like try to so that they can explain to you and see if they can understand. Because after all things need to be understandable to everyone and need to be simplified and if you read about business and all of that is, you know, systematize, simplify, make it super easy for people to take decisions as quick as possible. So I love that background and I totally agree on that because we have seen people like Alexa that we interviewed some weeks ago that she doesn't come from that we have a lot of people in the community that come from very multiple backgrounds that doesn't have to be anything related to tech. So I agree on that.
And you know, back to the question that I was seeing and thinking about this is like, you know, where do you see the finops job going on or the career going on in the coming years? What will you see the evolution? I think the career and maybe the practice. What do you see it coming?
[00:42:50] Speaker B: So finops is a fastly growing discipline.
I mean only in a handful of years we have gone to just give some recommendations about to increase accountability of cloud costs.
Now we're into finops plus trying to bring some practices to data center management.
Also other cost types like operational costs like HR stuff. There are plenty of stuff that we are branching out in many directions and we are also evolving into other branches like ITAM and tbm.
So I see that like software engineering, many decades ago you had software engineer, that was the one who created software.
A couple of plenty of time later you have now the data analyst, the data Scientist, then you have the ML Engineer, you have the ML Security engineer and so on. There are so many, plenty of titles growing out because you're covering certain specific stuff. So I think we will have some diversification within FinOps as well because we are already have the FinOps titles like FinOps Engineer, FinOps Analyst and so on in plenty of job offers. So I think there will be some new roles coming up that will depend on what kind of topic we are going to cover within FinOps.
[00:44:34] Speaker A: Yeah, that's very interesting and I also agree on that I, I think the practice is going to evolve and especially with the way this expanding and the diverse nature that it has already, like the amount of roles it involves and the amount of contexts it has, especially where it applies to public cloud, like the evolution to englowing almost all its spend independently of where it comes from. Not it doesn't have to be it, but also the payroll in it and you know how all the spend is evolving. It's going to be like super diversified and we are going to be seeing like, you know, a lot of specialty to be finished because I think it's such related to business and business is such diverse and has a lot of context and different ways to see that if it tries to do that and if expanding to that, it's going to be like super specialized and super diversified.
[00:45:37] Speaker B: Make a bet. How long will it take until we have a FinOps token specialist?
Let's say, let's by token, I mean obviously AI token.
[00:45:49] Speaker A: Yeah, yeah, yeah. So let's maybe let's reverse engineer the question so how much it'll take to have, you know, a token, let's say optimizer in terms of accuracy, that's already.
[00:46:05] Speaker B: For AI specialist, that won't take long.
[00:46:09] Speaker A: Because there is already roles that are trying to optimize in terms of the accuracy, like let's say scientific part where you're trying to do that so whenever you make it better. The only thing is that okay, we are spending too much so we need to optimize the way that that's concerned. And I think even for some reads that I took and some people that I know, they are already consulting a bit on that. So I would say in a couple of years that rules.
If the AI evolution continues, probably it will happen. That will be my bet.
[00:46:51] Speaker B: I mean, if the bubble doesn't burst.
[00:46:54] Speaker A: Correct.
But yeah, I would say that because I recall when I was doing ML, well it was more like AI but for images and ML I was more on the operational part. I was saying like how long it would take for you know, let's say the ML ops to appear. And it took like one year and a half since I started invest researching and all I knew was researching to me becoming like an MLOps people. And I was like okay, how the hell do we deploy these things and make it work for an application? So I think it's going to be like if the AI continues, which I think it'll be couple years, we'll have very specialized people into Finland for AI because it's going to be Such a cost driver, the same way that we have, you know, itam specialized people, it will be that. So that will be my take. What about you? What do you think on that?
[00:47:58] Speaker B: I agree, I agree.
I would say give it a year, one year and a half and we probably will have those job roles on our board.
[00:48:07] Speaker A: Yeah, we'll see. I'll analyze that data. I will see what the jobs are asking for regarding that and maybe a final question that they want is to give advice, let's say to the new generations of, of phenoms even though there are much older. But you know, if someone is starting on their phenops journey, what would you recommend to them both on the learning, on the approach of the, of the, of the story to introducing finops.
[00:48:36] Speaker B: If they're starting from scratch, as in they've just transitioned over from another discipline, then I would say do the practitioner's training because while a certificate itself obviously doesn't guarantee your job or that you're good at that job, you can identify your knowledge gaps very quickly. If you come from engineering, typically you have no idea what unblended and blended costs are and vice versa. I mean so you find out what you need to actually do the job and then you progress from there. If you want to ride the AI wave, you can do the FinOps for AI certifications and learn about that because it's, it's less about actually learning how to do machine learning and AI, it's more about how to govern it and how to control it.
I would definitely go pick your direction because it's no longer like software 30 years ago where you just did software engineering.
Now now you have to decide from the scratch more or less what are you going to be a well rounded like an all rounder or do you want to specify some as you know, specialized. Sorry. On something specific.
[00:49:57] Speaker A: Definitely. And with the, the broader, that we just talked the broader scope is taking I think especially like either you become a generalist and aim for a more let's say management role I would say and you know, coordinating that that is always become a more let's say generalist management role or you specialize in one area and you become the best for AI optimization.
Won't be nearly similar to doing a storage optimization to doing especially when I see bigquery, all these bigqueries Snowflake data optimization which it seems like two different worlds. It's super different from when I see other stuff and when like you cannot be the best like it's super difficult to. It's going to be the best. So you need to especially and there is like going to be probably plenty of people looking for let's say storage optimization. But of course there is a lot of storage management, let's call, you know, Canva for example, that saved like a lot of money on optimizing storage, but also people that are using BigQuery a lot and it's a huge cost driver. So I think that's, that's a very useful advice.
So thanks Eric for all your insights today. I think it was very useful and very helpful for, for the people that listen to us and hope you had a. You will have a great 2026 and thanks for being here today.
[00:51:26] Speaker B: Yeah, thanks for having me again. Looking forward to seeing you again soon.
[00:51:30] Speaker A: Yeah, looking forward to it and to everyone. See you in the next episode. Bye Bye.
If you would like to know how someone did a wonderful transitions from a non technical background into Finops following what you just talked with Eric, don't avoid the possibility to check our episode with Alexa Bruscato so you can know how she made it to create even her own Finops newsletter from being an English teacher. Please listen to this episode.
