Tech Team Growth, AI, and Startup Realities - Wes Ezzeddine

Speaker A: So hello again, uh, this is Fearcast. Uh, my name is Adin Herrich, head of marketing at Sphere. So um, I have a very exciting episode uh, with VEZ Ezedin. So he is the director of engineering at Mamo Pay. He has been in tech leadership for many years now. Um, also in VC backed but also revenue through businesses and um, my experience has been also in finance as well. And I'm really looking forward to speak to Wes um, and get into some really interesting topics. So we further ado, I um, would love you to introduce yourself also in a few sentences ah to our audience. So please go ahead and welcome to the podcast.

Speaker B: Adam, thank you very much for the intro and thanks for having me today. Um, as you mentioned, I'm um, a leading engineer here at MAMU today. I've been with MAMU for about uh, 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 uh, today at mamu, uh, 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 ah, all set together. You can say that we've found our uh, market fit at the moment but as you know companies this stage we have a lot to kind of like figure out at this point. 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. Uh, effectively you might say, okay, somebody whose engineer 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 are Fridays. I kind of like uh, 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. Uh, in between I will have an opportunity to work on my uh, own task, uh, 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 uh, different Parts of the business, uh, spending time with uh, product, spending time with sales support, um, and other times it's 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 a very specific day not just with the, with the team but also with various leadership uh, people across Mamo to kind of like catch up and see what's happening. But those won't be as regular as uh, the rest of one. So ideally like I'd be doing stuff related to engineering side people and project management, cross functional involvement, uh, prioritizing certain um, features, projects, pushback, reacting to what's happening with businesses and then also leadership related tasks, whether it's collaborating with the rest of the leaderships, uh, setting up uh, the roadmaps, technical vision plans, et cetera, those kind of things.

Speaker A: Well thanks a lot for your uh, day to day and a snapshot in your work environment. Um, I think it's definitely valuable to understand also how the weekly and the daily business looks like from a director of engineering perspective. So um, to my maybe second question, uh, was so you have been uh, part of the VC backed but also revenue driven startups, um, and I think from an audience perspective, um, they would love to understand and myself what is the biggest shift between the two forms uh, of uh, tech leadership, uh, and your point of view on that. So how are things going in a VC backed and a revenue driven startup from your point of view?

Speaker B: Yeah, very interesting question. Especially when we look at the change in the scene when it comes to startups over the last uh, five years would have seen like roughly around uh, 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 costs as opposed to going in with a mindset of we need to do 2x3x 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 2x3x 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, etc. All related to getting the company to grow these numbers at whatever cost it is. And sometimes you'll be losing money but you say okay, it's okay to do it for this period of time because we need to uh, bring in 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 release. 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. Like uh, at some point at Luco 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 uh, 60 engineers for, for a given year. And this meant that a lot of the company was kind of like focused on, on that, especially on the ENG 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 a 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 very different way. Especially when the team is a smaller size and you're not thinking of ah, scaling up the team in a drastic way. Like the team's kind of like maintaining a very reasonable size and you find that retention is a lot higher. So we find ourselves focusing on features that would drive revenue as opposed to features that will uh, show the metrics growing on the dashboard in a way that would be appealing to the VCs. Uh, we find ourselves uh, uh, focused uh, quite a lot on cost reduction, uh, features or implementations or projects. So we look at what is our biggest cost of uh, when it comes to like the engineer team and we say okay, uh, cloud is costing us quite a lot of money. How can we bring cloud down by about 20%? How can we um, improve the ability for us to uh, deliver faster without actually having to scale, whether it's through processes, development tools, um, building better architecture, infrastructure, et cetera, those kind of things.

Speaker A: Sounds very reasonable and interesting. So definitely we saw that also with a couple of our clients. Yeah so, um, as you mentioned, cloud, that's definitely the keyword where many of them try to optimize, if I may call it like that. Yeah. All right, so, uh, yeah, I think this is a great bridge to the next question. Um, as well was. So, um, growth versus quality. You know, as, as I think you know, in the, in the recent couple of months, um, you have grown your uh, tech team from 10 to 15 people. Um, and my question is, what is the biggest challenge when it comes to maintaining quality and, and scaling in, in your opinion?

Speaker B: 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 uh, move faster, whether there are a lot of features in the backlog that we need to uh, 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 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, etc. Those kind of things. So these are usually the points that would drive hiring and growth when it comes to the team. Quality overall 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 don't have any more, uh, 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 uh, 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? 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 quads. They can autonomously move, make decisions, find problems, create projects, etc. 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. 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.

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

Speaker B: So 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 iterating when it comes to doing this. So it's kind of uh, setting up uh, cross squad meetings in a way that creates collaboration but also maintaining very little communication. I'll give an example of, for example you 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 backend and other stuff you would have. We created something that we call 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 uh, later on and 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, uh, this coupled with proper processes. Initially we were doing Scrum and then we realized that slowing us down as a startup our size because it just meant that you spend a lot of time uh, thinking about what you want to work on 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 are you going to fit it in, what are you going to deprioritize, etc. 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 ah, agile when it comes to new uh, 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 um, these are the main ways. I would also add documentation, like good documentation to have it in place that it's accessible and automated, test as much as possible, whether integration unit test, end to end tests, and having a really good process to ensure that you have quality pre release and detecting issues post release through uh, alerting and uh, monitoring.

