Episode Transcript
[00:00:00] Speaker A: Welcome everyone to a new episode of the Finos weekly podcast. And today we are going to move a bit from the technical side to more into the accounting, into the finance side with Magda Finos from British Airways. Magda, how are you?
[00:00:14] Speaker B: Hello. Good, thank you. How are you today?
[00:00:17] Speaker A: I'm doing good. It's a pleasure to have you. And I would love to create an episode on this podcast to bring people from, from different backgrounds. And today we are going to talk more about the finance, the cloud invoicing, more on that side. Right. So, you know, I want you to make people aware that, you know, while this normalization comes from, from the technical and the leadership side, I like to involve finance people here and I like that one of the things that brought me into finops is that it's super engaged into finance and, you know, it's a pleasure to have someone from that here today. So, you know, I wanted to, to start right, with some finance questions for you and then we can go a bit about your story and how you ended up in finau. So regarding cloud and the invoicing, one of the most difficult things are the invoicing, the bills and understanding all the things. So on your perspective, why do cloud invoices confuse even experienced finance people like yourself?
[00:01:27] Speaker B: It is confusing, I think, because there is a lot of detail in the invoices and to be able to figure out what you have in your invoice, you have to go through at least one of them in a very detailed way.
And I think also the invoices are not showing fully the usage that you have. It has only the numbers, the cost, and this is, I think the most confusing part of it.
So from my perspective, to be able to understand the invoice and what you have in it, you should probably try to reconcile the invoice and try to see also the custom usage report parallel with it to be able to understand what you have in your invoice. But I would say the invoice is confusing also from finops and as well for the finances. And I had a couple of discussions with finances when I had to explain what actually we have in the invoice.
So I think overall it's a complexity of the invoice that confuses people.
[00:02:30] Speaker A: Yeah, I totally agree. I think one of the things when you are starting to cloud, even from testing, doing POCs whenever you are learning is like you are going to probably have a build even though it's small, and then the difficulty of analyzing even that build whenever you have a normal application deployment is Huge. I cannot imagine the complexity of having a mega bill of 100,000 million company billing. Right. How do you work with that?
[00:03:03] Speaker B: Yes, exactly. What I can add on that, from finance perspective, this is confusing as well that you don't have only one invoice usually it depends obviously on the setup for the organization in aws, but you don't get one invoice per month, so. So they used to ask why there is more. Why are we getting not the same amount of invoice every month? Sometimes it's more. And when you order something on aws, like you pay upfront for reserved instances or you buy something from Marketplace, you get another invoice and then there is a new confusion for finances. So this is something I went through and because I have an accounting background, I was able to communicate with the finances and procurement as well in a way that they understood me because I knew what they wanted and what they needed to understand from the documents.
[00:03:52] Speaker A: Yeah, and that's something that we have talked and it has been taught a lot. It's about talking the same language, being able to analyze the problems of the people in their own perspective. It's not the same to talk about to engineering side and to the finance side.
One thing that they wanted to ask you is that you may have a lot of experience checking bills and reconciling them. So what are the top three surprises that normally you see that companies don't expect in the cloud bill?
[00:04:26] Speaker B: I would say one thing is, I mentioned it already is the upfront costs. From financial perspective, you have to divide the upfront cost for the period for which you bought something, which means if you pay 3 year upfront result instances, you have to divide the cost into next three years.
And this is a confusion for both sides. I would say I understood it from the beginning because I have the accounting background. But if you have, you don't have that. You just get an invoice and you think, okay, we have an invoice, this is goes to, this goes to the finances. Another thing which I also already mentioned is that you don't see the usage on the invoices. So you get a bill and you think, okay, this is my S3 cost or EC2 cost, but you have no idea how to apply it to the budgets, if you have any, because that's another topic. But if there are some budgets for the costs for the teams applications, however you divide it, then this is also confusing how to get to those details. And this is when you have to go to the invoice reconciliation or you have to go to the custom usage report, Cost Explorer, whichever tool you want to use, if you have another external tool, you can use that as well. But this is also a confusion and the last thing I would say, and this is actually example from my previous jobs, is when we wanted to order something from Marketplace and it was an external tool that we wanted to buy through Marketplace and we got another invoice and that was a huge surprise. I mentioned that as well, but it was a surprise for the finances. Like why are we getting another invoice? It was budgeted because we knew we are going to buy it, but it was a surprise. There is another document, why do we get it? And next month there is none. Like why is it happening? So this kind of things I think are the biggest surprise as at least from my perspective there's obviously more, but I think these three are the biggest ones.
[00:06:31] Speaker A: Oh, that's like very interesting. And one thing you mentioned, and maybe I can ask you more on that, is the invoice reconciliation. So how is that process works for you without losing your mind? With all these type of different invoices that you have, how do you manage that?
[00:06:51] Speaker B: I cannot promise you will not lose your mind because it is a lot and it depends on the setup of the architecture.
How do you handle your infrastructure if you have multi cloud?
So I would say first you have to gather the data. So if you have multi cloud you have to understand that this will not just be one invoice, it will be more. And you have to reconcile them in a way that that works the best for your company that you work for and I worked for. Now is my third company as a FinOps. So I did it for each company differently. Now I'm working on how to do it. Actually we haven't done it yet, but in my two previous jobs it was for one year we used an external tool.
Then the next year we decided, okay, it helped us a little bit, but it's not like very customized for us so we want to move to another thing. So I also use the NEXO files, which I'm not ashamed of. It is not an automated process, but it helped a lot to figure out the cost to have everything in one place at the beginning and then maybe move to an automated version of it.
So I would say gather the data, know your audience, so know what you have in the company and what is the need for the reconciliation of the invoice. So do we want to understand if we have production, test environment and something else, do we need to divide into applications or do we need to divide into teams up to the company?
So first gather the information and then decide how you want to reconcile it. But you have a lot of tools that you can use. So I would say know what you need to get and then figure out which tools you want to use for that.
[00:08:39] Speaker A: I think that's. Yeah, you know, that's very useful because I also agree that, well, there is a couple of takes on that.
First, you need to know what you are aiming for, to know what you need to do together.
And secondly, once you have your stack of tools or a thing that you want, you stick with it so that you don't have to learn again the thing and create a new one or use a different one.
Is going to be like the learning phase and the change effort worth it to achieve to the red.
[00:09:14] Speaker B: And if I may add on top of that, don't expect that you will get the great invoice reconciliation first month you are in the company. It will take a time to figure this out. So give yourself that time. And if there is an expectation from the executives or managers, then they have to provide you the exact information they want to have, how they want to reconcile. If they don't know that, how they can expect from you to figure this out. So you have to know your audience, you have to know the data and then figure this out.
[00:09:50] Speaker A: Okay, no, that's good advice. And talking about more interesting or more funny things is like, what do you have seen as the most expensive mistake? Doing invoicing, because it's a difficult process and probably is prone to mistake. So what you have seen on that.
[00:10:11] Speaker B: Let me think.
I have actually two examples in my mind, but one is in one of my previous jobs and I was working in Germany. So there was a decision to move to change the currency on the invoice.
And you know, there was a question, but then the decision was made like partially without me taking into account without, you know, asking me about it. And then one month I see that we have an invoice in euro instead of US dollars. And I'm like, why is it happening? What is happening here? And I figured out we pay more because the exchange currency is not very pro customer. It's like it's customized, like upfront. It's done in not the best way for the customer, I would say. And then I asked why did we change it? And there was the thought in the executive, on the executive level that it would be better for us to have an invoice in the same currency as we have the budget and the accounting, so there would be no confusion between it and apparently there was not because I think we paid, it was couple of, couple of percent. I would say 5% maybe, maybe less.
But if you have a 3 million bill or 2 million bill, 3% is not, you know.
So I would say before making any decision, check all details and information that you can have.
And also, as you can imagine, this increased also the premium support on it and everything that we had on the invoice. So we paid a little bit more that month and then the decision was revoked. Like we have to go back to dollars.
[00:11:58] Speaker A: See, I guess that paying 5% more doesn't, you know, it's not the expected results that you would have for the accounting people. Right.
[00:12:08] Speaker B: But this is exactly like making a decision based on not all informations. So you think this is good because the currency will be the same as in accounting, in the accounts and everything. But, but then you don't take into account the other perspective, the other information. So before making any decision it's better to wait sometimes a little bit longer but have all information instead of going into this kind of problems.
[00:12:35] Speaker A: Yeah, yeah, that's a good problem that you need to definitely avoid. Right. And you know, thinking about maybe moving to a separate topic is the.
One of the things that I think aligns better the technical side with the finance side is the visibility of the cost. So I think both areas like to work especially on data, especially finance is more used to analyzing data. And one of the things that I think starts with showing that data is this showback versus chargeback. So whenever you have the cost allocation, let's say. So that's probably one of the most important, important things in finops. Right. So from your perspective on that side, what's the stage when a company should move from a showback that is more initial and nobody's, let's say accountable on that to doing chargeback.
[00:13:41] Speaker B: I would say you have to be.
The finOps position has to be very firm in the company and it has to be known in the company.
And maybe not the FinOps position, maybe FinOps strategy or that we have something that is called FinOps so the teams know that something is changing, something probably has already changed. And if they, if the teams are not happy to take accountability for their cost and to review them, to control them in any way and it cannot be controlled centrally all the time. At the beginning, yes you can try to input and implement some sort of reports or notifications, whatever you would like to implement.
But with the Time, it should go to the teams.
So my perspective is, and I landed in my current job, you have to have the executive support, sponsorship, however you want to call that. If you have that, you can then get to the team leaders or managers of the teams and make them the owners of the cost. And if they push back, then you can switch from showback to chargeback. If you are not taking accountability for your cost, then maybe not so harsh at the beginning. So it doesn't have to be the chargeback, but if they request something new, then you can push back and say, okay, you don't have control over your costs. We are not giving you more money to spend if you don't know what you are spending your money on. We need to actually understand where the money is going. So if you want something new, then we will push back until you decide to take the accountability. Then from that point you can also move to the church back. So actually charging the teams back. And if you are not within your budget, sorry, you don't get more, that's the end. But this is a very harsh position to be at.
It never happened to me happily. But I would say this is the very hard path to go to. I would rather to, you know, go with my soft skills to the teams and try to, you know, spread the awareness of how the visibility of cost is important, the control of the cost.
And yeah, I would rather to go that path than, you know, going from showback to churchback to the teams.
[00:16:10] Speaker A: Okay. And you know, diving more into that because let's say we want to avoid that, you know, hard conversation when we have like a lot of pushback and a lot of things. So how do you, let's say, empower or convince or however you want to call it, the teams, so that they follow that approach that prevents, you know, having a hard conversation in finops.
[00:16:36] Speaker B: I had a couple of those conversations.
Fortunately, I didn't have to go directly to the teams, but we've met with a lot of managers when I was in my two previous companies and we discussed how it should be spread, the cost accountability, how it should be within the teams and applications or however you need to divide it.
And quite often it happens that there was a response, okay, but it's only thousand dollars or it's only something like that was the actual response. And I reacted in a way that I said, okay, then give me thousand dollars out of your wallet if it's not so much from your perspective. And then it hits people. It's like, oh, okay, maybe she's right. Because it's you, you think it's thousand dollars like in comparison with 3 million invoice, it's not that much. But then give me those thousand dollars if you don't care that much.
This is also a little bit harsh approach. But this makes people aware that every dollar counts. It's not like we can waste that money because it's not ours. No, it's the money of the company and we want to spend as less as possible with the best solutions and you know, best roi. And you cannot waste any dollar. And this was an I think open minded kind of meetings that I had with people when I told them, okay, if you, if this is not so much for you, then give those money to me. And then they understood, okay, probably we should take care of that. This is harsh as I said, but sometimes you have to take this kind of steps because you can push from, you know, from executives level. You can push like with notifications, whatever you want. But sometimes the or even one to one meeting with a manager or someone that is pushing back the most can help a lot because one, you get to know that person. So when you know another person you get more, you get to understand more how that person works and what is the goal of the person. You can see that we have the same goal actually at the end.
So yeah, I would say that was my best, best open eyes opening solution for people to make them understand. No, every dollar counts. It's not like you can spend however you want that money. It is not your money, it is not my money, but it is within the company and we want the biggest revenue possible for the company to get maybe bonuses or some other kind of, you know, salary raises.
[00:19:16] Speaker A: Yeah, no, no, no, that's a good approach and I think it aligns with what they' discussing with several people. That is more of a people job than we think sometimes. And you need to handle case by case sometimes. And especially with big companies that each mistake or each development involves a lot of money in place. As you say $1,000. But some mistakes are like $100,000 for a specific instance cluster left up in a weekend or something around those.
That's a very interesting thing.
And also one thing that I want to ask is who or from all the people that are involved in the process. We have the product people, the engineering people.
How do you approach each conversation? Let's say that for example you have an issue or you detect it, you know, in the finance team detected an issue in that specific team. Do you normally go directly to management and Have a conversation there or do you try to then go level down to maybe the engineering team that are more under the manager, how that works on your side.
[00:20:43] Speaker B: There is no one way to work for that would work for each company. That would be my answer here. I was lucky enough that in my first job we went from migrating from on premise to the cloud and then everything was figuring out how it should be.
And I was lucky with the engagement of the teams.
I think I was really lucky with that. Obviously I have to spread awareness, I have to learn finops in the meantime as well, because it was something new.
But I would say you have to, you have to have the relationships with people. So if there is an issue, you should, from my perspective, you should never go to the executives first.
So never escalate first. I would talk to people first and try to figure out where the issue lies, why, why there is a problem, why there is a cost anomaly or whatever has happened.
Because it depends what kind of issue you have. If this is cost anomaly, then you can figure it out on your own as well. Or you can go to the engineers or any other teams. If this is an invoice problem, you have to go maybe to the finances or maybe to some admins that should change something on the cloud, on the, on the AWS console.
And if it's a problem with the budget, then you have to go to the budget owner. So depends what kind of issue you have. I would first talk to the people and if there is a pushback with, let's say it's a cost anomaly and we need to figure out what it is and why it happened.
And I had it in my previous job that we created a report in which I was able to find any cost anomaly within a week, sometimes even less. And you know, I had to reach out to different team members, different teams actually. And just first I was trying to figure it out on my own, then I had to, if I was not able, I was going to the teams. And then the explanation of the cost anomaly was, you know, different for every case. I would say sometimes it was, oh, I forgot, sometimes it was, oh, no, no, we need it. This is something new, we need it. Because there was, I don't know, huge traffic during the weekend and we needed to pick or add some machines during the weekend or there was an incident and we had to, you know, take care of that.
But you know, the main reason I would say is, oh, I forgot for any cost anomaly. And then I went directly to the teams and I put the explanation in the report. And then nobody from the executives were going to the teams. They were coming to me and I was like in between the teams and the executives. And I was taking the response also from the executives and then filtering a little bit and going to the team because I feel like FinOps is a filter or a communicator between those Personas, let's call them the finopsy wards.
But we have to be somewhere in the middle and talk to them in a way that is understandable for the both, both sides.
So yeah, I would say don't escalate right away. Go talk to the people.
[00:23:53] Speaker A: Okay. No, that's, that's fairly, fairly good advice from, from that side. And you also mentioned, you talked about in the last example about the reports. So how like do you, let's say frame or how do you focus on creating reports?
What does a good report have for you? Regarding like a FinOps report, I would.
[00:24:17] Speaker B: Say it consists of the information or details that are needed for the Persona that ordered the report.
But quite often those Personas don't know what they want because they have never had a report before about cloud costs. So sometimes you have to suggest, sometimes you have to give them options to be able to, for them to figure out what they want.
But I would say the most important parts are like, you have to know where you are with your cost. So total cost versus budget. Maybe you should be able to see a forecast of your cost. So if you plan a new project, we should be able to discuss and forecast the cost of the project.
Yeah, so I would say you have to have the details from the customer that is ordering the report. So actually I'm working on a document that describes the customized reports and I was figuring out how we can set it up in a way that is most useful for the customer and not very complicated for the finops that is preparing the report or helping to set up the report.
So I would say you have to have the requirements from the customer. If they don't know what they want, you have to provide them with them in a way that is the easiest way.
And then obviously at the end you have to have the report in a version. So in a documented version or online version that is most readable and understandable for the customer. I would say for finances it would be probably Excel or another tool that you use. You can use some external tools. For engineers it might be something different because they probably would rather to see the usage than the cost or usage and the cost in the report.
So maybe Power BI or something Else so depends. And for executives, I would say PDF might be the best solution. Just easy, easy, not too many details, readable report, maybe one page just to show them the overview of, you know, of whatever they expected you to prepare. Yeah, okay.
[00:26:29] Speaker A: No, that's, I think a very, very useful, very useful thing. And you know, we have said what is good for a report to Hub, but what is what it shouldn't be or what, what are the mistakes that you see normally in advice or in creating phenoms reports.
[00:26:52] Speaker B: I would say too many details is also a mistake. But in my previous job I did one mistake that was not enough details because I prepared the report. I had a quarterly meeting with the managers and then they asked some questions about more detailed questions and I was like, okay, I have to find that detail somewhere else because I had another file for that.
And then I realized, okay, I should have everything in my hand somewhere. You don't have to show it right away, but you should have it.
If it is a Microsoft PowerPoint presentation, you can put there more and then just scroll through it or you can have an Excel file and then you can have sheets for every, I don't know, question that can come pop up in regards of that case. But if it's a monthly or quarterly report, I would say too many details would be over, you know, overwhelming for the, for the Personas that are reading the report.
So when you get the requirements, don't put there more. If you get the requirements for total cost, cost versus budget, the usage of, I don't know, some services maybe for some teams, put just that, don't be, don't try to, you know, show off and you know, give more because it's not helpful for the teams. Maybe it's good for you to show that you know your stuff, but you should be, you know, a help for the team. So I would say too many details, it's also not good. So try to find the, you know, something in the middle.
[00:28:27] Speaker A: Yeah, I totally agree on that. You know, we, we have discussed it also in, in, in several topics. But one thing is that you, you know, the data on itself or the report is one thing.
The valuable thing is the insights like the actions that you can take from that info. And for that you may not need a lot of information. You may need a lot of information to get that insight, but not to share it.
To construct that insight. You may need a lot of inputs and then you need to analyze that, which is probably the job of the finops, and then provide that report so that the Executive doesn't need all the reports, all the details from the build, they just need like, okay, if they.
[00:29:10] Speaker B: Would like that, they can go to AWS console and download the custom usage report which has like, I don't know, a couple of thousand of lines. They wouldn't be able to go through it. So your role is to, you know, compress the data and filter everything that is important for the customer, that is ordering the report and then provide them with it.
Okay.
[00:29:32] Speaker A: No, no, no, that's, that's wonderful. I did that again. I think that's, that's wonderful advice and you know, I wanted to ask more to more from your advice and one of the questions that I've been thinking lately is Finops is purely almost related to the cloud and one of the most important roles in the cloud are the cloud providers. So the aws, the Azures, all of that. So in your perspective, what could we as a practitioner could be asking our cloud provider if we have one or all of them that we are not currently asking to them? Like what should be our questions to our TAMs, to the people that help us on the cloud provider side?
[00:30:25] Speaker B: I'm not sure if I would be original on that, but I would say how can we get more discounts from the cost? So this also an example from my previous job.
You know, we were planning to migrate a project from, it was not from on premise, we were migrating from another setup and you know, we reach out to AWS and ask, look, we are, we had a technical account manager from AWS so it was easier to reach out to that person and you know, discuss, okay, what can you offer us? Because we want to, you know, buy more from you. So what kind of discounts can we get from you on that? And they provided us with a discount and it was 25% on every migrated resource, which is a lot.
And you know, at the end we were able to save those 25% on the cost. So I would say don't be afraid to ask for a discount. Any further discounts you can get, you can compare always services from different cloud providers and say, okay, but I can get it cheaper there, so why I should stay with you if I can go there, like with buying anything jeans or I don't know, anything in the shop if you can get a discount.
[00:31:41] Speaker A: Yeah, no, no, that's totally true. Like if you're going to get the same for less, go ask and get a discount. And I think it's something that, you know, especially for big enterprise, that it needs to be right away that we focus on, you know, the current tables and all of that. But there is more personalization, especially as much as you grow the spend on that, if you reduce it, then maybe that's not that happy for them. But if you, if you make more, then they will be more prone to, to provide you a discount. Right?
[00:32:14] Speaker B: Yeah. I mean, the case. Don't be afraid to ask because I used to have that approach that, oh, maybe, you know, we should not ask because why.
But then, you know, with having that technical account manager that was very, very helpful person for us and that person supported us in a lot of ways, I was like, okay, maybe we can have a chat and discuss what kind of discounts you could get from.
It was AWS from aws. And then I realized, okay, asking is not making you any less a finops or any less, you know, a user of the cloud. You are still using it, you are still buying it. So it is just a decision. And you, you can, the decision is based on the information you have. If I have higher discount here, I will go here.
Easy decision.
[00:33:04] Speaker A: Yeah, yeah, yeah. It's basically any basic sales process could be involving discount. So definitely.
[00:33:12] Speaker B: Yeah.
[00:33:13] Speaker A: And you know, talking about, we, we have discussed the invoicing process and from what you talked and I think is one of the most difficult processes and one of the most difficult things to do. So if someone is listening right now, what is the one advice that you would give them to improve their invoicing process?
[00:33:36] Speaker B: I would say understand the finances expectations, because this is not. Usually it is not just one team. Obviously it depends on the size of the company. But if it's not just the one team, you have payables, you have procurement, have finances that are taking care of budgets, figure out their requirements and what they would expect or what would they like to understand from the invoice? Because invoice is just a document. It's the document that is set up in a way that is comfortable for aws, not the customer.
So you have to know what is needed for those teams that are working with the invoice and taking care of the payments and then try to set it up in a way that works for them. Automate the invoice reconciliation, get the custom usage report or try to figure out any other tool that is needed to make it workable for the teams. But first meet with the teams and understand their requirements. That would be my suggestion. Because without that you think you will help them with something and then you will end up with not making them happy.
[00:34:50] Speaker A: Yeah, you need to Know what you, as you mentioned before, Right, And I think it's a fairly good advice is, you know, you need to know what they need you for and what's the goal of your collaboration so that you can totally help them. And you know what? Because we've been like talking for almost 30 minutes now and we don't know almost anything about you. So can you tell us, Magda, what's, you know, how you arrive here in the finance world? What's been your story, you know, so people know how do you. Why you know that much about invoicing and, you know, fighting with other teams?
[00:35:24] Speaker B: My background is actually finances and accounting and my first job was in accounting. I worked for, for Lufthansa, a huge, huge company, I would say.
And after a couple of years, I was lucky enough to get an offer as a project manager, actually, at the beginning, and I decided to go for it.
And I would say because of my. A lot of my soft skills that I have, and obviously I had to work on them and I had to learn project management.
And then the migration happened in the company to which I, which I joined, and the cost spike was like, you know, hit the sky. And there was the question, like, okay, you have a financial background, maybe you can take care of that. That was actually the beginning of my FinOps journey, which is quite funny from today's perspective.
But, you know, I had to learn a lot about the finops and how to handle the cloud cost.
But because of my background, I was able to understand a lot from the invoicing and how to read the cost. I, maybe I was not able to read the services and everything that was happening and then the usage at the beginning, but that part was easy for me. So. So I would say if anybody is thinking about starting finops, don't be afraid of not knowing everything, because you will never know everything. You have to learn all the time. So don't be afraid to start.
And yeah, I'm really happy with the job that I have today and a lot of things that I learn throughout the process, but it's still a process that is ongoing. It's like with life, it's not like you have. You are in a point in your life and okay, I'm happy now. No, you should always try to, you know, search for new things, get new interests and. Okay, it sounds like you should always change. That's not what I meant. I meant you. You should try to not be too comfortable in, in a job you are currently in, try to learn something new.
Every possibility that There is no.
[00:37:30] Speaker A: I cannot agree more on that. I love to learn and FinOps is one of the things that for me also was one of that.
That thing is one of the ones that attract me to it.
Of course, there is one of the collision of two of my passions, which is finance and the cloud.
And the second one is that it was so new and I saw it like, okay, this is super ongoing. This is going to be there for a while up until it establishes and grow. And there is a lot of room to grow on that because there is a lot of things to be defined to scale to a lot of work pending to do. So it's definitely going to be an ongoing practice.
[00:38:15] Speaker B: Right, exactly. Yeah, I agree.
[00:38:18] Speaker A: And you know, and also one thing is that special thing, like you can be from the accounting side, it's not the same that you come from the procurement side. That is another like one of the most, I see one as one of the most powerful people because they deal with the contracts and contracts is probably one of the most, let's say dangerous or, you know, powerful things in finops. And also you can come from technical side, which is where I come from.
I see the whole different perspective and I find like I have a lot of enriched conversation because of that. Right. That you can meet a lot of people from the different sides, which is when you are coming from the technical side, you are meeting normally technical people, your PM and your manager, and that's it. And we live in a bubble.
And on Fino you need to deal with a lot of people, right?
[00:39:14] Speaker B: Yes, that's so true. And yes, building those relationships is also very important to get to know people because then you can cooperate easier and make the goals happen. Like if you have a goal to save a lot of money or to automate a lot of processes with the teams that you already have in the company that you joined, you can achieve it.
This is the only thing that you have to do at the beginning, build the relationships, figure that out and then I think you can.
And no matter what the background, because I used to have that complex of non technical background on myself, but I can show that here that it is not the most important thing. Maybe it would help, but I would say because I have another background that helps me a lot, so I try to concentrate on that. And obviously I learned with the process a lot of technical things, maybe I'm not able to code, but I can understand a lot of the things that are happening in the cloud and I can translate it to the costs.
And I think this is very useful. So try to avoid any complexes that you can have in your brain and go for the best skills that you have and cooperate, make the relationships and that will work. I think.
[00:40:29] Speaker A: Yeah, that's wonderful advice and also I think it, it aligns on that phenops. It's probably going to be more, way more specialized like in the future I believe there will be like room for every kind of specialty, specialty role. Now it's more of a, you know, hack of all trades as you would say. Like everyone is doing almost everything and dealing with everyone and you know, I believe that it's going to be way more specialized. But as mentioned, your skills for example on the accounting help you become a finops and coming from the technical side it's super different. You need to work on the code, on defining policies, on creating that and it works super different and it's great to see that it can be a lot of different people working together.
I think with that wonderful advice it's a good way to finish today.
So thanks Magda for being here with us. I think it was like a lot of insights in a short time. So thanks for being here today.
[00:41:38] Speaker B: Thank you. Thank you very much for having me. It was my first podcast so I was really stressed to join but it was a really nice conversation and yeah, looking forward to next one maybe.
[00:41:49] Speaker A: Yeah, for sure.
Great to have you here today and thanks for taking the time. You made it. I think it was a very good conversation for your first podcast. So people can comment down below if they like them and see you in the next episode.
[00:42:03] Speaker B: Bye bye bye.
[00:42:04] Speaker A: If you are liking the story of Magda who come from accounting to phenoms, we have another very interesting story from Alexa that came from teaching English to phenoms. So check the following video so you can check her story and see how someone can be came from a total different background to phenops.
