Entrepreneurship: Lower Barriers in the AI Era (feat. Brian Samson)

Foreign. Hey folks, welcome to Snowpal Podcast. Our guest today is Brian Sampson. Brian is the founder of Pluck Technologies. Brian, thank you so much for taking the time to chat. If you could give a brief introduction about yourself to our audience and then we can jump right into the topic.

Yeah, super excited to be here. Thanks for the opportunity, Chris. About Me I live in Hawaii and I've been focused on Latin America for the last 10 years. About 20 years in business was a head of Talent guy in San Francisco for a bunch of tech startups. And then the last 10 years I learned about the world of nearshoring Latin America. And happy to tell your audience all about that and how it all works.

Thank you for taking the time. And you've already made me jealous because, just because of where you actually live. I live in a little less exciting part of the country, I should say, but equally exciting in some ways. D.C. is never boring. Again, Brian, thank you for taking the time. So we have a few things that we want to talk about today. So just to get started, the topic that we had. Oh, before actually I do. I'm going to do a screen share. So folks actually know Plug Tech. There you go. Yeah, if you could just take a minute to introduce the company to our audience. Brian.

Yeah, absolutely. So I founded plug back in 2022 and. But I've actually this is my third business focused on the world of Latin America. So what Plug does is it simply it's a talent staffing company. And there's really a lot of interest in Latin America since COVID You know, remote work was kind of a Wild west thing, you know, before COVID And then now everyone's a lot more comfortable with it. They understand it, they know how to make it work. And companies I think recognized that remote work was possible, but if it got too crazy, it could get out of hand quickly. So companies realized that they still wanted people on the same time zone, but once they could figure that out, it was a lot easier to make it work. And if you were a San Francisco company and your software engineer was in Dallas or Kansas City or Chicago, it really wasn't a whole lot different from having them in those cities than it was in Mexico City or Sao Paulo or Buenos Aires. So Plug is really a talent connector of all this amazing talent of software developers, DevOps, QA data engineers, all these hot roles, but the talent's just in Latin America on the same time zone as the US and companies that need developers and all the different roles that is talked about work with Plug. And one of our differentiators, I guess, is I had been an expat in Buenos Aires. My partner, Ruben, who's the president of plug, I'm the founder, Ruben was an expat in Monterrey, Mexico. So we've kind of seen all this firsthand and we can give proper advice. You know, we're not just reading off of ChatGPT. You know, we can talk about what it means to experience the ups and the downs and the volatility and the chaos and you know, help. Help teams get the right talent and kind of skip all the, all the craziness that might come about if you're hiring in a country you're unfamiliar with.

Okay, I think that's a good point for me though. Interrupt you. Sorry. And if I might interrupt you as we go. And my apologies if I end up doing that. I think you've. You've kicked off a topic that is actually of immediate interest to not just me, but I think to a fair number of people. But let me ask some of some high level questions, right? What are some of the differences between near shoring and offshoring? In other words, what you told me just before the podcast was folks end up being in the same time zone or maybe a time zone that's not very different. Right. Maybe it's within an hour or two or so on and so forth. Yeah, that's, that's one difference. That. And what else do you see are differences between working with folks who are sort of co located, even if not exactly so not too far, and somebody who's like maybe 10,000 miles away?

Yeah, awesome questions, Krish. So let me do some definitions and I'm sure a lot of your listeners, they're smart people, they've got a lot of great acumen. So forgive me if some of this gets a little basic, but I promise we'll get into the advanced concepts.

No worries. Yep.

So basic, I'm sure your audience has heard of offshore, nearshore, onshore and outsourcing. So first I'll just start with outsourcing. Outsourcing can be wide open for location. It's really how you think about functions within your company. So often it's non core functions are usually what's outsourced. So if you're a tech company, you really care about your technical team, but maybe your finance and accounting, you outsource. Right. And you could outsource that to a company in your city, you could outsource that to the other side of the world. And then when it comes to offshore, nearshore, onshore this is where the team is located. And it could be your team, or it could be outsourced. Offshoring means that there's a whole ocean in between where you are and where that team member is. And again, it could be an outsourced team member or it could be your own company. So the often the biggest advantages of offshoring, the two biggest ones are it's usually way less expensive than hiring locally. And the second is you get this benefit of a follow the sun model. So what does that mean? You finish work and then all of a sudden you pass the baton to the team on the other side of the world. While you're sleeping, they're making stuff happen, they're pushing code, whatever. If it's nearshore, usually the biggest advantage is this means that it's not over an ocean, the team is in a different country, but a country that's on your time zone and it's relative. So if you're in Australia, the Philippines is a near shore country for you. Because we often think about everything in terms of the U.S. you know, we're very myopic, right? If you're in UK, Poland, you know, similar time zone. But if you're in the us, if you kind of look below on the map, there's South America right there. It's kind of our backyard, so to speak. And although the map kind of juts out a little bit to the right, for the most part people there are on Central time, Eastern time, or maybe Eastern plus one or two. And what's kind of fascinating is say, a country like Argentina, where I had happened to live for a while, they're eating dinner at 9, 10 o' clock at night. So that workday is almost fully mapped to even Pacific hours. So you don't skip a beat, even though it looks like it's kind of jutted out to the right. So the reason you would want a nearshore is you get some cost advantage. But it's really the workday collaboration. You know, I send a message on Slack right away, I get the message returned, or on Jira or I want to hop on a quick WhatsApp call or text, they're awake the same hours that I'm awake. And I think that matters a lot when you want to collaborate. You know, you want your teams working together, you want to bounce ideas off, you don't want to wait until the next day to hope that they understood what you were asking for. So you really don't, don't lose a whole lot. And the last is onshore so you're not worried about time zone because it's someone in your country. So if you're in Australia, it might mean you're in Sydney, your team members in Perth or you're in San Francisco, your team members in Dallas, that's onshore. You don't get tremendous cost savings. You certainly don't lose on time zone. But you don't have to worry about going cross border. You don't have to worry about any cultural misunderstanding.