Speaker A: Great, great stuff. Um, uh, let's go into the other one as well which uh, is quality and speed. Um, so if you had to choose which one um, in your current environment wins and why.

Speaker B: Yeah, this is um, 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 is 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 my experience I realized that it can't be either for uh, companies our size. For startups, um, our size, it has to be both, but it can be both at the same time. And what do I mean by that? I uh, 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, 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 maml, and I'll give two examples. One, we had a project to build an internal ledger and then another one, we wanted to build some sort of like sophisticated rerouting mechanism for uh, payments to reduce their cost and to improve their acceptance rates. 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 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, there won't be anything that will cause uh, any uh, issues with the, with uh, the, with the business, with the merchants. Well, when we were 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 park to just kind of like test it. And literally I sat down with uh, Dong, the staff, uh, engineer at mamu and we were 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 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. 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 building them.

Speaker A: So definitely understand from your perspective that choosing your uh, super important of course, uh, things that you need to have as a ledger, right. Um, that cannot have a failures basically that needs to go to the quality checks versus something that you MVP basically. Right. So good. Um, and let's go maybe into the next topic as and connected maybe also with the speed and quality. Right. Um, so AI is of course landed um, at many places and uh, I guess at mamopay as well. Um, so how do you see in the next 12 to 18 months, um, you know, your team uh, changes your AI processes, changing the AI implementations as ah, maybe also MVP tests and everything like that. Um, and how do you basically make sure that you're taking advantage of all this new emerging technology inside mamo?

Speaker B: It's a question that everybody's talking about these days. And it's kind of like, what is the best way to do it, but also what is the best tool to use in this cases? And when you look at tools, it just becomes like a bit of, uh, an ocean that you get into, and they're never ending. And one day, one tool is winning, and then a week later, the other two are something that allows it to perform better. So 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, uh, 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 two years ago when we started to experiment with AI tools, uh, 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 data, we went and we created a set of guidelines on what, um, is the best way to use AI when it comes to development. It's very, very similar to, you give chatgpt to any person today and you say, hey, like, you, uh, 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, um, you'll say, okay, this is, uh, a small tutorial that will allow you to get more accurate and better answers from the tool that 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, uh, when it comes to coding. And we found out that approaching it as a coding assistant rather than, um, 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 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 to allow, uh, you not to have to write a lot of boilerplate code or just generate the initial template or write, uh, the majority of the test cases for you and then you would just focus on um, optimizing these and uh, writing the edge cases that are missing from these set. So we kind of created this set of guidelines that we've introduced it, we've introduced some prompts ah, alongside of it where these are kind of like the best prompts to train the algorithm on and then also introducing AI in other areas of the business, whether it's related to uh, planning, whether it's related to um, analyzing and um, improving decision making and whether it's related to PR or like coding uh, discoveries. And the improvements that we've seen when it comes to speed were tremendous and we can say that we were close to kind of like doubling the speed. I know some companies find it very difficult 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 um, okrs and what the company is going to be working on, what the engineering teams are going to be focusing on to say 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 to kind of like measure the improvements in speed that we've gotten from introducing AI tools and AI ah onto the workflows. Moving into the future, I think it's going to be less of a kind of like chatting, um, setup with AI uh and kind of like moving into more of autonomous uh, background agents where you would sit and spend a lot of time kind of like describing a task and sending it off to create something for you and just coming back with a set of results.

Speaker A: Thank you, thank you for that information. I think uh, very valuable also to hear from inside the company how everybody is adopting different tools and in which also different ways. Um, as you said it's very hard to measure uh, as well the impact immediately. Um, good. Uh, go to the next topic. Um, moving a little bit from AI ah away. Um, so reporting topic. Um, One challenge many CTOs mention in translating technical processes into business outcomes is of course the reporting. So how do you approach reporting upwards to you know, the leadership team or even investors? Um, let's start with that question and then I will follow up with more.

