Internal vs. External: Finding the Right Balance When Scaling Tech Teams with Wes Ezzeddine

Adin Herrich: Welcome to another episode of spherecast, Sphere's bi weekly conversation with entrepreneurs, business and tech leaders. I'm your host, Adin Herrich, head of marketing at Sphere. Our mission here is simple. To educate, inspire and guide people on how to start, grow and scale their business by leveraging innovative technologies and best practices to succeed. Today I'm excited to be joined by my co host, Katya Savenkova, and our director of talent delivery and CEO at Sphere. Katja has worked with dozens of companies to help them scale engineering and product teams, and she brings incredible insight into how to balance internal growth with external talent delivery. And together, we're welcoming back our returning guest, Bez Azzedine, a seasoned technology leader with deep experience in scaling teams, building products and navigating the reality of startup growth. Wes, I know you can introduce yourself much better than I can, so I'll let you do that in a moment. In this episode, we'll dive into the nuts and bolts of scaling engineering teams. Everything from knowing when to hire in house versus bringing in external expertise, to spotting high performers, to structuring projects for successful execution. Whether you're leading a startup team or managing growth inside a larger organization, this conversation is packed with lessons you can put into practice. So let's get started. Well, Wes, welcome back to spherecast. It's great to have you here again. For those listening who may not know yet, could you give a quick introduction to yourself and your current role?

Wes Ezzeddine: Aydin, great to see you again and thank you for having me. My name is Wes. Um, I'm the Director of Engineering at mamo. I've been with MAMO for about over three years, leading the engineering team. And apart from Mamo, I do a lot of stuff when it comes to the AI safety industry and AI safety within the UAE in particular.

Adin Herrich: All right, thanks a lot for the quick intro, Buz. And we have of course also Katya Savenkova, my co host. So, Katya, please go ahead and introduce yourself as well.

Katya Savenkova: Hi everybody. Thanks for having me here. I'm Katya. I'm Director of Operations at Sphere. I've been working here for quite some time, 12 years. And I'm also. I also manage at Simog practice at Sphere. And yeah, basically. That's basically it.

Adin Herrich: All right, thank you, thank you. Thank you as well. So let's dive in it right. It's going to be exciting, I think. Podcast about everything related to scaling and teams. So Wes, let's start on your end, I would say. So when you think about scaling teams, it's of course not just about the headcount. So how do you break down scaling into concrete steps, processes, tools, or hiring in general?

Wes Ezzeddine: Yeah, yeah, very good point. And I think this is something that a lot of teams would have to consider. Especially when you have somebody who's setting up a new startup, uh, they hire a few people and then they want to consider, like growing the team or you have existingly large teams that want to scale. But I would say before thinking of adding more people to an organization, first, like, we need to think about what are we trying to scale in. We might want to do like an skills assessment gap. Do we want to take a look at the tools that we're currently using? We want to see that we have the most efficient processes in place. We want to see what the org structure is like and decide, are we optimizing for quality? Are we optimizing for speed? Are we optimizing for resilience? Are we optimizing for output? And based on what we really want to do within the organization, this is how we make our decisions. Because if we have a skills gap, so for example, if we say, oh, we don't have a data engineer, we don't have a QA engineer, some people might say, oh, we're missing these people. But the question is, do you really need a QA person? What's the quality like within the team? Are you able to deliver features that do not break in production? Are you able to get features out really quickly because they're not being failing? Uh, they're not failing testing, and then they're being sent back by the person who's testing them. And if you feel that you're missing these certain skill sets, then you kind of like figure out, what do I

Adin Herrich: want to do with it?

