Episode 43: Tech Team Growth, AI, and Startup Realities

So, hello again. This is SphereCast. My name is Adin Heric, Head of Marketing at Sphere.

So, I have a very exciting episode with Wes Ezzeddine. So, he is the Director of Engineering at Mamo Pay. He has been in tech leadership for many years now, also in VC-backed, but also revenue-driven businesses. And my experience has been also in in finance as well, and I'm really looking forward to speak to Wes and get into some very interesting topics.

So, Wes, with further ado, I would love you to introduce yourself also in in, you know, a few sentences to our audience. So, please go ahead, and and welcome to the podcast, Wes.

Adin, thank you very much for the intro, and thanks for having me today. As you mentioned, I'm leading engineering here at Mamo today. I've been with Mamo for about three years now. Prior to that, I've been in engineering leadership across different startups and scale-ups, and started my own startup right before that in Zambia for about five years doing that.

And today at Mamo, it's we are a pre-Series A startup, so we're kind of like in the process of growing and setting up the business and getting things all set together. You can see that we've found our market fit at the moment, but as you know, companies at this stage, like we have a lot to kind of like figure out at at this point.

In In general, my day-to-day is kind of like split up between multiple tasks. I find myself wearing different hats depending on who I'm talking to and what are the business priorities. Effectively, you might say, okay, somebody who's engineering leadership is doing a bit of everything, and this is kind of like what we do. But for me to be like quite effective in what I'm doing, I like to have like a clear schedule that allows me to get into flow and focus on the areas that I'm working on and kind of like switch to another. So, I find myself kind of like splitting up my week into three main sections. Usually, my Mondays or Fridays are kind of like drill-down, focus times, either planning, catching up, seeing what's happening, schedule things, but also to kind of like sit back and reflect on the week and see what went wrong, what went well, what can I do next week, and kind of like plan on from from there.

In between, I will have an opportunity to work on my own task: visions, roadmaps, big projects, setting up certain things, laying the foundations of specific projects. When I'm not doing this, I'm usually spending time either talking to different parts of the business, spending time with the product, spending time with sales, support, and other times just kind of like deep diving with the engineering team on specific tasks, specific projects, features. And then I would have like one day that is allocated for catching up with my team, so a lot of my one-to-ones kind of like happen in in a very specific day. Not just with the with the team, but also with various leadership people across Mamo to kind of like catch up and see what's happening. But those won't be as as regular as as the rest ones.

So, ideally, like I'd be doing stuff related to engineering side, people and project management, cross-functional involvement, prioritizing certain features, projects, pushback, reacting to what's happening with with businesses, and then also leadership-related tasks, whether it's collaborating with the rest of the leaderships, setting up roadmaps, technical vision, plans, et cetera, those kind of things.

Well, thanks a lot for your day-to-day and a snapshot in your work environment. I think it's it's definitely valuable to understand also how how the weekly and the daily daily business looks like from a from a director of engineering perspective.

So, to to my to my, maybe, second question, Wes, so you have been a part of the VC-backed, but also revenue-driven startups. And I think, from an audience perspective, you know, they would love to understand, and myself, you know, what is the biggest shift between the, you know, the two forms of tech leadership and and your point of view on that? So, how how are things going from a in a VC-backed and a revenue-driven startup from your from your point of view?

Yeah, very very interesting question, especially when we look at the change in the scene when it comes to startups over the last 5 years. We would have seen like roughly around 2021, 2022, kind of like this is when startups started to shift from being growth-driven to being like, "Okay, we need to think of ourselves as a particular business, as a business, and we need to figure out how we're going to break even, how we're going to generate revenue, how we're going to save cost," as opposed to going in with a mindset of, "We need to do 2x, 3x growth in a particular year, and if we don't hit those targets, then we're actually falling behind."

And the mindset, obviously, this is set by the leadership team, and it trickles down to the rest of the organization, becomes completely different. When you're talking about 2x, 3x growth, cost is not something that you think about, money becomes something that is abundant. You'd say that you have a lot of it, and all that you do are related to taking risks and putting in features, product releases, setups, hiring, et cetera, all related to getting the company to grow these numbers at whatever cost it is. And sometimes you'd be losing money, but you'd say, "Okay, it's okay to do it for this period of time because we need to bring in the the revenue." So, it means that everybody's focused on features related to that. It means that people are releasing a lot faster than they would normally would have released. But it also means that hiring becomes something that is at the forefront of what the company is doing, and you'd find yourself allocating quite a lot of time to this.

