Episode Transcript
[00:00:00] Speaker A: Welcome everyone to a new episode of the FinOps weekly podcast. Today we are going to discuss a bit about engineering and taking action and how you can get from the visibility and the insights towards, you know, real remediation, real action in your company. And for talking about that we have Diana Descano. How are you Diana?
[00:00:21] Speaker B: I'm good, Victor. How are you today?
[00:00:22] Speaker A: Doing great, doing great and well. We also have Damian, my co host. How are you Damien?
[00:00:27] Speaker C: I'm doing great.
Thank you for being here, Diana.
[00:00:31] Speaker B: Absolutely, it's my pleasure.
[00:00:32] Speaker A: Yeah. So today, as some of the audience may know, I come from an engineering background and I know a bit more about how engineers work and how they leverage things like security finops in their day to day basis. And I want to talk today with Diana about that, like how you can get action from engineering because I have my perspective but I know the finops people may have a different one. So kicking things off, if you want to learn about how your engineers or if you are an engineer and you know how to get actions from FinOps and you want to save some money to your company, you should stay today.
So to start, Diana, you know we have a lot of, we started, I think finops started a lot about visibility and you know, information.
We start with the inform phase, let's say and then we need to, you know, optimize and operate. Right. So how are you seeing that evolution about the action of or the remediation phase in the finops? Like how do you are seeing that taking action is happening in FinOps and how you have seen that evolving through your experience in FinOps?
[00:01:47] Speaker B: Sure.
So it first started where we just needed to get visibility. The native hyperscaler tools weren't giving customers enough depth into what they were looking at.
So I've seen a lot of tools coming into the market or some that have been around for years like the ProsperOps, they do optimization around RIS and savings plans and they work with all of the hyperscalers which really helps.
You know people can be a little hesitant about buying one year or three years of RIS or savings plans but ProsperOps takes the risk away from customers and really enables them to move forward of okay, this isn't so scary.
There are some customers that have their environments really well optimized in that sense. So then ProsperOps, it's not as beneficial, but they're still able to move forward.
Some really cool remediation tools that I saw during FinOps X in San Diego recently was around this new tool that I really loved which was called attribute or is called attribute and they focus on the unit economics side of things and they take that AI component on the back end and have flow logs so that customers know what customers, the end users know what each service is spending, where it's going, things like that. Which also then helps engineers with their visibility when they're building tools of okay, we don't need to use a Z1D6 extra large. We can use a Z1D2 extra large for this customer's environment.
So that really helps with just getting that in front of engineers and customers for the remediation. I've seen other tools that have AI integrated into them so anomaly detection, also tagging enforcements, things like that, tools like umbrella tools like cloud chipper, those, those tools give you the visibility and the remediation.
So okay, I work with engineers, we determine that this set of tags is okay to terminate or set on a lifecycle policy and within those tools we then automate it to go forth and prosper Basically.
Sometimes doing things within the hyperscalers has limitations because you have to go into each individual region you go and check one by one by one versus things like these tools give you that consolidated view to be able to remediate on them.
Adaptive also does a great remediation where they have the shift left and the shift right capabilities in them.
So you're not just limited to okay well I can only right size but you know, maybe I need to auto scale. Maybe we scale up, scale down.
OCI has a great, great feature natively for their dynamic scaling for volumes and those provisioned iops, those can get really out of hand. But enabling features like that has really helped engineering move forward and get past the oh well, we don't know if we can do this and give them the power to remediate across multiple accounts, multiple regions, all at once. It also cuts down on time that they're spending looking for this data and trying to find it.
[00:06:10] Speaker A: Yeah, indeed.
You have to consider the human effort that it takes to actually do the remediation itself. And I think you brought an interesting point for because we have seen this debate about building versus buying tools and there is a lot of tools in the market and there is a lot of decisions to make.
From your experience, what are the factors or what are the four or five things that a company should evaluate when deciding whether to buy or whether to build a tool? What are the things that do you have in mind? For example, if you were, I don't know, an end user thinking okay, should I buy or should I build something that is in house? What are your thoughts on that?
[00:06:57] Speaker B: Of course, the easiest one to look at is bandwidth. Do I have a team of engineers that are able to create these lambda functions against whatever APIs are needed and they're having to go in and maybe they don't know those. There's hundreds of thousands of services out on the hyperscalers. It's impossible to be an expert on every single one of them.
So engineering may not have the expertise.
So again, we look at that with the bandwidth, what are we limited to?
What can we do internally? Of okay, well, we can only do just a little snippet of this.
It helps, but it still doesn't really take a good chunk of it.
At my last company, that was our case where we had limitations on bandwidth. And while engineering was able to implement some of the stop start hours, we were able to get more breadth and depth on using tooling to really encompass everything with those start stop hours because it showed us a little bit more than what we were seeing within the hyperscalers.
That's the biggest one. And then of course, my favorite is customer service, of how engaged are these teams that we're talking to with various tooling?
Are they engaged to truly help us to move forward with growing our cloud environments, or are they more focused on the bottom line and money that they can get from us?
So that's where I really think the, the changes come into play.
[00:08:58] Speaker A: That you raise a good point and I think it's a very, a fair one. And it's something that you, you know, you have to know what your partners are in the road and you need to select the ones that are helping you. And of course, customer service is probably one of the things that show up the quality of the partners that you have and the effort that you can put in place. So definitely something that people listen to us and people that are evaluating tools should care about that it's not only technology, but it's only being able to support them to be able to help the user. Right.
It's. It's mandatory.
[00:09:38] Speaker B: Absolutely.
[00:09:39] Speaker A: And you know, continuing on on that side, I wanted to, to ask a bit about.
Okay, so we have this either tool that is built upon in house or it's, or we get a tool and we get this alert and how do. But moving a step back, right? So when we are designing the solutions or we are creating the POCs, the architectures, all of that, I know for a fact that the architects like, okay, the resilience of the application or we Create, I don't know, a microservice architecture that is super dynamic, cutting edge thing and then we build everything on kubernetes, whatever.
But then cost is not something that is super taken into account. Right?
Is something that is there. Of course it's not something that. Because you are thinking, okay, this is a poc, this is not going to cost us a lot. But how could you say that an organization can make cost a part of the PoC phase or the design phase? And what are your tips towards making that actually happen in an organization?
[00:10:49] Speaker B: Absolutely. So some processes that I have seen really work in an organization is bringing those, if you have a FinOps team, bringing those people in at the very beginning stages, when you're, you're talking about designing a new project or if it's just the finance team, that's totally fine as well. But bringing those people in on the early, early concepts, while they may not fully understand everything that's going on, they may not have that engineering background, they do understand, okay, we're going to, you know, take it back into terms of clothing. We want to purchase an extra large in this premium brand. But this other brand, this, this knockoff brand is the same quality and everything else, but it's just not that premium name.
And so it's things like that that really help in the beginning stages when you're setting this up. There's an organization that I worked at years ago and I loved how they incorporated this. They had an ARC team which is an architecture review board.
And within this it included multiple engineers, it included developers, it included leaders, PM's engine, and it included finance people.
And everyone worked together. And having that communication across multiple arenas within your organization, it really drives that structure of we are working together for the end goal, which in turn is the customer.
And we wanna make sure that we're fully supporting the customer, but we're also doing this within reason.
I know that building trust with engineers when you're coming from a finance perspective is very difficult.
I started in engineering and migrated over more into kind of like the finance spin ops area.
So I remember doing those deployments and not really thinking about it at first and then, oh no, we are over budget. Let's go ahead and take a look at this. What can we do to fix it? Let's. Okay, let's drop the instance size. We do not need this large instance size for testing.
It's fine. We can still replicate a customer's environment with whatever we have.
So it's really starting those conversations at the beginning and Showing that engineers put it in real world terms, not finance terms. When I'm talking to engineering, I am not using finance terms, I'm not using accruals, I'm not using cash basis. Those words do not come out of my mouth.
And when I'm talking to finance, I'm not talking about ebs, I'm not talking about specific instance types. I'm speaking a language that they understand.
So a lot of times I bring it into real world situations of you're heading out on vacation. What do you typically do when you head out on vacation? You make sure that your lights are turned off, your power breaker depending on how long the you're going on vacation, power breakers turned off, your water's turned off so that you don't accidentally get a spill that happens. These are kind of conversations that I have with both finance and engineering which makes it.
I'm building that trust within them to show hey guys, we can do this.
I care about your performance, I care about your scalability.
But at the same time I also care about can we help the team grow.
And everyone loves that idea because everyone is always underwater with we don't have enough resources, we don't have enough people.
Well, if we can cut back cost, maybe we can put that cost that we're wasting back into people and resources and get another person, get you know, a couple more people.
Just all, it all varies.
[00:15:02] Speaker C: That'S for sure.
[00:15:04] Speaker A: I think they had.
[00:15:06] Speaker C: Sorry, no, I said that they always, you know, no, no worries, go ahead. I said that always, you know, showing what else you can do with the money that you save. It's always a good, good strategy. And also we have started seeing as you mentioned, more of like, kind of like some kind of shift into the engineers. They do more kind of like the female. This is what I like when you first started the conversation you talk about this is I want to show them, right all this stuff that they can save and what is the current cost of what they are doing.
And I think that also one of the things that we are seeing lately is kind of some automations that will do even the work for engineer to try and solve those things.
Do you think also that it's a good direction of tools because we have so many tools then.
So I think it's a good. What would be the strategy also to choose the tool?
[00:16:12] Speaker B: But yes, please getting feedback from engineering. When I'm pocing a tool, I know what I like and I know what leaders are typically asking for and wanting.
However, if the engineers are going to be implementing it. I want the engineers to get into this tool and get their hands dirty with it. I want them to try and break something. I want them to see what it takes to set up things.
There's a tool that with a former company we were pocing called Perfect Scale, this does automations with Kubernetes engineers. I immediately, I'm like, hey, this is all you. I'm going to need your feedback on this. They went into it and they loved how it looked, they liked how easy it was to set up and okay, great, now what do I get out of it? So then I go into it once the engineers go in and then I start testing and poking around and seeing what I can break. And you know, I'm very much a just press buttons until something happens versus always reading instructions.
But that's a great way to also learn tools quicker in my opinion.
And engineers typically function this way as well as they'll just go in and deploy something before they go any further.
[00:17:43] Speaker C: Yeah, that's it.
[00:17:44] Speaker A: Yeah, yeah, indeed. And you know, with tools like, like that ones is, you know, very specific and you start playing and you start seeing like, okay, you may touch some buttons. They go to the documentations here and okay, what the hell I'm going, I'm doing. Then go back and say okay, then I will check this and that and then see if the, the monitoring makes sense or not. Especially with Kubernetes tool like Perfect Scale. That is very familiar I think to people that have used anything like Grafana or, or things like that. That is very straightforward and to continue about on the point that Damien Rice about automation.
So we are seeing, we are especially in the AI world and all this automation world and there is a lot of effort into automating things.
What do you think are the topics or in the whole finops thing, what do you think are the areas that could be more automated and which ones do you think should be? The less ones or the less prioritized in terms of automation because they have, I don't know, some difficulties that are especially made not for automation. What are your, let's say, your priors to automating? When you do start on, you go to a company, you arrive into a company and you say, okay, let's automate stuff. Where do you start and what do you ignore for? Let's say yeah, this is not automated, no worries.
[00:19:10] Speaker B: So I pretty much try to automate as much as possible just so I'm not spending hours trying to pull reports and going into the consoles and figuring things out from there.
But I typically start with the low hanging fruit of automation. So what I consider the low hanging fruit is those EBS volumes that have been sitting there for years untouched. You know, you have that last access date back in 2020 and.
Okay, why, why is this here? Oh, I totally, I didn't even realize it was there. Okay, great. So we, we set in automations that will kick out certain resources like that.
With that we'll also set just a time limit of if something, if there's a snapshot, it's been there 30 days. Okay, let's put it into deep archive. We don't need it readily there if we're only spinning it up every once in a while for testing purposes.
Elastic IPs, that's the easiest one that a lot of people forget about.
But as soon as those are disassociated from anything, just kill them.
They're collecting dust and costing money and you don't need them. You're not going to reattach them because then you're going to have to go and reformat all your code, which will take more hours than to just grab a new one from scratch.
So those are where I typically start, is the snapshots, the, the volumes, the elastic IPs and then we start going into. All right, once we have a good idea of this is typically running from this time till this time and it's not really in use around this time, we'll start setting then automation off hours.
So we'll shut down services after people leave for the day.
And we do it in areas that are specific to time zones. So for teams that are in India, it is set for their time zones for their on and off hours, for instances or any types of environments.
For those that are in the Netherlands, same thing.
We try to make it so that engineers know. Okay, great. It towards, towards my final days at my former company, I had engineers regularly reaching out to me and saying, hey Diana, can you go ahead and add this to the automation for these hours? Sure, no problem. It took two seconds. I went into our tool, went ahead and implemented it and went from there.
[00:22:02] Speaker A: It makes sense. Yeah, I see that.
I can explain it for myself that there is a lot of trickiness on the schedule hours.
We are seeing that the switch towards ephemeral environments specifically of when you can make it because the schedule on the time zone especially so the time zones are something that is not mentioned enough when you are dealing with the schedule hours because you can make a mess. I have done a couple of messes due to the time zone issues and it's something that you need to be really careful about.
I guess that and if you have like multi time zone teams working on the same thing, you'll probably switch to ephemeral environments if that's something that is worth for you. If not, probably you should think about serverless as well. Like if your application is fit for serverless then I would switch to that because that will help you a lot with the schedule hours not making a mess towards that.
[00:23:04] Speaker B: Absolutely. And also using if teams are spread using UTC just to make sure there's uniformity.
[00:23:14] Speaker A: All right. For sure.
[00:23:15] Speaker B: Versus setting something for an African time zone versus European time zone versus US time zone, North American time zone that gets too cumbersome of. Let's just make sure everything's uniform and we're all working together within utc.
[00:23:38] Speaker A: Yeah.
If any developer is listening and has deal with time zones and storing time zone and converting time zones and being able that when you store then when you retrieve the time zone is maintained. That's something that is probably one of the most difficult things to handle.
Yeah, UTC saves us all for.
[00:23:59] Speaker B: Oh, I believe it. I believe it.
[00:24:03] Speaker C: Well, if you by the way, if you're working on the global team and following the sun on your dev on your dev environment then you can do commitment and that's it.
No automations there.
[00:24:17] Speaker A: Yeah, I have to say that there's not much options that you can do unless you have a super big team and you can do the ephemeral environment normally. But like having the commit a good commitment time and spot time, spot instances is what's going to save you the best and it's the pro unless you are serverless as mentioned is the less effort to handle because yeah, ephemeral management are great but you need a lot of pipelines and a lot of DNS stuff and a lot of, you know, management to be working on that. I mean if you have good DevOps on your side, you may want to try it.
But unless your project is super scalable and super big, such as, I don't know, a Netflix kind of thingy or something around those lines, you should have been working on Run and as Damian said, a good commitment strategy plus some spot instances is what's going to save you a lot of money.
Indeed. And you know, moving forward from the dev environments and trying to, you know, to have some light on because I come from from development side so I know that there is a lot of startups, a lot of small companies that are more into the tech side. So you know, developing the stuff and being quick and you know, say fast things for, for them. For these small companies that are more into the tech side and more on the quick shipment stuff but they have scaled to something that is mainly may be costly.
What are your advices for them in terms of starting with the finops practices? So apart from you know, what you have said, what are your advice to them? Or in your case like if you land to a startup that is playing greenfield, what would you do?
[00:26:11] Speaker B: Sure.
I mean start with the easiest thing for those smaller businesses that are having to grow with their customers and start huge just to make sure there's not performance issues or I'm, you know, if I'm trying to log in and then all of a sudden I'm not able to because I've hit, I've hit max capacity for whatever reason.
Start with simple things for cutting costs. Start with the savings plan. Start with the reservations.
Those if done properly can save hundreds of thousands of dollars depending on how big environments are.
Start with intelligent tiering. Make sure if you're using an AWS environment, use intelligent tiering and set it up for every 30, 60, 90 days.
If something's not accessed within 30 days, most likely you're not going to need it instantly. I have a box of files. It is an 18 gallon tote.
I know that if I need something it's in there. I know it's going to take me a while to find it. I don't need it within seconds. I'm okay with okay, it's going to take me a half an hour, 45 minutes to, to find this paper, whatever I need.
So and that's, that's how companies should look at it. It's not everything needs to be readily accessible right up at the very beginning. It's okay to have a little dialog box that pops in if customers are pulling data that is years old of you'll be emailed when this report is complete and that's okay. It's let, it's setting those expectations and letting customers know like this is not about instant gratification. We are not shopping on Amazon.com with getting something same day or next day. It's okay to wait a little bit and then that's also setting boundaries for your customers that sometimes people forget.
[00:28:25] Speaker C: Yeah.
[00:28:29] Speaker A: That'S totally true.
[00:28:32] Speaker B: I mean I, I, to be fair I definitely do like my Amazon same day shipping but.
[00:28:39] Speaker A: I think everyone as, as Bezos said they, they said that yeah everyone wants ship fast and you know, same day shipping and lower price Products. That's always going to happen and I think everyone will like that anytime, any point in history.
[00:28:57] Speaker B: This, this is true. But at the same time, if I can get it cheaper and I can save 10 bucks, $5 by waiting a day or two, I am happy to do that. And that's what people need to think about. Sometimes it's okay to have delayed data. If it's large data sets, that's fine. I can work on it the next day, 24, 48 hours. Fine. Most of the time it does not take that long to pull data from a deep archive. But if it does, depending on the data set, then set those expectations ahead of time.
[00:29:38] Speaker C: That's a good point. I like it. We should add something like do I really need this?
I think once we were talking with Guillermo about it.
What is the kind of like with Guillermo Ruiz from aws. What is the type of service that you want to give your customers?
What is the line that you draw when you, you know, how fast do you give this? And I guess that is a good question to ask.
Does it make sense, right, to have this service, to have it so fast or can I wait? Also I would add that, you know, separating, you know, if you have a good separation between them and prod.
Even on the, on the account level or subscription or whatever or project, whatever provider you are using on the dev accounts, you can try more like you were saying, try more automations.
Go try more stuff that it can encourage you to save more shut down environments and stuff like that. Usually people, you know, tend to be a little bit scared of even. Right. Sizing. Oh no, this is a product. I'm not going to do it. Fine. In the product on the dev. Why not try it right?
[00:30:59] Speaker B: Absolutely.
[00:31:01] Speaker C: And tell us a little bit. You have any kind of like.
Yeah, you have like one of the success stories about all of this that we were talking something that it's. Do you want to, you know, share with us or something like that about, you know, went really, really well with the engineering team.
[00:31:26] Speaker B: Sure.
So the last company I was with, huge success story in our Google environment that ended up saving about €50,000amonth just by creating that trust with engineering. Yeah, it was a large amount and working with them and just helping them understand. Hey guys, I not trying to step on any toes here. Help me understand your environment.
What's running in this environment and what is the environment used for? Oh, it's just used for support tickets. Okay, well can we clean up some stuff that we don't need?
Obviously if something needs to be running for quick demos or support, obviously that's left running.
But we ended up clearing up that environment by working with engineering.
And like I said, €50,000amonth is not cheap.
So that was a huge, huge win. And that also helped build trust of. Okay, Diana's not just playing bad cop here. She's actually trying to understand our environments, what's going on in these environments and help us make these environments quicker, better, whatever the case may be. This in turn help speed up the environment as well as give them more budget back to work on other projects because they were hitting barriers that they weren't able to go past because they were at budget.
So it helped them in multitude of things and that was the biggest win.
Most recently I was really happy with the outcome of that.
[00:33:27] Speaker A: That's, that's quite some money, 50k per month. It's quite some salaries there and you can as as mentioned and as you have said previously, some money that you can reinvest in the product that you can make for other, you know, tools, people, roles, etc. Etc. So you can grow the company with the same resources. That's what we are talking always about, like having this either the same value for less price or more value for, for the same price. Right. And you, you, you mentioned quite a bit, quite well like you know, 50k being able to integrate and being able to take that role, like yeah, why are not engineering take action is like maybe you need to a different approach. Maybe you need to show them like what are you doing and that you are not the bad cop that you just hear. You want to help them and to make their life easier while helping the company by doing actually your work.
[00:34:22] Speaker C: Right.
[00:34:22] Speaker A: Being able to save some money or being able to use the cloud more, more efficiently, which is the main goal of finops.
[00:34:29] Speaker B: Absolutely. We want to be efficient in everything.
We all have bank accounts and when we see large purchases come out, it's oh no, okay, now I have to cut down on something else.
So why not take that mindset and put it into our jobs and what we're deploying.
Because it helps grow so many things within a company. It helps with aligning teams and creating that communication, creating that trust as well as building products, building brands, building teams.
I know many, many FinOps engineers out there that are a team of one and they would love to get additional support, but of course there's lack of budget for this. So therefore they need to work with engineering and all to cut down resources so they can become more than a team of one.
[00:35:29] Speaker A: Yeah, I think Damian can also talk about that as well. About how being teams of one or two can affect the famous.
[00:35:42] Speaker C: We can talk about it for hours.
It's a lot of challenge and it's very hard for me, you know, this topic of, you know, trying to, you know, have engineering, you know, do some of or work together, it's a topic that I don't think that will ever, you know, end and you can never stop talking about it because I think I always say that what, you know, when you're looking for, for qualities in a, in a, in a phenotype role, what are you looking. And I always say you need to be a person. You need to be because you need to work with engineering, you know, with all these teams and eventually that's, that's what helps you, not the others. Of course, if you're technical and stuff like, course it's as you. And of course, first of all, if you know those management skills, you know, soft skills help, you know, get people, buying people and buying stuff into either new project, into all the overall finops and to other people do some of the work that you needed to do, you know, in order for the beneficial for the company.
So, so yes, definitely worth talking about it again.
[00:37:02] Speaker B: That is a topic I'm actually really, really passionate about is leadership versus management and the differences of the two.
You're not just there to delegate and tell others what to do, you're there to lead them. And if a process isn't working, then okay, let's work together to figure out a process that will work to then build each other.
I recently participated or I've been participating in the FinOps mentorship program.
And it's not just one sided. Even though I'm a mentor and I have a mentee, it's not one sided. I'm increasing and growing my skills set while working with this person and they're also increasing and growing their skill set. And it's not just technical, it's soft skills like you were talking about that are really needed when you're working with multiple types of people. It's, it's like I take it back to my dog training.
I'm working with multiple types of dog. Dogs at any one point I got to know how to speak their language and work with okay, this dog is food motivated. This dog just wants to be cuddled and this dog will just do absolutely anything to make you happy.
So it's learning the different ways of working with people that I really feel are really undervalued in a Lot of positions that should be put at the forefront of when you're looking for those qualifications and requirements.
[00:38:52] Speaker A: Yeah, I think that after all it's a people role and you need to understand and I think probably coming from the technical side we rely less on the technique of the collaboration and defining things clearly and being able to articulate clearly and being able to define everything in a good way and less about the technical side that especially in the engineering side is main of the focus and less about the how do you structure things, how do you find things? Which is probably when you have the most impact is on the definition phase, then on the implementation phase.
The errors will take much longer to be. To be fixed. So yeah, you should be able to. To learn a lot of soft skills and be able to learn as someone that has done mentorships both on the mentee side, on the mentor side.
As for especially on finance. But in any, if you have any program in your company or you can join any of the mentorship programs that are out there that are free and public, I would recommend also to do that because if you think you know then you'll probably get with people and you don't know. You seem that you know shit about what, how to fix their problems even though they are your expertise. And if you're a mentee you can learn a lot about how things. How other people may be more experienced that you have done things even though they are different.
So I would definitely recommend people joining like ADP mentorship or mentor crews or any of these org. So really want to end the podcast with that message as well. So Diana, pleasure to have you here today. I think there is a lot of people that will get value out of this, especially small companies, engineering teams and finops frustrated maybe with the engineering inside that may need to know how to tackle it in a different perspective.
So it was a pleasure to have you here and thanks for, for coming back.
[00:40:56] Speaker B: Absolutely. Victor and Demi and thank you so much for having me. It's, it's. It was an enjoyable conversation.
[00:41:04] Speaker C: Yeah, thank you.
[00:41:05] Speaker A: Pleasure to you. I'm looking forward to.
Yeah, thanks. Thanks a lot and it's a pleasure. And we'll like to know what you are doing in the future as well. We'll keep posted.
[00:41:16] Speaker B: Absolutely, of course.
[00:41:18] Speaker C: Yeah. And one thing let's close up with. You know something that Carlos asks us all the time. People, please register into the podcast, into the channel. By the way, let's only congratulate Carlos on his newborn. It's the first podcast after his newborn Lucas. So great questions. Enjoy.
[00:41:38] Speaker A: Yeah, greetings to him and to his to his son, because, you know, Carlos is our, our backing guy, our editor, our everything, basically. And he's on on parental leave to take care of of his son, Lucas. And that I was happy to see this weekend.
So, yeah, greetings to to him. So please raise the like this episode and subscribe, you know, for us and for him as well. And we know that you love the, the project, so. Yeah, thanks a lot.
[00:42:11] Speaker C: Thank you very much, guys.
[00:42:12] Speaker B: Cheers.
[00:42:13] Speaker C: Bye.
[00:42:14] Speaker A: See you. See you next time. Bye, Sam.