Wes Ezzeddine: Are you looking at tools? Do you have the best tools in place? Are we using the tools that would allow you to ship paths to go quickly? Are the tools the most efficient? We've had something come up with the finance team, maybe less on the engineering side, but it's related to data, uh, where they needed to optimize, how they're doing certain calculations. When it comes to businesses that we're onboarding onto Mamo and one of the guys who's really into coding, SQL, et cetera, came up with a tool and said, hey, I've used Alteryx in the past. It's excellent. It allows us to reduce the work that we have to do within a day to an hour or so. And then we said, oh, well, we have like a data engineer. Why don't you talk to the data engineer. And then we looked at it and we realized no, Alteryx is the perfect tool for this. And I don't want to go into talking about AI and how you could potentially use AI to upskill teams today, but AI has a lot of use cases, especially within the engineering team. Do we have the most efficient processes? I would talk about Agile, talk about Scrum, Kanban, but we've literally seen in the past moving away from Scrum and to Kanban would allow us to improve the speed that we're moving at. So once we have this assessment done, um, then we can kind of decide what do we want to do? Do we want to go ahead and hire that QA person? Because the team is spending quite a lot of time testing and we don't have enough end to end tests in place, we don't have enough integration tests in place, et cetera. And then we really need to go and get that person to join the team. What kind of projects do we have? What kind of projects are we looking to implement in the next while? So all of these are quite important to consider before we go ahead and we decide how we want to scale

Adin Herrich: and what are we going to do

Wes Ezzeddine: when it comes to scaling? Because adding people sometimes to the organization does not necessarily mean that the organization is going to move faster. Because when you add uh, people, if that person is missing, you will definitely move faster. Like if you're missing a qa, bringing in the QA is excellent. It's going to allow you to improve your quality, quality, the features are being delivered, etc. But if you're not missing that person and you want to maybe add like more backend engineers or you want to add more front end engineers, what does this mean to the org? What does this mean to the person who's going to be managing these? Like is he, is that manager going to have enough time to still like go ahead and do a bit of coding or are they going to just be managing people? And do you have to like restructure the organization? Do you have to hire another manager? Do you have to promote somebody internally? So the question that we need to ask first is what are we trying to optimize for first? And then decide whether adding people is the right way to go and then if we add people, what's going to happen to the organization overall?

Adin Herrich: All right, thanks a lot. Thanks a lot for your analyze there and how you do it at Manopay. So when new initiatives come by, of course, how do you decide in your analysis if you would go for an in house recruitment or an external hire, for example, and in which cases, for example, would you choose A or B?

Wes Ezzeddine: Yeah, yeah. It's a question that kind of like comes up on a regular basis, especially when you're working on new projects. And there's usually a few things that you need to assess. And I have two examples within MAML where we've had to do either. One of them is building an AI chatbot within WhatsApp, and the other one is building plugins for WooCommerce, Prestashop, Magento, Shopify, et cetera, and making these available to our, to our merchants. And the key questions that we tend to ask ourselves, like what is this that we're trying to do? Is this a long term initiative or is this a short term initiative? Are we trying to just kind of like deliver something in the short term or do we have something that we're going to be doing over the next couple of years? Is this a strategic offering for our organization? Is this something that MAMO specializes in? Is this our moat? Do we have to develop something in a unique way, in an innovative way that will allow our product to stand out, or is it just something that we're going to be delivering? Is very similar to what other organizations have. Do we have the right skill sets internally for developing this particular feature or getting this delivered? What is the onboarding time like? If we have a project that is due to be delivered in about three months and then going and finding a hire and onboarding that person, and it takes about like two months to get that person to join and then a couple of months to onboard them, then this is definitely not the way to go. Do we have the bandwidth internally to take in on that project? If we have several projects that are ongoing, are we able to. Do we have the capacity to take in new product? Is this an isolated task, et cetera, all those kind of things. So when we are building an AI, uh, chatbot, we already had the experience of building a WhatsApp bot. We've went and we built a couple of WhatsApp bots for automating payment links, generations for doing expense management, et cetera. And naturally it felt that the easiest way to add this chatbot to mamu, to the sales chatbot is through the WhatsApp bot. And just all it needs is somebody to go in and better understand how to build an AI agent and have this integrated. It meant that we build this internally and then we could potentially use it in other areas within the organization. Whether it's for support. Whether it's something within the dashboard. This one was a no brainer for us to say, yes, we want to develop the skillset in house. These are the different courses that this person has to do. This is something that we haven't built before. How do we integrate this into the overall flow, how do we release this, how do we test this, et cetera, all those kind of things. But when it came to building plugins for WooCommerce Prestashop, these features, this particular offering is not something that we will be iterating over on a regular basis. Obviously there will be some improvements, but they won't always happen. It's something that we're going to build once, offer it to our merchants and then improve on it whenever there's a need for it, or there's something that is missing or there's a new version that is being released of, of WooCommerce or we'd have to uh, add a particular feature. But this is not ongoing work and building the right expertise internally is not worth worthy of our time. And going and hiring a person to come in and just be responsible for these SDKs is not worth your time. So the best thing to do is to actually go outside and say, hey, who's the best person organization that can come in and help Mamo build these plugins? And if there's one organization that can do WooCommerce preshop, Magento, Shopify. Excellent. Because it just means that hey, these are the requirements, they're the same. You have the expertise when it comes to each of these platforms. Build this for us, help us get it out and then maintain it for us like whenever we need something that requires some optimizations or improvements.

