Episode 46: Internal vs. External: Finding the Right Balance When Scaling Tech Teams – Wes Ezzeddine

Welcome to another episode of SphereCast, Sphere's biweekly conversation with entrepreneurs, business, and tech leaders. I'm your host, Adin Heric, 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, our Director of Talent Delivery and COO at Sphere. Katya 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 are welcoming back our returning guest, Wes Ezzeddine, 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. 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?

Adin, great to see you again and thank you for having me. My name is Wes. I'm the Director of Engineering at Mamo. I've been with Mamo for about four, 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.

All right. Thanks a lot for the quick intro, Wes.

And we have, of course, also Katya Savenkova, my co-host. So Katya, please go ahead and introduce yourself as well.

Hi, everybody. Thanks for having me here. I'm Katya. I'm Director of Operations at Sphere. I have been working here for quite some time, 12 years. And I'm also I also manage talent delivery practice at Sphere, and yeah, basically that's basically it.

All right. Thank Thank you, Katya, as well.

So let's let's dive in it, right? It's it's going to be exciting, I think, podcast about everything related to scaling and teams.

So Wes, let's start 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 or hiring in general?

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, 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 here. We might want to do like a skills assessment gap. Do we want to take a look at the tools that we're currently using? We want to see do we have the most efficient processes in place. We want to see what the org structure is is like, and and decide like are we optimizing for quality? Are we optimizing for speed? Are we optimizing for resilience? Are we optimizing for output? And and based on what we really want to do within the organization, this is kind of like 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 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 you're missing these certain skill sets, then you kind of like figure out like what do I want to do with it.

Do you are you looking at tools? Do you have the best tools in place? Are we using the tools that would allow you to ship fast, to to grow quickly? Are the tools like the most efficient? Like we've had something come up with the with the finance team, maybe less on the engineering side, but it's kind of related to to data, where they needed to optimize how they're doing certain calculations when it comes to businesses that were onboarding on to Mamo. And one of the guys who's really into coding, SQL, etc., came up with a tool and said, "Hey, I've used Alteryx in the past. It's excellent. It will allow us to reduce the work that we have to do within a day to an hour or so." And then we said, "Oh, but we have like a data engineer. Why don't you talk to the data engineer?" And then we looked at it, we realized, no, Alteryx is the perfect tool for this.

And I don't want to go into talking about AI and how you can potentially use AI to upskill these today. AI is has has a lot of use cases, especially within within the engineering team.

Do we have the most efficient processes? I would talk about agile, I would 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 we're moving at.

So once once we have this assessment done, then we can kind of like re- decide what do we want to do. Okay, do we want to go ahead and and hire that QA person because the team is spending like quite a lot 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, etc.? And then we really need to go and and get that person to to join to join the team. What kind of projects do we have? What kind of projects are we looking to implement in the next a while? So all of these are are quite important to consider before we go ahead and we decide what how we want to scale and what are we going to do 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 people, if if that person is missing, you will definitely move faster. Like if you're missing a QA, bringing in a QA is is excellent. It's going to allow you to improve your quality, the features that are being delivered, etc. But if you're not missing that person and you want to maybe add like more back-end 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 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 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?

All right. Thanks a lot Thanks a lot for your analysis there and and how you do it at Mamo Pay. So when when new initiatives come come by, of course, you know, how do you decide in your analyses if you would go for an in-house, you know, recruitment or an external hire, for example? And in which cases, for example, would you would you choose A or B?

Yeah. Yeah, it's it's a question that kind of like comes up on on on a regular basis, especially when you're working on on new projects. And and there's usually like a few things that that you need to assess, and I have two examples within Mamo where we've had to do either. One of them is building an AI chatbot within WhatsApp, and the other one is building plug-ins for WooCommerce, PrestaShop, Magento, Shopify, etc., 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 that is very similar to what other organizations have? Do we do we have the right skill sets internally for developing this particular feature or getting this 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 not the way to 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 projects? Is this an isolated task, etc., all those kind of things.

