Sebastian Alvarez, CTO of Remotely, The New Framework for AI Software Development

[00:00:04] So, Bas, okay, so months in the making, you just came back from a hell of a trip. First, well, let me press it for you listeners out there. So, remotely, I would argue, has been, and our platform data shows it, by far one of the leaders for the science behind evaluating and measuring what makes good software development.

[00:00:33] Down to the way you evaluate developers and down to that massive, massive research you did where you basically broke down what? Every single repo and then used AI to analyze that. And so, listeners, we have the brains behind probably the biggest brain of how software development gets done, right? In a good way.

[00:00:55] And we had Jose, so, you know, listeners, go back and listen to Jose's episode, you'll get the business mind. And now we get to have the fun, you know, the fun, real brain there. But the first question to us is, how do you feel about the loss?

[00:01:12] Well, as a good geek, I don't really care about soccer, football. But it was bad. Also, Spain deserved it. It was a bad game for us. I mean, I guess I just got hated by everyone in Argentina by saying that. But it was bad. It was bad. Argentina didn't play well. I was going to ask, is this why you're not in Argentina right now? Like, did you say soccer 20 years ago and they kicked your ass?

[00:01:41] Probably true. But no, I'm not. Actually, I'm in Spain, so it's even worse. So, no, the game was bad, I would say. I mean, it was very good. I mean, Spain deserved it. But I was in Dominican Republic when I watched it, so I was rooting for Argentina, but away from Spain, so it was good for me. I was going to say neutral territory. Probably smart for your own safety.

[00:02:08] Exactly. But it was full of Argentinians in the aisle, so we used a big group. But it was fun. The two previous games were good, actually. Egypt and England was good. Do you think he'll come back? Is this his last one, or what do you think? Yeah. Who can buy? Messi. Messi? I don't think so.

[00:02:31] And mind you, I'm not a football soccer fan, so I'm saying this all just totally pulling out of the air and hoping it's directionally even close to right. I don't think so. I don't think so, but hopefully. Hopefully. But I don't know. I don't think so. So I have one more fun question, and then I promise I'm done. Argentina, you guys have the best beef in the world. Why?

[00:03:00] I guess because we like it too much. And we perfected it. It is true. Now that I'm in Spain and people here like beef too. So we do it completely different, and I like it in Argentina better. We love beef, I guess. I mean, I even... So when I moved to Spain, I lost my ability to eat beef compared to when I was in Argentina.

[00:03:27] Because we eat so much, then when you come here, you eat less. And now when you go back, it hurts. And I actually had beef sweats when I went back to Argentina a year ago. And I never had that before by leaving there. So I guess I'm losing... Between calling soccer instead of football and having meat sweats, I think I'm losing my Argentine EP. So if there's ever a point in this episode to delete, this is the part to delete, right? Exactly. I refuse to delete this part.

[00:03:57] So let's get into the brains, okay? So like I said, you guys had this crazy, crazy, I don't know, years of evaluating the world's GitHub repos, right? From my understanding. But before we get into that, just give our listeners a quick overview. Who you are, how in the world you got to remotely, what you were doing before. Yeah, this is that boring part. I'm Sebas. I'm originally from Argentina.

[00:04:26] As you probably heard before, I'm now living in Barcelona. So I founded remotely with the same founders that before I worked at Olapik. My co-founders were previous founders at Olapik. It's a New York-based company. And I was living in Argentina. They hired me as their first engineer.

[00:04:50] It was my first real job to bring it away because I worked before, but it was more like freelancer type of developer. And now I dropped out of school, actually, because I never finished school to fly to New York and work with the team from there. And then I went back to Argentina. I built the engineering team up to almost 100 people. And then the Codola office became an overall office. We had operations, sales and all that.

[00:05:19] So I was managing the main office in Argentina. Then Olapik got acquired and the founders each went their ways. And a couple of years later, they called me and said, hey, we want to build something later. We want to build remotely. What do you think about it? And I loved the idea. So I jumped in and we started. I started from Argentina and then I moved here in the process. Which, give me, let's go.