Adin Herrich: Right, thanks. Thanks for that. Insights, of course. So Katya, you have worked with of course, dozens of clients on exactly this decision. Right. And um, so from your experience, what are the most common mistakes companies make when choosing between, you know, internal hires and external support?

Katya Savenkova: Well, first of all, I think it's taking it as a black and white. I can know whether we do only. I, I met with many companies which say we only do internal hiring or they say they don't have technical team and say we do only external. We work only with external consultants, first of all. And I think Wes covered this well enough. It really depends on the project. Right. It doesn't make sense to hire anybody, uh, internally. If you have a short term project, you will burn your budget in a few months for recruiting, for onboarding. But the common mistake I Often see is the expectations that companies have about external consultants. They often say, oh, okay, we, we are hiring expensive super experienced consultants. They will take it, they will catch everything immediately. And it's not like this, right? So even external, even super experienced, even uh, like very, very good team, they still need some part of onboarding and the company needs to provide it. And uh, the better onboarding is done, the easier things will go. So yeah, basically I think that's the main thing when I'm talking about this. It's more like small details like who to make sure that everybody has access, to make sure that we are aligned, we're aligned on the hour, working hours or communication hours. Right. To make sure that, I don't know, the external team has access to Slack and is aware that they need to answer and check their messages there. So these are small things which kind of look like not important, but I saw so many situations when the collaboration didn't go well just because of these details. So I think, and we are sphere, we pay a lot of attention to onboarding and also cultural feat of course. Uh, and um, like, you know, so to make sure that the team, the external consultants are the right fit for the company.

Adin Herrich: Um. All right, so I saw a lot of nodding from Wes and especially on the communication part. So I guess you have some experience there, Wes, if you want to share it, please go ahead. Or you just wanted to confirm what Katya was saying?

Wes Ezzeddine: Yeah, definitely, definitely. She's spot on with a lot of the points. And clarity before the project begins is extremely important. As Katie mentioned, access to Slack, having the right permissions, knowing when they're online and when they're offline, giving clear requirements beforehand is extremely important because it uh, defines the scope of the project. The team understands what is required to be delivered. And this means that when you hand this over to the team, they know exactly what they're, what they're going to be doing. And there's no this, oh, I don't understand this, or there's not enough details on this particular requirement, which means that we have to internally go and figure that out. And sometimes it's not just a matter of answering question and saying, oh, for this particular payload you just have to add flag and then it's done. Sometimes it requires us to go and do an implementation internally. And this is something that we recently uh, came across when we're building our Shopify. We went ahead and we said these are the requirements. We're not clear about what is required from us to make this update. Um, that we're looking to do. And then the team went, the external team went and said okay, let us do an assessment. And they said okay, this is what's required from your side. And we're like okay, we need to do a development that doesn't just require on us, that doesn't have just a requirement on us, but a requirement on an external partner that we have. So we have to go to that company that we work with and say hey, we're trying to implement this, what do we need to do? And this means that this is like a couple of weeks of work and for a consulting company that is helping out, uh, or somebody like you're outsourcing work to, they would have multiple projects and this helps them to be able to manage things on their under and then figure out like when to bring the developers back onto our project. So I completely agree that the onboarding is extremely important. Having a lot of clarity in terms of how the project is going to be managed, what are the requirements, how you going to communicate, how is it going to be delivered, et cetera. All of those kind of things make it a lot easier to work with somebody who's external.

Adin Herrich: Yeah, great, great. Katya, please.