So when we're building an AI 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, etc. And naturally, it it felt that the easiest way to add this chatbot to Mamo 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 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 organizations, whether it's for support, whether it's something within the dashboard. So this one was was a no-brainer for us to kind of like say, "Yes, we want to develop this skill set 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?" etc., all those kind of things.

But when it came to building plug-ins for WooCommerce, PrestaShop, these features this this particular offering is not something that we will be iterating over on a regular basis. Like, 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's missing, or there's a new version that is being released of of WooCommerce, or we have to 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 is not worthy of our time.

So the best thing to do is to actually go go outside and say, "Hey, who's the best person, organization that can come in and help Mamo build these plug-ins?" And if there's one organization that can do WooCommerce, PrestaShop, 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 or improvements."

Right. Thanks Thanks for that insights, Wes, of course. So Katya, you have worked with, of course, dozens of clients on exactly exactly this decision, right? So from your experience, what are the most common mistakes companies make when choosing between, you know, internal hires and external support?

Well, first of all, I think it's taking it as a black and white. Like you 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's really depends on the project, right? So it doesn't make sense to hire anybody 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 like very very good team, they still need some part of onboarding, and the company needs to to provide it. And the better onboarding is done, the the easier things will will go.

So yeah. Basically, I think that's the the main the main thing. So, and when I'm talking about this, it's more like, you know, small details like who to make sure that everybody has access, to make sure that we are aligned we are aligned on our working hours or communication hours, right? To make sure that I don't know, the external team has access to Slack and is is aware that they need to answer and check their messages there.

So these are small things which kind of look like, you know, not important, but I saw so many situations when the collaboration didn't go well just because of this these details. So I think, and we at Sphere, we pay a lot of attention to to onboarding and also cultural fit, of course, and like, you know, so to make sure to that the the team the external consultants are the are the right fit for the company.

Mhm. All right. So I see I saw a lot of nodding from Wes and especially in 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 what Katya was saying.

Yeah, definitely. Definitely, she's she's spot on with with a lot of the points. And clarity before the project begins is is extremely important. And as as Katya mentioned, like access to Slack, having the right permissions, and knowing when they're online and when they're offline. Deciding like giving clear requirements beforehand is extremely important because it defines the scope of the project, the team understands what 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 a question and saying, "Oh, for this particular payload, you just have to add a flag, and then it's done." Sometimes, it requires us to go and do an implementation internally, and this is something that we recently came across when we're building our our Shopify. There's we went ahead and we said like, "This is These are the requirements. We're not clear about what is required from us to make this update that we're looking to do." And then the team went the 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 were like, "Okay, we need to do a development that doesn't just require on us that doesn't have just a a requirement on us, but a requirement on an external partner that we have." So we had 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 of work, and for a a consulting company that is helping out 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 on their end and and then figure out like when to bring the developers back on to 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 are you going to communicate, how is it going to be delivered, etc., all of those kind of things, make it a lot easier to work with somebody who's who's external.

Yeah. Great. Great Katya, please.

I wanted to mention that what Wes mentioned is super super important, clear for everybody, clear goals and clear expectations on 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 in many situations, when if we're talking about mistakes, right, the the external team comes and is not sure what they need to do. So this is important.

All right. Yeah. So communication, alignment, I would say, and 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 culture, 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

Yeah, they cannot know everything about the company.

All right. I think you to transition to to my next question, maybe, Wes, you 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?

Yeah. This is This is probably one of those hidden 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 Mamo, we're we're really good when it comes to delivering 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 an EM level or at that level who has a lot of experience doing project management, but somebody who's an engineer who has an their own initiative to actually deliver that, we noticed that there's there's a bit of a gap here.

And when it comes to project management, it's it's also about the flow, not just about the project, the scope, the deliverable, the timelines, etc., but also the the flow within the team who's actually delivering that that particular project. So when you're looking at a 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 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, then 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 like whether the scope is negotiable or or what is it 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 to be as part of the scene?" So for example, we recently did a front-end migration and this mean meant that we have to get people from different squads who have different road maps 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 like 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 we 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 the quarter, etc., and and figure out like how these people are going to get together.