At some point at Luko, I was spending something between 30 hours a week on hiring, just purely doing interviews and hiring-related tasks because we had a target to hire like roughly around 60 engineers for for a given year. And this meant that a lot of the company was kind of like focus on on that, especially on the engineer side. But when you shift the focus to something that is more kind of like revenue-based or kind of like, "We want to break even," then cost becomes really important topic. What we are building and how we build it becomes extremely important. Hiring is still relevant, but we do way less hiring than we would have normally done. So, it becomes more about focusing on the team, making sure that the team is actually growing.

You're doing this in a in a VC-backed startup, but you're doing it in a in a very different way, especially when the team is a smaller size and you're not thinking of scaling up the team in a in a drastic way. Like, the team's kind of like maintaining a very reasonable size, and you find that retention is is a lot higher. So, we find ourselves like focusing on features that would drive revenue as opposed to features that will show the metrics growing on the dashboard in a way that would be appealing to the VCs. We find ourselves focused quite a lot on cost reduction features or implementations or projects. So, we look at what is our biggest cost of when it comes to like the engineering team. And we say, "Okay, cloud is costing us quite a lot of money. How can we bring cloud down by by 20%? How can we improve the ability for us to deliver faster without actually having to to scale, whether it's through processes, development tools, building better architecture, infrastructure, et cetera, those kind of things."

Sounds very reasonable and interesting. So, definitely, we saw that also with a couple of our clients. Yeah. So, as you mentioned, cloud, that's definitely the keyword where where many of them try to try to optimize, if I may call it like that. Yeah.

All right. So, yeah, I I think this is a great great bridge to to the next question as well, Wes. So, growth versus quality, you know? As I as I think, you know, in the in the recent couple of months, you have grown your tech team from 10 to 15 people. And my question is, what is the biggest challenge when it comes to maintaining quality and and scaling in in your opinion?

Yeah, very very interesting question, especially when we look behind the numbers and we say, "Why are we growing the team?" Because usually, we're not just growing the team for the sake of growth. We're growing the team because there's a specific reason, whether we want to move faster, whether there are a lot of features in the backlog that we need to meet, whether we've reached a certain threshold in terms of our ability to optimize, whether it's we're seeing certain gaps in the environment and what when we're building, when we're delivering, whether it's related to data, whether it's related to QA, whether it's related to DevOps, et cetera, those kind of things. So, these are usually the the points that would drive hiring and and growth when it comes to the team.

Quality, overall, will will get affected, but in a way that is not just focused on the quality of the deliverables, but on the overall structure and the foundation of a team. So, you start to think about team structure, you think about processes, you think about cross-squad collaboration, you think about technical leadership because you're not You don't have anymore five people just like reporting to you, and then you need to think about management and all those kind of things. You think about consistency, and you think about quality. So, just kind of like looking at things from that perspective, you start to think, okay, what is the best way for us to organize our squads? What are we looking to build? What is the most important thing for Mamo today? What can and how do we need to create our domains and subdomains and create ownership within these like different squads in a way that creates independence between those squads? They can autonomously move, make decisions, find problems, create projects, et cetera, but yet, at the same time, they're not completely autonomous in a way that allows the two of them to function within the same organization. Yeah? Because the main thing here is that we want to keep communication to a minimum in a way that it doesn't block your ability to deliver. Otherwise, it will hinder your ability to move faster. But also, you don't want to remove communication completely because then it impacts quality. Yeah?

And how do how do you balance that? Sorry to interrupt, but I think that's that's a that's a very very, very valid point, and I saw that also in a couple of of companies. And how how do you balance that maybe currently at Mamo Pay, you know? What What can you give as as some some learnings that you know or maybe some best-to-dos?

So, one of the one of the main things is that you will never get it right from the first time. So, when you first go to look at the problem, you would look at what you have and you say, "Okay, this is not working. This is not working. Let's fix this, but let's keep on on iterating when it comes to doing this." So, it's kind of setting up cross-squad meetings in a way that creates collaboration, but also maintaining very little communication.

So, I'll give an example of, for example, you can have a front-end guild where they would meet on a weekly basis to discuss front-end-related stuff. You would have the same thing on the back-end and other stuff. You would have We created something that we called the tech discovery weekly, which means that the entire engineering department would get together and they would critique a project that has the technical design ready before implementation starts. So, this means that everybody can learn, everybody can share their experiences, everybody can contribute, and all of this happens at a very early stage where the cost of correction is very minimal as opposed to correcting it later on.