Katya Savenkova: I wanted to mention that uh, what Wes mentioned is super, super important. Clear for everybody, clearer goals and clear expectations of what needs to be done. Funny enough, but it's not often it's not that uncommon that it's not set up and many uh, in many situations when, if you're talking about mistakes. Right. The uh, the external team comes and is not sure what they need to do. So this is important.

Adin Herrich: All right, yeah. So communication alignment I would say and, and if I may put it in my own words is actually you know, taking that external support as basically your internal hiring as well. Right. So, so I mean from a cultural communication onboarding perspective. Right. So it's not that they are magical people that know everything I would say right. When they are dropped somewhere. So, so everything all right. Thank you. Uh, to transition to my next question maybe was you mentioned a part, I think already on it. So many companies struggle to scope engineering projects early. So how would you break big projects into deliverables your team can execute on?

Wes Ezzeddine: Yeah, this is probably uh, one of those hidden hard problems like for example, like what Katya was mentioning earlier. People underestimate certain things and project management is something that is underestimated. And at um, maml we are, we're really good when it comes to delivering ah, projects from a product perspective, from anything that is like non engineering Perspective, but when we had engineers, like, as in not senior engineers, like somebody who's an EM level or at that level, who has a lot of experience doing project management, but somebody who's an engineer, who has their own initiative to actually deliver that, we notice that there's a bit of a gap. And when it comes to project management, it's also about the flow. Not just about the project, the scope, the deliverable, the timelines, et cetera, but also the flow within the team who's actually delivering that particular project. So when you're looking at a project holistically, you need to kind of like start to like break it down and say, okay, what are we trying to achieve here? Why are we doing it? Okay, and start to look at the end goal, as opposed to like starting with the requirements that we have in place. And once we understand the end goal, that this means that not only the person who's coming with the requirements, who's able to say, this is what we want to deliver, but the team and every single person in the team can actually jump in and say, oh, so if this is what we're trying to achieve, then maybe this can wait until later. And this can wait until later. So we have to figure out whether the scope is negotiable or what is non negotiable. Because when we figure out what the non negotiables are, we can decide on what the MVP is. And when we decide on what the MVP is and make it as minimal as possible, we increase the likelihood of this project succeeding. So then we say, okay, this is the smallest scope of what we want to try to deliver. Who are the people that we need to be as part of the scenes? For example, we recently did a front end migration and this meant that we have to get people from different squads who have different roadmaps that they need to deliver to come together and deliver this project. And it means like, okay, how are we going to do it? Are people going to just sit down and be removed from their squads and spend a couple of weeks migrating that project? The answer is obviously no, because it means that you're not shipping any new features. So you have to figure out how are you going to scope it? How are you going to get these people together? Is it once a week, is it for two separate weeks, within a quarter, et cetera, and figure out how these people are going to get together, decide on what the deliverables, because you set them apart and you said, okay, this is the scope. Breaking these into smaller tickets, doing your essays and Setting a target date. A target date is important. I prefer going with the term target date as a deadline. Deadline is a little bit too scary. So target dates are a lot more, uh, friendly as a term and just kind of like figure out, okay, how can we keep on delivering small working versions of what we want to do? In some cases it's not possible, but in most cases it is. And when we deliver small working versions, it means that people can see what we are about to deliver. If there are mistakes, they can be spotted early or like some miscommunication or misunderstanding in the requirements. If there are issues, we'd be able to go to that particular deliverable and immediately understand what is wrong or what happened as opposed to like waiting for about six weeks and then trying to run it. And then things, things go wrong. So all of those kind of things become important and then setting the milestones. Once all of this is defined, you also want to be able to figure out like, how are we going to measure success? How are you going to monitor what you're about to release, how are you going to test it and then know if things go wrong, how are you going to revert it and then bring back a working version? So there are a lot of things that need to be put in place and it's important that all of these are defined from the beginning while leaving some flexibility for things to be altered as we move on in the project and discover things that we were not aware of. Because if we spend so much time on the planning phase, then we're also restricting ourselves and we're spending too much time thinking. The best thing to do is do spend time thinking, do put in a plan in place, but don't spend too much time on the plan, otherwise the plan becomes very rigid. And then when you come across new issues that you haven't seen before or you didn't plan for, then it's very difficult to alter the plan.

