Empowering Local Engineering Communities: Why It Matters – CTO Talks

My pleasure.

Of course. So, a quick spiel about my latest enterprise. It's called Avansoft. It's basically a hybrid between offshoring and hiring software development locally. And the reason why we came up with this is that we're trying to solve the developer shortage. Today, hiring local developers is quite expensive for many companies, prohibiting them from developing their own software.

And pure offshoring tends to result in either very low-quality software with a lot of difficulties between the management of a company that's hiring and the offshore engineers in understanding each other and delivering that which brings value to the company. So, when coming up with Avansoft, we were trying to think how can we address this specific issue. And our idea, actually resulting in almost a school, as Dmitriy pointed out, was to do the following. We know that local engineers then matching the cultural traits of the company hiring them will often lead to the engineers delivering the closest value to their requests. They will better understand what managers ask because the latter are used to working with local engineers. They know the language, so they aren't in much of a language barrier. They're in the same time zone. There are a lot of advantages to having local engineers.

So, our idea was, why not pair within our company a very top-level senior tech expert who is local to the place of the company hiring an offshore engineers team that this local expert is already used to dealing with? He understands the second language, knows how to work with them, and knows their work's cadence.

And by pairing these two, this very senior engineer as a liaison between the company and the offshore engineers, we can do two exciting things:

• We can develop software at a lower cost because the offshore cost is lower than the local cost in these international communities.
• We can use engineers that are still early in their careers.

And that's where the very interesting aspect lies. Since these engineers are working with the senior, he is explaining what to do, reviewing their code, and ensuring everything is up to standards. And over time, they develop their skills and grow in seniority in a way that is hard to do if they're only assigned to very specific hyperlocal tasks that we usually assign to junior engineers when they're joining a company.

So, we can shorten this span of growing an engineer from their junior to senior levels and have them partaking in bigger and bigger projects over time. The idea is to create this hybrid approach between offshoring and local, to both serve companies while developing talent in communities worldwide. Today it's very important for companies to have a purpose. We actually source our engineers, the offshore engineers, almost exclusively from communities that are not usually very socioeconomically developed. They might be incredible communities, but they're not seen in these economic hubs, so they tend to be economically poor. And by hiring specialists from these communities, we can also start developing these communities.

Well, you know, every place is different. And if you go to different cultures, it's even worse. There are stories all over the place. As I said, I used to be a consultant at the time. And we were moving all over the place. And even in different languages that are quite similar, you find the same situation. Let’s take Portuguese and Spanish. Well, if you know Spanish, you move around Portuguese and the other way around. So, a couple of lessons and you have it. You think you speak Portuguese, which is a complete mistake.

I remember that one day we were talking, not with a team, but this was an auditorium. We had around 150 people. And we were talking about logistics, and we were talking about transportation. And actually, the way you call a bus in Colombia means something not that nice in Brazil—so same story. We're trying to be very organized. We're trying to send a direct message. And at the end, we said something that sounded different.

So, you can have plenty of those examples. And that is where you understand that reality is that when you start creating a team, and this may sound really strange for CTOs, the technical piece is probably 20% of it. Because, yes, we have to be technical. We have to know our stuff. But we have been doing that for the last 30, 40 years. We have been technical our whole lives. And there's a moment when we are not asked only to do that in our career. We're asked to do more, to know and understand our teams. We're asked to make sure that our teams are better.

I remember this happening 20 years ago. I was with a boss of mine at the time, a great, very intelligent guy. And I remember coming in from a meeting, and he told me, hey, how did it go? At the time, it was in my early 20s. And I said, right. And he said, why? And I said it was the smartest guy on the table, everyone was hearing me out, I was sending the best ideas, and it was awesome! And he looked at me and said, “You're really, really wrong. You do not understand how it should work.” I was like, why? And he said, well, it's very simple. If you are in a room and let's say that the average from one to 10 of that room, it's a five. What would you prefer to be one, but make that average comes higher, maybe a seven or an eight? Or ten and make that average may be lower? How does that make sense? Let's say that I'm in a team and I am one, but I'm putting all my energy into each of the people in that team to become a seven, not a five anymore, but a seven.

Or the other way around, everyone on my team is a five, and I am a 10, but everything that I do is try to discourage them and make them feel less strong. So, in the end, he sent me a really strong message and a really good idea, which is that my objective as a leader, not at the time a CTO, is to make the people around me better, because that'll make my job better. And to be honest, that doesn't make a lot of sense when you are a technical person because when you're a technical person, you're in front of a keyboard, and well, it's you against the screen, it's you against your code. So the better you are, the better you do your work.