Absolutely right. No, makes sense.

Yeah. Although I was. That sometimes we forget that there's a huge cultural difference, say between New York and Texas. Right. So you know, there is.

But, but you know, it's relatively much smaller. Right. The difference compared to between two different nations. So I'm going to say offshoring and outsourcing are kind of similar. Right. It seems like they are not particularly very different. And then on shoring, we know it because we are working with folks in the same country. And then we. You mentioned near shore. So let me ask you a couple of questions related to that. If cost was not a factor, like I've asked this to a couple other people. You know, this is an environment where this is a fairly valid question because a lot of talk on Twitter and every other place you could possibly see about, you know, jobs and whether they should be here or they should be shipped or all of those things. Right. And I think at some point in today's conversation you had mentioned H1BS. I, you know, we can talk about that as well. So let's talk about. Can you think of any reason, a reason, Brian, that you would want to actually do near shoring or offshoring, slash outsourcing outside of cost savings? Is there any one reason that does not have to do with the dollar and the amount being spent that you actually think is a good reason to actually do one of those things?

Yeah. So what I think you're hitting on is this concept of labor arbitrage. And I don't want to necessarily trivialize cost savings, but look at it in a different frame. So dollar for dollar, someone is probably going to be cheaper in India than they are in San Francisco, dollar for dollar cheaper in Mexico City than they are in San Francisco. But what you should really be looking at if you are curious about cost savings, because again, I don't want to trivialize that, but I do want to answer your question.

Sure.

Is you're going to save tens of thousands, maybe significantly more. But what you're really looking for is a value where your value is larger than the.

Cost.

So this is where the arbitrage comes into play. So often I'll get a question like, okay, what's the catch? I'm going to save money. The person's in India or the person's in the Philippines or they're in Mexico. If I'm going to save money, what am I really trading here? Right. And I try to make it a little bit into almost like a math problem. So I'll just focus on near shoring for the US which is Latin America. And every country in Latin America is a little bit different. So I don't want to just generalize this whole continent. Mexico is different from Peru, which is different from Nicaragua and Brazil and Argentina. And they all have different nuances around hardware, customs, talent, pockets, cost of living in those countries. If we wanted to travel there, nonstop flights, visas, you know, all these things. But let's just take Mexico for example. So Mexico on a dollar for dollar, you know, 150k might be like a reasonable base salary for somebody in a medium to high cost city. For a technical role in the US we'll treat the R and D and data engineers as outliers for purposes of this exercise where the compensation is pretty wild. But 150k, kind of a reasonable salary. That 150k is really a cost of about 200k when you factor in benefits, FICA, employer taxes, maybe even more. If you're looking at equity and things like that. We'll just say, you know, 200K, the cost of a developer in Mexico, it's maybe higher than you might think. You know, you're not going to get somebody for $8 an hour, right? It's, it's still going to cost, you know, anywhere from 60 to, I'm seeing some compensation, you know, close to 100k, right? 60k to 100k. But usually the cost kind of stops there unless you have them on your payroll. And then there's other things like benefits. They have something called aguinaldo, a 13 month salary. So let's just say the all in cost is maybe 100. So you'll save 100,000. So 50% cost savings. Does that mean that the quality is 50% worse? I don't think so. I think the quality drop off is maybe 10 to 20%. So therein lies the arbitrage. You say 50% but you have a 10 to 20% decrease in quality. So you have this 30% increase in value. That's what I want companies to look at is the value differential. Now the other thing that I think you were getting at with your question Krish is the world is flat in a lot of ways. Thomas Friedman wrote that book the world is flat in the late 90s really kind of changed the way we think about work and of course AI is only accelerating it. But there are smart people everywhere. I think top tech companies figured this out a long time ago as they set up offices and India and China and all over Latin America, Europe, you know, wherever good talent is, they have offices, right? So I think like the top 10, 20% of talent, it doesn't matter where you're born, you are in the top 10, 20% of the world talent. So that's what a lot of companies are trying to find is country agnostic. How do I get my hands on these 10x Brian?