Making sure that we don't have too many Slack channels, and making sure that the Slack channels that we have are active. Async communication and doing it properly, very little meetings and all of those kind of things really really helped. This coupled with proper processes. Initially, we were doing Scrum, and then we realized that Scrum is slowing us down as as a startup our size because it just meant that you spend a lot of time thinking about what you want to work on for for a sprint, but then you'd have like something urgent that comes up two days later, and then you have to sit down and rethink about where where are you going to fit it in, what are you going to deprioritize, et cetera, those kind of things. So, there's wasted time on planning twice and then on deprioritization. So, we completely shifted to Kanban, reduced the number of recurring weekly meetings, and this made us extremely agile when it comes to new requirements that are coming in, and also for the team to come together and to be able to remove blockers, which meant that we move faster, but also we can be a lot more reactive when it comes to those kind of things.

So, these are the the main ways. I would also add documentation, like good documentation to have it in place and it's accessible, and automated tests as as much as possible, whether integration, unit tests, end-to-end tests, and having a really good process to ensure that you have quality pre-release and detecting issues post-release through alerting and and monitoring.

Great. Great stuff, Wes. Let's go in into the other one as well, which is quality and speed. So, if you had to choose, which one in your current environment wins, and why?

Yeah. Yeah, this is a Yeah, you find quality versus speed like a topic that comes up in a lot of organizations. If it didn't come up yet, it just means that it's going to come up at some point where somebody's going to come up and say, "Hey, we are releasing a lot of features that are breaking in production," or, "We're not moving fast enough, and we need to figure out like how to move faster."

From From my experience, I realize that it it can't be either for for companies our size, for startups our size, it has to be both, but it can't be both at the same time. And And what do I mean by that? I mean that it's either time-specific, so depending on what the company is focused on. What do we need to do? Do we have some deadlines? Do we have some targets? Do we have some external deadlines that we have to meet? But also on what we are building. And what we are building is usually what predominantly defines whether we're focusing on speed or on quality at at Mamo.

And and I'll give two examples. One, we had a project to build an inter- internal ledger, and then another one, we wanted to build some sort of like sophisticated rerouting mechanism for payments to reduce their cost and to improve their their acceptance rate. The The first one, building the ledger, is in the core foundation of what it is at Mamo, like what we do at Mamo. You need to have a consistent ledger because you're dealing with businesses' money, so it needs to be accurate, it needs to be consistent, it cannot have any issues or any errors like 100% of the time. So, it just means that you need to sit down, talk to everybody, talk to go in-depth with product, go in-depth with risk, go in-depth with anybody who's working on this particular feature, and then afterwards, making sure that the architecture is something that will last us for a long time. So, and we're talking about something between two to five years depending on what's what's going to happen within within the bus- business. So, it means that the ledger should have all the aspects that would ensure a solid feature that is built very well and, when released, would have minimal issues. And if there were any, they won't be anything that will cause any issues with the with the with the business, with the merchant.

While when we're looking at the rerouting, it's kind of like an idea that came up that we weren't sure if it's going to work or it's not going to work, whether it's going to be important for the business, and we wanted to create a a POC to just kind of like test it. And literally, I sat down with Dong, the staff engineer at Mamo, and we're like, "Okay, we don't know whether we're going to use this or not. We just want to see whether the idea is actually something that that works. How can we hack our way around it to build something that is testable and just like present a demo?"

And for something that can be extremely sophisticated and extremely complex, something like this was built in less than a day, okay, in a way that is like very hacky, but allows us to bring this idea to the business and say, "Okay, there you go, guys. You can go test it. You can figure out what you want to do with it, and then come back to us and tell us whether this is something that we're going to be using in the long term, whether we want to create a small feature out of it, and then we decide how to handle it." And these are kind of like really good examples, in my opinion, of features that you can decide whether you want to optimize for quality or whether you want to optimize for speed when when building them.

So so, definitely understand from from your perspective that, you know, choosing choosing your your super important, of course, you know, things that you need to have as a ledger, right, that cannot have a failures basically, that needs to go to that quality checks, versus something that, you know, MVP basically, right? So, good.

And and let's go maybe into the next topic as and connect it maybe also with the speed and quality, right? So, AI is of course landed at at many places, and I guess at Mamo Mamo Pay as well. So, how do you see in the next 12 to 18 months, you know, your team changes, your AI processes changing, the AI implementations as maybe also in MVP tests and and and everything like that? And and how do you basically make sure that you're you're taking advantage of of all this new emerging technology inside Mamo?