So, this leader came in and asked, hey, does it really matter? You can not be as good, but if your team is better, your team’s average will be higher, and the results will be higher. That day was really important. To be honest, I didn't understand that, probably five years later. At the time, I was like, ah, he's crazy. He didn't get it.

And, Dmitriy, I like that you point out that you disagree because, often, the best processes are created from this adversarial thinking. It's when people with different points of view get together and discuss subjects and try to come up with what is best that you end up achieving something optimal.

And it is a process that we are still exploring. It is something that is new even to us. We last got in the market with this specific service line a while ago. And it is something we are experimenting with, something that we're learning from, and we're open to a lot of feedback.

The interesting thing to point out is that that is very similar to the story I followed to become a developer. I started programming when I was 13 or 14. Computers weren't even a thing, especially not where I was from. Internet was not a common thing either. I studied in school, then in college, and I got a PhD. So I did follow all the natural paths.

But all along, I was already working on my own side projects. And working on your own side projects is one of the key aspects that we try to look for when we're trying to find these engineers or future engineers, these juniors and developers. Because we've noticed that a lot of brilliant people simply don't have the access to the resources to put them on this, what I would call the normal, the standard, the expected path. For instance, we've had engineers that actually came to interview with us, and we do the interviews remotely, that did their coding interviews on their cell phones because they did not have access to a computer. And yet they managed to write code which I already find extraordinary.

What are the chances of you actually trying to understand the problem that is fairly complex algorithm-wise while talking to an engineer in a language that is not your own and writing your code on the phone simultaneously? It demonstrates a certain level of skill that is unusual. And this ability of these people to persevere without having the same resources makes them very capable of finding unusual solutions to problems.

So what we're really looking for in the engineers that are not already following the normal path, because, of course, we hire many junior engineers that did follow the normal path. They might have gone through a regular high school, started coding when they were in college, and then we hired them a few years into college or immediate life. Of course, we hired these engineers as well. But we also look for those who at the age of 16 tried making a little game at the age of 17, wrote a program that was a crawler that did something they needed just because they thought it was fun or interesting. And these people might not even have the chance to follow all of the natural path that we also look for.

It's an interesting part you mentioned before, that even the people who follow the natural path struggle, which is very true. I've been programming for many years now, and sometimes I still find problems that I do struggle to solve, which is actually some of the more fun problems is when you're trying to really solve something, you get stuck on it, and you have to think about it, and you come up with solutions.

And juniors get stuck even more often, and that's where this pairing with a senior engineer becomes very important because when you're part of a community of engineers, that is basically the employee base of any engineering company, such as is the case here at Avansoft, you have a lot of resources. If you get stuck in something, you can send a message in the Slack channel, and either another junior that has faced this similar problem before or one of the senior engineers will just say, ah, have you tried doing this particular thing here?

And that will shortcut some of these little moments where you just spent three hours trying to solve something and you couldn't find the answer anywhere, not Stack Overflow, not in your imagination, and you can have the help of your peers.

This is the interesting thing also that happens when you're actually working with a company that has a lot of engineers. If you hire only one or two of these juniors and put them to work on a project, it's likely that it won't work. We've done that experiment before because we had to experiment with different combinations to find just the Goldilocks zone. And we had a situation where we found two very capable engineers that were very junior. And we said, okay, let's do this experiment. Let's see if they can do this very simple project. And the outcome was not very positive. We had to have a senior step in to actually finish it. So it's all about this experimentation, trying to understand where each one is and giving them support via this community of engineers where we can achieve good results.

In the project that didn't work well, which was an experiment, because that's what we always talk about, correct? If you don't try, you never fail. In some cases, we try extremes to experiment. So we had an idea for a project. It wasn't for a client, of course. And we said, okay, can we get these engineers to do this experiment? To come up with something based on the specifications coming up here for something internal. And we experimented with it. We learned a lot from the process, but as expected, it didn't yield the best results.

Yes, but I have some interesting points here. So let's start with why collaborators in engineering projects tend to have such high salaries. I think the reason is because of a matter of impact, of not even impact alone, but scale.

When an engineer develops something, it can scale almost limitlessly. If you are a part of the development of a SaaS, you're maybe one of five core people developing a software that will be used by millions of people. The thing you're doing has an outsized impact, given the amount of work you put in. And the reason why you're able to have this impact is exactly because of all of this training that you have of this brilliance that this kid who spent 15, 20 years developing his skills got to have to translate real world requirements and needs and necessities of people and companies and put it in something that actually helps them.