That makes sense. Let me ask you a question there. I'm sort of going to play the devil's advocate here as well because I've worked with a lot of our work happens in the US but I've also worked with folks in other countries. Let's take certain roles as an example. So if you take development where people are writing code, whether they're writing code way you're writing it today with the help of AI and related technologies or like you did it two years before, doesn't matter. But if you're talking about developers, architects even, maybe then you're sort of, you know, you're in your own cocoon for lack of a better word, right? You just, you're given a task, you go execute that, work towards it, come into your code changes, work with people to review your changes, do a pull request and then you're good to go. So the cultural differences in my mind, right. Tell me if you agree or disagree, may or may not make a profound difference, right Brian saying Krish, can you just help me build this page? I go about, do their job, commit my changes, you have some feedback, I account for that feedback and we are good to go. So each of us learning the other person's culture would be nice to have but I don't know if it's, it's a must have, right? Not necessarily so. I mean I have tried to do that just as a person but I've actually worked with companies that they treat both parties or at least you know, as like a bot of some nature. But there's no small talk or any exchange of that sort, right? Hey you know what Brian, can you get started? Can you make these changes? And to me that's a little too quick. I would like to know the person that I'm working with, but to each their own. But what I'm trying to say there is from a development standpoint that does not necessarily seem to be a pressing need to know the person per se to have them get stuff done. Right. So the cultural differences may or may not make that much of a difference from a. If you're hiring an engineer, so if it's near shoring vs offshoring vs if you have somebody local but every other role. I want to get your thoughts on this. If it's not an engineering software development role. There are cultural separations and sometimes they are subtle, sometimes not so subtle. Your work culture, your etiquette, your body language, accent, I can speak to that personally as well. So if you account for all of those, Brian, would you still say it's a 10% difference or is it possible that you actually see the difference that you're seeing by virtue of the amount of money that you end up saving by doing that mere hiring near shore?

Yeah, I think that's a fantastic question and I love the frame that you set up here. So let me, let me hit on two different things. There's the cultural aspect of just customs and how we behave in our countries and things like that. And then there's this culture of high pressure, hard, hard problems solving hard problems for tech companies. Right, right. So, so the first is just the way we, we think about customs and you know, there's something that I wanted to illustrate that I think is often forgotten about, you know, as we, as we think about the attributes. You know, Krish, as cto, you know, you've hired a lot of people and there are, you know, usually certain attributes you're looking for and we might trivialize like I don't need to know this person. Let me just throw the task over the wall. But most hiring managers I think would, if they, they're given a choice, they'd want someone whether they're a software engineer or they're a marketing manager or a virtual assistant or any number of hundreds of jobs. Attributes that you'd want are people that have critical thinking. They're clever, resourceful, gritty, scrappy, humble, hard working. And I think that's starting to be harder to find in rich developed countries because so much is just taken for granted. So much is kind of given to us. And I can speak personally to Latin America because I've spent a lot of time there. I've for example, been to Argentina nine times. I lived there for a long time. And I can tell you on the Surface. Gosh, it seems kind of risky to work with a country that I see on the news. We're sending all this money to Argentina or, you know, Mexico. You hear about cartels and Venezuela, there's, you know, it's like a billion. A billion dollars or whatever the currency they have there. To buy a loaf of bread, you might as well set it on fire. But that's all governmental. It's not the population. But if you've had to deal with that your whole life of crazy hyperinflation and labor strikes, menu prices changing so frequently they have to be written in.

Chalk.

All this kind of craziness as a result. The population is clever, they're critical thinkers, they're resourceful, they're gritty, they're scrappy. So that's something that I personally, I can't comment on every developing country, but the ones that I've seen in Latin America, they just kind of intuitively and innately produce these types of team members that almost any hiring manager would want right in the US So I think there's that, and I think that matters. It doesn't matter what kind of work it is. We all want team members that are like that. And they're also committed, dedicated, loyal. The other thing that I would kind of lean into is so we talked.

About.

Just the general culture, but part of what I said, I think also reinforces just startup culture where it's hard. The rate of failure for tech startups is so high, it's so hard. The problems that you're solving are so difficult. And I've seen this really exciting trend. I've seen this happen in India, I've seen this happen in Argentina, I've seen this happen in Brazil, where venture capital is starting to flow to these countries. And what have we learned? I have a degree from Singapore, so I've also spent some time in Singapore. Singapore is a very rich country and they kind of tried to create just basically buy their own tech ecosystem. But what you really need for a successful tech ecosystem is you need capital and companies, a few success stories, and then people stay and they reinvest their time, their knowledge, their money, and they just keep growing. This ecosystem that's happening in India, that's happening in Brazil, that's happening in Argentina, where this ecosystem is growing. So we talk about the top percentile of talent. You need to experience hard problems and experience the stress of trying to build a company under very tight constraints and having wins. This is different than I'm bank of America and I need to hire 500 net developers to do integration work. That's a totally different subset than I need one data engineer. A bet the company kind of hire. And you can find those people now in the countries that I just talked about because they've been working in these small scrappy startups that maybe are domestic. Maybe they've supported the US but they've had that exposure to pressure. They've had that exposure to trying to solve hard problems under constraints. And that's really exciting.