[00:05:48] We usually don't do this, but let's go back to tell me how many years ago and tell me what it was that made you say, let me, let's go forward with this. Because there is such a difference between I'm going to take a job and I'm going to start a company. And so you must have had, right, these crazy, I don't want to say visionary, but like these crazy, the world needs to be this way, not the current way it is.

[00:06:11] But let's go back. Tell me how many years and why you were like, I'll jump on this crazy rocket ship that might totally sink because starting a business. So we started remotely, I think, five years ago. And before that, we worked together with co-founders for nine years, I think. So I knew them very well. I was not enjoying the work that I had at my previous company.

[00:06:39] We got acquired by a company that it was not fun. It was a big company, a lot of processes. They were public. So with everything, what means like being public, a public company, a lot of scrutiny. The revenue was not going well. So we went like, we were getting cut and cut and cut until that is most steam. It was not fun. And when Powell called me with the idea of remotely, it was not called remotely. The original idea was to build teams.

[00:07:08] The whole idea was that at Olympic, what we did was that they founded a company in New York and they hired the engineering team in Argentina. And the whole concept, we were, it was not normal for startups from the U.S. to have their engineering team abroad. And even investors will frown upon on the idea because it's like your whole team is like a product. How do you know they're doing the proper work?

[00:07:38] Like, do you even own whatever they do? So, but we were able to build a very good engineering team, actually top people from Cordoba, the city we were working on, because we were the only startup. And we were not only the only startup, but the only American startup. And by the way, by that time, the whole Silicon Valley TV show was going on and we were the, we were playing the Silicon Valley idea from Cordoba, right?

[00:08:05] So it was new, it was fun. We had incredible salaries for the, for being in Argentina. So we were the cool kids back in the day. But the whole learning that we did was how do you make sure that the engineering or the product team delivers value from a bazillion kilometers away from the main office and where the clients were and where they were having conversations.

[00:08:35] So that was our value to put in the way. We were able to build product for less money being abroad. So the whole idea was, can we teach other companies do the same? Can we teach other U.S. companies how to have their team abroad and, but, but do it properly and, and build value from Latin America based in the U.S.?

[00:09:05] And that was the original idea. And I think we proved we can. And the whole spin-off right there was also doing it remotely. Like the, the, the, the original generally way of doing it was like you fly to Buenos Aires or you fly to, I don't know, Peru, Lima, Peru, or whatever city, Rio de Janeiro, Sao Paulo. And you will like set up a whole office.

[00:09:32] You will hire a bunch of people and then set up the desks and ask people to work from there. Uh, but that was basically, uh, you will only tap into the, to the talent that was in that city. Right. And I was like, we should do it, but do it remotely also because I didn't want to have an office. I didn't want to manage an office again because I did that for nine years and I was the worst.

[00:09:54] Uh, and I wanted to travel the world and my whole, my, my, my biggest regret on my previous work was that I made it very, uh, well for me to not be able to leave the city because I, I had to manage the office right there. So I was like, I don't want to manage a team that is tied to a city. I want to have, and so the whole idea was in a row and it worked.

[00:10:19] And something that helped us, I would say is that by month eight, I don't remember exactly, COVID hit. So the whole idea of remote work became cool. Um, and from that moment on, we, we, we grew. Let's, let's, let's dig now. So, okay. Hypothesis, you did it yourself instead of, you know, building a full-time team in Silicon Valley and New York and Boston.

[00:10:50] It makes more sense to do it abroad. Right. And specifically in the LATAM, which I mean, it makes, it makes total sense, right? Time zones are, are closer aligned. There is a closer cultural, uh, mix. Less competition. Less competition. And then we'll, and then from a leverage point, right? Like you, let's say you're a series A, series B startup. Do you want to be the cool kid in, you know, Argentina or Peru?

