Episode Transcript
[00:00:00] Speaker A: Different people doing finops come from different backgrounds. Right. It's a DevOps background. I'm a cloud solution architect, but lots of people I meet don't necessarily have the technical experience. Right. For me it's more about almost a stakeholder management exercise in terms of developing trust, a level of understanding, a common understanding between those teams, partnerships, collaboration, developing trust in the first instance, before then getting to the actual incentive for engineers to reduce cost was that that cost saving could be used to bring in more engineers. The one thing for me is the common language, the common taxonomy, right. So if I go to an engineer and I'm talking about reservations and commitments and NFUs, right, and they don't know what I'm talking about. It's almost one of the bigger kind of change management, stakeholder communication projects that you might undertake to bring together such a broad community of people and to get them up to the same level so that they can communicate, communicate efficiently.
[00:01:04] Speaker B: So welcome everyone to a new episode of finos Weekly podcast. Today we have a very, you know, special guest that has been recommended by a lot of people from, from the community that has been featured in Professional Spotlight of Phoenix Weekly and I think it's a very well known figure of, of the community we have today. Jeremy Chaplin from Flexera. How are you, Jeremy?
[00:01:29] Speaker A: I'm very good, thank you, Victor. Thank you, Damien for the opportunity to come and join you today. Excited to have a good conversation with you.
[00:01:38] Speaker B: Thanks for having the call. I think it's very special to have you today. Of course. I want to greet my partner, Damian. Damien, how are you doing today?
[00:01:50] Speaker C: Doing well, very excited, doing a lot of stuff lately and again, always willing to talk about finops and especially with a good guest like Jeremy.
[00:02:04] Speaker A: Yeah.
[00:02:04] Speaker B: So it's been a pleasure to have you on today. I think we have a very interesting discussion because as several part of the FinOps audience, some people come from the finance world, but a lot of people come from the engineering perspective, such as, for example, me, I come from the DevOps background.
So we want to know a bit about the integration, let's say, about this engineering into the FinOps code. So in your perspective and in your experience, you know, how do you find the role of the engineering side into the finop ecosystem? How do you think it develops and what are the key factors so it's effective for the finop practice?
[00:02:47] Speaker A: Yeah, it's a great question. And if, you know, it touches on the fact that different people doing finops come from different backgrounds. Right. You, it's a DevOps background. I'm a cloud solution architect, but lots of people I meet don't necessarily have the technical experience. Right. They might be coming from a finance background, even a procurement background or whatever it might be even kind of licensing and other areas.
And so for me, you know, I've, I wouldn't say I'm, you know, I've got the DevOps experience, but I've certainly had the experience of trying to take recommendations and look to engineers to act on things. It becomes a trust issue. And that typically is, do you understand that the challenges around provisioning infrastructure to support applications, do you understand the process that has resulted in the decisions that we've ultimately made? Because you're challenging an engineer to say, well, we think maybe the decision was ultimately wrong or that there's a more optimal way that you can do that.
So for me it's more about almost a stakeholder management exercise in terms of developing trust, a level of understanding, a common understanding between those teams before even then getting into the nitty gritty about, well, how did I come up with this recommendation in the first place? What tooling might I have used in order to make those recommendations? So partnerships, collaboration, developing trust in the first instance, before then getting to the actual, hey, let's have a conversation about why this instance type or why this particular node type for a cluster or whatever the change may be.
How does that reflect on your own experience, Victor?
[00:04:32] Speaker B: Yeah, so I mean from my experience, something similar.
So basically, after all, what I've seen engineers do is basically start from building internal tools from end users. So in this case, if you are a, a vendor provider, basically building the actual tool that your service is doing, but for an end user perspective is actually working on applications whose target is reduced cost or cost, allocate or doing some stuff. And that's the way you introduce yourself to the ecosystem, start understanding showback, chargeback, all these terms, all this language from building the application.
So that's kind of the way that, and seeing it's introducing themselves. And from there this, this, let's say tier or this group of engineers can then expand or help the rest of the organization to adopt the, the practices and to install, let's say the finops culture from the engineering perspective because they already have worked in something that is, you know, finops related but from a application perspective. So that's I think, is the way.
[00:05:42] Speaker A: I think it relates meeting in the middle. Right? So the FinOps Persona kind of leaning in a little bit on the engineering side and getting some engineering, you know, understanding at a high level and then the engineer leaning towards the FinOps Persona and understanding the chargeback, showback use cases and the other terminology around finops. Yeah, I guess hence the training for finops for engineers. Right. So makes a.
[00:06:07] Speaker B: And also it's because after all in companies you get a point where the management asks about cost, not necessarily because of freenote but just because of finance perspectives. So that way you need to estimate what's the unit cost or what's the business cost or business area cost. And from there I think it starts okay, now we will check the cost one time a year and then we say okay, we are spending a lot on this, this and that and then from there let's say yeah, we can reduce from here to here and then, then it starts, you know, evolving and then now I think it's More expanded the FinOps culture and is more, let's say professional and constant rather than one time budgeting year.
[00:06:56] Speaker A: Yeah, you touched on a point there. I think that's particularly interesting in the unit cost space. Right. Unit economics measures because we're talking about eliminating cost or we're talking about reducing waste, but actually we should be having a conversation about value.
And it may well be that actually I increase the workload size, I process far more transactions or whatever the unit is and therefore the value increases and the unit cost decreases.
So it doesn't necessarily have to spend less, it could be spend more and drive more revenue. Right. So I think that that's common in the practitioners that I see and in the management focus of course in that it's always misconstrued to be a cost reduction exercise rather than a value realization exercise.
And I think that has different implications to people taking action as well because they're always make it cheaper and faster, quicker. Right.
Competing things. I'm also interested as well. So you know, given the recent direction of the foundation, you know, take taking action on recommendations continues to be challenging and the things that I'm seeing that are barriers, you know, potentially to doing that would be, you know, obviously shift left would be great to kind of bake those things in at the point of design anyway. Right. And that then becomes, well, FinOps as a solution architect or FinOps as a, an application designer or whatever the role might be. But then the other piece is of course, you know, the proliferation of infrastructure as code platforms, changing the size of an instance in a cloud console is no longer the right thing to do. What are the solutions that are more tightly coupled to the pipeline that you're using to build that infrastructure and I think that there's challenges in terms of tooling and how we go about that right now, but that makes it difficult, it really sits still with the engineer to actually make those changes rather than bringing any automation to bear at this point in time.
[00:09:06] Speaker B: Yeah, yeah, indeed. And also coming from that perspective, I think for example the recent acquisition of HashiCorp, which is the company building Terraform and all the Terraform movement that was I think a year or a year and a half ago but the change of licensing that it happened and all the OpenTOFU initiative, all these details that now affects a lot about infrastructure as code. Because after all apart from Terraform there is Pulumi and there is OpenToFu as an alternative for Terraform but everything is super concrete, super specific to these providers apart from cloudformation authorizer but for the generic multi cloud perspective it's only that.
So that changed a lot.
Now I think the FinOps is integrating more DevOps practices like infrastructure as code and all of these. So I assume that would come to.
[00:10:03] Speaker A: Be interesting to see. I think IBM just closed on HashiCorp. Right. So I think that is tweeted and announced this week. So it'll be interesting what direction they take that product in. I think there's some nervousness in the DevOps community that I speak to about that.
[00:10:20] Speaker B: Yeah, I think the change that like the first thing was the license change that I think was part or let's say part of the agreement to happen beforehand, let's call it that way. So I think that was related and that was a bit of a, you know, movement. It caused OpenToFu to appear.
So I'm not sure whether or not like now there's going to be changes. Probably there will be, but we'll have to expect and what's going on because Terraform is a very core element into infrastructure at code and it would change anything because providers have spent a lot of time making resources modules. So if you go to the code of Azure or AWS modules and you see like all the business logic there, I don't know, I think there are 2000 modules from AWS or resources alone, which is like a lot of engineering effort.
[00:11:16] Speaker A: Yeah. Do you know what the kind of market penetration is of like HashiCorp versus the native, the native tools, the cloud formations and others?
[00:11:26] Speaker B: I don't think I have the numbers but for, I think it's, I don't know, like everyone is doing Terraform unless you are, let's say super into one provider, like for example, cloud formation.
If you have More than one for sure. You are using either or Terraform or Pulumi I think or Open Tofno, I'm not sure. I would like to see what's the penetration of the market of Open Tofu and Pulumi versus Terraform. Now I would like to see if that trend has changed. That's a, that's a very interesting question. I will try to, to find that in for you.
[00:12:02] Speaker A: That'd be worth worth digging into. But nonetheless the challenge remains in that, you know, everybody is kind of focused on, particularly when we think about automating those actions, taking action on the resource itself. And really that's a little bit misinformed in that most people have got programmatic code pipelines and it's just going to replace the change that you made with something in a script.
[00:12:29] Speaker B: Coming from the take action thing the other day we were making a webinar about finOps in the DevOps cycle. So very related to what we're talking here today.
And the topic come about incentives, you know, because engineers may or may not have, you know, have some features or they have to, you know, have the application working, have the reliability, the security, etc. Etc.
But they may or may not have the cost part into account if it's not super, let's say relevant or there are not big applications. But what was the discussion point of that day was that okay, maybe if we put incentive programs on the end users we will get better information.
And so in your case, what do you think an incentive program for, you know, improving business value metrics or improving the cost relationship would affect the end users, engineers. How do you think that would play around?
[00:13:36] Speaker A: Yeah, what a great question. I mean it's really challenging. In fact, measuring the outcome of usage reduction in itself is challenging. Right. So, you know, rate reduction, savings, easy to understand what you might save with a reservation or a savings plan or a committed use discount. But when you produce a recommendation that says hey, right size this or delete this or terminate whatever, how do you know A that the action is taken, B that it's the action that you recommended and see actually what the material value of it was. Right. So incentivization, it's about, I think. Well, there's several aspects to it if you're going to do it after the fact. Right. And you're not going to build cost into the criteria that an engineer is considering, which one would argue is going to be the most successful way to do it. Because you know, they should be doing that at the point of design if you're looking at it after the fact. It's about efficiency metrics. Right.
Let's take a simple one, which would be recommendations as a percentage of the overall spend of the application.
Quite a blunt metric, but I think those things are extremely difficult to drive through the business compared to doing it first and doing it right and have an executive level kind of decision that cost is factor of consideration because they're up against competing priorities of the business. So anybody we're pushing into a JIRA backlog to prioritize, is it a case of, okay, I'm incentivized to save cost on this, but actually the business needs me to build a new feature or a new application or whatever it is. And so those things can be very hard to get relative prioritization from the business.
And therefore the incentives would have to be pretty strong and maybe in opposition to other outcomes that you're looking to achieve.
So I don't think I know the solution. I know that it's a complex problem and one that we spend a lot of time kind of chewing over with customers around what KPIs are going to deliver the right outcomes.
But it again goes back to the shift left, right. If we can get that baked in alongside the functional requirements, then we're more likely to be successful at the point of build and design rather than after the fact.
[00:15:57] Speaker B: Yeah, definitely.
[00:15:59] Speaker C: The incentive is a key part because I always, when we talk about pinups and DevOps, I first think if I was doing my job, you don't want to someone external come and tell you what to do.
So I think the problem starts in there and incentives are, I think it's a must in order to make people, to engage people. So it must be on the. Whether it's a yearly, you know, when you do an overall, you know, an overall.
I forgot the word performance review. Performance review, exactly. The performance review of the person. It should be there.
[00:16:46] Speaker B: Right.
[00:16:47] Speaker C: And that could be a good metric.
[00:16:49] Speaker A: API for if you can bake it in. But it's also a retrospective thing then and against other competing priorities, isn't it? So it becomes difficult to achieve both of those outcomes potentially and which one delivers more value for the business.
But yeah, interesting challenge.
[00:17:09] Speaker B: I think what you said is pretty interesting. Like the reactive versus the proactive approach.
I think now mostly everyone is on the reactive approach. Like, okay, we're spending a lot. We already have the architecture, design, everything is designed. So the main issue or the main point of conflict that was said with the incentive programs is that, okay, if we reduce, let's put it the case that we reduce and maintain the same value.
So if we maintain the same value and reduce the cost, then how we can prevent.
Because in companies this tends to happen like you reduce the cost and your budget for next year is lower.
So the idea is that that's very problematic and you need to prevent like how do you tell the executives or the people that are above that that yeah, we have reduced because we made a re architecture, we make an effort and we need now with this budget, the application was good. So the only thing that we need is instead of reducing our budget, keep the budget and have more people or have more features or have more tools. How do you translate that to the executive above you? How do you get executive buy into not to cut your budget when you have done finops?
Let's say savings in this case.
[00:18:27] Speaker A: Yeah. It reminds me actually of a great incentive that I heard. I can't remember where I picked this one up from, but there was one organization that the incentive for engineers to reduce cost was that that cost saving could be used to bring in more engineers. Okay. And so the savings were effectively retained and invested in growing the team.
And of course then your velocity increases and the business value ultimately increases as well. So I think, you know, it's twofold. Using that as an incentive to, you know, bring more, bring more engineers in, grow your know, share the, share the workload. But also talking at an executive level about not driving cost out, but driving value in. Right. So if I can save money here, but I can make the team go faster and deliver your business outcomes, then it's a win, win for, for all involved. So I think it's, it's again, not just thinking about it, you know, driving cost out, but actually driving value in and growing your business and using finops to make money. Not necessary to save money.
[00:19:35] Speaker C: Another option would be invest in innovation.
Technical people like to, you know, like technology, like to test new things, learn new things and, and that can be also a very good incentive that I also think is a very valuable one.
[00:19:53] Speaker A: Put the money in, I don't know, an ML pot or an AI pot that you can go and look at automation or whatever it might be, but reinvest, I think is, is the key there as well.
[00:20:03] Speaker B: Yeah, yeah, we maintain the value and we try to improve the margins while trying to, you know, reallocate the input to a different, let's say, area that can bring more value in the future.
That's super, super interesting. So yeah, I mean we've been talking about, you know, A lot of, you know, advices and goes about engineering but maybe the audience want to know more about like you know, because I think people are super, you know, interested and they have doubts about how, you know, they become phenops either engineers or leads etc. So for someone that is, you know, trying to transition, I have a lot of questions about transitions about to finop. So tell us about you know, your story and how it's been your, your road till, till this point.
[00:20:50] Speaker A: That's a great question, interesting one. So it background. All my life, you know, even as a kid I knew I wanted to do computing despite my inability to do maths very well. So I persisted, I persisted at that. But yeah, spent, spent a lifetime in IT originally in kind of desktop, you know, and networking and then you know, into a kind of change management and ITIL space. I spent time in the CRM industry with doing Siebel and that was my kind of first exposure to SaaS and other applications.
But the journey really to FinOps was as I started to lean into the cloud architect role.
So as a solution architect in the insurance tech space originally on premise, the insurance industry were typically kind of a little bit laggards in kind of modernization and adoption of cloud.
But yeah, that was a great opportunity for me to sort of learn initially on aws, you know, a bit about cloud and get, get educated. And then I was involved in a data center, you know, migration program. So that, that was really informative for me, you know, and of course a lot of that was driven by cost based decisions. The cost of a data center, the cost of refreshing a data center, you know, and modernization was, you know, one of the reasons for the adoption of cloud amongst others.
And at that point actually, you know, I changed roles and went contracting as a consultant for a UK based MSP reseller of cloud and they had a practice for FinOps, it wasn't called FinOps at the time, it was cloud Financial management and they had a partnership with you know, a well known vendor of FinOps tooling, but hadn't been too successful in kind of getting leverage and getting the traction there. So I went and worked with them on all things finops, you know, the go to market, the consultancy, the delivery, you know, the outcomes and value realization. So it was really a kind of a baptism of fire I guess at the time because it wasn't called finops and I didn't know really what it was at the time but you know, it was super exciting.
And then from there I've been in the vendor space since which is looking at it from both sides of the fence. So that was my journey. But I come across people that have come in from all different angles.
Consultancy of course in the IBMs of the world, but Linux engineers and finance Personas and people that have come in and have been given control of finops from an ITAM or a license management background as well.
I don't think that the background necessarily other than IT being, you know, having a little bit of an IT background is necessarily important.
But you know, my keys I guess to success would be that you know, the willingness to learn, get hands on, get involved. I mean there's just so much learning. Every day is a learning day, you know, and so embracing that and enjoying that, you know the passion for finops comes from a passion folk from learning things really and such a deep and broad area that there's always something new to embrace.
[00:24:13] Speaker B: That's quite an interesting story. I think that for whatever reason all the finance, insurance perspective come to get related to finops. After all it's kind of the source of all the practice plus all the freelance and consulting. I think all these, you know, consulting tooling site has a very powerful role about making I don't know what you said the bad things on fire. Like I don't know if you're a freelance and then you get, you have to make a cost reduction because you are a cloud architect or whatsoever then you start you know, learning a lot of things and that's what happened for example to me that I was helping someone on their cloud architecture and there was some objective to reduce the cost from there I discovered like okay, cloud cost reduction and then I search about the keyword finops and then I researched everything and you know we are here now so it's, it's super interesting to see like how this bad things happens. So nowadays for someone that is, you know, maybe an engineer that has some, I don't know, inclination to finance or likes numbers or I don't know all these finops related practice. What would be your advice or your considerations now that you have experience on the field to become someone that is, you know, FinOps oriented or a FinOps engineer? What do you think are the steps to be able to become a good prenups practitioner from the IT perspective?
[00:25:45] Speaker A: Yeah, I mean I don't think it's a difficult transition. Most engineers that I've met, you know are very interested in efficiency generally. Right. So you know, it's just that another metric that one would consider to be successful if I can make it run Efficiently then I'm typically reducing the cost. So yeah, obviously you need to be interested and want to deliver the best outcomes against the requirements that you have.
But an interest, whether it's from a finance perspective in the levers that you can pull, an interest in the business side of it, in terms of how an organization is committing to use cloud, what the cloud strategy is and those kind of things are important because you know, commitments, RI savings plans, all of those kind of financial instruments, if you will, you know, become part of the puzzle. And there's a lot of depth and complexity in there for kind of reaching out to it. But you know, start small, go and go read the docs, look at, you know, the finops.org, get involved, look at the KPIs, you know, the fact that it's effectively, you know, open source at the end of the day and open for people to participate and share their thoughts I think resonates well with the engineering community as well. You know, so everybody's welcome to participate.
So I would just see it for me as kind of a natural career expansion. You know, there's another requirement that I need to consider in the build. There's a whole framework that gives me a bit of structure about how to think about that. There's a massive community now of course of people like minded that are willing to support and I think now the time is right to get involved particularly with the kind of shift left momentum that we're seeing from the foundation and the community because those engineers are going to be the ones that are needing to think about that and do that early on in the design life cycle. So now's the time to go and get involved I would say.
But start small, learn lots and contribute as you learn.
And that's how the framework and the foundation ultimately have been successful in the rapid growth that we've seen in terms of membership and participation.
[00:28:01] Speaker B: Yeah, I agree. And also I think the target that it's super business impactful.
I think that also contributed to the expansion of, of the old ecosystem plans. You know, all the community work that everyone is doing. I think it, it's, it's very good. And so, so continuing on that like for example now this, this person of these people have become Phenups engineers or they have like a clear, let's say role now they are attached to that or they have like partially tasked to that.
What are your considerations in terms of the collaboration or the communication perspective? Because we've seen that this role is super collaborative, super oriented to communication because you have to deal with the finance perspective, with the executive perspective, a lot to get buying of the initiative. So what are your indications for these people in terms of like how to communicate, how to learn how to get buying from the executives and see to progress the practice?
[00:29:00] Speaker A: Yeah, it becomes a question of organizational wide change. And I think anybody that's done the kind of finops professional course, it's, you know, almost less about going deeper on the finops aspects of it and the actual optimization side of things. And it's more around the organizational change, the stakeholder management, the communication, common taxonomy, education, you know, those that I've seen being successful and a few organizations come to mind, but have fantastic training programs mandating engineers, go and get FinOps certified for a start. But also, you know, educating from an executive level level all the way down, you know, around finops, around the why and around the value proposition of it ultimately.
But the one thing for me is the common language, the common taxonomy. Right. So if I go to an engineer and I'm talking about reservations and commitments and NFUs, right, and they don't know what I'm talking about, we're off to a bad start. And similarly, you know, I should learn a little bit about, know the engineering disciplines and understand some of the challenges and competing requirements that an engineer needs to consider on a daily basis as well. So getting people in a room, you know, getting onto the same page, whatever that might take in terms terms of education, of course an executive mandate is going to help with that, but doesn't have to. Right. Cloud, center of excellence or heavy, whoever's going to kind of lead that and just be mindful. I guess at the end of the day everybody's, you know, actually focused on the same outcome which is driving business value. We're just coming at it from slightly different angles.
So common goals, common taxonomy and an open mind I think are keys to success there.
[00:30:48] Speaker B: Yeah, I think you have highlighted very good things. And also the language part is crucial, I think, for, because especially in this practice, which has a lot of terminology and very specific, you know, terms, I think being able to understand everything, being able to digest everything, since it also impacts like a lot of areas.
We need like a single point of trust to be able to, you know, to communicate and learn.
[00:31:18] Speaker A: That's another key point, isn't it, that the broad range of stakeholders impacted by cloud, you know, shouldn't be underestimated. And so when I'm talking about having the right people around the table, it's likely finance, it's likely engineering, it's likely, you know, the architects, it's likely security people. Right. I mean the impact and the business themselves ultimately that are looking for the outcomes.
So it's almost one of the bigger kind of change management, stakeholder manager communication projects that you might undertake to bring together such a broad community of people and to get them up to the same level so that they can communicate efficiently.
So yeah, it's an interesting challenge. It was one that we undertook in the kind of fintech and insurance space that I was operating in initially as we looked at the early adoption of cloud.
But always a challenge. And we see organizations, of course, all sorts of different levels of maturity as they go on that journey.
[00:32:18] Speaker B: Yeah, I think it's built on the cloud journey. Especially now it's expanding to the whole, let's say on prem, hybrid, cloud everything.
But it's going to be like an ongoing practice and as you mentioned is organizational wide impact to the audience.
So yeah, I think we covered a lot of interesting topics. I think engineers and executives and finance will have a lot of information here to take action. So Jeremy, thanks a lot for giving all those insights. It's been a pleasure to have you here today, man.
[00:32:53] Speaker A: Likewise. Thank you both, Victor Damian, for again the opportunity to come and talk to you. And I will keep listening and look forward to hearing more from more guests as you continue with the podcast here. So wishing you every success.
[00:33:08] Speaker B: Thanks a lot, Jeremy. It's been a pleasure. See you in the next episode. Bye bye.