It's a It's a question that everybody's talking about these days, and it's kind of like what is the the best way to do it, but also what is the the best tool to use in this cases? And when you look at tools, it just becomes like a bit of a an ocean that you'd get into and they're never-ending, and one day one tool is winning, and then a week later the other tool release something that allows it to to perform better.

So, what when it comes to AI, we wanted to figure out how can we make the most use out of the tools that are available without actually spending too much time on whether it's related to investigating or assessing the tools or kind of like having to constantly switch from the current best tool that we picked to something that just came out and became like a lot better. So, initially, obviously, like we just opened it up, and we said like, "Okay, we need to experiment with the tools that are available." And we're talking this is like roughly less than less than two years ago when we started to experiment with with AI tools. Not much guidelines were in place kind of like how we use it, and just kind of like started to experiment with some of the tools that are available.

Once we had a bit of a bit of data, we went and we created a set of guidelines on what is the best way to use AI when it comes to development. Yeah, it's very very similar to you give ChatGPT to any person today and you say, "Hey, like you This is a tool that will give you a lot of answers," and they would just kind of like ask the questions and they will get answers. And then you'll say, "Okay, this is a small tutorial that will allow you to get more accurate and better answers from the tool that you're you're using, and this is how you can you can optimize for it." And the guidelines are kind of like a very similar way where, rather than just kind of like doing it in the most intuitive way, just kind of like figure out what is the best way to use AI when it comes to to coding.

And we found out that approaching it as a coding assistant rather than a tool that you're just like giving it a question that gives you answers or you give it code and then it completes it changes the the whole narrative because it becomes you're the thinker, you're the one who's driving it, but you have somebody who's assisting you like to allow you not to have to write a lot of boilerplate code, or just like generate the initial template, or write the majority of the test cases for you, and then you would just focus on optimizing these and writing the the edge cases that are missing from from these set. So, we kind of like created this set of guidelines and we've introduced it. We've introduced some prompts alongside of it where these are kind of like the best prompts to to train the the the algorithm on. And then also introducing AI in other areas of of the business, whether it's related to planning, whether it's related to analyzing and improving decision-making, and whether it's related to PR or like coding discoveries.

And the the improvements that we've seen when it comes to speed were were tremendous, and we can say that we were close to kind of like doubling the speed. And I know some companies find it like very difficult to to measure this, and for us, it was relatively straightforward from a high-level perspective without actually going into too much details by just going and saying, "This is what we had planned for that quarter in terms of OKRs and what the company is going to be working on, what the engineering teams are going to be focusing on," to saying, "Okay, now we have all these tools in place. Let's see how much faster we're going to go, and let's go and double the number of tasks that we have created for from the previous quarter, and see how much we're going to achieve." And this is kind of like was the best way for us kind of like measure the improvements in speed that we've gotten from introducing AI tools and AI into the workflows.

Moving into the future, I think it's going to be less of a kind of like chatting setup with with AI and kind of like moving into more of autonomous background agents where you would sit and spend a lot of time kind of like describing a task and sending it off to to create something for you and just like coming back with with a set of set of results.

Thank you. Thank you for that information. I think very valuable also to to hear, you know, from inside the company how everybody's adopting different different tools and in which also different ways. As you said, it's it's a it's very hard to measure as well the the impact immediately.

Good. Let's go to the next topic, moving a little bit from AI away. So, reporting topic. One challenge many CTOs mention in in translating technical processes into business outcomes, you know, is, of course, you know, the reporting. So, how do you approach reporting upwards to, you know, the leadership team or even investors? Let's Let's start with that question, and then I will follow up with more.

I I think this is usually like one of the biggest challenges that anybody that is moving from an IC role to a leadership role kind of starts to face because it becomes less about the technical skill sets and more about mastering other skill sets. And as you move higher within an organization, then your peers become less technical and more in-depth in their own areas, whether it's like the head of sales, or head of ops, head of legal, somebody who's leading compliance or risk, or the CPO and the CEO. And then the conversations become completely different because now you're representing the technical side of things to the external world. You would have done this as an engineering manager, but with somebody who with some people who are still kind of like involved in the in the product development process.