[00:11:16] Or do you want to be the same kid in Xenon. Right. It's like, obviously you want to be the cool kid because it's caught up, right? Which dovetailing into this. So give me a lay of the land of just software development in general. And there's one question that I know a lot of our audience is faced with, which is why not just lay everyone off and have one person run Claude, which we know is not the solution, but you have the actual brains behind it.

[00:11:45] And so let's just start by like, dude, answer, answer that question to us. Like, why not just lay everyone off and use Claude? I would say that the, um, I don't remember who said this, but I read it on a, on a tweet saying that the, the code was not the, the bottleneck. Like, like it's not about, um, writing the code is to actually write the, the proper code or the, the, to solve the solution, to solve the problem, actually. The proper solution.

[00:12:13] Um, I, I think that the main problem now, even now with AI is that we're, we're writing too much code that, that nobody cares about. Uh, so the, first of all, you cannot fire everyone because you can, you must still run whatever you have built.

[00:12:37] Uh, and not every piece of code can be managed by AI properly. And I being beaten by this. Um, so this is the first reason.

[00:12:49] And, and then you have, so I think that the, the, the, the same team that you have with AI can help you build a better, uh, product because you're, you're, you're, you're having more hands to, to define properly, to think properly, to, to build properly.

[00:13:11] Um, and I even think that the, like the front end engineers that you have in your team, if you give them AI, maybe they can, they can get closer to the customer and now become closer to like, I don't know, designers. Right. And, and, and you can, you can tap on the design skills and, um, iterate faster on how your product looks like.

[00:13:34] If you, your backend engineers can allow the full stack engineers, they prototype faster and then your backend engineers can now go and sweep and clean the code that you're, that the, the AI is writing. So, um, it's not about replacing, it's about teaching them how to do better and forget a little bit about how to write the code and worry about the architecture and the quality of what you're writing, but let, let the AI write it. Um, yeah.

[00:14:04] I remember when I, when I went from developer to manager, I had to transition from that when, when our team grew. I remember that I was saying that people were asking me, do you, do you, um, do you regret moving from developer to manager? And I was like, well, I sometimes, uh, I sometimes want to code more, but what I had to learn is how to code with someone else's hand.

[00:14:31] So my, my goal was that how do I convince this person to code what I'm thinking? And I think with AI is the same thing. Uh, you have to like, how do I convince this AI to write what I'm thinking? Uh, but it does it like a million times faster than me. Which I would, so I want to double click on, on what, uh, what I would call context. Um, and let me know if it's the right technical, uh, way to put it. But so I want to double click on that.

[00:14:59] And then I want to answer the question, well, what does the proper team look like? And I want to get as granular as like, does it look like all full-time employees in Argentina? Does it look like a mix of full-time contractors, some in US? So that's where we're going to get to. But in this context point, um, I can't agree more that the ability to like productivity is probably the wrong metric, right? Like if you are evaluating right now based off of lines of code, you're screwed.

[00:15:28] Just like if you are evaluating your marketers based off how many articles they've written or whatever it is, like productivity is now blown off the door. With that said, the context to be able to navigate the AI is by far the most critical thing. And I'll give you two examples that have hit us this, this week and this month.

[00:15:47] First is, um, someone had asked, you know, had asked me like, how do you know, like, how have you iterated so quickly in terms of the way you built human cloud? And my answer was, well, because I already have the context of 15 years of this industry. So I'm literally having this partner that will do all the work that I prior had to do over weeks, but it'll do it like this. And I'm, I'm giving it the context though.

[00:16:14] So like, if I was telling it generic stuff, it would, it would not work. Right. So it's, it's taken 15 plus years experience in this industry. Second one though, was we had automated this podcast and automated our media. Now we, and not just automated, but we had three X the productivity. So we were able to post like 10 social things a day and whatever it is. But so we bring in an expert in growth and what's the first thing that she does?