Speaker B: 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 uh, 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, uh, somebody who's uh, leading compliance or risk or the CPO and the CEO. And then the conversations become completely different because now you're representing the technical uh, side of things to the external world. You would have done this as an engineering manager but with somebody who uh, with some people who are still kind of like involved in the, in the product uh, 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 ah, areas that we're focused on. Whether it's infra, front end, back end, mobile data, uh, APIs, et cetera, all those kind of things. We'd have roadmaps that are being regularly built up but just kind of like plan 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 those kind of things. And when we, when we get these, when I get these uh, objectives, this is what I'm 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 give an example of something that was really easy to pitch to uh, 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 um, front facing data uh, at work where they're going to be helping like a lot of these squads and they're going to, and he's going to be focusing on something that nobody's going to be seeing. Ah, we've done two of these projects over the last three months. One of them was in relation to migrating away from Fivetran to uh, data stream on Google GSP. Uh, so 5tran for collecting all of the data, just putting them in the data warehouse and then the other one is migrating from Looker to uh, Looker Studio. Uh, 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 quite a lot of money. So it was 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 the amount was significant where it was a no brainer. And when you do the calculation regards to uh, the cost spent and what is being saved, it's a no brainer. And it was like yeah, go ahead. And nobody was asking question as to why there were any delays in regards to data. And the same thing when it came to Looker, Looker was a little bit different because everybody at ah, MAML uses Looker. We are a data driven company, we rely on it quite heavily. But then we looked at the tool and we said Looker is extremely expensive 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. So these were like really easy to go and pitch to the business and say this is related to our initiative of uh, wanting to break even and 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 know is how does it impact the overall business. And it's not just something that we feel that is cool to do on the engineering side of things.

Speaker A: I understand. Yeah. Ah, thank you also for bringing up the examples. Um, definitely, definitely worth it. So uh, 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, um, that you would change and that you learned of course then later on that you would change when growing a team. This is for all the uh, inspiring upcoming ctos, Head of uh, Engineering, Director of Engineering. So maybe they can learn something from this.

Speaker B: This is a nice question. Uh, obviously building a team would uh, be a little bit different than general leadership. And if I were to just 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 uh, 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 uh, it's going to impact everything that you do over the next three to five years and correcting this would be extremely difficult.

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

Speaker B: So when it comes to engineering culture, as much as we as engineers don't like to be in meetings, we like to uh, sit down and focus on tasks and get into a flow and kind uh, of like not be interrupted especially by things that we 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 uh, build a product but also have other things in common and trying to build this is extremely important. The important thing about this is that it's not the sole responsibility of the leadership to build this. Every single person will take part of it. And ah, for example, uh, I'll give an example that's 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 game. They like to go uh, and play online games. I personally don't play online games. Uh, it's not that I don't enjoy them, I enjoy them, but I don't have the, I can't find the time to sit down and spend like a couple hours doing Gaming and many people within the team, they meet after work. We're remote first company and they meet remotely and they just like sit down and play games. And this brings them a lot closer and creates this kind of like feeling of friendship, uh, comrade community amongst them. So culture is extremely important. There are different ways to do it. Uh, definitely bringing the engineering team, uh, together, creating the right vision, ah, 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 important role. It's uh, extremely, I don't want to say complex, but it's something that deserves a lot of attention. Regularly to make sure that, uh, things are being up to date. Uh, sometimes things used to work for a very specific, uh, 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, a maml, 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 people around.

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

Speaker B: Yeah, I'm going to start with the, uh.

Speaker A: It's.

Speaker B: It's probably a cliche answer, but it's uh, 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, uh, are the ones who are going to remain in business. So I would highly encourage engineers to figure out the most optimal way to use AI and kind of like start to think from a person who has a junior engineer alongside him, m who can complete tasks at a very incredible speed. And this means that in this case, uh, the engineer needs to focus on quality, needs to focus on edge cases, needs to focus on clear communication, needs to focus on system design and Architecture needs to focus on uh, a prompt engineer coming up with really good, uh, prompt mastering, AI, uh, 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 uh, growing and moving at uh, the right speed and generate the uh, best quality and uh, we're able to uh, develop all the features that we want to build. I believe that the future of engineering teams is going to be a small, uh, group of elite people that have multiple skill sets and that are able to deliver uh, high quality products 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 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 uh, one or two extremely relevant people who have good insights and good advice, uh, on the industry, on what's happening in AI, uh, follow them, listen to them once a week, pick up something new once a week 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.

Speaker A: Very well said, Wes. Um, I, I agree and I, I see it also from, from a marketing perspective and in a marketing team, you know, um, so definitely agree on that, that people have to be more generalist and, and, and use the tools to be more efficient, basically. Right, um, so, so as I can sum it, um, up last question was um, which other tech leader would you recommend for us to invite to this to our podcast?

Speaker B: Yeah, I'm gonna, I'm gonna put maybe uh, two people on the spot. So let's go. They'll be able to answer the call. Um, a very close uh, friend of mine, Nasser, uh, Ojidan, uh, who's the uh, CEO and co founder of Tapper. I think he would be a great person to have on this podcast with a lot of insights and, and uh, my former uh, boss and uh, my close friend Anton Gotchev is the uh, VP of engineering at Luko, uh, previously and now Alliance Direct.

Speaker A: Nice. Well thank you, thank you for naming them and I will definitely uh, connect with them and invite them to our podcast. So, uh, from Sphere and the Sphere Cast, um, I really thank you for taking the time, uh, to bring some insightful information from your personal experience, but also at Mamo. Um, and, uh, I wish you really, all the best with Mamo and your further career.

Speaker B: Thank you. Thanks for having me. And thank you for the interesting questions.

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