Makes I have one last question before we sort of switch to the next topic. Right. The question I have is I completely agree, but personally I have one, one thing I want to ask you here. If I was looking for somebody, doesn't matter what the role is, could be a product manager, could be a developer, could be an architect, somebody who can help us say at Snowbell build whatever it is that we are building at any given point of time. If, say I was talking to somebody who was located not in the D.C. metro where I live, but somewhere else, be it in the continental US or it could be in Alaska or Hawaii as well. When I talk to that person, I, you know, my focus is generally on the skills that we are particularly looking for, whatever that skill needs to be. But I'm not worried that Brian Sampson is Brian Sampson. I'm not worried that, you know, Brian's resume is any different from what Brian purports that resume to be. I go to LinkedIn profile, I know Brian's been doing this and I trust everything that Brian says. There is a legal system that I believe and I trust. That gives me a lot of confidence. So I'm only worried about can Brian do this or can Krish do this from a job and a role standpoint, but when it's not in the country, when it's somebody someplace else. I've had a lot of different experiences personally, Brian, so I've become a little bit more careful to the extent I can be. I've had a lot of other people tell me the same things and I want to end my question with see, I grew up, I've lived most of my life in the US here. But I was in my formative years were in the south of India. So I understand the parts of India where I either grew up or I had some familiarity with for whatever reason. India is a large country as well. But I don't know every state in India, don't know all of the schools or engineering colleges in all parts of India. There's a lot of them. So when I know state the city I have a bit more comfort than when I don't know it, even in the country that I was born and raised in. Now, if I'm talking about, say, Argentina or Colombia or Poland or other places, other parts of the world, a lot of us do not understand the geography of those countries. We don't know. Like, if you ask somebody in other parts of the world, can you find tech talent in Boston versus Kansas City versus the Bay Area versus Seattle versus Austin? I mean, those are all just names of cities to them. Right. They probably couldn't tell the difference. So you kind of have an idea where I'm going with this. Right. So what are some of those challenges? And to people who think, you know what, I know it's a little bit more affordable. I agree. And I also agree that you can find really good talent in any part of the world. It's not just, it's not just our luxury. There are people who are just as talented, if not a whole lot more in other parts of the world. But that is this risk that I have to sort of assume because I don't know the culture, I don't know the laws of that land, and is it really worth it? Right. I mean, what, first of all, do you agree that some of these are challenges? And if you do, how do you, what do you recommend to people so they could actually go about addressing these challenges?

Yeah, fantastic question. I love, love where you're, where you're going. I've spoken to someone who's a veteran, who's hired a lot of people and felt the pain. I could feel the pain, totally. Yeah. So let me maybe state a truth that you could easily find out. I think the US and the uk, by almost every rating system, still have the top educational, still the top educational system. So if you're looking like, what's the Stanford of Latin America, what's the Berkeley of Latin America? It's a little harder to ascertain that. India obviously is iit, and that's very, very well known, but there's thousands of universities we haven't heard of. Same thing with Latin America. So I think it's still very important that we, if you're in a hiring role, you have a rigorous hiring system rather than just basic pattern matching. So, like, oh, they have this school in the resume. They must be smart. We should still have a clear understanding of what is this role doing, what is the impact of this role, how do we want to vet for this role, who's asking which questions? So we have some consistency there So a good hiring system beats a lot of the potential risk of candidates. Now, there is something that I wanted. There's maybe two other things that I wanted to hit on. The first is maybe this is AI driven, but there are more fake candidates today than I've ever heard of.

And that's saying something because there have always been fake candidates. It's not like there weren't any. There were always plenty. But you're saying you're seeing it be a lot more today, which is scary. Yeah. So.

Yeah. So recruiters just have to be this much tighter with their screens, video calls, you know, like.

So Brian, who, first of all, who is a fake, Just so you know, people understand this. When you say a fake candidate, what do you exactly mean by that?

Yeah, so maybe someone's impersonating that person or someone does the interview on someone's behalf and you'd have no idea. Now, you know, knock on wood, but with my company Plug, and we place mostly technical people with our clients, there's maybe been one time in the five years that someone showed up to the first day and we were all kind of questioning, is this, was this really the same person that did the interview?

If you don't mind me asking, which part of the world was there?

They were, they were in Brazil. I want to say.

Okay, but.

Forgive me, Brazil. I don't want everyone to think that.

No, I understand. Yep.

Full of fake candidates. Because it could have been anywhere. I could have said anywhere. And it was just that one time. Right. And Brazil has, you know, over 100.

So in other words, Brian, you hired somebody and then the person who showed up to the job was different from the person who actually took the interview initially. Yeah.

So I think, you know, oftentimes there's pressure to hire. I need to hire somebody yesterday. So again, I think if you have a good interview process and hiring system, you'll catch this. It's the, it's mostly the companies that are trying to steamroll somebody in. They kind of skip the steps. They don't do a background check, they don't check references, they don't do video calls. They just do like a one quick interview or maybe a two quick interview. And so we've got a pretty rigorous process. I think a lot of good tech companies have rigorous processes, so they catch this. But even a company like ours that has a good process, it's non zero that this happened. This did happen once, but I still think it's in the single digit percentile for good hiring processes. But again, non0 and it's important to have all the things set up in your system.