Adin Herrich: Um, I see myself and I see Katja nodding. Skatja, do you want to add something on this topic? Because I think it sounds familiar or.

Katya Savenkova: Well, I think Wes covered and yarn. I. I see. It's very good point about. I like this, uh, detail about project plan and when, whenever it's very detailed, it's actually makes things more complicated because nothing ever goes according to the plan and.

Adin Herrich: Yeah, exactly. I like your mini MVPs, if I may call it in my own words. Right, so you, you have the target, what you want to get right, not the line. But I like the mini mvp, so. So I I try actually to use it also in my team as much as possible. You know, I think that the easiest example is like, um, you know, if we all are, you know, take a piece of paper and draw a horse. Everybody will draw a horse. Some one will look to the left, one will look to the right, one will look to you. Right. So I just want to compare that to, to a product as well. Right. Or an MVP that maybe the person actually talking about the mvp, M means M actually completely something different than actually what you have in mind. Right. So I think these small mini MVPs and I'm going to steal that kind of a thing as I'm going to use it in my team is definitely good from agile perspective. So Wes, to go into projects, adding more to dos, hiring comes also into the place. Right. And sometimes hiring is being done under pressure. Do you have any frameworks for yourself and your team to make sure that, you know, when hiring under pressure, you don't lower the bar to just a federal role, for example?

Wes Ezzeddine: Yeah, yeah, exactly, exactly. And when you're within a small organization, every single time you're hiring, it's always hiring under pressure. So it's kind of like the constant of mamo. Whenever we're about to hire for a new role, it's kind of like a requirement to, to, to move fast. And I like that you use the term raise the bar because this is kind of like our main point that we look at when we look at a person holistically and say we want to make a decision as a yes or a no. The most important question that we say, when this person joins the organization, are they going to raise the bar? Are they going to improve our average and how we, we work? And this is something that's important because with every new hire, we want to become better as an organization and not stay the same and not become a little bit less efficient and less effective than we were. So there are a few things that we look at, especially when it comes to culture fit, their ability to work with the team, their ability to work remotely, are they technically strong if we're hiring for a technical person, and whether they have the right skill sets that we're currently missing. Because sometimes they. The definition of a role is not the same in every organization. So what we normally do is the most important thing is move fast. And this means that we have everybody on board. We have approximately about five different stages. So there's the initial culture of fit, then there's a, uh, technical test, and then there's some Technical interview, hiring manager interview, and then meet the team. These are usually the five steps. And when we meet a person that we like, usually these five steps are done within a week. And when I'm hiring, my entire week just becomes about interviewing people. So I jump in and do the initial interview of the culture fit so that I help the HR team that we can move a lot faster. And this means that when we spot somebody who's. Who's good that we like who's a good fit. Because at the end of the day, we're not saying, oh, this person is good and this person is bad. Like, this is not what we're doing. What we're trying to say is that is this person's skill sets and what they're looking for aligned with what Mamo is looking for, and if the alignment is there, then this is the perfect hire. It's not about, like, we're not trying to assess whether this person is a good person or bad person. It's literally about the fit. And when you get the right fit, then this person, one, they're going to be able to enjoy the work that they're doing, they're going to grow within the organization, they're going to be able to deliver, and Mamo will see, will see the impact. So the most important thing for us is moving fast. And a lot of these are predefined in terms of what we're doing. And there are some interesting things that we look at, and one really important one that we found, which is usually neglected, like, obviously, everything else is there. Uh, the culture of fit, their ability to work remotely, their ability to deliver, their ability to innovate, how they look at quality, how do they assess quality versus speed, et cetera, all those kind of things. But there's one really important factor that may seem irrelevant, but is extremely important for that person when they join Mamo is their ability to receive feedback. It's a very simple one, but it has been proven time and time over again. That is an extremely important one because it just means that when this person comes in and you give them feedback, do they receive it well, do they incorporate it, and are they growing within the organization? And as simple as it is, it's extremely crucial and we found it to be important. Any hires that we have.

