Engineering Enterprise FinOps ft. Piotr Kuczmera | Ep # 72
FIA - Piotr Kuczmera
===
Piotr Kuczmera: [00:00:00] I would wish that if every company would start with the question: what exactly do we need? Uh, what kind of FinOps do we need? How big, uh, does this practice should be? Um, I like the comparison to, to a tailor where, who's making a suit. It's like when we would like to order a new suit, we, we go and we make a, uh, we should start with a good requirements, right?
What kind of suit do we need? For what kind of occasion? What kind of guest will be? The same with FinOps. We should ask ourselves, what do we really need?
Intro: welcome to FinOps in Action. I'm your host, Taylor Houck. Each week I'll sit down with FinOps experts to explore the toughest challenges between FinOps and engineering. This show is brought to you by 0.5, empowering teams to optimize cloud costs with deep detection and remediation tools that actually drive action.
Taylor Houck: Today's guest leads FinOps for a 150,000-person global business running at enterprise scale across a complex multi-cloud environment, and he got here almost by [00:01:00] accident. Five years ago, his manager asked him to build a single report on cloud spend, and he's been building ever since, from forecasting to optimization to building an internal FinOps platform from scratch, and the team behind it.
He is a FinOps certified professional and focus analyst. Head of FinOps at ZF Group, Piotr Kuczmera. Welcome to the show.
Piotr Kuczmera: Thank you, Tyler. Thank you for a wonderful introduction and inviting me here.
Taylor Houck: Absolutely. I am... I'm super excited to be chatting with you just because of the, the scale of what you've been able to build and the fact that you've done it from scratch.
Just to start us off, when you reflect on the journey and how you've gotten here today, what's the number one thing that you wish every organization understood about
Piotr Kuczmera: most, very often I hear a lot of companies, uh, equals FinOps to the cost optimization or the cost savings. Uh, having a successful FinOps, how much you can save money, and that's it.[00:02:00]
Uh, but FinOps is much more beyond that. Um, I would wish that if every company would start with the question: what exactly do we need? Uh, what kind of FinOps do we need? How big, uh, does this practice should be? Um, I like the comparison to, to a tailor where, who's making a suit. It's like when we would like to order a new suit, we, we go and we make a, uh, we should start with a good requirements, right?
What kind of suit do we need? For what kind of occasion? What kind of guest will be? The same with FinOps. We should ask ourselves, what do we really need? Are we interested only about reducing the cost as much as possible, or do we want to have, or i- is it important for us to, uh, to manage properly the cost, to make sure that the chargeback is working?
Do we want to build our platform by ourselves? Do we want to order it? So there are a lot of aspects that we need to consider, and I think the initial question should be, what exactly do we need? Because if we are starting only looking on the cost optimization and skipping the whole requirements at the [00:03:00] beginning, then we will end up with, uh, yeah, uh, not, uh, successful FinOps implementation.
Taylor Houck: It's an interesting perspective, and I think that it's so easy for people to always fall back on optimization because it's easy to measure, right? And like everyone loves parading and, and talking about their wins and, "Hey, I saved this much money." But as you're mentioning, there are a lot of other aspects.
What are some of the more important things that you think a FinOps program should be focused on, especially within large enterprises such as yours?
Piotr Kuczmera: So I think it's important is, um, is trust. It's like, um, uh, one thing is to make numbers, savings, like, let's achieve X amount of money savings. Um, but what comes next?
So for me, more important is to make a practice which is still driven. So, uh, to earn trust from engineers that they know to which team they can go. They, they trust in us. They know that we can, uh, show them reliable numbers. They... We can give them [00:04:00] a good recommendations. So when we build, not the team which is making savings and that's it, but when we build a partnership with the, with the, uh, with the, the different departments, with different personas, um, then I think we can really make a very efficient and successful FinOps implementation.
Uh, because then we take the, the expertise from every area. We take the technology, uh, expertise from engineers. We take, uh, people from finance, from purchasing. We, we then take also, um, uh, the knowledge about FinOps processes, the experience from other FinOps, uh, organizations. And if we combine it together, then it can turn into really- efficiently working bicycle.
Taylor Houck: It's such a great point, and it's something that has come up on the podcast before, this idea that FinOps, it's, it's not an individual sport. Mm-hmm. It is a, a team sport, and getting more and more folks involved from across the business is what leads to a successful program. From your perspective, I know that you've built, [00:05:00] uh, a, a team within ZF Group to manage FinOps.
What are the types of personas that you like to see on a FinOps team? And then who are the primary, uh, folks from outside of your team that you're finding yourself working with on a regular basis?
Piotr Kuczmera: So when, when we started with FinOps, um, one of the first questions was, um, do we want to buy a tool which is already on the market?
Do we want to build something by ourselves? So we started making a, a research on the market, what kind of tools are, um, available, uh, what kind of benefits they can bring. Um, and we had, I think, really good discussions to see what others have developed, but, um, also we needed to, yeah, challenge them a little bit with, with our strategy.
Uh, and there were some points that we make a conclusion that it would be much better for ZF not to buy existing tool, but to develop one of the, uh, the tool by ourself. Uh, why? Because we could. We can develop this tool. We, we ha- we know that we [00:06:00] have capabilities that we can use. We have really good experience of great experts that we can, uh, use them to, to build FinOps team, and we can together build a t- a tool that will, um, uh, give us a very big flexibility.
We can make every product we, we, we wish. It's, like, very important in FinOps is also transparency. Put a requirement, we need this in report, and they're not dependent about any other company. so then we said, "Okay, that's, that's quite important for us."
Uh, we had a strategy with multi-clouds, as you mentioned at the beginning. So we know that there are a few companies, uh, that will provide cloud services for us, so we know, okay, with building it by our hands, we also have bigger power because we do not-- we are not dependent on the strategy of the tool provider for FinOps, but we have our own strategy.
We can drive it, and that was very important for us. So then we-- when we did, did a decision, then we, of course, said, "Okay, what exactly skills do we need?" Uh, so we built a, a FinOps team, [00:07:00] which is a mixture. From one side, we have FinOps practitioners, colleagues who are, uh, fully working about FinOps practice.
I would call them really FinOps, uh, consultants. And but together with them, we have in, in the team data engineers, colleagues who are developing the reports, colleagues who are maintaining our data platform so it can work, um, uh, efficiently. And I must say that it's not like black and white, um, let's say, um, differentiation because it's not easy to say like, "Okay, I'm a data engineer.
I don't know what is FinOps." To, to make a successful report, you need to have the basics. You need to know how FinOps is working. So it's like, uh, colleagues working more on the FinOps, colleagues working more on data engineers, but their c- uh, their topics are, uh, let's say, crossing, uh, each other, and that's working really well, and I think it's also great for, for the team development Uh, so we have a core FinOps team which is operating, uh, FinOps practice.
And, [00:08:00] um, uh, one of the important challenges for us was how we want to work with the rest of the dev. We have cloud consumption in IT. We have various, uh, engineering departments. We have business, uh, cases where we have also a cloud consumption, colleagues that we know that we want to support. So in every area, we, let's say, uh, nominated someone responsible as a, uh, as a, let's say, um, owner from financial perspective, but we also nominated a FinOps champion, someone who is between us and the respective team, someone who knows a little bit about FinOps, but knows also exactly what is running, what is important in the respective, uh, products, what is important, uh, for them, and then we can find a really good balance, and this is how, how it works at F.
Taylor Houck: Man, there's a lot to drill into here, and let me just repeat to you what I heard and make sure I understand this correctly. Mm-hmm. What you're saying is that your internal FinOps program and team is built of a [00:09:00] combination of, let's say, FinOps experts, FinOps specialists, FinOps consultants, and data engineers who work together and complement each other quite well to build your custom FinOps platform, which sounds to be very focused on the visibility use cases.
And then when you go and work with your external stakeholders from across the business, you're designating, let's say, a, a budget holder, someone that, that owns the value and the cost of the cloud for a specific scope, and then within that group, you will enact a FinOps champion, which is someone within that team to help drive FinOps best practices within that org.
Is that fair to say?
Piotr Kuczmera: Yeah, exactly. Yes. That's a very good summary.
Taylor Houck: What kind of scale are we talking about here? How many of these budget holders or FinOps champions are you working with regularly?
Piotr Kuczmera: It's, it's very dynamic, I would say, because when we, we started with the, uh, with FinOps and, and we were on the early stages of the, uh, of the cloud migration, [00:10:00] uh, we started calling them commitment category owners because these were the major workloads that we, uh, we, let's say, um, started discussion to, to collect our requirement.
Um, and then during the time, there were multiple changes. Um, so there were new project raising up. There were some which were decreasing. Uh, there were some new services. Uh, but I would say it's approximately fifteen, twenty people. So fifteen, twenty, uh, different categories with nominated champions.
Taylor Houck: And how are you finding yourself working with these different teams, right?
Because I'm imagining you have this central hub of FinOps talent, and then it's kind of a hub and spoke model with these different organizations. How much time are you investing in meeting with these different teams, reviewing their spend, and helping them become more optimized? Or is it more of a self-service and, and they come to you?
Piotr Kuczmera: Um, it's a mixture of both. So, so there are teams who are, uh, working closely with us for a longer time, so then it's like we, we keep the regular, um, synchronization of course. [00:11:00] Um, but they are more, uh, self-independent. They know what kind of processes are in place, where they can seek for support, they know which reports to use, and that's working very naturally.
Um, there are colleagues who need a little bit more support, especially in the beginning. Uh, but that's a really great journey because that's also a, a moment for us to ask ourselves what we are doing. Are we providing a good services for them? Have we forgot about something? It's very easy when we are starting cooperation to provide something and then do not think, "Okay, what exactly, uh, they need in addition?"
So when we have a new colleagues onboarded to our FinOps practice, then it's a good moment that we can ask ourself, "Okay, this and this is missing." They ask questions that no one asked before, and that's really a nice thing because then they can, uh, challenge us
Taylor Houck: Great. And, uh, Piotr, I'm realizing that we're, we're skipping forward a bit, right?
Because now at this point when you have this, you know, hub of folks, FinOps [00:12:00] experts, data engineers focused on FinOps with embedded champions and budget holders who care about spend and are coming to you, this is what happens after five years of building a successful program. I kind of wanna now take you back.
My understanding is, you know, you studied math, you joined ZF as a business analyst, and then your manager one day asked you, "Hey, can you help us kind of, uh, uh, build a report showing what we're spending on the cloud?" And then, you know, now five years later you have this complex program. Can you bring me back to the early days of when you were first getting started?
What did it look like, and how did it grow into what it is today?
Piotr Kuczmera: I- initially it was a, it was a package in- inside of the program, which was about cloud cost, uh, monitoring and optimization. So we said, "Okay, let's, let's monitor how we are progressing with the migration, uh, if we are proceeding according to plan.
Maybe we are too fast, maybe we are too slow." Um, so we started with building the first reports to, to, to track our, uh, consumption. And then we said, "Okay, [00:13:00] let's think how we can optimize." So we started with the first basic, um, steps to, to, to, to make it more efficient. Um, with all the measuring, we added planning, forecasting, and then we said, "Hold on.
We are doing more and more about FinOps. So, uh, do we want to do it as a part of the program? Do we want to do it only for a short moment of time, and then we want to cut it?" And then we, we came to a decision, okay, we want to build a, a FinOps practice. Uh, so then we started the whole discussions about collecting requirements, what exactly do we need, uh, how we want to build that inside of ZF, uh, in which department should be positioned, and so on and so on.
And yeah, um- I would say these five years went very, very quickly, uh, but that was, uh, that is a really exciting journey and, uh, I'm really looking forward for the coming years and the new challenges that are in front of us.
Taylor Houck: That's one thing that has held true about FinOps since I've got
involved, is it's always evolving and changing.
I mean, we're gonna get to AI later. I don't wanna- Yeah ... [00:14:00] uh, jump the gun on that one, but I, I do wanna talk about your journey of building this FinOps platform, right? Because it seems to me like, you know, you got started, had the visibility use case. I, I gotta say I relate a lot to that story because I also got my start in FinOps from a similar kind of experience where my company was just, "Hey, we gotta get a grip on our, on our cloud spend.
Let's build a report. Let's start optimizations." And then, you know, the rest is, is history. But I wanted to kinda take you back to when you were initially building out your, your cost visibility. It sounds like you did it all in-house. You understood that there was an option to go external and- Mm-hmm ... a perfect tool to help you, but ultimately decided that you were gonna double down on kind of a homegrown solution.
Can you walk through that, uh, that decision and how you came to build your own platform?
Piotr Kuczmera: So I, I must say that on the beginning we had an idea, okay, let's [00:15:00] do not build a tool, a tool by ourself. Let's do not invent the wheel once again. Let's use something which is already available. Um, and then we started all the discussions with the major tool providers to, to see what is available in the market, uh, to also get some feedback from similar technology companies, what they are using, how they have built a FinOps, uh, practice in themselves.
And there were tools that we were, um, um, yeah, really looking for, but there were always some, some, some points that we struggled and say, "Okay, we cannot accept that." Like, for example, they were not supporting all our cloud providers, or the license, uh, fee for the tool would be very, very high. So then when you are considering that you are in the migration phase, and then you are calculating, "Okay, to- today I will pay this amount of money, how much I will paying in two or three years," right?
We are building, uh, we are talking about building FinOps practice, not for one or two years, but for a couple of years. So we also ask ourselves, "Okay, how much we will be paying in a couple of years?" And, uh, [00:16:00] also in very important flexibility is how, uh, how... Because at the end, FinOps is, um, is, uh, is a practice which needs to be suited to the existing process in the company, like charging, uh, invoicing processes.
So there are a lot of processes with finance procurement that we need to adopt to the existing one. So we cannot develop something just for cloud, right? Um, so we said, "Okay, if we buy a tool A, for example, everything is working, but we will have this problem, this problem. And if, for example, we will have a new demand for purchasing, what we will do?
We need to go to them, we need to raise a requirement." That's the obvious process. So that's, that's all the things that you need to consider when you are purchasing something from external, right? Uh, and then we said, "Okay, um, and what additional value we are getting," right? What, what would, what, what this tool will bring to us?
And, um, of course, I think the, the, the biggest value is about transparency, about reporting, which are showing you the cost recommendations, how much you are spending, and so [00:17:00] on. And then we said, "Okay, but, you know, we have capabilities inside to build it by ourself." Uh, it's not like we need to find 20 developers and start building a, a experience from scratch.
We, we had these capabilities in a s- in house. So we said, "What if we would build this tool by ourself, and we combine it with the native tools?" So it was not like building a FinOps application, but making a FinOps application which is, um, working very closely with native tools. So we have something, I would say this FinOps application is supplementing this native tool.
So we said, "Okay, if there is something which is done by a, a tool, native tool from cloud service provider," like for example, recommendations, and let's say that they are very good, um, we don't need to build something like that in our tool. Let's focus on the areas that we want to present differently, uh, or maybe we want to improve this recommendation.
So we try to find a balance not to duplicating something which is already existing, but [00:18:00] rather finding a, a good solution how both can work together
I
Taylor Houck: think it's so interesting and I, I, I'll tell you that I have a similar sentiment, especially as it pertains to cost visibility and reporting, because the reality is that all the data is out there and available, right?
Mm-hmm. And in 2026, especially now, building a data pipeline is quite simple, right? Yes, it is. And then you have a, a BI vendor, I'm not sure what you're using. I know a lot of folks are using Power BI or Tableau or Looker. Whatever it is, you build the data pipeline, you get the data into your BI platform, you can build any custom dashboard or visualization that you'd like.
And again, we're not gonna jump the gun on AI, but AI is making all of this even so much easier. And exactly what you said, where every single company has their own way that they want to represent their spend and they want to view their spend. So when you own that, you can build something that is uniquely valuable to [00:19:00] you and not in a, let's say, out of the box, um, environment.
What... Can you tell me about the skill set of the folks internally that you needed to get to this point?
Piotr Kuczmera: Just one last comment regarding this, this what you, what you also mentioned about reporting platform. Um, uh, what I also learned is, uh, from the beginning when we started with FinOps, I also saw that there are different principles, right?
And v- too, too many of them, I had the distance in the beginning, like everybody takes ownership, uh, reports needs to be timely and so on. These are the things that you say, "Okay, it's a nice theory," but at the end everybody will be looking on the, on the, on the, on the numbers, savings and so on. Um, what I discovered that these principles are very important.
It's like, uh, when you get the trust, when you show the, the people, "Hey, you are owner of this specific, uh, sub account, how much you can save," that was like, uh, switching a, a, a button. They really, you know, get into these, these topics. They make a decision. They are, they are very active because they feel accountable for [00:20:00] that.
So that was also one of the benefits why we said, "Okay, if we develop something which they know, they know already, uh, um, the reports, uh, um, that they know the reporting platform, I need... don't need to go to them, 'Hey, you need to press this link. You need to log in with this account, and then you will see this.'"
I said, "Hey, here we have five reports that you already know from this department, and here is one extra." So then it's much easier to, to earn their trust and, and that was also, I think, really, uh, something which, which pushed us, pushed us into this direction. And, uh, another thing is you, you already started about AI, and that's really interesting, uh, potential, and that's, uh, if, if you, uh, if you built a platform, um, it was like opening a box.
It's like when, when starting the beginning, "Hey, let's make a, a tool which will, uh, make some reports. Let's make a tool which will show some recommendations." But then we said, "Okay, if we will have this data in our hands, we can connect it with multiple [00:21:00] services, external services that will be, you know, analyzing this data, and then we can...
It's not only about making some reports, it's really about analyzing the data and taking the right conclusions that can really speed up the, these activities."
Taylor Houck: Yeah, absolutely. I, I, I do wanna just jump back to one thing that you just said that jumped out to me. Mm-hmm. And it was that when you had someone who owned their spend, that's when the switch happened and they started to care.
Can you talk to me a little bit about how you got them to feel that ownership and care? Was it chargeback? Was it just education? How did you, um, get that mindset instilled within,
Piotr Kuczmera: So I think the, the, the chargeback was one of the most important capabilities, because then, then you can easily, uh, uh...
When, when you are talking about the costs which are related to project, and then there is, like, a project budget, you don't really feel this accountability. But when we are saying, "Hey, you are responsible for this budget, and it's, connected with your name, and this is the amount [00:22:00] that you need to pay," then there was, like, an easy connection between the person and the budget, and that's something which, really speeds up things, because then we were not talking about overall budget for an application project.
But when we precise our chargeback process and then say "Hey, you will get this invoice," then people start asking, "Okay, for what am I paying? Why am I paying so much? Tell me how I can decrease the cost." And then we said, "Okay, great. Let's, let's work together. We have all the recommendations, and we w- we can, uh, show them to your team."
And that was something which, uh, which I think it was really a very big step towards a, uh, successful FinOps,
Taylor Houck: That's great, and I can imagine that when you have, you know, especially, again, at a company like yours that is so big with so many different types of teams and, and types of business units, these people that you're working with, they're not all necessarily cut from the same cloth, right?
Mm. They all are gonna bring their own background, experience, perspectives. How do you find it is working [00:23:00] with, you know, a, a diverse group of individuals, and how do you work with them to ensure that you're all on the same page?
Piotr Kuczmera: That's something that I, uh, that's one of the things that I really like in my job, that, that we have so many various personas.
It's like, uh... And then I realized that, that FinOps is not only about making cost optimization, making reports, but making sure that each persona understand everything. And you have, like, on one day you have a meeting with financial, uh, colleagues who are then paying invoices, and then you have engineering teams.
How to translate to each of them, okay, how your change is impacting another department, and that's, that's... I, I feel that- And then the organizations, there are different blocks. Uh, but what is missing with FinOps is like something which is combining these blocks together, which is ensuring a proper information transition from one box to another.
So how to say to, to an engineer, "Hey, if we do these recommendations, how it will impact the budget [00:24:00] of your manager," for example. How it will also impact the, the other processes. So I feel that FinOps is really like in the middle of, of the chain between different personas. And, uh, that's for me, um, really interesting because that's, uh, you know, always need to switch from one team to another team and ask yourself what kind of information they really need.
And, and that's, that's also very important to understand what are the requirements. Uh, financial people do not need to know, okay, for which VMs they are paying, right? They need to know only the financial figures. Then the managers, they need to know, okay, what is the impact of this change, not going into too many details.
So with every personas, you need to be very direct what exactly they need to hear, what exact information they, they need, and how we can support them. It's like they, they have every puzzles from their team members from different... It's like if you are responsible for a certain product, then controlling finance, they are giving you a lot of financial information.
Then your team is giving you a technical, uh, background. And I [00:25:00] think that's also a role of FinOps to say, "Hey, let's put everything together. Let's, you know, let's glue this together, and then it will make sense."
Taylor Houck: Yeah. And it's back to that same idea that this is a team sport, right? Mm-hmm. And you want FinOps to be that, you know, connective tissue that can bring people from different, let's say, walks of life or experiences together towards this common goal, which is to improve the, the ROI or the value that you get out of your technology spend.
Um, and with that being said, I, I do now, Piotr, wanna transition to the topic of AI because- Mm-hmm ... this is the number one topic that is on everyone's mind that I'm talking to right now, right? And there's really two angles that I see coming up over and over again, and I would love to get your thoughts and perspective on, on how you're thinking about...
You can choose one, the other, or both of these ideas, and this is, one, AI becoming a bigger line item within the cloud bill. Essentially, we're spending a lot of money on AI. How do we manage, govern, optimize [00:26:00] AI spend? And also, how do we use AI within our FinOps practice to become more efficient and deliver more value back to the organization with this now, you know, silicon intelligence that we can use, uh, to, to grow our, our team even further?
Piotr Kuczmera: So then, then we have FinOps for AI and AI for FinOps, I, I was interested, I'm interested, especially in the second, um, part, how AI can leverage FinOps, uh, especially when we had this discussion about re- building reporting platform one of the drivers was also we have the data, we have capabilities to , uh, connect them with different services, and also we can leverage AI services on our data because we have them in our hands and that's, that was a, a moment when we discussed where we want to go, how we want to increase our maturity, how we want to automate our steps. And if we will look on, on multiple processes from FinOps, uh, there are a lot of steps which are repeated. so then we said, "Okay, we can [00:27:00] make a, you know, a, a really easy workflow from one step to another step."
but there are many things that you need to consider in addition. Like for example, recommendations. if you have a specific VM, There are a lot of parameters about CPU memory that you need to consider. but what if We want to go beyond of that? We don't want to only measure two pa- parameters. We want to something more.
We want to check what kind of features we are using. maybe there is a completely different family which can, can provide us. Maybe there is A connection with, uh, some commitments. so various things. Um, Then that would be a good thing to, to see how AI can support with one, but that's I think only beginning because with every week, month w- that we see how AI is developing very, very drastically, uh, I think in half a year, in one year, we will have much more c- possibilities with AI.
We will have much more use cases that we can use. And it's also clear that if we will use AI for one of these scenarios, then we will have 10 new scenarios, right? So [00:28:00] that's really exciting, uh, journey in front of us to, to see how we can really use AI to, to help FinOps.
Taylor Houck: Yeah. And, and using it on the optimization front, that's something that I'm focused on pretty much every single day.
And there's really so many new use cases that have come up, and the possibilities are endless. I mean, especially even just around, uh, remediation, right? And helping engineering teams to take action on recommendations as they're given, right? So how do we use AI to make sure that our recommendations are sound, accurate, right, descriptive- Mm-hmm
telling them exactly what's needed, and then of course, also help them actually take that action. There's so much to that. I now want to shift to the first, uh, topic, which is
FinOps for AI and talk about AI spend. Is AI spend something that's become a priority for you and your program at ZF?
Piotr Kuczmera: Um, I would say yes and no because from one side we treat AI services as, as every other service. So we [00:29:00] didn't say, "Okay, here is the, uh, FinOps practice for non-AI users and here is for AI users."
So we treat it similarly as the other services. So, um, that's something that we learn on beginning. We will be multi-cloud, so we want to be cloud agnostic. So we wanted to develop processes which will work for every different type of services, uh, including AI. So our processes are, I would say, cloud fle- uh, quite flexible.
So we treat AI as any other service that we can purchase from the cloud providers
Taylor Houck: Piotr, that's, that's so interesting and I think that, I mean, you alluded to it earlier about the, the, the pace of innovation right now is so rapid that it's almost hard to look too far ahead for ourselves.
But when you think about these two aspects, FinOps for AI and AI for FinOps, when you look for, let's say, just one year, a year from now, what do you think the well-tailored FinOps suit is going to look like?
Piotr Kuczmera: this, this, le- let's say, final suite, which is supporting both aspects, [00:30:00] um, would from one side text, uh, take maximum possibilities that AI can bring to leverage, uh, the capabilities. Um, but also especially when we are talking about AI spend, FinOps shouldn't be a blocker. We shouldn't slow down AI, uh, let's say innovation because of some existing processes.
So if we have FinOps, that's something that should be support, that should be opening the gates. So, um, this, this tailor, this, this let's say suite, which is, yeah, uh, tied to, to, to the company needs, uh, should support this innovation because that's, that's clear the, the direction that we want to go. It's clear that we want to use more AI.
We want to be, using more of, of, of the AI services. We want to be more innovative. We want to be faster. So FinOps, that's something which should only make it happen and not, uh, be any of the potential rule blockers.
Taylor Houck: Awesome. Awesome. It's gonna be so fun to see how it all plays out, Piotr. I know you're gonna be [00:31:00] a, a big part of it now.
As we get to the end of our discussion today, you know, we've spent the first bulk of our time really learning from you, but now I actually want to change gears just a little bit and learn a bit more about you because I think that there's a lot that the audience can learn, not just from the practical in-the-job aspects, but also, um, some more personal things.
So I, I kind of wanna first take you back. I know that you studied math, right? Mm-hmm. Did you ever have an idea that you were gonna end up, you know, running a, a FinOps team for 150,000 person organization? How, how did you even get here?
Piotr Kuczmera: Uh, not, not really. Not really. And, and being honest, that's, uh, I, I'm sometimes joking that I'm in the IT because of an accident.
So it's like when I was studying math, very often I, I heard a phrase that, uh, after finishing a math, you don't have anything concrete, but you also have a lot of possibilities. It's like if you go on a, uh, on a, uh... I don't know, study with a clear direction, you want to be a doctor, then you will end up in the hospital, [00:32:00] right?
In the math, you can go into multiple, uh, departments. So then after finishing that- I started looking, okay, uh, where I can- what kind of opportunities do I have? And from various companies, I received an offer. So I was thinking, "Okay, do I want to go more into IT? Do I want to go more into the static, uh, the statistics?
Do I want to g- go more into, uh, a, a manufacturing department?" Uh, but somehow, uh, on the first job, my, uh, first boss, he convinced me to, to join an IT department. And then it worked smoothly from one company to another, uh, learning, uh, different, uh, technologies. And, uh, being honest, I'm really happy that I'm here in the FinOps because I feel that I can use something that I was studying.
I can use all the experience from my past companies, like working in the, in the second level and having the, the contact directly with the, with the business or working with different stakeholders. I feel that in, in the FinOps, that's something that I can use [00:33:00] really experience from the past years, and that makes me happy because then I have a feeling that these last years, that's something that was preparing me for, uh, what I can, uh, work today.
Taylor Houck: You know, we have a lot of listeners, Piotr, that are earlier on in their, their careers, their journeys, and they're, they're really just getting started. If you could give one piece of advice to a younger version of yourself, what would it be?
Piotr Kuczmera: Stay humble and don't be afraid of challenges.
Taylor Houck: Awesome. I absolutely love that advice.
Piotr, this has been such an amazing conversation. I really appreciate all the time that you donated to us to share your knowledge and expertise.
I think everyone who listened today has something they can take away and implement for themselves. If people want a little bit more and wanna connect with you, where's the best place to, uh, to find you?
Piotr Kuczmera: Um, I'm present on LinkedIn, so it would be really, uh, great if you could invite me. We can start a conversation, um, about FinOps or about any other topics, so I'm really ke- looking forward for that.
Taylor Houck: [00:34:00] Awesome. Piotr, this has been fantastic. Thank you so much for coming on the show.
Piotr Kuczmera: Yeah, thank you for invitation. Thank you, Taylor.
Taylor Houck: Absolutely, and thank you to our audience. If you got something out of today's conversation, which I'm sure you did, please share it with someone who needs to hear it. This has been another amazing episode of FinOps in Action, and I'll see you next time.
Outro: That wraps up another episode of Fit Ops in Action. Thank you for joining. For show notes and more, please visit fit ops in action.com. This show is brought to you by 0.5, empowering teams to optimize cloud costs with deep detection remediation tools that actually drive action.
Creators and Guests