No, I think that's fair. Right. So let me ask you a question. It's a good segue to the next thing I want to ask you. You mentioned that. Okay. It's probably, you know, if you could hire two people in Argentina in place of hiring one person in the US Just because there's a cost difference. And even if the efficiency is not exactly the Same, hypothetically, by 10 or 15%, you still have the 35% gain because you are able to get more people for that exact same dollar amounts. Now, let's keep that in mind, you know, just a narrow, you know, hypothesis, but let's keep that in mind. And here's my question. With the advent of AI, and we know it's just going in one direction, right. Nvidia has become a $5 trillion company. So even anybody who was a naysayer was skeptical. There's little, it's becoming more and more difficult for people to be not willing to accept, you know, be accepting of the impact that AI is going to have. Because you can see that Meta is spending, I don't know, $100 billion. Right. And the stock plunged 14%. Right. So it clearly means that companies are doing that spend. But even outside of these big, large hyperscalers, everybody is beginning to invest to some extent in these technologies. And as I talk to more founders such as yourself, Brian, one of them actually is based out of Australia. He told me that he had a 50 people and now he's got eight people. Right. Right now part of me is like, hey, did you have, were you overstaffed to begin with? If you could actually, your size, you know, the employee size is changing so much. But assuming that they did not, they were not overstaffed, it means that AI is bringing a lot of efficiencies, right? You're going to write, have to write a lot less code. People who are not coders can now start coding with vibe coding and all, all kinds of stuff. Long story short, it's going to bring some cost savings, right? Where you needed five developers, you probably need two when you had 10 of them, you probably need three today, right? And maybe that's going to change dramatically with Claude and all of the code generations. It does. So if I were to tell you, hey, Brian, you know what, I get it, that I can go someplace else and save that money and find somebody, or I could have fewer people who are co located with me in the US and the money, the savings I could bring those savings by using these technologies. What would you say to that? And I'm going to jump the gun and assume you might say this, but I'm going to ask you what that means as well. You could say, Krish, I could do the exact same things and have somebody in Argentina and I'm going to save that much more. Right. That's a valid answer. But I want to get your thoughts on what this means to the future of Mia shoring and offshore.

Sure. So I think your question maybe doesn't have the assumption that AI is being used all across the world. It's not just by U.S. companies. Right. So and you probably were thinking that as you, as you were asking it. So I've often explained it. We talked earlier about labor arbitrage but I think talent in Latin America that's using AI, it's almost like a double bonus arbitrage for companies. So you know, maybe the company had 50 people and I'm bad at doing public math here but you know, they had 50 people and you know, we saw this 2021, everyone overstaffed 2023, everyone probably overcut. So now we're trying to right size and then also right size with AI. But if you're a US company and either you leverage AI or you leverage Latin America, you'll get the first level of arbitrage. But I think if you use nearshore plus your nearshore team is using AI, that's where you get that second level effects the second order effects of labor arbitrage. And that to me is really, really exciting. Let me say one more thing that we didn't totally touch in is. I think it's quite aggressive to be a founder and then you're all, your team is in a different country. I still think there's a lot of value in your core team being in your, in your office. But then it's all the additional hires you make if they're augmented by nearshore offshore, that's using AI. That's when you start to get tremendous economies of scale. But it's not just cost savings. It's high quality work that gets done.

No, I get it. So I guess the way, I guess there's two ways to look at it. At the very minimum, here's how I see it, which is say you have $100 to build something. It was going to cost you $150. So, so you either you, you didn't have the option to build it locally like in the US you had to go near shore, offshore or whatnot because you had $100, you needed 150. You're going to have to find that saving someplace. Now my assumption was with AI, I'm able to build that with a hundred dollars because I need fewer people. And with the use of technologies, I can do it here. Right. So that's one way to look at it, saying, hey, you know what, I don't need to do near shore or offshore because I have the hundred dollars and I don't need as many people and I can just do it without going outside the country. But the second way to look at it is, well, you can now spend $80 or $75 and not even spend the $100. So you could still go do the near shoring or offshoring if you're able to find the talent that you're looking for and still have the savings brought to you by AI and everything else in that space. Because the assumption cannot necessarily be that it's just us in the US who are sort of who are caught up with it. Even if in many cases we are leading that trend. You know, if you will, I would say probably the US and then China, maybe two countries that are actually driving a lot of this. Yeah. So I think that that makes sense. Before we go to the next topic here, Brian, any anything else you want to add to what we've discussed there?

I think there's one more thing that is really exciting that I think you're hitting on. I mean, we also Amazon laid off how many thousands of people and you know, the layoffs and are just continuing. And sure there are people that I think will kind of be caught, you know, and long term unemployment that are waiting to be hired. But the real exciting part for me is all the potential opportunity for entrepreneurship. And now entrepreneurship, the barrier to entry just keeps dropping because now you've got offshore and you've got nearshore and you've got AI so you don't have to raise millions of dollars anymore to start a company. You know, maybe it's tens of thousands or hundreds of thousands to get something to a place of traction. Yeah, yeah. And I think it's going to be so exciting to watch how it, how it impacts the economy.