Adin Herrich: Interesting. Wes, could you maybe share some insights or some questions you do to basically assess if a person is open to receiving feedback? Asking, are you open to receive feedback?

Wes Ezzeddine: No. Usually the way it works is there are a bunch of questions that I look at and they're usually following the situations. Actions, result format when it comes to giving an answer. Something similar to it is called the uh, star format of answering that question. And maybe you say give me time when you receive constructive feedback and how did you proceed and what is expected in this case not to receive a general high level answer, Say oh, I would do this. No, I'm looking for a concrete example where somebody within that person's team came and said, hey, uh, you did this. It didn't work really well. This is what it caused and what that person did, how did they receive it and the actions that they took as a result of that feedback that they were given and then what was the outcome afterwards? Ah, maybe long term, maybe short term. Uh, or sometimes it's give me a time when you've helped one of your teammates to become better at what they do and this is them providing feedback to other people. So these are standard questions that I usually ask. I think this means that I have to go and revise these questions for anybody who hears uh, this recording and I'm about to interview them. But it's something along these lines.

Adin Herrich: I would say the person is very well prepared if they listen to this podcast and they say I listened actually to the question. So we'll give that an extra bonus point to the candidate. All right, good. Thanks a lot for that. Maybe just a quick follow up question on that was I think many people are interested into spotting red flags during, during the interview process. Could you give maybe just a few tips on, on that one as well? How, how you do it of course inside your team or, or just in the hiring process.

Katya Savenkova: Yeah.

Wes Ezzeddine: Yeah, interesting. I think when it comes to red flags, uh, feedback, I did mention it as one somebody who doesn't have a lot of experience working remotely. This may cause a lot of issues later on when you bring them into the team. Obviously I don't want to talk about technical skill sets, etc. But it also depends on the role. So if somebody is going into a managerial role, I expect them to be really good at understanding product and working with the product team, being able to do project management and being able to manage people and having the technical skill sets as well. Other hidden kind of like skill set and it's more on the personal level rather than on a professional level. And this is related to procrastination and these are kind of like small things like the, the one that is related to feedback, the one that is related to procrastination. These are uh, extremely important when it comes to being able to deliver work and being able to deliver tasks that you find to be difficult or tasks that you don't want to do. Because we all know as part of our job we have certain things that we really enjoy doing and certain things that we don't like to do. But the job comes as a whole package. We can pick and choose and say I only want to do the things that I like to do. And understanding how people approach this in their personal and day to day life helps us also know what they're going to be doing in their career and in their professional day. And if I get an answer where a person says I have five tasks and there are three that I really like and two that I don't like and I will start with the two that I don't like first and then leave the three that I like till the end and they pass interview. Yeah, uh, uh, not regardless of the other.

Adin Herrich: I wanted to say I do it like that actually.

Wes Ezzeddine: No way.

Adin Herrich: I, I used to, I used to be the other way around and then, and then I found out I actually don't like doing end of the day things that I don't like to do. So, so that, that was my, that was my you know, happening moment I would say. And, and I changed it to just you know, you know, if you hate running, go run first and then do everything then you know, later on so to say. Right. Because you're thinking the whole day on that thing that you don't like. Right. And it's, it's deviating you from actually doing the things that you also like. That. That's my just own personal story.

Katya Savenkova: Right.

Adin Herrich: But yeah, it's, it's a good answer. I think, I think uh, I relate to it at least.

Katya Savenkova: I would also add me. I would also add uh, this like you know, very obvious thing but coming on time to the interviews it's. Or not or coming late. And yeah, I'm not the most punctual person that's need m to. I'm not very good at managing time. But if you have an important call, if you cannot show up, especially in remotely, especially online, on time, on the call for your interview, it's, it's a red flag or not giving the heads up that you are not coming on time. We have lots of other interviews at Sphere and many people uh, like and I'm still surprised how often people don't come on time or come like five minutes, even 10 minutes late and don't give the heads up.

Adin Herrich: Yes, definitely. All right. I think we touched also a Little bit on this, but I would like to know maybe really on the, on the left I have the in house things that I can do and on the right I have the external things that I can do. So just also for our audience maybe just to understand how you think at uh, uh, Mama pay, of course. So from your perspective, you know, what kind of roles or projects you know, do you base on external talent delivery partners like Sphere and which ones are you always saying this is for in house projects? Just to have a little bit of that comparison. What kind of projects that are left and right?

