Offshoring in Software Development
0:00 Topic Intro: Offshoring
0:28 Cost of Labor
3:06 Not So Pure Cost
5:31 Product Quality
9:08 Larger Talent Pool
12:16 Replacing Employees (Attribution)
13:50 Time Zones (24/7 Development)
19:36 Irreconcilable Time Zone Differences
21:37 Less Support Staff
24:30 Missionaries, Not Mercenaries
25:52 Collaboration & Culture
31:19 Partners
33:31 Real Perspectives on Hiring Mercenaries
38:03 Counterpoint (Shoe Store Example)
41:52 Wrap-Up
42:40 Being "Southern"
= = = = = = = = = = = =
Watch it on YouTube
Please Subscribe to our YouTube Channel
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Google Podcasts:
https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcw
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Our episode today is about offshoring., do you deal with offshoring in your company? I think it's a normal part of software development. If you're going into software development in any way, shape, or form, you're going to deal with offshoring. Yeah. So, that's what this episode is all about. We're going to talk about the pros and cons of offshoring. We're going to talk through our experiences. I don't know if there's going to be a lot of, what the book says on this one. I don't think there is a book on this one. I'm sure there's a book, somebody's written something, but we're not gonna argue. Maybe we should buy it. Buy our book. Yeah, buy our book. That's right. Yeah. So let's, let's dive into this, right? Everybody, I'm sure has heard of it at least, or if not have experienced it off. Why offshore offshoring? I mean, let's get the easy stuff out. Let's get the low hanging fruit out of the way you ever heard of the loom. Yeah. Yeah. That's a phrase that I don't hear too often. Yeah. Low hanging, low hanging fruit, cost savings, having employees in house is high costs. And, sending your employees to the, Spice Spice Mines of Kessel is low cost. that's what I... That, that's typically where most people start, right? Typically. It's cheaper to outsource your work. Right. Yeah, yeah, I agree. But then, let's, offshoring has been around for a while. That's nothing new. So has it still proved out that it is proven, proven, proven, that it is cheaper today or, are we looking at, diminishing returns here? Well, we, we, we did an exhaustive, 30 second search of the internet. Oh, is it that long? Wow. I'm tired. Oh boy. And, we found a code submit that I, Oh, the most trusted source. in sports. I don't know. And so it gives the average salary. I think these I think these average salaries of software engineers is I think this list is a bit dated. Yeah, the numbers suggest that I think so. But But I mean, it does like if you compare them to each other, right? I think they'll probably be close to normal. It gives, a high list of numbers. And at the very bottom of the list, it gives a low end of the numbers. So at the high end of the numbers are the United States, Switzerland, Israel, Denmark, Canada. Now those are the top five. At between 110 all the way down to 61 000 i'm assuming these are adjusted for US Dollars. Yeah, they are and we should mention that these are average average. Yeah, right Which is interesting. Anyway, like if you go further down to the low end of the spectrum here, It goes low. Yeah, it goes pretty low with the lowest, I mean the bottom five are South Africa, Brazil, Philippines, India, and Nigeria. Which I didn't expect. You know, it's kind of surprising to me. The low end is, is, the low end is lower than I expected it would be. Yeah. You know, compared to where we start. So it's 110 and the low end is like 7 something. Yeah. Yeah, which I didn't expect to be that low. I don't even know what I expected. It wasn't that low in my mind, but that's what they're saying. So, okay, we'll go with that. These are, I mean, these are just pure costs. Like in the pure cost is nothing about, the tactical expertise of the, of the people and nothing about the, the, the communication skill and a million other things that we're going to go into. So just averages, I kind of, I kind of feel the cost is, is, what normally people will point out to kind of defend offshoring pure cost, but like pure costs is like, it's the tiniest fraction of what you can control in this category. What, what you saw on that list, it would be the cost of an employee in that country. It's not going through a staffing firm or a contract firm or whatever because a contract firm has to make money. And they're going to charge, like in my experience, a contract firm is going to charge a minimum of a 50%. 50% meaning 100%, 100% of what you pay. They're going to charge a minimum of 50% up charge. So if you're paying 25, 000 for a developer in Ukraine or somewhere. They're going to bill you for 50, 000. Okay. And that, that is assuming they're going with a 50% margin, which if you're again, if you're in the recruiting industry and you're listening to this podcast, so I don't know how you found us podcast, but thanks for finding us. But if you did find us and you disagree with what I'm about to say, please comment below, I've been told by recruiters that a 50% margin, basically a hundred percent, upcharge, the recruiting firm is taking 50% and the candidate is receiving 50% that is like the most skim bare deal they are willing to get into because there is very little profit from what it takes to pay all the recruiters and pay the cost of running their business and all that kind of stuff. That's the minimum they can afford. Yeah, I concur with that. It is, I mean, I've seen as high as 60, 65 in some cases. I've seen people paying three times what it would cost to hire a developer in house. To a contracted, and company management, like feeling good about it. Believe it or not, because, because they are capitalizing that labor. Right. And they think that because it's capitalized and, they, they're, it doesn't go on the budget that the employee payroll comes from that they feel good because they can spread it out and it actually looks like a lower number. Anyway, the sticker shock cost of what it costs to bring on an employee and have them in house and work directly for your company versus the offshore costs, not including any hidden costs that you pay, like I want to get past what we're talking about now because I want to get to all those hidden costs. Because the hidden costs they add up the hidden costs certainly add up because what like one of the hidden costs That I can think of immediately is, quality control with offshore developers, offshore development teams, which means you're like, you're, you're accepting that in order to speed your development by going with this team of offshore developers. You will have rework. This is the same in products sometimes in order to speed to market. I accept that I will have to come back and refactor sections of the code to do a better job later or to serve more users later. This is the same kind of deal it's like, hey, we're, we're building our teams offshore for now. They're going to turn in code that I tell them to turn in and they're going to do exactly what I tell them to do and nothing more. Sure. And even then sometimes they may miss things. I am not certain about the individual skills of every single person that the contract firm is sending me. So they could be sending me people that don't write unit tests, for example, that don't understand, listen, we talked about our own experiences. My experience is that, on paper, these guys are rock stars. I mean, they've got all the skills under the sun, right? But then when you. When you actually see the quality that comes from them, it sometimes, quite often leaves a lot to be desired. So yeah, you do suffer this risk of, suffering that, that cost of quality, rework, I mean, not going to go to market with that sub product. So now what happens is that hidden cost to your point, you've just, you've just spent. Time and a half or whatever, right? Sometimes more than that, sometimes double. So really, net, net, are you further ahead? Because remember, even if you're financially, ahead. Right. Let's just assume that for the sake of argument, you've lost time, right? And that's an opportunity cost right there. the problem with that as an opportunity cost is that Typically companies have no ability nor awareness to track that if you're engaging here, I'll try to help, I'll try to be helpful and not just bad mouth offshoring. If you're going with an offshore solution, you should track rework. Absolutely. You should be tracking re like put a tag in JIRA or whatever ALM system that you're using and track what is rework and be open with your team about like, listen, I'm not like, I'm not doing this to try to penalize everyone, anyone. I just need to help teach management that if we're going to engage in this strategy of development. Then we must understand that a certain amount of our time will be reworked and that's okay. That's okay It could be that the the cost of offshoring is justified by how much we save and Like that that's the bottom line is, if you're real early in your company, it could be that the cost is Everything and there is no other option to launch you or to scale your to whatever and that that could be a thing, but it doesn't mean you should not track that metric so that as time goes on and that number goes up and up and up and up, you can't make another decision for in the future of the company. You should track it. You definitely should track it. A big advantage that proponents of offshoring. Will proclaim is that you have access to a global pool of talent when you go with the offshoring route, as opposed to my company is based out of Tampa, Florida, and I can only hire people within 30, 40 miles of my company office. But the point is, if your, talent pool is global. It's easier to get better talent because it doesn't matter where you get the people. Yeah, I think that's true. I think it's also, companies that insist on employees being in the office. Perhaps they find it harder to find people locally. Shocking, shocking. Yeah, exactly. It doesn't just, roses just don't grow around your feet. So yeah, that's true. That is shocking. I think the other, the other thing is, If you don't have if you have plenty of people that you can pick from locally, but you don't have the specific Talent that you're looking for specific technologies, but then you're forced to look a little bit further, right? Sometimes a lot further. I mean, in the spirit of arguing agile with this category, you're planting your flag in a, in a shifting bed of sand with this category with me, because I'm looking at it saying like, well, access to talent globally, is that a reason to offshore or is that a reason to just make up your team permanently of this pool? if I was hiring permanent developers as opposed to going with contract firms. Around the globe or whatever, like what's to stop me from just sourcing talent globally myself and hiring them is permanent. Well, nothing except it will be costly for you. Yeah, but I mean, if, if, if the first category, if I had kind of gotten over the first category and I understand that, I don't want to deal with cost of delay and I don't want to deal with time zones being off and I don't, I don't want to deal with my people not being able to talk to each other and stuff like that. If, if cost was not the issue, the advantages expressed by pro offshoring advocates. Are there pro offshoring advocates? I don't even know. Anyone who's pro offshoring versus either nearshoring or onshoring, whatever. I feel if you're willing to hire. remote talent and truly have them be remote, right? I feel like you just defeated the entire advantage of this category, you just defeated by saying like, okay, I'll have a remote team too. No. So at that point, there are companies that could name them. I won't, but I could name them that. They consist of exactly these kinds of individuals. They're full time employees. They live anywhere, not only anywhere in the continental US, but anywhere in the world, but they're not hired hands in terms of like work, offshored sure. Contract folks, right. They're full time employees. They live where they live. Sure. And these companies are thriving, so I think it can work the proponents would say, yeah, but they can only work some of the time of their day. Whereas if you, if you offshore people can develop 24 seven, it's that elusive 24 seven dev cycle that was promised, in the early days of offshoring. I promise we'll go into that one next, but before we get into that category there is this other promise in offshoring about, well, if someone quits or if we have to get rid of somebody, we can quickly replace them because we have all these people on the bench. That's what I hear from offshored contract firms. Which is in reality, having, having been a part of a firm that sold contract services, I know in reality what, they really just, they run out and they try to hire somebody quickly to backfill just like any other company would. So, this is sort of like a, it's like a ghost of, well, it's, at least I, with my internal HR people and my internal recruiters, I don't have to scramble to replace a permanent employee when they quit. I can just... I can just delegate all that to somebody quote offshore who doesn't work at my company and then they, they shouldered the burden of that expense. That, that's what I hear when I hear this, this, this quote, resource attribution complaint with, offshoring, advocates. I think it's a numbers game too. They probably do have a deep bench and they can just swap out a body with another body. That might be true. Not necessarily that that's a good thing from your perspective if you're the company that's, you know. Hiring their services, but yeah, I have seen that too. To your point though, it's a substantial savings. You think about it, right? If you're a medium sized company or even, a small company, the expense to go recruit on your own is not insignificant. But you mentioned, time zones it's sold from pro offshoring advocates as listen, you can have a development team in Latin America and you can have development team in Eastern Europe and you can have a development team in the Philippines or something and you can have 24 seven code progression through your pipeline Also inside of that, 24 seven progression also is built in redundancy, where if something happens, if there's a typhoon in the Philippines and your Philippines team can't work today or whatever, then at least you have the other two teams is spread across the globe. So the offshoring is billed as a benefit in this case, because you have people constantly working in every single time zone so that 24 seven a day the trains are running that's the way it's sold. Yeah, I agree. And that's how it was sold to begin with before, people realize the cost aspects of this, let's just take advantage of the 24 hour cycle, right? The downside is when, when they first introduced that we didn't have the DR. Technology that exists today. So code had to be literally shifted. So, last thing you did as a developer before you left for the day is you put all your code into an area that FTPs it somewhere or whatever. I know that. So now, yeah, so now it's different. You know, now that there's truly a redundancy available, but let's talk about the other side of it. Do you really get the efficiencies if you want, of, three full days worth of development in a single 24 hour cycle? Does that really work that way? Because what's lost in that? What is not happening there? I mean, you've got people that need to communicate to one another as teams. You got three teams now. So you have many channels of communication here. And anything can, fall through the cracks at that point. People are developing, sure, but are they developing to a cohesive plan? Everybody bought into the same plan. Well, I don't know if this experience directly relates to what we're talking about, but I think it does. I, when I was on a very large, like a 200 something program, like a lot of people, a big program, and I was, I, I sort of played a couple of different roles, but sometimes I play the role of the, like a coordinator between teams of like this team starting something you need to start this, that kind of, that kind of stuff. And, I had a couple of Indian teams and if I wanted to be on their daily scrum at the start of their day, it was like 11 o'clock at night for me. And I told that team, no problem. It's like, you guys want to schedule a daily schedule? I'm like, I'll jump in at 11 and I'll tell you what the teams did the day previous so that you can jump straight on and not have that communication gap where you got to wait until the morning because they would, they would work like a swing shift in India, I believe. And, if you want to jump on with me, I'll tell you what the team did. That way you can, hopefully jump ahead. If they wouldn't, it takes a conscious effort to do that, doesn't it? Like you agree to work that, that shift. So it does take somebody to say, yeah, this is a problem that's worth solving and we're going to invest in it. Yeah. I needed to do something like that in order to make sure that that team was as productive as they could be otherwise that team would run into a problem with a particular story That was a high priority story and then they would have to wait until 8 a m East Coast time to engage with the product owner To engage and ask their questions of the product owner because they would say, well, we started working on this and we realized we couldn't proceed because we had a question, no matter how minor the question is. We had a question and we stopped. So we moved over to this other thing that wasn't necessarily the highest priority, but we could move forward and we kind of knew what we needed to do. But then when you give us the answer, we'll move back, we'll shift back to this other thing. And I remember that always used to drive me crazy to say like, even if you would implement the wrong thing, at least you would, at least something would be in production and I mean, I think everybody in the business would appreciate speed to market as a, just as a principle of like, if you don't understand and you have to make a guess. Make a guess one way or another and then let's get to market, let's get to prod as fast as possible. Yeah, because in this scenario It's paradoxical really because in the scenario where we're saying look, we take advantage of the 24 hour development cycle But what you're highlighting here somebody has a question they fired off. They don't work on that issue. Here stateside somebody wakes up at 8 or 7 or whatever and they give the answer That's just in time for them to be going home going. Yeah, they haven't already. Yep They worked swing shifts so I think they started, sometime in the morning on East Coast and then they finished sometime around like 11 or noon, East Coast. But suffice it to say, there's, there's every... Possibility that you actually lose time in that case. Oh, we did. We certainly did that and that and that's why I told them like hey, I will relay all the decisions that happen during my business day Like they would write up notes and they would turn in their work items And all the decisions that I would have to track down in the business day I would have for them at the start of their day And and yes, you could say well just write it down and send it over in reports But that's not the same because if I send it over a report now, they'll read my report And if I was not completely clear with what I wrote down, they might have other questions and they still might not be able to work on the ticket. It's better for me to jump on and then they can ask me questions and I can fill in contexts where maybe I was not great at writing it down or whatever. Again, the time zone thing, it's great. The idea that we have 24 seven, the train is running 24 seven. That's a great concept. However, I can think of any city I've ever been to that the trains don't do not run 24 seven. They don't run. There's a period of time where they decide like, well. There's so few people actually doing productive work, and we do have to do some things to the trains during a period of time. It would just be better to not run the trains between midnight and 5 a. m. So we're just gonna take this slice and just... Rest during that period of time. So in that example, I was kind of proxy playing the product owner role, going between teams, getting on a little bit later tonight, getting on a little bit early and stuff like that to try to be that, that glue that binds everything together. If I hadn't done that, these offshore teams probably would have You know, again, under the guise of not wanting to make a mistake because of the way that they're judged through contracts and through that, you know what I mean, through proxy kind of metrics, they would have just delayed this decision and the cost of that delay over time. Would have been huge. It would have been massive. The point of this category is the idea of, well, there, if we have somebody in different time zones, it gives us some redundancy. It gives us some risk mitigation. The trade off of that is yes, it does. But communication between teams becomes more difficult, the factor in delays and the factor in communications and not clear communications of people just talking to each other, going to scaled events, scaled planning and the fact that you're unable to do that kind of stuff. Well, you have to set up some kind of special event to do that kind of things. I don't know if it's worth it. I, I, I think, I think we can call this whole category a wash because, all the benefits kind of cancel out the cons. They cancel each other out. Yeah, yeah, I concur with that. They certainly do. The other big advantage that people will say for offshoring is that you don't need to ramp up your company with a lot of support staff. You don't need to hire a lot of HR people and recruiting staff, and you don't need a lot of, people to manage payroll and you don't need layers of mid- management and stuff like that because it's just your CTO or head of development or whatever directly asking or quote writing requirements and sending it to the offshore people and then they just build it so, so you can do a lot with. a little quote resources. And that's a valid point. I mean, if you look at just a pure numbers, the savings are real, right? Then flip side of that. So what do you lose when you do that? You're left to the devices of those companies, the offshore companies, as far as the quality of people they find, are they just finding anybody that has a pulse saying this guy is now a DBA or are they truly getting somebody who understands databases, right? But I, cause that's been my experience by the way, not wholly, but you know, somewhat where you say, well, I need somebody who can develop in this new language called parrot. And they go, we got five people that can do that. It's like, really? I just made that up, you know? So yeah. Yeah. the concern in this category of, Oh, we don't need to, we don't need to staff up to hire these people. Like the, what I hear on the other side of this is, first of all, if we get beyond Brian being sassy, like what, why do you need to ramp up all those people? Like how many of those people do you need? You don't listen. You need a, you need a minimal set, if you like, of people because you need somebody to manage the contracts, TPL type of people. Sure. Right. Third party labor type of people. Sure. Yeah. But you don't need a lot of those. They have services that, that do that. They, they do. I mean, so you pay for those. Right. I've been at more than one startup in my career. Let me put it that way. I've been part of more than one startup. And usually those startups don't have permanent HR people. They have a part time person that does both all of the HR function and all of the payroll function. And that person does both of those functions. Those very different functions as a part time employee. I've seen more than, more than two companies do it that way. Yeah, one of the small, contracting, start up company that I work for, they don't, they didn't have anybody, basically. They're a small company, about 50 people, 50, 60 people. And all of the HR, all of the payroll, everything was handled by a third party. Right. And they did a fantastic job. Yeah. Right? You pick up the phone, call them. Yeah. It was great. Yeah. Payroll, as a third party payroll, I've seen that quite a few times, actually. And if there's any problems, then you just work with them and then they, I mean, that's what they do. Basically. Yeah. These days they may as well call it payroll as a service. I mean, my, my big issue with this category is, you, you want missionaries, not mercenaries. Yes, that, that comes straight out of Marty Cagan's inspired. I'm not going to link it. But I don't know, like you'd listen, you want missionaries, not mercenaries. I mean, as your, as your company grows over time. You're going to branch out. You're going to want people that understand your culture. You're going to want people that have those strong relationships with both your customers, by the way, we haven't even talked about that yet, but with your customers that understand your business, they understand your business domain, their domain experts, as well as developers or salespeople or support staff or whatever. They know your domain. And, when you're. When you're offshoring all that, you're not, you're not keeping any of that knowledge in house. And that, that just, that seems ludicrous to me. That you would not want to keep that knowledge in house. So, so many companies though, fall foul of this, don't they? And they, they suffer, but they don't know if they're suffering, because they just short term vision is on the dollars, right? But yeah, it is causing the company harm because of that loss of domain knowledge. It's going to, how can it not cause you harm, right? It's, it's not being diluted. It's being lost. Yeah, right. It's never being gained. Right. I don't, I don't see how you, um. Can't ignore that, We already talked a little bit about. Being more difficult to communicate, being there in different time zones. Perhaps they speak different languages, that kind of thing. Like maybe it's like just purely just basic communication might be more difficult. Basic communication. But I'm now I'm talking about collaboration, like actually peering with people to write code or to write tests or to talk about requirements of the software or talk about potential architecture that we might or might not do. That's way more difficult when people are in different time, time zones. Speak different languages, have different cultures. Completely agree. I think some of that is basically underpinned by the time difference. I mean, if they're not working when you're working, how do you collaborate with them? Right. But but the, the other issues that you, you, the other topics you've raised, different language. So there's, it's not just simply, Oh yeah, everybody understands English, right? There's nuances and interpretation and how you comprehend things, right? Yeah, it could be, it could be a number of different things. Before we even get to the cultural differences. Yeah. Language. So they learn the English language, but in a different way. Like, I know that if you're dealing with folks from India. They didn't learn American English, they learned some derivation of British English, right? And certain things mean different things, even though the words are English. So there's that issue. Now let's talk about some of the cultural issues, right? So first and foremost, the underlying culture there is... Keep your head down. Do your job. Don't take risks. So from that point, I mean, we're talking earlier. How, if you're not sure about something, make a decision and move on now, they're not going to do that's not the culture. That's right. Because the reason why they're not going to do that is because that is looked down upon by their culture. Yeah. Supervisors. Yeah. Then you say, well, why'd you do that? If you weren't sure, stop. And so when they stop, it costs you another day because then they fire off the question, they wait for the answer. So that cultural aspect really is, is pretty important here. even if there were not a backdrop of a caste system at play, specific to India, Even if there were not that, I would understand if you were in a culture where making a Wrong decision was like, I've been in companies like this where making a wrong decision was 10 times worse than making no decision and just sitting around, so I understand it from that perspective, but also like, then, then you double down on the fact that, that the culture has different classes. And that's just ingrained in this, this system that you don't like as an outsider, you don't even understand. You don't need to, you just know that it's a complex ball of wax, right? I mean, nobody needs to understand it. They need to get rid of it. And I think in the bigger cities now. You're starting to see some of that, but they were a long way to go. Yeah, but I mean, the, the point is like that backdrop is still there. It is American. And like, if you're, if you're, if you're just looking at these pros and cons and your big pro is like, well, it's, it's half as half the costs cheaper, you know? And then you don't understand any of these. You, you've never been over there. You know what I mean? You've never, you've never worked with teams, where you have the one tech lead or team lead who the whole team waits on that person's opinion before they say anything. Yeah. Japanese culture is kind of the same way as well. They'll, they'll defer to the person at the head of the table and that's why some of the traditions over there is, you give your opinion starting from the youngest person at the table and then goes, goes around to the most senior person last because you, you as a senior person, you don't want to influence the conversation in any way, shape, or form. You want to hear everyone's opinion, you know? Yeah, there's the other side of it, which is, you as a junior person don't want to disrespect a senior person. And I know that in some Asian cultures, that's, that's very prevalent, right? So, so if a younger person has something valuable to contribute, they'll hold back, right? Until somebody else says something close to it, and then they'll say, oh yeah. That happens, and that happens in corporate America too. Is it like people, it may not even be a For positions and ranks, it does. Not so much for like age, right? But yeah, you're right, it does. The cultural differences is a great category. Like just people working together who do not share the regular cultural norms is a great category because people outside of software, people that might be listening to this, that are at the beginning of their career or people that have not worked on these really, really , culturally diverse teams. Throughout their career may not have been exposed to like I mean, I think in those basic concepts because I work with these other culture. I've directly observed other cultures at work Yeah, but if you're making just a purely financial decision and you haven't even thought about how these things are gonna Play into the you know into the cost They're going to, they're going to play in the cost eventually. They will for sure. I mean, people here, that you hire team members, the junior folks that you mentioned, you don't learn this stuff about culture and stuff like that in school. Nobody teach. There's no class for that. You sort of learn it by osmosis, by working in school of hard knocks and experience. So yeah, ignore it at your peril. The other thing that is worth mentioning is, if you're going offshoring, kind of the opposite of my, my whole statement about missionaries, not mercenaries, is now you're dependent on a third party, like whoever you're using for that labor in that country. You're dependent on that now, and I'm not I'm not saying you have to have a slush fund for bribery Depending on what country you're in. you're dependent on that third party labor source So whatever you need to do to keep that third party labor source going and to not disrupt your business I mean basically you have to do it. You don't have a choice now You're held hostage in many ways, actually, because you're, a lot of your domain knowledge is with another, another entity, right? Overseas. So, if they suddenly, let's say, get acquired, and they decide your business is not profitable enough for them, and they're going to drop you. Yeah, too small. Right. So then what happens, right? Or, or the other thing that, that, people that, that are working at those institutions, they leave, right? And the company doesn't do anything to retain them. All right, just go. So again, you've suffered sitting here because of those consequences over there somewhere. Right. So these dependencies are huge. What a great point. Because, people that talk about offshoring talk about being easier to replace people. And easier to scale up development efforts as a pro of offshoring. We talked about this a little bit earlier in this podcast about like, well, it's not really true of like, well, I got to go hire 10 people, so I'll just go to this firm and they have 10 people sitting on the bench. Well, they don't really have 10 people quote sitting on the bench. No, they're going to, they're going to scarper really quickly and try and find 10 people. Yeah. They're going to do the same thing that you would do if you had to hire. But hang on. Will they? Because they're possibly going to simply find 10 people that have a pulse and go, Yeah, we got these experts for you, right? As opposed to you will do the due diligence, hopefully, because you want that quality, right? So I think that that risk is always there. Because all that company is interested in doing is putting butts in seats so they can charge you. Yeah, I told the story to Om before the podcast started, like I was coupled with a development manager one time who his, his viewpoint was with the contracting firms that he was, employing. He did not want to, spend any time, training up the individuals. That he got from the contracting firm. He felt they should already be trained up, and they, the, the, the time that it took them to learn the domain knowledge, and the, the, the code specific knowledge for that company or whatever, he, he felt that that should be a minimal amount, rather than, a, a steep uphill climb, to learn their code base and stuff like that. They knew the language, so it wouldn't, it shouldn't be that hard for them to, Learn the the domain basically from the code that that thought process is not Uncommon at all, right? Yeah, we don't train contractors, right? Well, then the flip side of that is are you willing to pay more so they get trained up because someone's got to pay to Have them trained up, right? core skills like development language skills things like that ideas, whatever it is, that's one thing but But learning your domain, you better train them in that, cause they're going to come in and it's like, they're going to do sword fighting in your room with blindfolds on. Right? I remember I had come up from another contract that was a much longer term. I was there a long time and, I had come onto a contract with him and I was kind of his peer in the organization at this point they brought me in a product capacity and I was really his peer it's a small company, had a lot of managers. That were, kind of equity level managers of the organization. And, I was kind of his peer and I, and I kind of cautioned him, Hey, bringing on these people. And then kind of emphasizing that they're just kind of mercenary hired guns. This is not going to scale well for you in the long term. I mean, at some point, you as a leader in the organization, I mean, that's who you are when you're, when you work directly with a CEO and you're part of the leadership staff or whatever you want to call it. Your job now is to, like lay down the vision and extend the CEO to these other departments that maybe the CEO doesn't have technical expertise or experience in and whatnot. And that's what they need you to do. And I was like, if you just hire a staff of mercenaries, I mean the, the, the first minute that the, the mercenaries decide to turn on you, I was like, you're out. They, he's gonna blame you. He's not gonna blame the mercenaries. That's right. Yeah, somebody decides to pay those mercenaries a little more they're gone. That's exactly that's exactly right because you've not made them part of your culture. So I was like, I mean be very wary of this attitude of like well, I mean, they're you know, they're a third cheaper than Because I mean after after all said and after you pay the agency fees After you pay whatever taxes after pay whatever like how much actual savings you're getting You know, I mean, the, the tables we looked at real early, I feel were not exactly, I think they were pretty low. And I think they were old too. I think they were pretty low. I think they were a couple years out of date. I think in actuality, you can only expect to save maybe 50% of hiring an employee, permanent employee in house. And out of that 50%, how much of that money is spent in overhead costs to communicate and collaborate and to, to fill in the gaps. And then of those costs. Like, what, what, what are you left with, really? Anyway, the, the, the point of this was, that individual that I'm talking about, his, his feeling was, I want to hire people, and then, I want to give them core responsibilities of developers, where their job is just to write code. And what I tell them to write code on, and not to quote, distract them, with other activities in the business that takes their quote, hands off keyboards. We're being facetious But like that was like he he was a very experienced developer who had graduated over time to higher and higher and higher level supervisory positions Within the development domain and landed in this, in this peer level to me in product. I couldn't just discount what he was saying. It was like, yes, I understand what you're saying is like, we need hands on keyboards and, and like, I can't have these people like I'm paying these people to develop my solution and to maintain the software I have. And I don't want them spending much time chasing down people around the business and being in unproductive meetings where they're not writing code. That was his perception. Okay. Now listen, my side of the world, every bit about the domain that they. are struggling to gain expertise in, I should be helping them gain expertise. Hey, we don't understand about this part of the business. Well, let me get some users in the room that can help you accelerate and get your understanding to a much deeper level quicker. So you have to spend less time, instead of spending a half an investment. Yeah, right. So let me, let me, so. Let's say we're Brian and Om's software development company. We're in the, in the software development business of selling shoes that we, we have the best software that sells shoes online. Right? So I got to do that. I got to teach you about shoes. I gotta teach you about what shoes are for what specific type of activity. I thought these shoes were made for walking. Maybe these shoes are made for walking. Maybe they're running shoes. Maybe they're made for walking all over you. I don't know. They could be made for anything. They're all blue suede shoes. The point is, they could be blue suede shoes. How do you deal with, how do you upkeep blue suede? That's what I want to know. How do you upkeep blue suede shoes? You don't. You buy new ones. You don't. You send every customer a 10% off voucher for a new pair of blue suede shoes. The point is I got to teach my developers about the shoe business. Yes, you do. What is the typical software developer out of South Africa? Know about the shoe making business, whatever the diff of your answer is between what they know and what you, the shoe business owner, knows, you gotta fill in that gap. Right, they're not gonna, right? Someone has to fill that gap. They're not gonna do that because they're hired hands. They're gonna, they're here today, gone tomorrow. That would make a great title. Like a, a name for a barbershop. Hair today, gone tomorrow. Nevermind. Nevermind. That would make a great name for a shoe store. I was like, that's a long title for a store. My brain just... It'd be interesting. It'd be interesting. You have all these hired guns. You're not willing to teach them about the shoe business, but that's your main business. You just want to say, hey, go code what I tell you. But all they can do is the minimum of what they tell you, and they don't know if it's right or wrong. Because you're unwilling to teach them if it's right or wrong. And that was the core of my problem. That was the core of my problem. Right? In that scenario, that company can expect a high degree of refactoring because these people don't really know the business. Right. And again, that's my problem with, with the, the very first thing we started in this podcast, the bottom line of the money per hour. It takes my problem with the bottom line of the money that it takes is you can track that. That's fine. As long as you have a little rework tag in your ALM system that says this, we're doing this because. We have to rework this item that we did before because maybe we didn't know or whatever. And, and, at that point, now you're playing a bunch of, potentially, based on who raised your item and stuff like that. You could be playing a bunch of games with labels and JIRA and reporting and stuff like that. I'd, I'd just rather not be in that business. I would rather... everybody we onboard, they're part of our culture now. We want them to believe in our mission. We want them to know what the vision is. We want them to talk to our customers. anyway I react poorly to this whole like Oh, I want I want to offshore because I want to keep these people focused on the core of what I want them to do. Or I want to not distract the core of my business with all these development activities or whatever. Right. I've seen that too, but like, I don't know, I'm thinking, it's, it's very, it's a very myopic view. I think I really think it is. I really think it is. The last thing is like the feeling of direct control. Like I, I would rather not offshore so I can control people that I can see that are in the office. I would rather not offshore because I don't feel like I have control of those employees. I don't know what they're working on. I don't know if they're working. Right. I know. Again, short term thinking. Hey, anyway. Speaking of things that don't make sense, I can't believe that we went 120 plus episodes and we've never, talked in depth about offshoring. It really is surprising. You didn't mention it. Yeah, but there it is. It's out there now, right? In the interwebs soon. I know everybody listening to this has had an experience with offshoring. So I will be disappointed if you do not make a comment about your experiences with offshoring down below. I don't know what I'm doing. I guess this is typing, making typing fingers. Well, while you're doing that, make sure you subscribe and like our podcast. It will make your life a whole lot better, I think. The financial numbers told us that it will. Yeah, that's exactly it. And financials don't lie, that's what we figured out in this podcast. I remember working with a team from Central America and they're like, you're the most southern person we've ever talked to. And I was like, I, I like, I don't even, I don't even sound that Southern. Yeah. Like you're so Southern. We can barely understand you. Wow. That's hilarious.