No, I think, I think what you said there is super interesting and maybe I'm going to ask something. I was going to ask something else, but this is even more interesting. So let me ask you. I saw something popped up on my Instagram feed, I think two days ago where there was this guy, I don't know where he's located, somewhere in our country. And he was pretty frustrated because he's like, hey, I spent three years building or four years building this app, and now there is somebody who built this using white coding. And he just showed in the video, he just said, you know what, I just did some research on who this person is. And it didn't help his frustration that it ended up being a middle schooler. Somebody who was in middle school ended up building an app using wipe coding that he, that, that had taken him like three to four years to build. Now that sometimes could be dramatic. Something that took four years for somebody who's been in the business of building software with wipe coding, can you do it in like, I don't know, I mean it's, that's just an example. Take it with a grain of salt. But there is a fair bit of truth to it. You mentioned entrepreneurship. You also mentioned layoffs. Right? So what do you see the future of? What do you, Brian, see the future of engineering be, in other words, I never thought there was a safe job ever. Because, you know, people who thought federal government jobs were safe are probably finding out otherwise. Right? So federal government jobs are not safe then probably. No other job is probably safe, right? Maybe, maybe college professors or tenured, maybe it's a bit safer, I don't know. But, but in general, there is no such thing as a safe job. No matter what you do, you could be working in this large company, doing some really exciting stuff, and then you're not needed anymore. Right? And it's just the nature of the beast, right? We live in a capitalistic society and it's just how things are going to be. So, you know, the population is just growing, right? You know, I think that by the end of the century or middle of the century, there's going to be a whole lot more people. We need a lot lesser people to do what needs done. Some countries have more, you know, a population that's growing a whole lot more, like maybe India, Nigeria, compared to South Korea or Japan, for instance. Right. So the world order is. Could be philosophical to some extent, but the world order is changing, correct? Given that, my question to you, Brian, is do you see the future as option one, which is, hey, you know what? We're going to be building software and everything else, not just software, doing things more efficiently using AI, but the whole dynamic dynamics of how it's being done here, there, everywhere, and co located, not co located offshore, near shoring. The fundamental tenets of that approach are going to pretty much stay the same. It's just that the technology is changing. So you're going to do things differently or do you see the future of engineering as you know what it's not going to look anything like it's looked in the past. Right. What we do, how we do that and who does it, it's going to be dramatically different. Which means we have to brace ourselves to a future that we actually have little clue about. Sort of. I know those might be some sort of extremes, but where do you see the future be? Fear the crystal ball.

Yeah. You know, I'm sure there's a lot of listeners for this show that maybe also tune into the all in podcast and one of the hosts of that is Chamath Palihapitiya and he's founder of a company called 8090. So with essentially the premise of, you know, pick like all the common most popular softwares will make this 80% cheaper and 90% as good. And I think that's where engineering's going. I like his vision for that. The richest companies will still pay for Salesforce, they'll still pay for some of the very expensive commercial software. Oracle, aws, they'll still pay for that. But as the friction to get a new company off the ground. And there's a lot more entrepreneurs, I think there's going to be a lot more 80, 90 opportunities. AI nearshore middle schoolers where the bar for perfection. There's still people buyers for those but there's going to be this whole group of buyers that now just have more choice of what type of software they can buy. Recognizing that there's trade offs like okay, like I'll get this for a much cheaper monthly price and it's mostly as good. Almost the same principles that I talked earlier about using Nearshore, you know, like big cost savings mostly is good. And I think companies, buyers, consumers, we all understand the trade offs that exist in the world.

Okay. And if as we get to the sort of the tail end of our podcast here, if you have to in the last six months to a year, how what you know you've been building software for a long time and you know you've been working in this capacity, what do you think are some of the things that have actually changed and changed dramatically in the last three to six to nine to 12 months, Brian, that you see as hey, you know what, I would have done things quite differently a year ago but now the whole approach to this problem, at least the way I'm, the approach that I'm taking is seismically different from how I had done it in the Past.

Yeah. Well, you know, what I'll say is maybe about 12 years ago I was working at a unicorn company in San Francisco that ended up going through an IPO. So you know, we saw it grow from like 12 engineers to 120, you know, in like the course of a year, just, you know, hiring a lot of people. So what was really interesting about that is just as you'd expect, a company that has that level of growth, you need to start professionalizing it. And like, let's bring in professional engineering managers and directors. They're no longer coding, they're leading, you know, and doing hiring interviews, performance reviews, all that stuff. And what kind of blew my mind about that is on the surface that thesis seems to make sense like okay, you need to be more professional and have a typical org chart. But most engineers still want to work with a lead that's still coding. Right. That's kind of leading from the front. And I think maybe that's like the key lesson is what, you know, like the professional managers didn't last despite the size growing. And I think professional engineering managers are in trouble because if you've made the leap to C level, you're safe. And if you're a lead engineer, you're safe. But there's a whole world of people kind of in this middle where they're like a man with a.

You hear that all the time, right. You hear these, I think the Meta or Google and you see Amazon and even Microsoft laying off a lot of the mid level management. Right. They're like, you know what we don't need? They've moved a lot of those people I read, to actually independent contributor roles. Right. Where they spend a lot of time doing that.

Yeah. Because they're kind of like man without a country. They're not senior enough to think like an executive, but they're too far removed from day to day coding. So they're stuck in no man's land. So I think that's my lesson is that trend is going to continue at an accelerated pace. I still feel good about the role of software engineers. I'm not a doomsday synergy person. You know, AI will fully replace it, I think with the amount of connectivity, APIs, you know, there's. They're still going to need humans to do this a lot of qa. But if you're strictly an engineering manager today or engineering director, I would encourage you to either significantly up level or get back to the code.