[00:16:42] Not use more AI, not create more, actually nuke basically the overall plan and direction in a way that now our AI is properly aligned. And we have, you know, a brand new brand in a way that was only someone like her, right? With her context would have been able to build. So AI was almost getting us in worse trouble when the foundation wasn't right. So all that to say, code is no longer king, context is king.

[00:17:12] And you have the keys to knowing how to build the right context and right keys. And so from a software perspective, what does the best team and the best structure look like right now? So you reminded me of something that I thought a couple of months ago when I was testing AI for different things.

[00:17:37] And I realized that I was very, I was for things that I was bad at, I was still bad with AI. It just made me feel more useful because everything I do with AI for the things that I was bad, it was still bad. But I was doing a lot of it. It doesn't make me better at something. So, but it made me way better at coding.

[00:18:05] So I think it depends on what you want to do. But I think my favorite team right now with AI is a product manager and a full stack software engineer. With AI, both running AI, right?

[00:18:22] Because you can have a product manager going ahead, talking to users, figuring out, having the conversations about like what matters, prioritizing the things that we should be doing. And then a software engineer with AI iterating very quickly into the details and worrying that it runs properly, that it scales and all that.

[00:18:47] So if I could do everything all over again, I would have a bunch of teams of product manager and designer and let them go and try stuff, iterate, give it to users. And then work on connecting that into the main platform.

[00:19:10] So you will iterate a lot of an experience and then merge it to your main platform, ship it and continue. That is what I think is the best approach. You probably need at least one or two other engineers running around, like giving you the infrastructure to run all that.

[00:19:33] You probably need a bazillion agents helping you synthesize PRDs. And something I also, this is maybe not specifically on how to build product, but on how to run a company. I would probably have one of these teams or two building the harnessing of the company.

[00:19:59] So building the tools for the operation team in your company to run better. I don't know, like for example, in our case, we use Drain and we record every meeting that we have. And this is something that I love about Remotely is because we started remote from the beginning. All our meetings since day one are recorded. So I can go back five years ago, read the transcript and remember what we were talking about back in the day. And that is context, right?

[00:20:29] And I just add context on top and I can distill information. So if you do that with, for example, all the meetings that you have with your customer, you can have a very, very rich, detailed thought of your customer. And then you can build on top of that. And you can, if you have the tools to tap on that, because it's hard, it's a lot of information.

[00:20:52] You have to summarize it and you have to learn how to synthesize it, store it, so on and so forth. Like, I don't know, transcribe multi-language audio and things like that. So having a team in your company who can help you do that to give data to the product managers to build a better product. I think that's a loop.

[00:21:18] Would it be really dumb to say that the best possible team right now is the talker, the builder, the designer? Meaning the talker is the one driving sales, driving customer relationships, and honestly, getting the talking that feeds the recording. Because that's one of the things, right? It's like, you can record everything, but like, do you have the person who knows? Ask the right questions, build a report. Right? I totally agree. And now on builder and designer, so here's a question for you.

[00:21:46] So Satya came out and said, hey, you know, at LinkedIn, we've reduced five roles into one called the builder plus. Now, traditionally, there was always what? The front end, the back end, the full stack, the designer, the product manager. And you would have these like eight person teams just to basically focus on one thing. What does that look like in the age of AI? And I'll also give you some more context of we've seen multiple customers now come to us say, hey, we want AI developers.

[00:22:15] And we turn around and we go, define an AI developer. And they go, oh, a developer that can do everything with AI. And I'm like, listen, let me tell you, I don't think that's possible. But if it is, Savas would know. But so how do you view the whole like, okay, now it's just one developer who does everything versus what used to be front end, back end, designer, yeah, yeah. So actually, we had a lot of customers asking for the AI developer. And the first question we ask is, what do you mean with that?

[00:22:42] Because I think that we have three main types of AI developers. I would say that we have the engineer who uses AI to code, code, codex, whatever. The engineers who actually build with AI, I would say that integrating open AI in your product or like 11 labs or like where they use AI tools or mainly AI tools to make your product better.

