Episode Transcript
[00:00:00] Speaker A: Welcome everyone to a new episode of the Finos weekly podcast. And today we have a very special guest, we have Frank Antepois from Kovlan. Frank, it's a pleasure to have you here. How are you doing?
[00:00:12] Speaker B: I'm doing great and it's my honor to be there.
[00:00:15] Speaker A: It's great to have some experienced podcaster host in the podcast, a fellow podcaster that I've been following since I introduced Phenips and much more than a podcaster for sure. And you already been doing some great work in Finops, so maybe we can start with some introduction for people that don't know you before we start with the big guns. Top down finops, that is the topic of today.
[00:00:43] Speaker B: Okay, so yeah, I'm Franc Contrepoix. You can guess from the accent that I'm not British native even if I'm based in London.
Overall, what I've been trying to do over my career is to be a full Stack person.
And so for example, what I mean by Full Stack person is that I started as a developer in my garage, not wanting to talk to human beings, then discovering talking with human beings that was useful. I became an exec in a company in a startup that got sold for a billion, so that was quite a stressful environment.
I've done something to learn about how the board reacts or a non executive director diploma it's called and it's quite cool too. So the idea is I want to understand finance, I want to understand the board, I want to understand the executive and I want to understand the developers and the engineering team. All of this together. I have to admit it's slightly hard to keep track of all of this, but it's fine, it's doable from your perspective. I've been Finops has been now from the beginning really. I was at Finops X the first one.
I had a short talk about forecasts that day that was really funny. And yeah, with Stephen Old, we used to work for the same company, which was very Finops company, but thinking from the banking perspective, which was really cool.
For five years now, more than five years, we've been doing a podcast once or twice a month.
So yeah, that's me in a nutshell. Yeah, well, now I have my own francontrepois.com when I show my ideas analysis. And yeah, I think too much, some people say.
[00:02:16] Speaker A: So it's fine, thinking is good.
So yeah, I definitely recommend everyone to go take a look at your website because you could find very interesting articles that have been featured a couple more times. In the news newsletter. So definitely quality stuff. So let's start with the main topic of today which is like top down finops, a topic that you have been developing for a long time and for the audience to know. When you say top down finops, what exactly do you mean? How is it different? Sorry for another approaches that we have in finops.
[00:02:54] Speaker B: Okay, so think of it this way. Until now we almost.
And I think I wrote about this. Yeah, bottom up finops. So opposite of top down is ask engineers to fix things with no connection to the strategy. So it is when you go into, when you start, most of the documentation you have in finops is about and the complaints also is about engineer not taking actions or I have a list of lots of recommendations. They should be doing all these kind of things. This is what I call bottom up finops because yes, it comes from the data but it doesn't have any real connection with what at the exec level they might need or even just at the VP level who pays the bill. Yes, you might reduce my cost by think by a certain amount but if you are reducing the speed of delivery, I might not be that interested in the savings or there are lots of things like this that the default, let's put it this way, the default finops approach is bottom up until now, most of the time and we're trying to get access to I would say top management and executive and C suite, mostly for sponsorship. This is slightly changing but until now they were just a participant, someone to inform.
So executive, we're here to sponsor you. You were to inform them and they would be here to sponsor you. While on the other side, what I do believe is their job is to make decisions, take the responsibility when these decisions go well or bad and then depending on this. So they made bets, depending on these bets you want them to be implemented and we are completely missing that bit. So for me, top down finops is to give back 60 to 70% of the data, which usually is enough to make it executive to decide what they want to do is the risk they want to go. Do they want to go all in on obviously AI. I need to say AI in any conference or do they want to go full speed onto AI? Do they want to deliver much faster? Do they want to increase their margin?
Depending on that they might choose different option of implementation and that needs to go then down and that's what you need to implement as a FinOps team. That's your priority. Your priority should not come from a tool, your priority should come from your boss.
And that's what I call top down finops is we give back the decision making the risk. Also we save ourselves. We are more secured because the risk is handled by people who are paid and trained to make decisions and risk.
[00:05:37] Speaker A: Yeah, that's a very interesting approach because finops is such a, I believe that is such an important practice and such an important thing to the company that it was weird or extreme that the thing was coming bottom up. Like you are implementing changes that are super important and super relevant to the company but going from the bottom, which is fine, like to get, you know, a promotion or whatsoever, but then the strategy and the, you know, that kind of important changes need to come from, from the, from the top down. Because you know, correct me if I'm wrong but you know, it's such an important strategic decision that the ones that need to decide are in the top and not in the bottom.
[00:06:21] Speaker B: Right?
Yes. And you've, you've highlighted also there is a very interesting thing about top finance is vastly different depending.
You say that cloud in this case of finops is very important. It will depend on the companies. So my short version is that if the company is on a very thin margin, so very small margin, the CFO has more power than the CTO and cloud is probably, if I do glasses or if I create that stuff for mouse, cloud is yes, it's a necessary evil for something, but it's not my business. So at that point, as you say, finops is less relevant, cloud is less relevant. Ito also on the other side, if you are on a fat margin, you're probably a startup, you're probably in tech and at that point the CTO will have more power because they have more capability for spending because there is money in theory.
So the strategy, the top down finops, that's part of what I'm saying is do you know what your company is really targeting? Do you know in which, what really would make an impact?
[00:07:31] Speaker A: What.
[00:07:32] Speaker B: There was an interesting discussion recently about what can go into the balance sheet and what can go into CapEx. OpEx is the usual, something you need not to talk. It's a hell of complications.
But overall what we are talking about in here, it has tax implication, it has assignment, it has investor relationship implication, which is why it's not as simple as oh yeah, OPEX is best.
The other point that came to my, to my thinking is how we see we live in a bubble, okay, we live in a bubble of cloud. And it was. And we in that bubble of cloud, we've been shaped by the marketing of cloud vendors. Okay, let's put it this way. By default, if you know CFO would say yes to cloud, if they're in their right mind, because you ask and say, how much is it going to cost? I don't know, can we put a cap on it? No.
Or is it going to cost us another? I don't know how much in technical setup I can put alarms. You'll say, yeah, but that's too late, I don't care about alarms.
How do I? And so the point being that you can see that the reality is me, for example, the big cloud vendors started from shadow, was someone in the dev team that bought with their credit card something to do a project. And that was cool because cloud is brilliant.
And so it was really cool. It was working and it grew and it grew and it grew. And now it's reaching the CFO which starts saying, what's that stuff?
What's the margin out of it? How much does it impact my tax? And you say, well, my ebitda, where's my. I'd say, oh yeah, well that reduce your bidding, it makes it worse. Say, well, I'm not interested in that stuff.
And so we have that conflict at the moment and the people in the bubble that we are are fighting back, saying, no, no, our way is good and you're there. No, cool down, two seconds. Part of top down finops is starting to put yourself in their shoes. Okay? We've been managing money for more than 5,000 years, okay, so they probably know something. We've been managing cloud for the last 20 computers for the last 50.
So 50 to 5,000 mean that they probably already have a name for it. They probably have seen it, they probably have tried it and it might not be in it. It might have been in trains, might have been in oil, even agriculture, I don't care. The point is it's been already standardized in lots of things. And so part of the top down finops, I'm saying the impact is for us in that cloud and finops bubble in particular is a good dose of humility.
And starting back, coming back as you accepting that we are biased in our decision, particular from the marketing. And last but not least, I'm talking about reserved instances. I'd like to talk to people that they are neither reserved nor instances and they are the word I hate the most in the cloud world, by the way.
And the small fun story.
One day we went with my boss, Dr. James, we went to talk with the CFO and the CFO was saying, I Don't understand that stuff. And James was very kind to explain what in financial terms what an RI is and how you can sell it on the roi Marketplace for 12%.
And the answer was it's a forward buying contract with an embedded put option at 12% out of the money.
Okay, that is done.
The CFO knows how to account for it, how to manage it, the risk implied. But they never use that in AWS because they talk with the tech people and they don't want it to spread because as I said CFO might not see that uncertainty and unlimited spend positively.
[00:11:38] Speaker A: Yeah, definitely. And you know, if you have dealt with you know, finance people and accounting people, they want to have things like very under control and you know, as also research instances is something that is super.
I think it's one of the most trickiest thing to think about because they are very similar to what a capex buy would be. Yes, but they are not.
[00:12:03] Speaker B: No they're not.
[00:12:04] Speaker A: And I think that's deserved like a whole podcast on the reserve instance like saving plan thing on how to account for it because it's.
[00:12:13] Speaker B: No, I think you can't. So the point is we did some research.
You cannot really account.
The accounting is obviously going to be extremely complicated. And by the way, just say that was one of the things we used to do is to help people. Because every time you buy a, let's say a 36 months RI, so 3 RI every month, the accounting team need to count it how it is because if you spend $1 today is not $1 in three years time, there is inflation in the middle. So you need to start accounting that on a monthly basis in advance. There is ton of accounting work for anything partial or full upfront. Which is why I think on the new ris for DB or savings plans for db, they've just removed any other up. It's nothing upfront.
[00:13:00] Speaker A: Yeah, it's like if you are into like that's one of the things that I like about finance because I come you know from the tech side but I also like the finance and when I see like finance stuff and it's super, super interesting and you know it's very tricky. It's very tricky but you know moving on to the, the top down. So we have thought about, you know, how the responsibility has swapped from you know, swaps to the bottom to the people to the top down. But some of these things like those cascade of tools on some practices is like how do you cascade from the different teams from the top down without feeling like this is super mandatory. This is a policy.
How do you do that? So it's embedded into the whole. Org.
[00:13:49] Speaker B: That's interesting. So there is a say that your creativity comes from constraints. Okay, when I used to, I have a beautiful book on programming which is called Programming Pearls and it is from the very beginning days when you add 664k of memory. Okay, and your problem was bigger than 64k, how would you solve that? And so you had that constraint that was forcing you to think through and find new ways and innovative way. So what I see is that for me, top down finops as policies and it is mandatory but it's set the way you need to do it and that's why you have multiple layers. I think on one of my article I've highlighted seven layers.
They are theoretical layers but the idea is that if the CEO says.
[00:14:38] Speaker A: We'Re.
[00:14:38] Speaker B: Going to be a lean company for hr, that means that yeah, you don't fly business, but for the cloud it might be that a, you do not use the latest generation because prices are going up and you're just gonna stick to. But by defining some constraints, you create what I call the sandbox. You create a perimeter where the developers or the engineers, they don't have to think if they are doing right or wrong or going back to the architecture. Now that's fine, that's covered, I can focus on the real problem I have.
And so if we were to say, look, we're gonna be old style, we're just gonna do three tier architecture. The database we're gonna use is postgres. The intermediate we're going to use network load balancers, EC2 instances only spot, 80% spot, 20% non spot and I don't know, application server in the middle, whatever. And you just say hey, that's what we're going to use for the next year or three years.
It frees you as a developer to say okay, how can I optimize that? How I can go deep dive into postgres optimization instead of thinking I should use DynamoDB for this and key values be in the other store and that there and then it's going to be hell on earth.
So the way I see it, yes, it is mandatory, yes it comes with policies, but those policies, if well done and the hierarchy is right, are going to be freeing you from. They're going to give you a pitch in which to really play freely without having to be responsible for stuff that were totally out of your control or.
[00:16:18] Speaker A: Yeah, and definitely you highlighted something very interesting that I totally agree on. That is like you need to constrain a bit the development cycle. Even though for certain cases, like, I don't know, AI things or all of that, you need to. Okay, let's frame this and let's see what's the new thing. But for the general software development, you can constrain what is best for your company because you can then optimize more like on the performance side, on the technical side, on the price side, you can then, like if you have a stack, like that's something that, you know, a lot of SaaS builders said that, you know, you stick with your stack and then like you will be much more productive. So innovation is great, like in tools and there is always new tools and all of that, but then if you constrain it, you become the best at your stack.
[00:17:06] Speaker B: Exactly. And that's value, I think also. Yes. And there are software, it's interesting to say, and you work for one of these companies which are enterprise type of company and the enterprise type of company of company, they are here to stay for years because they manage things that you cannot change easily. If you have a supply chain, you produce a product and you have a supply chain that goes through China to India to the US to Europe to whatever, you need a software that holds it up together and it needs to have a strong base. That's what I've noticed. Enterprise software have a very strong base and then you can adapt on top and almost every. So let's say the Oracle, the SAP, the Salesforce, they're all based on that model.
And that's something maybe we don't have yet matured in finops. We have tools that try to tell you, oh, those are the best practices. And you say, well, cool down, maybe not for me.
And I think, yeah, that's it.
[00:18:03] Speaker A: And talking about best practices and saying that what you just said about that's not for me, maybe it's for another company. So that relates to one of the topics that I wanted to discuss today, which is context. Right. So you have said in multiple times that context is everything. So why context can be sometimes more important than the actual numbers that you can see.
[00:18:28] Speaker B: Yes, So I think it's the. So I will. Yes. And then I will tell a longer story later on. I think when we talk again about context is everything, but to start with, context is think of it in a very simple way. We all have brilliant dashboards now out of fashion because now we decide that it's not enough and we all need a chatbot. But overall, when you look at Any graph. Okay. If I tell you 46% you have no clue what I'm talking about. There is no context attached to it. And that's what if you look at the. I will say the Kudos dashboard because I had the pleasure to working a lot with it. Pleasure.
It's a ton of information without context most of the time.
And you just. So I've. We. Stephen, we did a talk about this. There are five things you need to have in every graph to make it useful. You need to and to add that context. And the first one is the data. Yeah, thanks.
Second one is some text. Explain to me if I were to tell you that those 46% is an intake of fruit and vegetable in my diet every day, that would already make you more understandable.
But then what you need to have and which almost everyone misses is what is good, what am I targeting?
Because I don't know if 46 is good or bad. And the same way I need to have a good which can be a value or a range.
And then you need to have also what is bad, what is the bad range. So you need to have the number, you need to have some context with text. You need to have a good, you need to have a bad. And the last thing you need to is to explain what good is good and bad is bad. So for that example, and it is the one we've used, I think in a keynote we delivered at one point it is. Imagine if I tell you that the goal is to get to between 25 and 38 and I say, why is that? Well, because if I have less than 25% vegetables, I'm probably ingesting too much fat and too many sugars. And so it's going to be bad for my health and cardiovascular thing. If I am above 46%, I'm probably not taking enough protein in and I will need to. And so at that point, if I tell you 46% showing you the ranges and all the stuff, I give you a full context, you will understand that graph without me having to tell you anything. And that's why I am a data guy. I love dashboards and stuff. And I think we are just throwing numbers of people and telling them, you should learn my stuff to understand these numbers. And I totally disagree with that because I'm very opinionated.
[00:21:12] Speaker A: I also agree, I also deal with a lot of data and a lot of data can be useful, but with the proper insights I can have, I don't know, we can see bills and all these excess and you can have Okay, I have a lot of data and a lot of visualization and all of that.
But one thing is like, okay, what do you do with that data? What does it mean?
Why is it relevant for you, for your clients, for whatever? So talking about this and adding more about how does adding this context change to what decision people make when they have this data and then you have context and then how does it change for the decision?
[00:21:55] Speaker B: I think it put into, as we say, into context in this case. But think about it, when you have people, an engineer, they'll have a certain salary. And we all have a sensibility, for example, to money, which is different. Okay, we say, oh, if I'm earning tons of money, I can say, oh, $100. That's irrelevant. That's a small amount of money. But a million dollars is always going to be big. But if you are Fortune 500 or even 2000, really, and you say a million dollars is irrelevant, it's just, it's peanuts. But if I am the person in the finops place or the developer, I might find it very important. I hear continuously, you can see people telling you, oh, you could save $300,000. And you say, yes.
And I don't know if that's important because $300,000 is just the price potentially. I used to manage 40. I had a team of 40 developers working for me. And you end up and say, yeah, I can tell you that their salary, okay, they're all earning quite a good amount, is way more than per month. So no, I'm not stopping, I'm not distracting them, even two days, all these people to do an hackathon for that amount of money, it's just no go. And these kind of things, I think, is what the context bring is when you bring the context, it brings clarity with those constraints that we talk about to every individual. So I know that in my company, any savings that is less than 10,000 needs or better for every 10,000 saving, it needs not to take more than an hour of time, engineering time. Does it take more than that? Yeah, it's not worth it. That's a context that is really useful for me because all of a sudden I don't need to make decision based on my biases.
It's been decided, top down, that this is a number that match and that number is communicated to me through context.
[00:23:57] Speaker A: Yeah, that's something that, it's very interesting and I can totally relate to that. I recall when I was, and probably that had happened to some people as well, that when I was starting to do finops in my company and some others were like if you are doing like $100 in savings a month and your salary is more than that an hour, then you need to do it in like five minutes or something.
Because let's say the human cost that you have, let's say for the human resource that you are for your company is not worth it. It's not worth it. So you need to take that, you need to, as you just said, define a decision process so that people can make the right decision. So that they define like okay, let's do this or let's not do this. You define your decision process so that we can apply to FinOps. Right?
[00:24:55] Speaker B: Yeah. Context is transfer of information. It is, and sometimes it's limbadi. It is transfer of information. And it works very well with the top down thing is this is the context of our company, this is the strategy and that goes down through the right channels, through the right people whose job it is to make this so.
[00:25:12] Speaker A: Yes, and you know, you mentioned before like you had a story to tell us about the, the context. So can you, can you tell us more about that?
[00:25:20] Speaker B: Yes. This is a story that come from one of the best book that I invite everyone to read, by the way, which is the seven habits of highly Effective People. I don't know if you've got that one, but there is the story, that is the story in the tube. And so it is imagine yourself. So this isn't imagine, but imagine yourself. You are in the subway, whatever city you want and you've just finished a hard day job, okay? You're tired, you're exhausted, you're reading your Kindle there and you want some time.
All of a sudden it's chaos, absolute chaos. Because you have two kids that are jumping around smashing things, kicking or touching people, they slap your Kindle. You get so upset and they are old enough to be, to do a chaos but not old enough to be on their own. So you look for the parents, you know, someone to blame until. And you go and you find the father who is completely lost and seems to ignore all of that. And you get very upset, okay? So you are very upset. And you look at that person, you say, get a grip on these kids. They are doing chaos.
And that person tells you so the father tells you.
They've we come back from the hospital, they've lost their mother.
I don't know what to do. They don't know what to do. I don't know what to do. Okay. At that point the chaos is there. The Facts are there. If you were to measure things, nothing has changed. I just want to hug that person and make sure these kids are going to have all the emotional support they can get.
The only thing that changed is the context.
And so when you read a number and it doesn't have context, it's useless because we are emotion driven people. So that story for me shows and I have shivers every time I tell it because I think of myself. If you want any of that, it's enormous and I would completely change my behavior.
And it's not that. And so I invite other people not in an extreme as this way for example, but to put yourself into someone else's shoes.
Learn that finance bit to understand why are they being so painful. With some aspects it's assume give an A, that's another from another thing. But given a start by assuming that people are doing their best and they're smart and that's you are missing something and ask for that something.
[00:27:45] Speaker A: Yeah, that's like that was, I recall about that story from the book and it was very powerful to you know, to showcase as an example it was like. And the way that it was written it was very, very good to a very good read. So I definitely recommend people to do. And I totally agree. I think that can be applied also in finos but in general business if someone is pinging you or someone is you're not understanding why they are acting some way, you probably need to ask why the reason behind it and they'll probably dive deeper and then you will know what's behind. And that can apply especially when you are and getting into more management, more business style. You deal with more people and we get with more emotional and decision making is something that you need to dive deep into. Like okay, what's the whole thing behind this? So we can reframe as you mentioned ourselves so that we get to the right point, we get to the right solution. Everyone wants to have like a win win solution and that's it. If not, then that's someone you shouldn't be doing business with.
But that's like, that's a super powerful example. And you know, so we have talked about the context and how it affects us but you know most of or several people that are listening to us may be working in a, like in a big company, in an enterprise. So how people can implement context at scale. So like for a, for a big company like where do you start like on the first place?
[00:29:25] Speaker B: Well, you start so it goes as we say probably with the top down thing. So the first thing I would invite people to do even today, and I think that's is if you are in a big company, you're probably public company or even if you're not a public company, you have investor report, you have strategy report, have a look at your quarterly report. Okay. Have a look at how the company define themselves. What are the risks that the company as a whole is thinking about that they are presenting back to investors that the board are looking because we talk about the board as if they should care all this stuff. Have a read at these documents and you will discover their read. There is a big bank that is a lot in the cloud and all and we were all use cases and success stories, all the stuff behind it. And then you go into their report and you search cloud and there are three reference to cloud and they're all in the same paragraph and they talk about weather and it has nothing to do with it. So you look into the IT thing and you find that some of the cloud in IT or the IT vendor was named more in the risk side of things as we have a single vendor and you're like, okay, so these kind of things will even just reading this shall help you understand what is the board really think. And there is a really, really, really good chance that they don't give a monkey about cloud or it. IT for most companies is a necessary evil.
The only one it's not a necessary evil are usually startups. Because even when you, because when you get to a certain size, even let's say Microsoft, Microsoft is a tech company, we all agree with that how much are important compared to programming and creating license or managing your licenses or other people around.
It is vital, but still it's not the main value driver.
[00:31:37] Speaker A: Yeah, I think that what you said about the necessary evil is like something that we, especially from the technical side, we need to reframe ourselves because we think, you know, the development the applications that we do is the most important thing of the business and we are doing a critical thing and you know, we are super important and that's fine like self esteem and that's super great. But sometimes like if you are working for, I don't know, a supermarket or something like that, the good the thing that brings the business is to sell on the supermarket the products that you have.
Not the IT infrastructure that goes behind it and monitors everything and whatsoever if they could avoid it, they would do it because the only thing that matters is to sell the products and have quality products that people would buy with a good margin. That's business and all that comes behind is just necessary evil.
You can think with legal, you can think with it. It's all necessary things that you need to make it happen. Right.
[00:32:42] Speaker B: And let me be a little more positive on this again with some sort of story because I want to highlight the good thing of cloud. But the way I express it company, I say, hey, if you're doing every company big enough as employees, and so they're doing payroll, okay, so you do payroll. And in the past I used to have to manage some payrolls and you would have a payroll and it would, you'd have a cutoff date which usually was 10 days before the pay, so that you would stop and say at that date we cannot approve holiday expenses.
All this kind of stuff. It's going to be backported to next month.
So sometime you would have to wait a month for something done, I don't know, a week before payday because they had that cutoff and that was normal. And that was because you were limited by the amount of power it would take to build. You had four servers to do all the accounting, monthly accounting.
But cloud changed that. All of a sudden you can ask, how long do I want that cutoff?
And if you were to say, hey, I want it to be one hour.
So okay, to one hour you need 2,000 servers. Say, well, let's get 2,000 servers one hour before.
And all of a sudden all the admin work of the cutoff, all the backlog, all the bad complexity of oh, pass my expenses that day because it's going to be before the cutoff and all this kind of stuff, they just disappear.
And that is, for example, the power of cloud is if you have some problem which can be solved with quantity or things which are one off and that you need that the one off you need massive. Just do it.
When I was at Strategic Blue, we had a guy, it was before all the AI craziness.
He's a researcher at University of California San Diego. And he told us, he said, I want to buy every spot GPU available of all three cloud vendors in, in all regions in the world for one hour, all of it. And he had, I think it was half a million dollar for that hour budget.
And the first time I was calling data centers and were there. I don't care about the marketing, don't tell me infinite, how many GPUs do you really have?
It was a really interesting thing. And he'd never managed to spend all that money. Now it would be very easy, but at the time he had with that same budget, he did a couple, I think of rounds to get it all. What it showed on the other side is that we were able to bring up. I don't know if it was, I'm going to say a number, but it might be slightly different. It was 20,000 VMs up Cloud vendors in all regions in the world in 15 minutes. So in 15 minutes we were able to have 20,000 VMs up and running, synchronized and working and same thing for turning them off. You say turning off, 20,000 VM went down in five minutes and you're there. Wow, that is a scalability which is mind blowing. So well done guys. Managing infrastructure because that is huge.
At the same time, that was a problem he had for scientific research.
Volume really is available for cloud vendors and they are doing it exceptionally well. So if you need that.
Brilliant.
[00:36:06] Speaker A: It's crazy the things that we can achieve. Like you mentioned having all the GPUs or all the spot GPUs that you can have in the world at the accessible of clicks.
That's great. And talking about these experiences, what do you think are the mistakes that we can have on context and in context to the cloud financial data? We have seen you share case studies that look awesome. But what are the mistakes that people normally do with that?
[00:36:36] Speaker B: Well, well, I would say you go, it's as usual. There is the same French which is le trop et les du bien. The too much is the enemy of the good.
Okay. Which means that when you start expanding, let's go back to the top down. When you start with the top down and you start enforcing things to a level that is not your competence anymore. So if I as the cto I decide we are just going to use this type of instances that is so totally out of your depth in theory. You should not make these decisions.
I'm still talking about a big enough company. Your job is to make sure that it get the budget and that it is allocated correctly. That's it. VP of engineering will start working and et cetera. So you go down. So one thing is to be too prescriptive so that at that point you kill creativity.
You always need to assume than the engineers and the tech people are still very creative because it's still a job that is not standardized enough to be non creative. By the way, there is the Pixar book on managing creative people which is an absolutely must, which is genius.
But they are.
So that's a mistake. Do you have. The other mistake is just again is to throw data at people Expecting them to understand your context is to not put yourself in other people's shoes and assume that they are stupid or that they don't know their stuff and they should know my stuff.
Always assume that it is you. So the mistakes are going to be there for, for context. Yeah, not enough or too much. That's why I'm trying to figure out those five things. Look, you have five things you should say and they should stand in a graph. Okay. It's. We're not talking about trying to explain the world to everyone, but yeah, those are the things. And last but not least that comes to mind and we've talked about before is assuming that yeah, people, they should know they're stupid or they're doing it on purpose against you. And you say, look, in a company it's extremely rare. It's usually you have incentives and eventually these incentives are badly designed.
And yes, you're trying to game the system.
Is that a bad thing? It's. It's the system that is wrong. Don't change the people, change the system.
And that is the thing that comes from, from good leadership, in my opinion. And that's a, that's the thing you need to, to go for.
Yep. Though I hope that kind of answers your question.
[00:39:18] Speaker A: No, no, no, it does. It definitely does. And when you said it perfectly. Because you need to put things as mentioned in context and what you said about the system is you have to. In finops in general, incentives is one of the things that one of the leverages that you can have that are more powerful in the practice. Right?
[00:39:40] Speaker B: Yes.
And you always need to think about that it's going to be in some form a gamed.
Okay. And you need also to remember that the extremes are usually if you were to say, hey, you get a bonus if you reduce by 25%, say oh, it's proportionate. And you say, well, perfect, I'm just going to turn everything off, I'm done. Oh, massive bonus for me. Absolute horrible for the company. They'll come back and say, oh, that's not what we intended. Well, yeah, but that's what you intended. But by putting that.
Not requirement but that incentive.
So it's very important to. When you set incentive gamification or this kind of stuff, I highly recommend you to have a time period, an end to that so you can review is it doing what we are expecting?
And don't put extremes or unlimited boundaries because you're going to end up in a mess. Because yeah, the developers or we are all techies, we know the Math usually that's why we don't play at reinventing casinos most of the time.
But on the other side, if there is a way that math is involved, how we can trick and tips and change, then we'll probably do it.
[00:41:02] Speaker A: Yeah, definitely. And what you said is like the most representative case I think in finops especially to illustrate to work on the business value and not on the cost. And one of the most used examples and one thing that you said about we are from the techie side we always like tools and technology. So what do you think what tools or what tech can be used to make top down finops or make context possible in a company? What do you have in mind?
[00:41:33] Speaker B: So in finops we still have a set of tools and they are trying to do lots of things but they are trying to be everything for everyone.
And as I said I see enterprise. So the next level of software development which we are not there yet to be a very strong stable thing for everything that is standard. And yeah, the SAP for example Oracle is one like this is you have a database all style is very strong. There is a strong base on performance, quality, et cetera and you have a very simple interface which is SQL in the case of databases and on top you do whatever you want with it because you need to adapt the tables to your need to your data to your queries to all this kind of stuff. That's what I see an enterprise thing is. But it all start from there is a strong base that you can solidify Salesforce does that was able to do that because the CRM was quite clear oh, there is a lead, there is a prospect, there is an opportunity, there is a company. All this kind of stuff we are not there yet.
I think with FinOps so at the moment with FinOps I would say you probably will need to. That's why people are using four or five of them.
There is this aggregation that's happening at the moment.
It's probably going to go into that direction but to answer really your question it is so I see and I think I've put it in the notes from our things. So the first thing is you start the.
Where is it? Where is it anyway you start with decisions and decisions are usually on pen and paper or on. So you start with a pen and paper and then that's the first tool the tool technologically tool that can work and I've been working with them quite a lot is the policy is to be able to transform high level mandates into policies that are overarching. Okay, I'M not gonna force you to use a tool or another, but I want to make sure that if I'm in a bank, you're encrypting everything.
I need to validate that because yeah, my mandate is to be secure because otherwise I lose customers. So I think you have policy engines are really powerful.
There are potentially also orchestration systems that will help you with that. I will glue things together because you need to glue things together today.
And then you need to ask and be a pain with your vendors to say, yeah, but my.
Whatever.
Do not understand what this graph is about or how does that relate to my thing. Remember that the more data we have tons of data and that's why we want finops to expand horizontally with scopes and go all over the place, which I like. At the same time, I see it as a dependencies. We are curious animals. I think the National History Museum was showing in London was showing that curiosity is an instinct. So if I can have more, I will always ask for more.
Do I know what to do with that more? Probably not.
And so the point is, what I'm saying is from the tools is start by your questions and then go and see if the tool answers those questions or ask them to answer the question. Which is why we do custom things lots of the time. That's why Excel still exists. That's why every data goes through Excel. Because Excel is the most contextualized thing that you have. And by the way, AI is the same. We love AI. That's the superpower of AI. I wrote an article on this. It's because it's contextualized. I can say, hey, tell me as a PhD in FinOps or oh, I know nothing about FinOps. I change my context, I change everything, I change all my answer. So tools at the moment I don't think we have the maturity in cloud and the cloud vendors do not want that maturity completely to get through. They don't want to be a commodity or commoditized because let's be clear, the relational databases is a commodity. That's why you have tons of them.
It's just, it's a mathematical problem and now there are best people doing it in certain way or others. But you need that level of commodity that we do not have in cloud. So the tools, I would say pen and paper communication. Fortunately, Excel for you probably Policy engine would help if you're in a big company. Really helps to make sure that everyone's following at least that minimum baseline that we can agree on. And then underneath, yeah, you'll have multiple tools and use each tool for the niche they're trying to cover. And don't believe the hype of oh, we do everything for everyone because everyone, every vendor is correctly following their customers. Not all their customers, the biggest customers. Cloud vendor is the same. When they tell you we follow the customers, they say yes, but Netflix is more important than me, I guess.
[00:46:30] Speaker A: Yeah, I guess the big ones are. It's what drives the priority of the business. And you said it right. I totally agree on policies like independently of the tool or the native one integration that you have. They are mandatory I think for any big company because otherwise like policies and automation, that's where you are going to ingest things.
[00:46:54] Speaker B: But build them from the top down. So build your policies based on what your boss's boss is, wherever you can go at the top and if you can justify it going down on the way I see it is take the big guess, the big yearly guess that every company will have that is called the business plan for the year. When they tell you we're going to grow by 20%, we're going to. If you attach anything you do to this kind of the business plan for the year, the objective of the year, the strategy of the year, you're going to be able to justify almost anything you do in an extremely easy way. I'm going to ask for more budget, for 20% more budget because the boss says we're going to have 20% more customers.
Yay.
Yeah.
[00:47:40] Speaker A: And it makes it way more, you know, let's say sellable or way more easy to achieve because you have a goal so you can have a focus and by having a focus you can have more. Like you can have infinity request or infinite actions that you can take. But if you focus on the goal then that's that thing. So talking about action and talking about goals is, you know, if someone wants to do all the advice that has been provided today, this week, what is the one thing that they should do to give context and make top down happen?
[00:48:15] Speaker B: I think it's start read your company strategy.
I would say that's the first thing you should do because with that conversation, if you've got some aspect of it which is top down, decisions have been made already.
Okay. And they are written somewhere to get to that and start from that and say how does it apply to me? It's going to make it much simpler to sell whatever initiative you have, but it's also going to make it much simpler for you to understand what is relevant and non relevant for your business.
Because that's the thing. Another thing is if you are one of these that feel that you have problem having engineers to do stuff the finops things.
Again another article. But there is this thing from the developer's perspective. For example, if it's not in the backlog, it does not exist. So instead of bombarding the poor engineers, go to the product owner.
How do they get requirements? Can you have finops requirement to fit? Can you have some Sprint points to be assigned to you so that that they are rewarded because engineers doing the job you're asking them for finops are probably mislapped on the hand because they are wasting time on stuff which is not what been requested.
And so go to your product owner, have a chat with them. How does it work for me to be on your backlog so that I become I exist and I think that would solve the problem that we plagia people for four years and you're there. How can that be happening?
So that would be my two things. Read your company strategy and apply it to yourself. And the other one is if you want engineers to do stuff, have a chat with their product owner. So again, top down finops because that's the person that has the power to create a slot for your activities and will tell you why they can't do it this month because release is in a week. So just, just get out of my way is a really good answer for them.
[00:50:28] Speaker A: Yeah, I totally like, I haven't thought about the product owner thing but now that I am especially like I'm working more of on that role than on the developer role. I totally agree. Like I am the one, let's say making the calls and redirecting people to what they need to do and what they don't need to do.
And that's like if it doesn't come through, let's say me or through anyone, then it's very difficult that it's going to be made by the team. So I totally agree. That's a wonderful advice for getting people involved. It's like you make it top down, you achieve the product owner and then the engineers will do the work.
[00:51:11] Speaker B: Especially you would be upset if you discover that one day of one engineer was lost trying to optimize a database that was totally unplanned and they've not delivered a feature and you're there. No, no, no, no, no, no, no. Go back.
[00:51:28] Speaker A: That's great, great advice. And you know, I think with that we have more than enough to cover today. So it's a pleasure to. It has been a pleasure to have you here, Frank. I think you provided a lot of wonderful advice. So. So thanks for being here today.
[00:51:46] Speaker B: My pleasure. And I will be slightly selfish. Promotion. I just published a book for managers, so please have a look at Protect the Do let me know what you think about it.
[00:51:57] Speaker A: Yeah, we'll put the links in the description below to all your stuff. And definitely for the book because we love books here, to be honest. And you know, pleasure to have you and see you all in the next episode.
[00:52:11] Speaker B: Thank you, Victor. Bye, everyone. Thank you, listeners.