Absolutely. I think that's great advice. And it's not a question of Whether, hopefully, you like to do that as that person. Because if you don't like to do it, you won't have to do it just because you have to make money, which is fine. A lot of us have to do it. It's just the way life works. But hopefully people like to do that. They have to pick one or the other so that you enjoy doing that while you actually are doing it. Awesome. So, Brian, I've asked you a bunch. Before we wrap this up, any questions that you want to ask me?

I think some of the big topics we talked about, I'd love to get your opinion on that. What do you see over the next 24 months, especially as the acceleration of. Everyone can get their hands vive coding, all this stuff. Everyone can get their hands on these tools. What's your prediction?

You got five minutes for an answer?

I'd love to. Yeah.

Here's my take on it. Right. As you know, I said this, I think, in one of my other podcasts, and I'll say it maybe differently here, a little bit differently is I see three categories of people at the highest level, folks who've sort of been working in this business for four, maybe five decades, and they are very nearing retirement, so to speak. They actually have the luxury to sit this one out. Meaning they're like, you know what, I'm either retiring very soon because I know a few people, you know, who I've worked with in the past on LinkedIn. They're like, you know what? I'm done. I'm excited to know where things are going, but it does not personally impact me, right? Because I've built software a certain way. Five decades, I'm done. It's awesome. I'm out of there. They're all right, I think, right? Because they're not going to be impacted directly. So. And then there's folks who are graduating from college, you know, recently entering the workforce. They've never built software any other way before, right? They are used to chatgpt. They're used to getting used to wipe coding. They're used to everything that today's tools and technologies and copilot gives them. So they only know how this works, right? They don't know how things worked in the past. And to be honest, I don't even think they need to know how things worked in the past. To me, I don't believe, you know, it is necessarily important. So they're all, they're okay, right? There's an impact, but they're okay because they're learning it. Hopefully the Right way. I'm not sure if colleges are teaching them that. I'm very skeptical about it. But at least they are learning through some way, form or shape and entering the workforce. So they are the future of the workforce and they're learning it hopefully the right way and they don't have to relearn something. I think the people in the middle, I'll take myself as an example, been in the business of building software for over two decades. You've done it n number of ways. Things have been never static. They always changed, but never changed at this pace necessarily right now. We've never, you know, other industries could have been more static, Brian, but I think software engineering was never a static industry. Right. Things always change, right. There was JavaScript libraries coming up every three weeks or so. Right. So we're used to that change. But even for us, this change is slightly different. The pace of change is much, much faster. So I think we have to do a lot of unlearning, some of us and relearning because we've done it a certain way. And you have this muscle memory and building software and that's scary, right? We've actually, we're very conscious about that. Right? When we're building, working on the next API that we're working on building, it worries me every single day that we shouldn't end up doing it the way we've done things in the past. That's not just the end product or the outcome. It's not, hey, I'm using this tool or that tool or wipe coding or whatnot. So my end result, you know, my end product looks different. We also want the journey of building that software to look entirely different, right? Not just from an engineering or a development standpoint or an architecture standpoint, Brian. It's also from a product management standpoint, from a testing standpoint, from a deploying standpoint, from a selling standpoint. Right. From a content creation standpoint. All of that has to be done very differently. I mean, we use canva as one of the tools for content creation. How we used Canva eight months ago is not how we used canva today. Right. I mean, it's a moving platform. They keep adding features. Some are good, some not so good, but. But the point I'm trying to make here is we're going to have to completely forget, remember to the extent that we need to remember how we build software, so we don't forget the fundamentals. But I think muscle memory is going to be detrimental to progress here when you actually start writing code you're going to have to make an honest attempt at doing it very differently based on how it should be done today. But there's a caveat there. Not too long ago, there was a recent change that was made to one of the Flutter libraries and our app. Actually, we use Flutter. My first hope was, you know, there was no backwards compatibility on those dependencies that we use. So I was like, you know what? I don't have to do anything. There's Copilot, there's this, there's that. So why should I even worry about doing it? So I went to the prompt, I just said, hey, you know what? This is what I need help with. Things have changed. There's no backwards compatibility on a lot of these dependencies. Can you get me the code to get this working? In the ideal AI world where engineers are not needed, where the tool does most of the heavy lifting, if not all of it. One, I was looking. I was wish. It was wishful thinking, as it turned out, but I was looking for an answer where it rewrote the code. But guess what, Brian, it gave me the exact code that we had. Because a lot of these LLMs work on what the data that does exist already, right? So they're not necessarily able to think, not at least at this point, not in that example. So what I got was exactly the code we had. And I'm like, this is useless. Like, absolutely useless. And if we did not have a developer in the team to fix that problem that day, the problem could not have been fixed. Now, it didn't matter if the developers in Argentina or India or Kansas or San Francisco or D.C. but the truth of the matter was there needed to be a developer who needed to do this. So here's how I see it. You don't need to be a developer to build prototypes today. You had to be one six months ago or one year ago, right? So, yep, you can use a lot of these tools and can educate yourself, which is awesome, Right? More people can become entrepreneurs, but I don't think we are there yet or we might ever get there, where you have a team where nobody understands computer science or nobody understands algorithms or coding. Right. Maybe you need fewer people who understand those types of things, but you still need somebody who does. And maybe you need somebody who does understand that very well. Right? So here is where I see some part of what might happen in the next three to six to 12 months is the composition of an engineering team is going to change dramatically. I think it's going to look so different from how it looks today or how it looked one year ago. And arriving at that right composition is not going to be like, hey, I need three developers, one architect, one product manager, one tester, one project manager, whatever. The way we did that in the past, way we approached it, I don't see that happen in future. I think there's going to have to be a level of customization. So no two engineering teams in my mind are actually probably going to look similar, right? They're going to look very, very different is my take on it. Which means if you're running a company, you need to understand engineering because you're building software, but you also need to understand what are those key roles I have to fill when I'm building that piece of software so I don't end up having one too many engineers or one too few product managers. Or maybe, maybe I need three product managers and one developer. You know what I mean? Something preposterous, right? A composition that you may not have thought about in the past. I think there is a chance for those types of things to exist because as we are building more things, Brian, at Snowpal, I recognize the need for a specific set of skills for each of the things that we build that's very different from the other thing that we are building. And I'm not just talking about technology skills, right? I'm not talking react versus Flutter versus AWS versus Google Cloud. I'm just saying just the whole composition of the teams are going to have to look very different. And, and how you create those teams is going to make a big difference to how successful you are in actually creating that. At least that's my take. At least that those are some of the challenges that we, I think, are running into.