[00:23:08] And then you have the hardcore machine learnings guys who are probably modifying models, making models better for your specific use case and so on and so forth. So the first question that we ask our customers is, what do you mean? What are the three from those three? What are you looking for?

[00:23:28] And then I think that if we think in the future, I think that the engineers who will last are the ones with the best social skills where they can translate from conversations,

[00:23:50] from the needs of the user and being able to convert that into software, decide what's the best architecture, the best solution for that problem and go back and let everyone know what you built and show them why you built it that way and how you built it. And I see that over and over.

[00:24:14] However, the engineers, the AI engineers who get hired are the ones that are best at explaining what they built and how they built it. Not because people care about how they built it, but because they are able to articulate the requirement back to the user and explain to them why they built it that way.

[00:24:38] Versus the classic engineer who would just get a PRD, write it down, execute and go back and say ticket done. Those engineers will die, I think, because the value now is the communication. And the closer you are to articulating, those are the engineers that will last.

[00:25:04] And then you will probably have engineers who have better skills for something. Maybe those who are front-end more, we have an eye for detail and they will build better UIs or better UXs versus those who will do back-end who maybe are better at architecting software. But going back with what you built, show it and making it appealing for users to pay attention to it and use it. Those are the engineers who are going to last.

[00:25:34] So let's do a funny exercise because I'm trying to get as practical, tactical as possible. So let's say I'm a CTO. I have probably, we'll say $5 million that I've allocated towards talent, right? And I mean, historically, that might mean literally just a couple of developers, right?

[00:26:00] If we're talking about Silicon Valley talent, I might be out. We'll reduce it to $2 million. So I might be out if I only got $2 million. Now, it seems like the world is my oyster in terms of what I can do with this $2 million and turn it into $10 million. But how would you, like, how would you structure? If I say, Sebast, I got $2 million. We got to build this platform. What would you tell me? Would you say hire one person paying $2 million?

[00:26:30] Would you say hire those three? What would you tell me? The first thing I would say is that $2 million is a lot of money. I would build several combos. Like, I want to say the product manager with maybe two product engineers with AI.

[00:26:55] And I will give them each team, each two or three, depending on the size and how much you want to build. And maybe drop a designer right there to help them build. Or maybe the three are, like you said, the talker, the designer, and the builder. Give those three a KPI and go run. And the KPI should be a business KPI, but give them the power of building product for that. And go.

[00:27:26] I love what you mentioned before. If you could just double click. When you had mentioned, you know, you build a couple pods, but there's that one pod that, how'd you say it? They were just focused on internal, like, harnessing and building up that org context. Can you tell me more about that? That to me, so the way, so I can use examples for that for ourselves.

[00:27:54] For example, one of the things that we built internally was a chief of staff. And that chief of staff, the main feature was that we wanted to give it access to all our data, our business data, our BI, right? Our BI database. And let everyone in the company ask questions about the business and have proper curated data back.

[00:28:22] So you can say things like, how many engineers are we, I don't know, how many engineers are we getting hired every week, every month, every year? Or what type of companies are opening more openings? And things like that. And that took a while. But that took a lot of learning, technical learnings.

[00:28:46] And I mean, when I said about transcribing multi-language audio was a problem that we had to solve. How do you solve for transcribing people with thick accents from Brazil? Speaking in English, right? Those are the actual problems that you have to get a very good transcript. This is our reality, right? And then how do you connect that to HubSpot?

[00:29:11] So that HubSpot has, when a customer comes in and they apply to remotely asking for a demo, we can, on that same lead, include in that lead possible candidates for that customer. Because we saw they have open positions, right? We navigated their website. We found open positions. We matched that to candidates in our platform.

[00:29:37] And we added, so how do we build this extra layer of information on top of the tools that the demand team is using? To have a better meeting the next day they apply. Gotcha. That is a lot of software. That is a product manager talking to our own sales team, looking at how they are doing,