Wes Ezzeddine: Yeah, it's kind of like as you said, it's something that we had touched on in the previous question. But maybe to summarize, anything that is strategically important to maml. So for example anything that is payments related, anything that is directly touching the main code, especially when it's not a short term deliverable, anything that we will need in the long term, not just something that's for example a QA hire or at least the first or second QA hire. All of these will be internal. But let's say uh, we have a project that we're working on that will require more resources for us to be able to deliver it on time. Then we want to augment the team that we have, ah, already and just kind of like maybe bring in additional backend engineers, front end engineers, etc. Or maybe like a QA person to help with uh, testing or writing the automated test. But also when it comes to expertise that we don't have internally and expertise that we do not necessarily need to have because we will not be doing these on a regular basis. So the plugins example is a specific example. That's something that is like quite accurate and something that we do today. Anything that has to do with building these plugins is all done, is outsourced.

Adin Herrich: Mhm. All right, thanks a lot Katya. I would love to also know your perspective on this one. So you have led a lot of blended teams with both internal staff and external consultants. So what patterns do you see in successful collaborations and what sometimes goes also wrong?

Katya Savenkova: Well, I don't want to repeat myself about you know, wood onboarding and double in the details, but what I also see that in many situations, well, uh, in most cases the negotiations about the contract, negotiations about getting external team in are done on a C level. Right. And we know, we all know that from sea level positions the you, you see the things differently than when you see it from the project level. And the things that were discussed or explained during the negotiation and the first, like, stage of onboarding team can be very different from what, how the things really work on the lower level. So I think that's very important prior to start the project. Like, maybe like the initial step of onboarding is to talk to people who are really involved into the project and to understand how things work. It can be like, you know, the list of tools that are normally used in the company. Uh, the. I don't know, the. Yeah. Who. Who is doing what? Who is the person you need to give the heads up that you are out of office or you got a sick leave. These small things. Again, this. It's very good to discuss them and, uh, to agree before the project starts.

Adin Herrich: All right. Okay. So it's again, definitely communication, right?

Katya Savenkova: Communication. And. Yeah, and to manage the expectations.

Adin Herrich: Yeah, definitely. Yeah, I can definitely understand that point. And I think, whereas I guess in smaller organizations, you know, you. You see, of course, a bigger overhead, but I. I imagine that, you know, when you have teams 50 plus in tech, that, of course, you know, things can get a little bit lost in translations between, you know, what we actually need and. And what the person on the top is writing from. Contractual point of view. Right. So. So I understand, I think, at the very front coming from. If you want to comment on that, please go ahead.

Wes Ezzeddine: Uh, completely agree, Completely agree. I like how communication keeps on coming up because it's such a soft skill that is extremely important when it comes to managing projects and ensuring that the right work is being done and the work is delivered on time and that expectations are clearly defined and everybody's on the same page. So communication cannot be underestimated.

Adin Herrich: Yes. And I think it's the number one reason why actually you get in those uncomfy meetings, you know, because there is just expectation and there was a communication mismatch, I think, in my opinion. So. So it's not about the skills. It's not about, you know, the work that can be delivered. It's. It's more about the communication between. Definitely. Cool. I mean, I need to think about the title for the podcast, so communication maybe is the keyword here. All right, so, uh, let's go to one of those closing questions. I think, Wes, we're running a little bit out of time here. So when you distribute work across internal, external teams, so how do you set up accountability so that the ownership is clear and quality doesn't slip? And I think we just talked a little bit about the keyboard.