Decide on what the deliverables, because you kind of set them apart and you said, "Okay, this is the scope," breaking these into smaller tickets, doing your essays, and setting a target date. Like a target date is is important, and I and 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 friendly as 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 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 we going to monitor what you're about to release, how are we 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 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 to alter the plan.

Mhm. I see myself and I see Katya nodding. Katya, do you want to add something on this topic because I think it sounds familiar or

Well, I think Wes covered. And yeah, and I I see it's very good point about I like this 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 yeah.

Exactly. I like I like your mini MVPs, if I may call it, in my own words, right? So you you have that target what you want to get, right? Not the deadline, but I 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 the the easiest example is like, you know, if we all are, you know, take a piece of paper and draw a a horse, everybody will draw a horse. Some one will look 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 talk talking about and to me, means actually completely something different than actually what you have in mind, right? So, so I think I think the 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 is definitely good from from an agile perspective.

So Wes, to go into 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 to make sure that, you know, when hiring under pressure you don't lower the bar to just to fill a role, for example?

Yeah. Yeah, exactly. Exactly. And and and when you're within a small organization, every single time you're hiring, it's always hiring under pressure. It's kind of like the the constant at Mamo whenever we're about to hire for a new role. It's kind of like a requirement to to to move fast. And 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 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 than we were. So there are like a few things that we look at, especially when it comes to like 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 kind of they have the right skill sets that we're currently missing, because sometimes the definition of a role is not the same in in every organization.

So what we what we normally do is the most important thing is is move fast, and this means that like we have everybody on board. We have approximately about five different stages, so there's the initial culture fit, then there's a technical test, and then there's some technical interview, the hiring manager interview, and then meet the team. Like these are usually the 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 that person 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 is a good person or a 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 the impact. So the most important thing for us is is moving fast, and a lot of these are predefined in terms of of what we're doing.

And there are there are some some interesting things that that we look at, and one really important one that we've found, which is usually neglected, like obviously like everything else is there, yeah, the culture 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, etc., 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 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 as simple as it is, it's extremely crucial and we've found it to be important in any any hires that we have.

Yeah. Interesting. Wes, could you maybe share some some insights or some questions you do to to to basically assess if a person is open to receiving feedback, asking, "Are you open to receive feedback?"

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 what is called the STAR format of answering that question. And and maybe you say, "Give me a time when you received constructive feedback and how did you proceed?" And what is expected in this case to not to get 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, 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 that feedback that they were given, and then what was the outcome afterwards, maybe long term, maybe short term, yeah? 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 that I usually ask. I think this this means that I have to go and revise these questions for anybody who hears this this recording and I'm about to interview them, but it's something along along these lines, yeah.

I would say the person is very well prepared if they if they listen to this podcast, and they they say, "I listened actually to the question."

So I will give that an extra bonus point to the candidate.

All right. Good. Thank Thanks a lot for that. Maybe just a quick follow-up question on that, Wes. I think many people are interested into 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?

Yeah. Yeah, interesting. I think when it comes to red flags, feedback, I'd I'd mentioned it as as one. Somebody who doesn't have a lot of experience working remotely, this may cause a lot of issues later on when you when you bring them into the the team. Obviously, I don't want to talk about technical skill sets, etc., but it also depends on 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 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 these are kind of like small things like the the the one that is related to feedback, the one that is related to procrastination. Like these are 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 like 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't pick and choose and say, "I only want to do the things that I 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 in their career and in their professional professional day. And if I get an answer where a person says, "I have five tasks and there's there's like 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," then they pass the interview.

Yeah. I I I wanted to say I do it like that actually.

No way.

Hired.

I 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, epiphany 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. But that's my just own own personal story, right? But yeah, it's a it's a good answer, I think. I think I relate to it at least.

All right.

I would also add if I may, I would also add 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 so I'm not very good at managing time, but if you have an important call, if you cannot show up, especially remotely, especially online, on time on the call for your interview, it's a it's a red flag. Or, not giving the heads-up that you are not coming on time.

We have a lot a lot of interviews at Sphere, and many people 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.

Yes, true, 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 at Mamo Pay, of course, Wes. 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 of that comparison, what kind of projects that that are left and right?