[00:30:02] trying to make it better, building the harnessing for open AI with HubSpot and connected it. And then the same on the other side. We build things like AI-based interviews or automatic matching, something like that. And that is software that we build for ourselves, right? And we would never sell that to anyone. It's software for us. And it has to scale.

[00:30:31] And it has to, I mean, the same problems that you have for a tool that you will build for, I don't know, a thousand customers, you would do for us because it has to run. So I got a question specifically on the job description. Kind of coming back to this, okay, I have $2 million and, you know, in your, what I would, how I would generalize what you told me was, okay, take that $2 million,

[00:30:56] reduce it to probably one to three business metrics or, you know, core KPIs that you need to hit and then resource around those KPIs and literally resource with a talker, a builder, and a designer. And some KPIs might just need one. Some KPIs might need two or three. So, so, you know, that is very practical to me. So for you listeners out there, you know, take your top 10 problems, reduce it to three, and then resource based off that.

[00:31:23] But now we're in the stage of, okay, I understand that. And I'm so, I'm so much happier that I no longer have to stand up a PM, a full stack, a front end, a back end, a designer, right? So I have so much more opportunity now. But with that said, I need to create this stupid thing called a job description, right? And I need to get actually spec out either the project plan or the spec doc or the JD.

[00:31:53] So what is, what does this job description look like? Because also part of this, a lot of hiring managers out there, they were just given a JD that their colleague used, right? So they didn't have to create anything that net new. And it was nice that like a five-year full stack developer, I can find what that JD is going to be online easily. But now with AI, that's all blown off the doors. And so do I just ask Claude to create this JD?

[00:32:21] What would you say as the buyer side hiring manager that has to create the JD to do what we just said we were going to do? How do I do this? I would tell everyone to do the same I did. Record yourself with Whisperflow and ask Claude to write it down. But I think that description looks like you're looking for an engineer who,

[00:32:47] so I think that you don't, if you're actually running AI and you can, if your code can actually be developed with AI, which is a big thing to say, to be honest, because not every old product can be developed with AI. It depends a lot on how your infrastructure runs, how your code is built, et cetera. But if you can,

[00:33:15] you forget about the language that your platform is built because AI can write in any language. You forget about those details and you care more about what, so I would say first, what defines your culture as a company? Because in essence, you want to find an engineer who fits your company, less in the technical side and more into how you work

[00:33:45] and what you value. So I would put a lot of effort on what's your process look like for deciding what to build? What type of people fit in your company? Are you a nine to nine, seven days a week type of company? Or are you a Monday to Friday, whatever? Are you expecting the engineers to solve every problem? Or are you more product-based,

[00:34:14] meaning that everything has a PRD and you just execute? Or are you more into the, I want to take you to the meeting with the customer. So not every engineer can meet a customer. I would focus more on that and less on the technology that you use and all that. because I would say that any good engineer should be able to, with AI, work on any platform, quote unquote.

[00:34:46] I would start from there. And also I would stop doing the technical test. Like I don't think that the technical test has any value anymore in the sense that writing code by hand is not a feature anymore. And you should meet with them. Like you should actually talk to them. You should ask, you probably ask them to record a video and then talk to them

[00:35:16] and talk to them to look for cultural fit and less on technical. Like will this engineer fit your team? And how you want to work? And less on the technical stuff. But ask a lot of questions on what they built. Yeah. So that makes total sense. It actually validates two things that I'm like, I didn't pay you to say this, but it was very validating

[00:35:45] because one validation is I do believe there's a place for like talent leaders, whether it's HR or people ops, whatever it is. I do believe there's a place for them and increasingly more strategic, valuable space for them. And what you just told me was if culture is first, then I'm sorry, but your typical CTO, CMO, CRO, yeah, they're not exactly cultural experts, right? So no one knows