Wes Ezzeddine: Yeah, yeah, yeah, exactly, exactly. So I'll maybe try to kind of like, summarize this. I would say accountability, ownership, clear deliverables, a way to track systems, clear timelines. How are you going to be testing it? What are the metrics that you're going to be measuring? When you're looking at testing, how are you going to be monitoring? All of these are extremely important. It's defining what needs to be done and who's doing what and who's responsible for every single deliverable at every single stage is extremely important because we've run into this several times where you get to a point and many people think that a person is doing a particular task. For example, let's say when it comes to coming up with the, uh, deployment plan and the delivery plan and how we're going to go live, that person is not aware that they are actually the ones who are going to be working on that, or somebody thinks that somebody else is doing it. So clearly specifying who's doing what and when this is about to be done and having these documented is extremely important to ensure that this is defined from the get go. You know that you were responsible for this, you knew that you had to get this done in time. And this means that everybody knows what they're working towards. And also iterating over this, because sometimes it's not enough to say it. Once we get into a meeting, and we've all been in those kind of meetings where there's quite a lot being dumped in a meeting, where it's very difficult for a person to comprehend all of this, especially for somebody who's seen a project for the very first time. So saying it in a meeting, having it documented, having it being shared, iterating over the plan, making sure that you're catching up on this plan and where we are, all of these are extremely important to ensure that every person knows what they're doing and they're held accountable and responsible for what is being delivered. And quality is not something that needs to be done at the end. It's not like, oh, uh, now we're done, let's do testing though. What we like to do at MAMLU is we involve QA from the very beginning, from the grooming session. So QA comes in and says, okay, this is what we're trying to build. And they kind of come in and give their own opinion. They wear their QA hat and they say, well, well, have we thought about this? What about this edge case, what is going to happen here, et cetera and all those kind of things. And then what happens is that when we create the deliverables we also create tasks for the QA to start from the beginning because the requirements are clear, the tech, uh, discovery is being done, the tech documentation is done, the payloads and the APIs are defined. So the QA can go and start the work. They can build their end to end test, they can build their integration tests, et cetera. And then what happens is that when we're ready to deliver, the QA is ready, the scenarios are defined, the tests are all in place and they have to run them, iterate over them a few times to fix a few things and then we're ready to go. This means that we start thinking about quality from the very beginning and it's not an afterthought.

Adin Herrich: Nice, nice. So Katya, I would love to also understand from the, from the delivery side, you know, how do you ensure that external talent is integrated as smooth as possible into existing organization and teams and you know, the accountability, as Wes said, is also set.

Katya Savenkova: Well, the first step is to meet with a client, uh, with a company and to make as many questions as possible to understand not only the project but also the company size, the structure, the organization, how things work. Because it's like, you know, it's a little bit like, like dating. The more information you have, like the better the probably the better you understand if it's the right match or not. So yeah, this is the uh, first step and the next, the second step to do basically the same thing with the uh, with the consult the consultant. Right. To see we have a huge pool of developers of consultants and to talk to them and first to share the information about the project and to ask the right questions and to understand not only from technical. Right. I'm skipping the technical part because it's obvious and it's relatively, I think it's. From my perspective it's easier to check the technical part and uh, how the person is experienced technically then to understand the cultural feeds and uh, the communication skills and so on. So yeah, so basically you need to ensure that the team who is going to the project is pre vetted and knows what to expect and the client, well, the company as well.

Adin Herrich: All right. Okay. So there is definitely a matching M going on. So to say, if I may stay with them with the dating keywords to say. Right. All right, good, good. All right, thanks for that insight as well. And to close off Wes, same last question as in the first episode, you know, who do you think from your network we should get on the sphere? Castle, do our best to get on this fieldcast

Wes Ezzeddine: and engineering I would say, uh, and I don't think you've had that person on Anton Gotcha would be the. The right person to. To bring on this. And yeah, Anton would be.

Adin Herrich: Would be great. He's.

Wes Ezzeddine: He's got incredible experience managing teams of. Of various sizes.

Adin Herrich: Well, I will definitely go and reach out to Antonio and definitely talk about some interesting topics. Definitely. All right, good. Wes, I would like to thank you for the second time. Thank you for taking time out of your day, joining us here for almost an hour and sharing really insightful information. I hope the audience will enjoy it. And Katya, thank you also for taking the time out for joining us here with vez. And I would say thanks very much. And who knows, maybe we see each other a third time, right?

Wes Ezzeddine: Uh, maybe.

Adin Herrich: Maybe.

Wes Ezzeddine: Katya, pleasure meeting you. Aiden, thank you very much for hosting me. Really appreciate it.

Adin Herrich: You're welcome. You're welcome. Till next time.