Yeah, I love your take on that. I think especially the, the product focused engineer, I think is that's where the education system really has to make sure they, they train future computer science grads on how to think more like a product.

They're not. You know, I'll tell you, I've been talking to a lot of recent graduates, how the schools have been teaching them. At least the ones I've talked to, gone to a lot of good schools and stuff has been very similar to how they would have taught them five years ago or three years ago or a year ago. See, I think these large institutions are like, they don't change, they don't move quickly, quickly, quick enough. Right. So I think it's going to be up to the, the students, the individuals and their support systems to actually figure out where they need to be. So there is a lot of anxiety and I think rightfully so. Right. Things are changing rapidly and everyone says it's only the software developers. Right. I tell them, hey, you know what, it's not just us. If you can replace software developers with AI and AI tools and technologies. Brian, I'm pretty sure people ought to agree that there are a lot of other roles that can be replaced a whole lot more easier. Right. It's going to be a whole lot more easier to replace these other roles. So I don't know why it's just software engineers that everyone seems to come after. I think there are a lot of roles that are going to disappear. It's not just us.

Yeah, yeah, I agree. I do think, you know, the, one of the hardest things to find for a long time was a technical co founder. But I think that minimizes the impact of a technical co founder today because you can vive code and the business person can kind of take it to a certain point and then if, if it's validated, if there's some traction, then you probably rewrite the whole thing into, you know, more professional software.

No, absolutely.

But I think there's going to be a lot more seed funded companies that maybe don't have a technical co founder.

Wow, that is amazing. Yeah. Just to think about the fact that you're building a software company, you're building software, but you actually don't have a technical co founder, which is a statement that one could not have made, you know, a year ago or maybe two years ago. Amazing. Yeah, that's all I have. Anything else for you as a closing comments, Brian.

I wanted to hit on one more thing that you said that I think is really interesting is the analogy I think about is mobile phones. Where the US long had landlines and infrastructure around landlines so it was actually one of the slowest to adapt to mobile. Right. Where countries that never had that infrastructure, almost like leapfrog and they went straight to mobile phone. I think that's the case for software development today, you know, is the people that don't have to like forget everything that they learned and they're just learning brand new. There's a huge opportunity to leapfrog if they lean into the thinking like a business person.

Well, I think that's an, it's very interesting and it's an important point. Right. Because as you onboard people into the team, you know, I've, you know, the last thing I would say is I've never understood why when you onboarded somebody into the team. You always told them how you did things at the company and expected them to sort of make all the adjustments. I always think people who are entering the workforce are the next generation of people are going to run that workforce who are going to run those companies. So it's very important that you come to a middle ground at the very minimum, that you do things the way you did in the past and you also, you do things how Gen Z or Alpha is going to actually want to do things, whether you understand the language or not. I don't understand a lot of the words, so you have to have a dictionary that translates or interprets these Gen Z and Gen Alpha words. But I think it's important to understand how they want to be able to approach software and find a happy middle ground for doing that. Amazing. This was great, Brian. Thank you so much for taking the time talking about all the way from near shoring to offshoring to just the challenges of what it means to build software in the months and years to come. Anything else you want to say before we call it wraps here?

No. This is a lot of fun. I really appreciate the opportunity and the conversation.

Well, thank you so much. And again, folks, this is Brian Sampson, the founder of Plug Technologies. I shared the screen earlier, but we include the link to Brian's LinkedIn profile and the company, so definitely do check that out. Amazing. Thanks a lot, Brian. Much appreciated.

Yeah, thank you so much.