[00:36:15] the intended culture better than a talent people ops leader. So that's validation. One is damn, okay, like there is really a place for good, good, good talent leaders. The second one, which you didn't explicitly say, but I implicitly heard is there's a lot of support that is going to be needed for this. So if I am hiring an engineer, I don't do it that much, right? Like I'm doing it, I don't know, maybe once a year,

[00:36:44] once a quarter, but either way, you guys are doing it every single day. And so if I'm doing this, especially now that it's so new, I, I don't know what I don't know. And I definitely don't know a lot. And so you need a partner, right? Which is my, my, our second thing is, is we fervently believe that the future of work is not directly connecting with individuals. It's directly connecting with new types of partners that are directly connected with individuals.

[00:37:14] Because you, which you're going to into the next segment, which is give us the science and the brain of how you figured out what makes good developers and literally the science of why it remotely, you guys are doing so well at placing the right developers to the right team to the right problem statement. But so you validated the two things, which is there's a place for talent leaders. So you listeners, that's a good thing to hear. And the second thing though, is you need to find the right partner versus doing everything yourself.

[00:37:43] But so it's about, let's, let's literally dig into the science of what makes remotely so powerful. And we can start with the massive research project you did across the GitHub repos, if you want. I'm just going to give you the floor, show off, brag, and tell us data on what's made you all so good. So, I can tell you a little bit about the technology that we built at the beginning, how we bootstrapped our database of engineers,

[00:38:13] our network that we called, and then how we cheated a little bit. So, when we started remotely, we were, we only, I only knew the people who worked with me and my friends, right, from Córdoba. So I was like, okay, I can do this, but I can only tap to these people in Córdoba. They're all great people. They're very well, great engineers, but I will probably need more, more than people

[00:38:42] that I know about. So, we met, we heard about these people from Spain who were doing GitHub analysis and they basically were looking at every comment that happens on GitHub and analyzing those comments. So we called them, Cabo called them, for those who heard Cabo talking in the other episode. Cabo called him

[00:39:12] and we said, hey, can we, we want to help you build this, but we wanted to build it in a way that we can map every engineer in the world, learn about what they do or what they are doing, what they are good at and use that to find, to help them get work in the US. So basically, can we tap on every engineer in the world outside of US and help them find a job

[00:39:42] in the US? That was our plan. So what we did is that we literally analyzed the firehose from GitHub, analyzing every commit that happened. We would map them to people. We were learning how, like, the technology they use, how many, if they did more commenting than writing code, if, how many pull requests they created, how many other people they work with. so that we were mapping GitHub, public commits.

[00:40:11] So all of this was information that people were putting out there. We were just mapping it. And we used that to bootstrap our database of engineers. So we started to connect with these people. We were on one side, like every marketplace, we were on one side looking for open positions, like we were getting customers, opening their positions, and then using those job openings to tap into this GitHub database that we built,

[00:40:41] and say, okay, these are, these 5,000 GitHub handles seem to be good profiles for this position. Then we, and that's when we started doing the profiling. So our first feature was English. So we started having conversation with all of them. We will record them and ask them questions about what they like to do, their best technical efforts that they did, where they were working at. And one of the questions that we

[00:41:10] did a lot was, what type of work do you want to find? Because we use that to match cultural fit, which is what I said before. For that, we found a team of sisters from Cordoba who are, one is a psychologist, another one was an English teacher, who were doing HR for, for, I think, their whole

[00:41:40] life. And they were an incredible team doing this cultural fit matching that I'm speaking about. So they had a very good sense for understanding what was important for the customer in the sense of cultural fit. Like, the type of question they would ask was, what type of person do you want to work with your team? They would ask questions about how the team was built, where they were finding these people, what they

[00:42:10] value the most. And using those signals to try to, and when we interview candidates and we had a huge number of candidates, we were trying to match the signal, right? And saying, and this type of candidates will say, I prefer to work at a startup or I prefer to work in a reviewer company. Or some people say, I worked at a startup and it burned me out. I worked for two companies that went to hell and I don't want that to happen to me again. So we say, okay, this is not a great candidate for