Yeah. Yeah, very it's kind of like as you said, it's something that we had touched on in the in the previous question, but maybe to to summarize, anything that is strategically important to to Mamo, so for example anything that is payments related, anything that is directly touching the the main code, especially when it's not a short-term deliverable, anything that we will need in the in the long term, not just like something that is like strategic, like for example a QA a QA hire, or at least like the first or second QA hire, like all of these will be will be internal.

But let's say 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'd want to kind of like augment the the team that we have already and just kind of like maybe bring in additional back-end engineers, front-end engineers, etc., or maybe like a QA person to help with testing or writing the the automated tests. 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 the plug-ins example is a is an is a is a specific example, it's something that is like quite accurate and something that we do today. Anything that has to do with building these plug-ins is is all done is outsourced.

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

Well, I don't want to repeat myself about, you know, good onboarding and double in the details, but what I also see that in many situations, 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 C-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, 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, this small things.

Yeah, this it's very good to to this to to discuss them and to agree before the project starts.

All right. Okay. So it's again it's again definitely communication, right? So, yeah.

Yeah, it's all about communication and, yeah, and they're to manage the expectations.

Yeah, definitely. Yeah, I I I can definitely understand understand that point, and I think Wes, I guess in smaller organizations, you know, you 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 Katya very from coming from.

Wes, if you want to comment on that, please go ahead. If not, then

No, I completely completely agree, completely agree. And and I like how communication keeps on coming up because it's it's such 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.

Yes, and I think it's the number one reason why actually you get into 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 I mean I need to I need to think about the title for the podcast. So communication maybe is the is the keyword here.

All right. So let's go to to one of those closing questions, I think, Wes. We're running a little bit out of time here. So when you're 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 keywords, I think.

Yeah. Yeah, yeah, exactly, exactly. So I'll 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, like all of these are 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 we've ran 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 the 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 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. Like we get into a meeting, and we've all been in those kind of meetings where it's there's quite a lot being dumped in a meeting where it's very difficult to 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 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 are extremely important to ensure that every person knows what they're doing and they're held accountable and responsible for what is what is being delivered.

And quality is not something that needs to be done at the end. It's not like, "Oh, now we're done. Let's do testing." No. What we like to do at Mamo is we involve QA from the very beginning, from the 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, have we thought about this? What about this edge case? What is going to happen here?" etc., 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 discovery has been 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 tests, they can build their integration tests, etc. 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 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.

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 it's integrated as smooth as possible into existing organization and teams, you know, that the the the accountability, as as Wes said, is also set?

Well, the first step is to meet with the client, with the company, and to make as many questions as possible to understand not only the project, but also the company size, who the 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 and the better you understand if it's the right match or not.

So yeah, this is the first step, and the next the second step to do basically the same thing with the 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 to understand to understand not only from technical, right? I'm skipping the technical part because because it's obvious, and it's relatively I think it's from my perspective, it's easier to check the technical part and how how the person is experienced technically than to understand the cultural fit and the the communication skills, and so on.

So yeah, so basically the you need to ensure that the the team who is going to to the project is pre-vetted and and knows what what to what to expect, and the the the client, well, the company as well.

All right. Okay. So there is definitely a match matching going on, so to say, if I may say with a with a dating keyword, so to say, right? All right. Yeah, good. Good. All right. Thank Thanks for that insight as well.

And to close off, Wes, same last question as as in the first episode, you know, who do you think from your network we should get on the SphereCast or do our best to get on the SphereCast?

In engineering, I would say, and I don't think you've had that person on, Anton Galtsev would be the the right person to to bring on on this. And yeah, Anton would be would be great. He's he's had incredible experience managing teams of of various sizes.

Well, I will definitely go and reach out to Anton and 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 taking time out of your day, joining us here for almost an hour, and and sharing really insightful information. I hope the audience will enjoy it. And Kat Katya, thank you also, you know, for taking the time out for for joining us here with Wes.

And I would say, thanks very much, and who knows, maybe we see each other a third time, Wes, right?

Maybe, maybe. Katya, pleasure meeting you. Adin, thank you very much for hosting me. Really appreciate it.

You're welcome. You're welcome. Till next time.