And for me here, it becomes more of a conversation that, rather than starting with tech, you start with the KPIs or the OKRs of the business and kind of like saying, "Okay, what are we focusing on as a business for the next three months or the next six months? What is really important for the business?" and then pitching things that are related to that. So, obviously, we would have our own technical vision, our own technical roadmap for all of the different areas that we're focused on, whether it's infra, front-end, back-end, mobile, data, APIs, et cetera, all those kind of things. We'd have roadmaps that are being regularly built up, but just kind of like planned for the entire year without any specific prioritization. Prioritization happens when we have a definition from the business to say, "Okay, it's really important for us this quarter that we reduce our costs as much as possible," or, "It's really important for us that we are able to move faster down the line," or or those kind of things.

And when we when we get these, when I get these objectives, this is when I'll be able to figure out like what do we need to need to focus on, whether it's cost saving, revenue, customer satisfaction, et cetera, those kind of things. I'll I'll give an example of something that was really easy to pitch to the rest of the business, especially to the CEO, and to kind of like not have pushback on why our data engineer would not be doing any front-facing data work where they're going to be helping like a lot of these squads and they're and he's going to be focusing on something that nobody's going to be be seeing. We've done two of these projects over the last three months. One of them was in relation to migrating away from Fivetran to Dataflow on Google Cloud, so Fivetran for collecting all of the the data, just putting them in the in the data warehouse, and then the other one is migrating from Looker to Looker Studio. And in and in those cases, we had these initially set up, and we looked at Fivetran and we realized that the tool is too sophisticated for what we're doing at the moment, and it's costing us like quite a lot of money. So, it was like a really easy pitch to say, "If we spend the next three weeks working on this migration, we're going to save the business x amount per month." And and the amount was was significant where it was like a no-brainer. And when you do the calculation regards to the the cost spent and what is being saved, it's a it's a no-brainer, and it was like, "Yeah, go ahead." And nobody was asking question as to like why there were any delays in in regards to data.

And the same thing when it came to Looker. Looker was a little bit different because everybody at Mamo uses Looker. We are a data-driven company. We rely on it quite heavily. But then we looked at the tool and we said like, "Looker is extremely expensive as as a tool, very expensive, and it has a lot of bells and whistles that we really don't need, and we have all the underlying infrastructure that is related to BigQuery, et cetera, all those kind of things." So, we kicked off a project of migrating Looker to Looker Studio, which took around two months to complete, but it literally meant that the cost of Looker went from a particular amount to zero in in two months.

So So, these were like really easy to go and pitch to the business and say, "This is related to our initiative of wanting to break even and to to reduce the cost." So, how do you This is one way of presenting it to the execs. You can use a very similar lingo when you're presenting it to the investors. But this is kind of like what the business side wants to hear. They don't care about the technical implementation, they don't care about which tool it is, they don't care about all those kind of things. All they want to do want to know is how does it impact the overall business, and is it just something that we feel that is cool to do on the engineering side of things?

Understand. Yeah, thank thank you also for bringing up the examples, definitely definitely worth it. So, Wes, you know, you have been growing teams, and if I may ask you, like if you could have a time machine, go back to growing the team, what was maybe the no- the one lesson that you would change, and that you learned of course then later on, that would you would change when growing a team?

This is for all the, you know, you know, inspiring, upcoming CTOs, head of engineering, director of engineering. So, maybe they can they can learn something from this.

This is This is a a nice question. Obviously, like building a team would be a little bit different than general leadership. And if I were to just like focus on building a team, I would definitely say that it's extremely important to pick the right people and the best people, and best people, I mean the people that are most aligned with the business, the business's needs, and the culture of the organization, not in terms of generic best.

So, to pick the best people first, and because those people will define what your predominant culture is and they will help you with hiring the the rest of the team later on. So, I would say it's extremely important to be very picky and to take your time when hiring your first few engineers because it's going to impact everything that you do over the next three to five years, and correcting this would be extremely difficult.

Let Let me just ask a a question on that. So basically, as as your team has grown, you have, you know, how do you keep a consistent engineering culture? And and what's what changed for better or for worse as the team grows, maybe on that?

So, when it comes to engineering culture, as much as we as engineers don't like to be in meetings, would like to sit down and focus on tasks and get get into a flow and kind of like not be interrupted, especially by things that we don't want to don't want to do, we also like to feel that we are part of a bigger team, that we're part of a community, that we're part of a group, and where we don't only align on, yeah, we're trying to build build a product, but also have other things in in common. And trying to build this is extremely important.

