Building Elite Dev Teams in LATAM – Episode 55 of the Agency Operators Podcast

Building Elite Dev Teams in LATAM – Episode 55 of the Agency Operators Podcast Speaker 2: Hey everybody, welcome to the Agency Operators Podcast. Today I'm joined by Roger Einstoss of Braintly. How are you doing Roger? Speaker 1: I'm Haim Saenz. Thank you so much for having me. Speaker 2: Really excited about this conversation. Something that you're doing, I have not had anybody on this podcast who's done that. So I understand that you are now and for many years helping to build development teams sourcing people from Latin America. Is that right? Speaker 1: Yeah, that's right. We started 12 years ago. I've been in the business and industry for almost 20 years. So I started coding when I was 15. So many years working in the industry. Speaker 2: Wow, at 15 coding. So what kind of language was that back then? Speaker 1: I started with Visual Basic 6. We used to be back in the 2006 trend language. Now I think it's a little bit deprecated. Speaker 2: Yeah. What year was COBOL and all of those? Is that before the one that you mentioned? Speaker 1: Yeah. Yeah. Speaker 2: Yeah. My father is a software engineer, so I grew up around a lot of these A lot of these terminologies, but I'm not a developer, I'm not a coder, so I just hear the C++ and things like that, Visual Basic, but I think it's evolved quite a lot. I speak to a lot of developers actually and they're kind of telling me now that it's turned into something more of building blocks because of AI, right? Now you just have like these blocks of code and you're just like putting it together like Legos versus like actually spending time writing lines out. Is that true? Speaker 1: Yeah. Yeah, that's true. That's like an approach that I think it was born when we started coding like object oriented. Now I can see a kind of parallelism between the object oriented developing and the agent development. So at the end of the day, it's always the same, but the industry is constantly changing and you have to Learn new things, but the core knowledge, it's always the same, but you have to be always learning how to adapt to the new era, new technology. Imagine that when I started coding was before the iPhone. Speaker 2: Hmm. Speaker 1: So mobile didn't exist in those times. So When the iPhone was released, I had to learn how to work in a mobile world. So it's something really interesting and common for engineers. Speaker 2: So would you say that it was more simple back then because there was less factors to consider but at the same time you had less tools? Speaker 1: I don't know. No, I think that it's easier today. We have AI, we have ChatGPT, many, many tools that I think that makes like developers' life easier than it used to be. Imagine even maybe 40 years ago when you used to go to like a big data center with your car just to compile your solution. Now it's all on your computer and you can ask to an AI for a solution. And then you have to, you need to have like certain knowledge. It's not just about the AI working for you. But I think it's easier. Speaker 2: Yeah, like you have to know what's going on, right? Like you have to have some kind of Basic understanding, but I guess now would you say like for somebody who's wanting to kind of start understanding or start learning, there's probably more resources than ever. There's more tools than ever. So it's just like the barrier to entry is lower, but in a way to become a very good engineer, you need the experience. So still like people who are looking for top engineers, it's always going to remain like a very high paid position, right? Unknown Speaker: Yeah, yeah. Speaker 1: And besides, I always try to make this, I would say that thinking that AI will replace a developer, it's like thinking that now some pilots in an airplane will replace the pilot. This is the same. Obviously, it's easier to start calling now because of AI and because of the resources that we have in the internet. But you still need those years of experience when it comes to build a complex solution or a complex software because at the end of the day, it's always about solving real problems more than just building software or writing code. Speaker 2: And at Braintly, people come to you and they say, hey, I have this project. I need people or are they more coming to you guys and saying, we are in the process of building this, but the project has gotten more complex. Let's just like expand our team or maybe a combination of both, right? Because I'm sure there's different cases. Speaker 1: Well, you know that it changed along the time because three or four years ago, we used to be really involved in building MVPs for clients. But that changed because of AI because now it doesn't make sense to hire an agency to build an MVP because you should be using AI or no-code tools just to build your MVP in two weeks, three weeks, a month and go to market and start building your solution, not your software. So most of our clients are post product when they have product market fit or they are pretty close to the product market fit. And they need to start building their engineering team. And most of the times they probably try first going to India or the Philippines or Eastern Europe. And sometimes they are not happy with the quality. Always they are not happy with the time zone difference because it's really difficult to deal and work when you are in the startup mode or the growth mode working with someone who is maybe 14 or 15 hours ahead of you. So that's where Latin America. comes to the table. It's one of the things because it's really, really interesting to start thinking about Latin America as a new hub of innovation and software developers. Speaker 2: I see. So that is off the bat. I mean, not even talking about the quality of work or the education that is given in certain countries, because I know you guys are sourcing a lot in Argentina, but also expanding to Mexico, Colombia and a couple other countries in South America. So, not even talking about the way that they're educated there and their experience, but just the time zone thing that I can totally see because I've worked with different time zones and it's kind of frustrating when somebody has to take a call extremely early or extremely late, right? People have families and other responsibilities, so you want to kind of stay within working hours. But also just to have like an ability to have somebody respond to you pretty much like all the time, right? Like, you know, you have a question at this time or you have a question at another time. There's not that huge gap because when there's momentum building, you start a conversation and you can actually get a lot done. But sometimes that momentum gets broken when you're each person is waiting five hours for a response, 10 hours for a response, right? It's very tedious. Speaker 1: Yeah, yeah, I totally agree. I mean, it's not only at Samsung. Also, Argentina has one of the best level of English in Latin America. Also, some of the universities are in the top 10 of Latin America. So it's people that is really well educated, really willing to work in startups because of the ecosystem, because of the unicorn that we created in the last 15 years. But one of the first things that that clients in the US. See, in Latin America, it's time zone because then quality we can discuss. I mean, there are like many, many like high quality teams in India and low quality teams. And also in Latin America, you can get like high quality teams and low quality teams. But the thing is that the time zone is something that you can't change. It's just because we are here in this part of the world. So we are taking advantage of that. Cool. Speaker 2: How do you decipher what is a good team, what's a bad team? What do you think are the qualities that make a good or a bad development team or employee? Speaker 1: That's a really good question. Many times it's not just about technical skills, because you can teach technical skills, but if someone is not involved, if someone doesn't have ownership about the project and is not willing to be a real challenger employee, I think that won't create a high quality team. When it comes to building software, building solutions, growing companies, you need people that not only have the technical skills, obviously you need technical skills, but you also need people that are ready to say, hey, I think this problem must be solved. In another way, maybe not the way that you are proposing. And that's something that you usually will find in talent from Latin America. We have been growing, creating big companies. We have been, we went through like many, many like macroeconomic challenges, especially in Argentina, that we grew up just trying to understand and figuring out how to make things happen. And it's weird, you know, but many times that resilience creates great talent, that it's perfect. And it's a perfect fit for this situation. To sum up, it's not only about technical skills. Obviously, you need to vet those technical skills, but it's more about attitude. It's more about the way they work and the experience they have working. Being a senior developer, it's not just about understanding the best design partners. It's also about knowing how to make things happen. Speaker 2: How do you test for that? Speaker 1: We make like a three steps interview. In the first step, we go through a cultural fit interview because, as I was saying, that's something that is difficult to change. So if we don't have fit, Also with the client, if we don't find the right fit between the client and the developer, it's something really, really hard to change and to teach. So that's the first step. The second step, it's a technical interview when we face the candidates with our engineering team. And we don't want them to solve problems just by heart. We empower them to solve problems being creative and using AI and using Google because we don't want to see how they not only want to see how they solve the problem, but also we want to see how they think. That's the solution. So taking the chance to see how they Google things or how they use AI or how they face like a complex problem that it's not only like a technical problem. It's a business problem. Show us how that person thinks. And the last step is putting them in front of the client to say, hey, this is the person that will be working with you. This is why we think it's the right fit for you and your team. And also the client is the one who has the last decision, because at the end of the day, it will be working with you as a client. Obviously us as a team, but we are all a team. The client, the candidates, we as a company. So that's pretty much the process. Speaker 2: Very interesting. So if I was building a new project, Traditionally, in my experience, I've seen that you have an MVP that you want to go after, as you were mentioning, or you've done some testing and you built that MVP and you saw that it's more of a proof of concept and you want to expand on it. Do you need this entire team with all these different positions? So in my experience, I worked with a team out of India, a very large company, and they assigned to us a number of different people which were on every weekly call as we were kind of developing the project. And there was a quality assurance person. There was a manager. There was somebody that was responsible for this specific thing. Like, you know, they were doing Figma files and those kind of sketches. And there was a person who was the actual engineer and implementing and writing code. And there was somebody else. So we had, I don't know, a total of six or seven people, all these different roles. And I always wondered, like, how necessary is that to have so many different people involved? The scale of the project was not huge. It was a project. There were moving parts to it, but I'm wondering for anybody who's looking to develop their idea, can you get by with just one or two people? Speaker 1: Yeah, yeah. As a matter of fact, I don't think that having six or seven members in a team for a small project makes sense because you spend so many time just communicating and trying to be aligned. So most of our teams have three members, the developer, the QA, and the project manager. And then if we need more developers, you can start adding developers. Always, when a client comes and says, hey, I need, I know, a backend, a frontend, a mobile developer, whatever, I always say, let's start with one. I mean, you're a startup or you're a company that is trying or are testing a new product, so you don't need a backend and a frontend. You need a full stack because you don't have enough assignments, enough tasks. For both, for two people. So don't waste your money. Because my job as a company is trying to save you money. That's why I'm trying to convince you to come to Latin America. And that's why I need you to succeed. Because if you succeed and you grow as a company, I will go with you. So I think that having too many people In the same team, it's not efficient. Obviously, it's about understanding each project, but I'm not a big fan of having too many people. I know that it's something that most of the times big companies do. The other day, I was talking with an entrepreneur. He was working with a team in India, and he told me that he has three IOS senior developers. So he told me he was paying an amount of money that was impossible for a senior developer even in India and the problem that he was facing was that the team was not like shipping on time, delivering on time. So I started asking questions and at the end of the conversation I told him It's I can assure you 100% that those three members are not senior developers. So it's not a matter of number of people. Many times is better to have one people, one person, sorry, with seniority. Instead of having five junior developers, and I always say the same, when you're hiring an agency, you have to understand where is the people, where is located, and understand how are the salaries in that region. So knowing that data, you can understand if they are assigning the right, the seniority they are telling to you or not. I mean, if a senior engineer in Argentina is 5,000, And I'm charging you $4,000. It's impossible for me to assign a senior engineer. So that's important. Speaker 2: And you have to have these three that you mentioned, the project manager, QA, and the developer. To do any project, you're kind of in a position where you have to hire the three. And so if that is true, then why would you go that way if it's just a really small project? Why would you go through the effort of bringing some three people on versus just giving a project to an agency as like a one-time thing? Speaker 1: Well, we don't work with projects that are just one shot because we, after 15 years working with the company and many, many companies, we understood that building a software, it's a long-term thing. It's not just about working for two months and that's all. So we work in two different ways. When we have technical founders on the client side, we can assign only the developers. That's more like a staffing model. So if you are the CTO and you know how to manage the databases of the developer, probably you don't need a project manager. So we will give you only the developers and you will be the one who will manage that relationship. But when it comes to a client that doesn't have technical founders, we assign That's it. With the project manager, with the QA, and with the developer. Because you as a non-technical founder will need this project manager role to have some interface between your business ideas and the developer. Because if you are a non-technical person, you don't know how to talk to a developer. And the developer probably will not understand you. That's why the project manager comes in the middle of that relationship. So it really depends on the kind of project and the client. Speaker 2: And can the project manager do the QA's job? Speaker 1: That's a critical question. We are testing now some AI tools. We are testing an AI tool that allows us to I would say that we don't need a QA, but in some small projects, maybe the project manager can take care of the QA, thanks to this tool. But it's something really, really early that we are testing now, but QA will be necessary because they know how to create like the testing scenarios, even more if you are thinking about automating QA. The answer is it depends. Speaker 2: Okay, fair enough. And do you need to hire full-time all the time? So I understand what you're saying that software is a continuous thing, but maybe some people they have a limited budget so they can't afford a project manager or a senior developer for, like you said, $5,000. That's monthly, right, in the U.S. So let's say that the total budget for a development project is $4,000, $3,000 a month, let's say $3,000 and there's a six-month timeline that they can spend. So they have $18,000, right? Are you able to get those three people on a part-time budget and is that more efficient than hiring an agency for that same $18,000? Speaker 1: Well, in our case, we don't work with partial assignments because many times when you face a client that can't pay a full-time developer, If you assign a part-time developer, it's a ton of money for them, but they think it's very, very difficult to make them understand that they don't have full-time person. So in my experience, at the end of the day, they feel kind of disappointed because they feel that they are spending a lot of money because they are hiring someone part-time because they don't have money. So that money for them is a big amount of money, but for us, We are always in the position of saying, okay, this is what we can do with a part-time person. Imagine that it's a person that is only working four hours a day for you. After that, The developer needs to change to another project. So that's why along the years, we understood that working part time, it's not for us. And also, assigning people full time allowed us to focus on another type of client. Clients that understand that they need a development team, they have revenue, they have profit, they see the advantage of hiring in Latin America. And also, coming back to the first point of AI, using AI, most of the times, or very first clients, 10 years ago, 15 years ago, now they can build their solutions using AI. We'll be using a freelancer. So that's why, you know, five years ago it was normal to charge $60,000 for an MVP. Now it's insane. I mean, I'm a mentor in different organizations and I always say, don't spend more than $10,000 in an MVP. Because you need that money for marketing, for sales, for hiring an engineering team after you found the product market fit. So things changed in the last two years, three years, five years. So that's a way of, that's something that helped us to find the right client, the right fit and the right size of company also. Speaker 2: So if somebody wanted to reach out, how can they find you, Roger? Speaker 1: They can find me only if I think I'm the only Roger Einstoss in the world, or at least in LinkedIn. So if they find my name and surname, they will find me. They can also go to our webpage, that is braintly.com. I'm also on Twitter, but it's just for personal uses. Cool. Speaker 2: Thank you for the conversation, Roger. This was really insightful. Speaker 1: I wish it. Speaker 2: Thanks everyone for listening. Catch you on the next one. Bye for now.