Because of this outsized impact, you receive an outsized compensation. Of course, this is not something that will probably last forever. Like every type of job, you expect a certain cadence. You might have an increase over the years and then suddenly you have a decrease, whereas something else comes in later on.

Nowadays, there's this talk of no code, low code, and how that can impact software development. I don't actually think it impacts that much, but it is these types of tools and others in the future. Who knows, someone might come up with an AI that you can just explain requirements and suddenly, poof, software comes into existence 50 years, 100 years from now; however it may be. I can't really project the future. I don't think anyone can, but everything is possible.

Now, on this topic of some people not coming into the industry because they don't think they will make money forever, there are a few things here, correct? There is the seize-the-day approach. If you can make money now on this that is more than something else, do your risk assessment, see if it's something that you enjoy, and go for it.

And on the other side, like anything that you do in life, you're much more likely to be good and succeed at it if you actually enjoy it. And if you enjoy it, you tend to do it even if you're not making much money. And that's what scares me a little bit about the IT industry or engineering and all of that nowadays is that you have an immense amount of people going into this industry just because they hear that it's easy money. When in reality, it has its hardships like any other job has. There are difficulties, and there are people who will not find jobs, there are those who can, there are those who will make more, there are those who will make less. So it is an industry like any other, really choose the path that you want to follow based on more than just the possibility of making money.

Something interesting there that you pointed out is how in the IT industry, of course, there are likely other examples of this type of phenomenon as well. But in the IT industry, since most developers now work remotely, you have seen this equalization of salaries worldwide. Of course, it hasn't yet equalized, even within the United States. If you go to California, the salary is one way. In Florida, it's another. In Brazil, it's another. In Mexico, it's another. Of course, there's still this variance. But you did see a little push-up in the salary from these international locations.

And a large part of it actually happened due to the pandemic because of the normalization of this remote type of work. And regarding that specifically, it's a very interesting scenario. Because if you're living in a country where your cost of living is much lower and being paid by a company where the cost of living is higher in a way that is similar to the local employees, then yes, you do have this phenomenon of this weird multiple of payments. Even though you receive the same, you get two or three times more. So I don't have quite of an answer if that will last forever, but it's definitely something interesting to see. Some larger companies are starting to adjust salaries depending on the region you're in. So if you're in country X, they will adjust your salary based on the cost of living.

And a tricky thing as well with this hybrid work is that it's not very useful for you to have just a rule, come into the office twice a week. Because unless everyone is coming in in the same days, you're not getting the true benefits from having people in the office. Because what are the benefits of having people in the office? Is to have this human element in your company where people are exchanging ideas, they're talking, they're befriending their coworkers, and it's humanizing both the company and your products.

If you just have people popping into the office just to pop into the office, maybe to deliver a stakeholder meeting and leave, you're not getting any of those benefits, but you are getting all the inconveniences of having to one, keep an office and to go in. So I actually struggle a little bit to try to find out where the correct balance for this lies. Maybe it is for companies just to have almost like co-working spaces or these cool spaces where people can go to work if they want, and maybe it's some hybrid approach where companies have a bunch of these all spread like WeWork tried to do and close to your house you have one, so you kind of collaborate with other engineers, but they're not even from your same company. I'm not entirely sure, it's just spitting out ideas, but it will be interesting to see how things evolve.

Yeah, of course. I've lived in, actually I've lived in Switzerland, I've lived in England, I'm from Brazil, I lived in Brazil, I've lived in the United States. So I've moved a lot between different countries, worked in different countries, studied in different countries. And it's very beautiful to see how different cultures and countries evolve to work in different ways. So you have, for instance, the American, the United States mentality that you live to work, build your own thing, and achieve greatness. You have this culture in the US, which comes from the very foundation of the country.

You have the style in Brazil, for instance, which is to, you work to live, you don't live to work. So in Brazil, people really try to enjoy their lives, they try to just work as little as they can and just meet the requirements.

You have the Europe, for instance, which is a collection of countries that has existed for millennia, a culture that has evolved tremendously over many years. And there you have, of course, it varies by country and country, but some of the countries have been to there, for instance, they have a very good balance between work and life, where they actually know where the boundaries are, where they actually know when to stop, when to start enjoying. Even in companies, you see that they usually stop at a specific hour, they all go out together, they hang out.

So, it is very interesting to see how this changes between countries. And that affects a lot of things in the way that you need to deal with these offshore collaborators when you're including them in your team. Because if you're including someone from a place where they work from eight to noon, then they take a siesta where they take a two hour break and then they work again, you need to take that into account. You shouldn't be scheduling meetings during their siesta, for instance. Of course, it's a silly detail, but a lot of different things come into play when you're working with all of these countries.