[00:42:39] a startup. This is a great candidate for a scale-up or for a bigger company. And we would tag these candidates in such a way that once we got the customer, we knew from where to find. So because we were looking at the heat half, we already had a lot of signal on the technical side. We already knew their technologies, we already knew how good they were at writing code, at writing comments, how much people will accept in their pull requests and all that. And we

[00:43:09] were matching that with a personality, cultural type of information and we started matching and it worked. And now what we did is a lot of that, a lot of times, like you said, reps is what gets you there and we just did that a bunch of times. I don't know the numbers now, but we have almost 8,000 accepted candidates in our network from more

[00:43:38] than 200,000 people that we will probably be tapped into, talked to, interviewed and all that. And on the same side, I'm a customer. So we know how to profile customers and we know how to profile people and try to match them. So you ready? So here's the summary of the episode, like literally from start to finish. So we started and rather than code, it's now about context, right? So rather than a million lines of code, it's about

[00:44:07] the one singular perfect context that creates X my lines code. So context is king now. Second, how do you know or how do you get to the people or person that creates that context? And what I was surprised to hear, but glad I did, was you saying you look for culture. So it's no longer the technical test, it's the culture. Now the third thing that we

[00:44:37] have not talked about and intentionally I'm going to shut you off from talking about it because you listeners, this is when you go reach out to, if you're lucky enough to hear from us, they're probably going to hear what? From Cabo first? But so the third thing that I want to mention is, well, what we haven't really talked about is what is the model to do that? And model encompasses, you know, how do you engage with this person? Do you hire them directly? Are they a contractor? Are they just working on a project based?

[00:45:06] Which the wrapper around this whole episode and why we even exist is because our belief is you have to partner. And rather than going with a staffing firm who literally can't do what you did to us, right? Like, in one way, you are as easy to work with as a staffing firm in terms of it can be staff. Here's the exact right person, go, right? In another way, I'm sorry, but a staffing firm does not have the technical capabilities to do exactly what

[00:45:36] you just did. Instead of investing in the GitHub repo deep dive, the staffing firm really only invests in a really good account management sales layer and manual recruiters, which, it's not bad. It's just the way the world was 10 years ago, so that's what they had to optimize for. You have optimized for today's world, which is a network driven, human cloud driven, whatever you want to call it world. So, the framing I would say of this episode is, according to you, and I

[00:46:05] think everyone will understand this the deeper they get into AI and software development, context is king. How do you get the context? You screen for culture, not for technical specifications, and how do you build this right model? Just go to remotely, right? And sorry to talk like a salesperson, but just go reach out remotely. The last question for you, Sabas, and the most important one is, what is the one thing you want our listeners to do right now? And you can say,

[00:46:35] fly to Argentina to have some steak. You can say, call it soccer, not football. What is the one thing you want them to do? And then let us know where to reach you. the one thing I wanted people to do is to call us and let us help you find engineers. I love it. I thought you were the technical guy, man. I thought Convo was the sales guy. I'm a founder. also.

[00:47:05] Listen, man, the reason I get so excited about solutions like y'all is, your founding team is still intact. That's another thing as well. You're not dealing with the CEO that a private equity firm placed. You're dealing with the people who, I'm sorry, but if you guys mess up, you're going to be really sad and you're not going to let that happen. We are all still deep in the trenches. I'm still working with the talent team, interviewing, I'm still meeting customers. We're

[00:47:35] still in the process, even five years later, because we love it. It's a different world. But Sabas, thank you for hopping on, my friend. Listeners, go reach out to remotely ASAP and just go higher. I don't even care. Whip the credit card out. Just go higher. Open up the PA, whatever you got to do. But Sabas, thank you for hopping on, my friend. Thank you. Thank you for everything.