The Outsourcing Playbook Gets an AI Rewrite: Engineering in the Age of AI and Global Teams
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub dig deep into the real-world lessons of managing outsourced and distributed engineering teams. Drawing on decades of experience with partners in Romania, India, Syria, and Ukraine, they unpack what makes these relationships thrive, or fail.
From timezone pains and cultural mismatches to the power of long-term trust and shared context, Scott and Brad cover the spectrum of challenges leaders face when their teams span the globe. They share tips for CTOs navigating fractional teams, staff augmentation models, and agency partnerships, and reflect on how the rise of generative AI is starting to echo some of the same tensions and tradeoffs seen in outsourcing.
If you're building a product with engineers you don't see in the same room, or considering whether AI is the next evolution of outsourcing, this conversation is a must-listen.
- 00:00 Introduction: The Need for Communication in Distributed Teams
- 01:04 Challenges of Outsourcing: Pros and Cons
- 01:24 Personal Experiences with Outsourcing
- 02:00 Successful Outsourcing Strategies
- 02:35 Long-term Commitments and Time Zone Issues
- 03:33 Staff Augmentation and Agency Experiences
- 06:32 Fractional CTO Insights and Common Issues
- 19:06 The Importance of Shared Understanding
- 21:21 The Role of Product Management and Technical Leadership
- 22:24 Future of Outsourcing and AI Integration
- 23:39 Conclusion and Call to Action
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #Entrepreneurship #Leadership #Management #EngineeringLeadership #TechnologyLeadership #EngineeringManagement #GenAI #AIRevolution #AIEngineer #BuildWithAI #GenerativeAI #StartupTech #RemoteTeams #OutsourcingStrategy #DistributedEngineering #EngineeringManagement #StartupTech #FractionalCTO #TeamVelocity #EngineeringCulture #BuildWithAI #GenerativeAI #AIAndOutsourcing #GlobalTeams #TimeZoneChallenges #ScalingEngineering #TechLeadership #OffshoreEngineering #AgencyWork #Nearshoring
Brad: What we're really talking about is the need for communication and shared understanding of how a system works.
When you have people who are in different locations,
how do you get them to work together effectively?
Welcome back, everybody,
to another episode of How Many CTOs Does It Take?
And in this case, it's how many CTOs does it take to find software engineers to work with you or with us who live in another country,
as they say offshore or outsource or near shore,
all those things.
Scott: Or maybe not necessarily.
offshore but even just outside of your company like
Brad: Yeah.
Scott: agencies consulting firms right like that's the thing i want to talk about is when we as a cto or when an entrepreneur who's got an idea basically uses an outsourced firm
What are the pros and cons of that?
What are the risks of that?
Brad: I
Scott: That's what's on my mind.
Brad: have had, I would say, three experiences using outsourcing.
They are very successful,
somewhat successful,
and not successful.
Scott: Wait, I thought it was one of the possible answers, complete and utter failure.
Or is
Brad: I
Scott: that
Brad: have
Scott: under
Brad: that.
Scott: not successful?
Brad: That was under not successful. I have had the complete and utter failure a long time ago,
and I've learned along the way, but I feel like I haven't got it nailed.
And I feel like I want to learn from some people who have got it.
Let me tell you what I feel like I do have figured out.
There are a handful of, there are probably many firms out there, but I know of one that I go to, which.
essentially is a group it's almost a collective it's a group of about 20 staff level engineers and they charge like that too it's not a bargain but when I work with when I know I want something done and I want it done well those are the guys I call because I know that I'm going to get people who are not order takers but who are bringing something to the table
Scott: Yeah.
Brad: And then I've had an experience where we set up like an office in Europe,
in Eastern Europe,
maybe Central Europe.
I don't know. It was in Romania. Do they call that Eastern Europe or Central Europe?
I'm not sure,
but it was in Romania, whichever Europe that's in.
And so we,
and that was like a long-term commitment, you know, 10,
15,
20 engineers for.
a year i mean multiple years um and there were pros and cons that very talented engineers um fully you know dedicated to us like each individual was hired to be on our team so it was like they're really building a team for us um but then the time zone was a killer really Yeah. hard
And ultimately,
at that company,
we had ended up buying a company that was based in Barcelona.
So those engineers in Romania started working with the engineers in Barcelona and that it wasn't such a big deal.
Scott: Solve the time zone problem.
Brad: It's called the time zone problem.
And then I've had some experiences that are like what I would call staff augmentation where you get individual engineers,
sometimes you get them through an agency,
sometimes you get them.
just individual view of the street and you just embed them with an existing theme.
Scott: I okay so I might here's my list of kind of like experiences using these sort of like various outsourced teams so
I have had a team that was a full-fledged engineering team given a specific project that was in India.
And that was a team that we kind of like shopped around,
found a team,
selected them,
you know, flew to India and met with them. And, you know, they were.
pretty solid and they had you know solid leadership um i've had um i worked for a company 20 years ago that actually had outsourced team that was in syria uh this was 20 years ago so it was before um you know all of that um
Brad: Yeah,
Scott: yeah
Brad: Civil War.
Scott: um and um and then interestingly enough
Because that Civil War in Syria is a great example of a thing that happened.
I also had an outsourced team that was in Ukraine and they were very top-notch engineers doing great work and then boom,
Russia attacked.
And so that was a great example of, you know, the types of things that you,
I almost have like,
you know, is that something that is on my list?
My engineers might actually have to like shelter in place like that's
Brad: Mm
Scott: so
Brad: -hmm,
Scott: and of course, there's plenty of places in the world where that's like a reality.
Right.
I mean, fantastic engineering teams in in Israel doing amazing things.
Brad: mm-hmm.
Scott: uh i've had plenty of teams that i've worked on where we did the staff augmentation thing you know where it's like oh you've got like a kind of a you know engineers for hire and they just kind of come in and start working on the team and you're they're mostly like a expensive employee because you're you're essentially paying hourly plus the extra add-on for the agency right
And then I've worked with agencies that are like, like you said,
kind of like the staff level engineers or agencies where it's like they kind of do a whole project,
they assign their project leader,
which is usually a kind of a staff level product and engineering architect expert,
and then they have.
you know, different grades of engineers working for them and you give them the whole project.
And so those are kind of the mix of things.
Now,
as a fractional CTO, I've ran into, I've been called many times, like more than once I've been called by an entrepreneur who's like,
hey,
I have my MVP kinda,
I used this outsourcing team in, you know, name a continent.
uh it's buggy and it's and they're slipping and they can't give me you know they can't um i'm struggling to get results out of them right
Brad: Mm
Scott: and
Brad: -hmm.
Scott: um so
that's kind of the stuff that's on my mind is i think
Like that, that, that, that particular question is really,
I think, quite perplexing because I think it's very closely related to what we're about to see with these, you know, vibe coding things where it's like the person that's the product owner,
like they can get far enough to like describe the thing. Like I almost feel like maybe we should think of vibe coding as like the.
The sort of like game of telephone,
distant engineering team that if you're not technically capable of sort of validating or verifying their work,
that can get you in trouble.
Brad: Mm
Scott: What
Brad: -hmm
Scott: do you think of that? What do you what do you have you seen that where essentially like the business owners who aren't strong technically kind of can get.
I'm not suggesting that they're like in any way nefarious intent by these outsourced teams.
But, you know, if you if you have that, if you don't have that like bridge of communication,
you can it just feels to me like you can get really, you know, kind of stuck in churn.
Brad: Yes, I've talked to several people who have had that problem and I feel
um sad for them sometimes and they're not getting swindled necessarily but they spend a lot of money and a lot of time and they don't get working software i had this idea once i wanted to write a book called how not to build a website and it was cautionary tales for people i'm thinking of a particular friend who inspired me like she spent easily a couple hundred thousand dollars on having someone build something for her that never really worked
Um,
and do I believe that the engineers she hired were totally incompetent?
I don't think that's probably the case,
but somewhere something got lost in translation.
Scott: Yeah.
Brad: And there's also the piece, especially if you're doing an online type of thing where if you're a non-technical person trying to hire a firm.
You also, someone has to operate it after it just you can't just build it, be done and like here's your website or here's your mobile app and it's
Scott: Right.
Brad: over with.
Scott: Right.
Brad: And that's often a puzzle I've seen people get from some puzzle but a situation I've seen people get themselves to which is like,
okay I got this I build it, they built it they put it on this server for me that was 18 months ago,
and now it doesn't work or I'm getting this error.
Scott: Right.
Brad: and what do I do they're saying I need to do this that or the other thing I
Scott: Or hire them again.
Brad: mean yeah higher than that's what I mean by this that or the other thing higher than again that's exactly what I meant to say about uh there's a dimension I haven't experienced though probably at least the last 15 years
which is you know working inside companies that have gotten a little bit bigger you know the company i'm at now is not acceptably big that's 500 employees or so give or take a little bit um and the business people say well couldn't we move some of this engineering from san francisco and seattle and you know the we hear about these places they're cheaper right the philippines or india or
probably ukraine or mexico or wherever and i would love to do that and i would love to do that not as much to save the company money which i would like to do but hey boss i didn't mean that what i meant to say was i definitely want to save you money no what i mean to say is i found you can sometimes just get more people for the same amount of dollars right so i can get more done which is what's important to me
And I feel like I haven't totally cracked that nut yet,
with the exception of the case where we put a long-term investment into Romania and really got that to work.
I haven't quite figured that one out yet.
Well,
the challenge with Romania was the time zone.
So I haven't really figured that one out yet in a closer time zone.
And the reason the Romanian firm worked is because we hired a guy who had come to the United States from Romania.
And we were saying, hey, we were thinking of hiring some contractor. He's like,
well, hey,
I know these guys at this firm. That's where I used
Scott: By
Brad: to work. They're all great.
Right. So we
Scott: the way,
Brad: had.
Scott: that's interesting that you say that because that particular pattern.
of a local person who you are able to interact with and know and trust like you you can validate their bona fides right bona fides and then they essentially have developed
affirmed they're essentially signing their name to as far as quality goes right in
Brad: Yeah.
Scott: some location that's exactly the pattern that i had successfully work when we had a strong outsourcing team in india and we had the strong outsourcing team in syria and the strong outsourcing team in ukraine so like in all three of those cases they were that kind of a they were that kind of a relationship where they had strong
verifiable U.S. leadership that then moved back and was co-located with the team, managing that team, hiring that team,
vetting that team,
vetting their processes.
Brad: That isn't quite what happened with us. We kind of had the opposite.
Let's call him John.
He worked there. He was Romanian.
He worked there.
He came to the United States.
We're sitting around. We hired him.
He applied for a job.
We hired him.
He's a very talented engineer.
We're sitting around one day saying,
hey, we need to hire a contracting firm.
He said, well,
I used to work for a contracting firm in Romania.
And they were all good engineers.
We trusted him because he was a good engineer.
Right. And he made the introduction.
So with a little bit of the reverse,
Scott: but I
Brad: it's still
Scott: think there's this is
Brad: a a person
Scott: similar.
Brad: of out.
It's a person of out, really.
Scott: That's the part that's the part that I think really matters.
Brad: Well,
I'd love to get some other people on here and talk about how they've made it work.
And we could talk about all the different dimensions,
whether it's agencies or individuals or building teams. I'd love to figure out how to build teams in South America and Mexico.
Things like that. It's the kind of thing I'm doing right now is a real leverage point.
If I could stretch, just like people are trying to stretch their dollar with AI,
I can stretch my dollar with, you know, I can hire one engineer in San Francisco or two engineers in somewhere else
Scott: You know, it's so
Brad: in
Scott: interesting.
Brad: the Western Hemisphere.
Scott: Yeah,
it's so interesting,
right?
Like, what is the overlap with this and AI assisted coding?
I think there's a lot of overlap.
The
Brad: Agreed.
Scott: first one is at a simple level,
right? Like your point you made is capitalism constantly is about how can you be more efficient,
right?
And so, you know, again,
I was just talking to this.
uh fractional CTO client uh yesterday and I was like look you know eventually the CEO you as the CEO you're always going to say like how come my engineers can't build stuff faster right like I want to build things faster like that happens everybody asks that question and so that's all about efficiency right that's whether that's
I need and I want to build faster without paying a lot more,
right?
Like I can't necessarily increase my burn by to build faster.
And so anything and everything that helps us build faster with less burn is something that we're going to want to try as CTOs, as advocates for the business of building these things.
And so AI is one of those things. And then essentially.
more affordable labor is another one of those things and
Brad: Right. Yeah.
Scott: no
Brad: Go ahead. You're going to say it.
Scott: well what I was going to say is what I think what the part that I think is also related to this is just that I
don't want to say you get what you pay for because that's not that's not what I I believe but I think it's very difficult to avoid the fact
That you still need someone who knows how to vet and verify and lead and audit and manage all of those engineering choices that happen,
because that's
Brad: Mm-hmm.
Scott: where the problems come,
right? That's where the tech debt comes from.
That's where the failures come from. It's the oops,
we made the wrong decision.
And who's?
on the hook for that and
Brad: Right.
Scott: that's the that's the common thing i see in these these
these like uh sort of like outsourced type solutions is that's where it can go wrong you even said it yourself right like you use a team that's all staff engineers so you know that you're going to get what you want
Brad: Yeah,
I'd say the tradeoff there,
whether it's AI or lower cost is.
essentially the quality of the code and the quality of the technical design and that's not a commentary on the people i would say it's mostly a commentary on lack of especially younger less mature companies commentary on the lack of understanding exactly what they're doing having to you know because they're coming into a place with you know just institutional there's just tribal knowledge they don't have institutional knowledge
Um,
and you know, you know, like in the case, I mean, now very monolithic system is very hard to come in and work on when it's all institutional knowledge or tribal knowledge.
And so I imagine like I have this dream,
I'd love to hear if somebody succeeded at this dream,
which is, hey,
we have we have a service oriented architecture,
and we have this team in Mexico City that owns Service X and it does whatever it does.
does and that's their thing we've got this other team and I don't know Santiago Chile I'm making these locations up I mean there are real locations but I'm picking them out of thin air and you know they own service why and I have this idea that that might work
But it means a commitment to those areas because you're saying,
hey,
the ServiceX team is going to be in Mexico City and it's not just like, oh, we're going to hire them for three months.
And so we're making a commitment to having, as a company, we're making a commitment to have a presence in Mexico City,
whether it's a owned and operated commitment like we hire people or just a vendor commitment where we.
Not employees there, not employees, but contractors there.
I have a hypothesis that could work, but I've never made it work, and I'd love to talk to someone who has and how to do it.
Scott: So I totally agree,
and I think that's a great,
let's put that out there.
Hey,
listeners,
if you've done this before, we would love to talk to you about this.
And I think that if I kind of like circle back,
like what are the topics that were sort of like.
scratching at right well one of those topics is a time zone distribution right like that that can be a problem whether they're in-house employees that just happen to work for mega corporate
Brad: 100%.
Scott: or their individual contractors so that's like a piece of this puzzle
you kind of describe an architectural approach to it like service you know service-based architecture or like microservices or something like that where maybe you're like hey let's give you an area let's give a group an area of concern and that allows us maybe to reduce the amount of overlap and back and forth right and that that might that's a strategy that can apply
regardless of whether they're outsourced in-house,
time zone shifted or not, right?
So Yeah, that might be
Brad: yeah.
Scott: a really important part about this,
Brad: right? What we're really talking about is the need for communication and shared understanding of how a system works,
whether they're contractors or full-time employees.
I mean, that's just a legalism of how someone gets paid, right?
what we're really talking about is how do you have teams this gets the remote team the remotes and hybrids of the world right when you have people who are in different locations
how do you get them to work together effectively um and so much of this job is communicating believe it i mean people don't you know people say oh engineers they just like to talk to computers they don't like to talk to people that's why they're a soccer programmer but it's so much about it is
understanding shared understanding it's just it's
Scott: Yeah,
Brad: like the whole thing
Scott: 100% every single retro part of it has to have that topic in it, right?
Brad: We understand what we were building.
It's always on there.
And I think that last point is kind of one of the reasons I reached out to you for this conversation today is I've also noticed that that challenge of shared understanding is particularly challenging if you don't have that strong Rosetta
Stone voice.
And you and I have talked about so much about the job of a CTO or the job of that engineering leader is to be that translator between the business requirements and
Scott: Mm-hmm.
Brad: the technical team.
And that's all about shared understanding. That's all about communication.
And it's about being able to do that communication across these two,
you know.
colloquial languages right and
Scott: Mm-hmm.
Brad: that's where i've seen this this process blow up right the the go get them energetic business owner non-technical ceo product person who is like yeah i'm gonna hire a firm and then that gets away from them i think maybe because they don't have that champion
Scott: Everybody forgets.
The key in this is the role of product management,
whether you have product managers or not, right?
The role of product managers and the role of tech leads,
right?
The people who figure out what's the thing that we're going to build and how do we translate that from an idea into a software plan like those, everyone just wants to hire a software engineer.
Can you hire someone that codes for me?
It's like, sure, I can hire a guy that hits nails into a two by four,
but you actually need the architect and the engineer to tell that person what to do.
Brad: Yeah,
Scott: And that's, it's like, it's so fascinating about our industry. Everyone focuses on how many carpenters do we have when the thing that really builds
Brad: right.
Scott: you good houses and accelerates your building of houses are.
The architects and the geotechs and the structural engineers and all those kinds of things.
Brad: And so the part about this that I kind of gravitate back to is, to your point,
it's really important that you have that architect.
And I wonder,
are there parallels to the way that, you know, outsourced engineering teams, agency-based engineering teams, those are not new.
Those have been around for a long time,
Scott: Mm
Brad: 15 years
Scott: -hmm.
Brad: easily,
20 years, right,
depending on the language that you're playing with,
right?
And is there a parallel with...
the sort of the architect that somehow is running the minions of AI agents.
Scott: Right.
Brad: Right.
Like, is that is that actually the next job?
Is that is that really, you know, you and I were talking like, what do we how do we coach young people coming into industry right now? Right. Is the is the thing that we need to be coaching people on is look, it's really about how many carpenters can you orchestrate effectively?
Scott: Yeah, yeah.
Well, I think there's another thing that I think I hear you getting at, which is if we can talk to people who've successfully figured out how to wrangle large groups of outsource engineers, there's maybe something to learn from there how to wrangle a lot of AI bots.
Brad: Yep, that's my current operating theory.
Scott: All right.
Let's leave it at that for today.
Brad: All right. It was great talking to you, Scott.
Scott: It was good talking to you too,
Brad.
Brad: Another fun episode.
Scott: Till next time.
Brad: Exactly.
Till next time. And wait,
remember,
smash that subscribe button.
Leave that five star review.
Scott: I know.
Give us a review. Yeah, do it all. Do it all.
Brad: Do it all.
Join the Patreon.
Scott: Thanks,
Brad.
This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigout.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at how many CTOs pod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon or at our website at howmanyctospod.com.
And remember to rate,
review,
and subscribe on the podcast platform of your choice.
Thanks for listening.