And if you really want to have a successful multicultural team that spans multiple regions, you need to consider all of these things. And this takes a lot of learning and being exposed to it and working with these different places for a long time, which is why when we were discussing what we are trying to do, we always try to pair these more senior engineers with locations where they have some experience with. If they speak the language, that's a huge plus because sometimes the brilliant people might struggle to explain what they're thinking in a language that is not theirs. You might have like an incredible Mexican programmer who has a lot of trouble talking to you in English, and because of that, you don't give as much value to their opinion. In reality, they might have some brilliant things to say.

So, it's important to consider many of these different aspects when working with different people, being open to knowing other languages, understanding their cultures and adapting and working around things.

Exactly. And that actually goes to a thing that we really try to do here in the company: give people control over their own time. As in, don't try just to buy all of your employees' time; give back control over their time. If they are accomplishing what you need them to accomplish, do not create constraints for them just to be there and be present. It's very important, at least in my opinion, to be very results-driven. As in, you have tasks to do, you have results, let's achieve excellence in what we do. But there is no reason to be pushing different people to behave the same way as everyone else. Try to understand how each one excels.

For instance, we have engineers from the same location, some like to wake up incredibly early, and you see their Slack messages starting to pop in at 4.30 in the morning when I'm still asleep then. And you have other engineers that like to work late at night; they might go to sleep at 4 in the morning. So, there is no reason to say, okay, we all work from 9 to 5. Give them the freedom and understand how to make that possible because you still need collaboration.

For instance, it is important, or at least it is a management style, to have stand-up meetings. So place your stand-up meetings in a time that makes the most sense. Maybe it's the end of the day for one and the start of the day for another. But there needs to be this combination of being able to collaborate by sharing some time while keeping each one, giving them the freedom they deserve.

I'm sure there are some interesting nuances, correct? For instance, if you're working in a country like Switzerland, correct? Switzerland is an extraordinary country. You're talking about a country that has been around for millennia and remained neutral in most conflicts. It's almost its own bubble and isolated community, surrounded by mountains. We have water produced from multiple alternative sources. It's a very incredible infrastructure, and this infrastructure has been around for a long time. So when people are working there, they're working a little differently than when you're working somewhere like Brazil, for instance.

In Brazil, you're working to build things. You don't have much that already works. Everything is kind of chaotic, and you're trying to organize things. Let's build, OK, things like organize, build.

When you're working in Switzerland, you're working to maintain. You're working to make slow, sustainable progress that will affect the country probably many years from now and not today. So when you're working with these two cultures, you need to understand this difference. For instance, if you're working in Switzerland, you need to understand that there will be definite times to work. For instance, as you mentioned with your friend, you will work from X to Y hours. If you're working in a country where things are slightly messy, you might work from X to Y, then from X1 to Y1, then from X2 to Y2. When you have breaks and you have this and that. So there are differences in how you work between these two countries. And it all stems, I believe, from the difference in the developmental stage that this country is just because of the time that that culture and country has been around.

Oh, this that you mentioned is also a very interesting phenomenon. The level of QA required might vary by region. And that is not necessarily a bad thing because often there is a difference between the speed of work and the amount of QA it requires. And this ratio of how fast you want to develop, how much QA you want, how many bugs are tolerable depends on the type of industry you're on. Because if you're a very small startup where you need to push a feature every day because you're in the build, measure, learn cycle, you need to measure the results of something that you thought of this morning, tomorrow, you need to be pushing code fast. And it's OK if when you push this new code, you break some unrelated feature that you're planning to offset or sunset.

Whereas if you're working with software for a bank, you better not introduce any bugs. It's not acceptable for there to be bugs in that type of software. Of course, it's not impossible for bugs to make it through.

So that point that you brought up is very interesting. For some reason, we think that the people who test the code are somehow on a lower scale than those who are developing the code. When, in reality, they're both very specific skills that require a long time to master in every case. It's not because you're a very good developer that you're a very good QA. There are some people that are extraordinary at QA. They can look at a piece of code, understand the requirements that were in the code somehow from just the nuances of what it's doing, know what to test for and find bugs that even that person who developed in the first place couldn't even have fathomed about.

I don't think there should be any difference between QAs and developers. I think we see this almost stigma towards QA because historically, many companies have been putting their developers that don't perform to the same level to work in QA because QA usually has a lower budget. So, the developers that don't make it through and get promoted to higher levels of development tend to just get stuck in QA, which might have created a negative stigma around it. Exactly because you said that it's hard to explain to stakeholders why we're spending as much money testing features as implementing them in the first place.

It was a pleasure talking with you, Dmitriy, till next time.