The important thing about this is that it's not It's not the sole responsibility of the leadership to build this. Every single person will will take part of it. And for example, I'll I'll give an example that is related to culture that is not within the company, but kind of like a little bit external that brought people together, is that many people on the team like to like to game. They like to go and play online games. I personally don't play online games. I don't It's not that I don't enjoy them, I enjoy them, but I don't have the the time. I can't find the time to sit down and spend like a couple of hours doing gaming. And many people within the team, they meet after work. We're we're remote-first company, and they meet remotely, and they just like sit down and play play games. And this brings them a lot closer, and creates this kind of like feeling of friendship, camaraderie, community amongst them.

So, culture is extremely important. There are different ways to to do it: definitely bringing the engineering team together, creating the the right vision, all being aligned, but also the company culture helps, and also something that happens outside of this. Besides that, processing, tooling, and team structure play an an important role. It's extremely I don't want to say complex, but it's something that deserves a lot of attention regularly to make sure that things are being up-to-date. Sometimes, things used to work for a very specific period of time, but they no longer serve us as a company, so we need to iterate over this. And also, the team structure, when we're trying to, for example, focus on one particular product at Mamo and we're trying to build and develop this to reach a particular state, once we hit that state, that particular product does not require as much attention as it used to, and this is the time to kind of like look at restructuring the team and kind of like moving moving people around.

Thanks for that answer, Wes. Interesting.

So, last two questions, Wes. We're we're almost at the end. So, looking back maybe into the future in AI, and I think this is also what many, you know, engineers ask themselves. And and I think there is a lot on the on the on the internet, if if I may call it like that, you know, with with AI, you know, losing the job, and and and everything like that. But what do you think from your own own perspective and in your team, what is what are the the skills that engineers should use, you know, when it comes to AI to to to to stay relevant in the upcoming months and years?

Yeah. I'm I'm going to start with the It's It's probably a cliché answer, but it's it's something that is quite relevant. It was relevant during the digitization era. I would say that AI is not going to replace engineers, but engineers who use AI are the ones who's going to are going to remain in in business. So, I would highly encourage engineers to figure out the most optimal way to to use AI, and kind of like start to think from a a person who has a junior engineer alongside him who can complete tasks at a very incredible speed. And this means that in this case, the engineer needs to focus on quality, needs to focus on edge cases, needs to focus on a clear communication, needs to focus on system design and architecture, needs to focus on a prompt engineering, coming up with like really good prompts, mastering AI workflows, and all those kind of things.

And being able to move in that direction is something that will allow engineers to move a lot faster, but it will make them a lot more relevant because I don't see the future of engineering teams to be we need to hire as many engineers as possible to make sure that we are growing and moving at the right speed, and generate the the best quality, and we're able to develop all the features that we want to build. I I believe that the future of engineering teams is going to be a small group of elite people that have multiple skill sets and that are able to deliver high-quality products at a at a very high speed, but also those that understand how AI works, they understand how the business works, they understand the product, they understand the architecture, and are able to to correct all of those things accordingly.

When it comes to staying up-to-date, I would definitely say don't read the news every day or kind of like figure out what is the latest thing to do. Find one or two extremely relevant people who have good insights and good advice on the industry, on what's happening in AI, follow them, listen to them once a week, pick up something new once a week, and and that's it. Anything more than this becomes a waste of time, and you will not get the the results in comparison to the to the cost and the effort that you're actually putting into it.

Very well said, Wes. I I agree, and I I see it also from from a marketing perspective and in a marketing team, you know? So, definitely agree on that that people have to be more generalist this and and and use the tools to be more efficient basically, right? So so, as I can sum it in one sentence.

Last question, Wes: which other tech leader would you recommend for us to invite to this to our podcast?

Yeah. I'm going to I'm going to put maybe two people on the spot, so hopefully, they will be able to answer the call. A very close friend of mine, Nasser Oudjidane, who's the CEO and co-founder of of Taptok. I think he will be a great person to to have on on this podcast with a lot of insights. And my former boss and my my close friend, Anton Gotchev. He's the VP of Engineering at Luko previously, and now Allianz Direct.

Nice. Well, thank you. Thank you for naming them, and I will definitely connect with them, and and and invite them to our podcast.

So, Wes, from Sphere and and the SphereCast, I really thank you for taking the time to bring some insightful information from your personal experience, but also at Mamo, and I wish you really all the best with Mamo and and your further career.

Thank you. Thanks for having me, and thank you for the interesting questions.

You're welcome, Wes. Thanks a lot. Till next time.