This video podcast is for technical leaders and those who want to become them someday. We have a guest who possesses extensive experience in the area of technology, and tonight's guest is Paulo Carvalho, CTO, entrepreneur, and investor. But before we start our discussion, consider subscribing to our channel. We have lots of great content coming soon, including future installments of CTO Talks.
Now let's talk about our guest, Paulo Carvalho. With over ten years of experience in multiple domains, he finally landed in software development as a co-founder of multiple companies. And Paulo has a unique multicultural and multi-professional perspective on many aspects of life. Paulo, it's nice to have you here on our podcast today.
And two topics we will discuss today are growing professionals in software development, alternatives way to grow professionals, and, I guess, your multicultural view. I know you have much experience, and I would love you to share your opinions and insights with our audience.
So, let's start with growing a specialist. I know that you have founded a school, but not a standard one, that most software companies have, but slightly different, slightly unique. What's so exceptional about your approach?
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 basically establishing some foundation for future growth in education as well, establishing better schools, better universities, and growing your community. I disagree with some of your arguments about your school. I mean, not everything. Mainly, it's along even with the approach that we're using in our company.
But only this purpose, growing your local community, seems to overcome all my disagreement and negative feedback about your school. That's great. I totally agree with you, especially nowadays, that companies should have a purpose, not just to make money, not just to do something. But it should be something useful. Of course, we do useful work for other companies, developing products and everything else.
But we definitely should remember about local communities, the ones who just cannot afford to grow and bring them closer to us, especially considering our opportunity and level of opportunities, right?
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.
Growing Self-Educated Talents
You don't make mistakes only if you don't do anything, right? And I think that's a way to grow, to make a few mistakes, learn from them, and grow on the mistakes. No, no, my feedbacks are not significantly negative. I would like some disagreement about some assumptions you put in the beginning. So don't take it hard. I am all growing local people, teaching, educating, and giving opportunities. Any opportunity I have, I always invest in those activities. Limited, but whatever I can afford. So, I am delighted that some people put more effort than, for example, myself into such activities. The world is better out there.
Good. Paulo, one of the concerns I have about this approach is that software developers grow from the school. They fool around even at school, doing some small algorithms, sorting some graphs, something depending on the level, on the school, and so on and so on. Then they solidify all this knowledge in universities, studying typical algorithms and approaches.
And when they become juniors, not seniors or middles but juniors, they can apply those knowledge templates and approaches. They've been learning for five, six, seven, sometimes 10 years. And even after these ten years, many of them, they struggle. So can you tell me how you plan to overcome such a big chunk of the educational process?
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.
Okay, so you're saying that some self-educated personnel are striving to grow, to learn this, and you're going to just handpick them. Good.
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.
But those juniors, they were supervised, right? I mean, they were not doing the work by themselves.
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.
Why People Choose Tech
I think that's too big an extreme, don't you think? I mean, putting two juniors on the project independently. Okay, so you're saying that you already tried multiple combinations and you somehow worked out the best combination that works for you and matches the goal of the company.
By the way, it’s a little bit off-topic and related to our next section, but I think it's a good time to ask now. So in my experience, especially in Eastern Europe where the economy is not that great, the IT industry is so lucrative, so with such great opportunities that people with the old school and emphasizing the old school simply don't believe that it is possible to be so lucrative with just a regular job. I mean, not business, not banking, not financing, just regular job, regular guys doing some engineering work and making 10, 15, 20 times higher than average salary. And some people just don't go in the industry again because they don't believe that it can be so good or maybe they don't believe that they can make so much money because they just don't fit it. Did you see a similar view, maybe something like this, in your country?
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.
Well, like it's any economic process, it always goes in cycles, it goes, as you said, it goes up and then goes down. I disagree with you about compensation, because, for example, in the United States IT salaries, they are average. I mean, they are slightly higher than the average salary. Well, unless you go to, I don't know, San Francisco, Manhattan, then yes, you will have some crazy numbers in hedge funds or some financial institution. But that's more like an exception. On average, it's reasonable.
When I started working in the IT industry 20-22 years ago, my first salary was, well, now I can tell, I think. I mean, NDA does not cover it or anything like this. My salary was about $200 a month. And I was quite happy with the salary, by the way. It was a great salary. It was sufficient for me to live, well, not great life, but I mean, better than my parents' life, let me put it this way.
But the sharp growth in demand for software engineering brought that even offshoring engineers, they became almost as expensive as engineering in the United States. And frankly, the difference is very marginal right now. And now it's very hard to compete. Before you can say, well, I can sell you engineering for 400 plus whatever margin I want to put on this engineer, let's say $600 a month, and you pay $6,000 a month to your local engineer. It was a very clear choice. Of course, I will go with the offshoring.
These days, no, you need to provide the service, something that helps your client do the job. And it's not just software development anymore. That's gone. It's more wide service. And your approach, I don't know, growing people, making sure that they know, growing under some supervision, mentoring, making sure that they deliver high level from the performance, from the quality, from many other aspects the result that fits client expectation that something different and not many companies in the United States can afford this kind of approach. So you definitely have a unique approach here.
Remote Work vs. Offices
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.
If they adjust, they're not adjusting it that significantly. I mean, most adjustments are coming actually again from Manhattan, from San Francisco, Los Angeles area.
So if people leaving those very expensive areas, they would adjust. I mean, a company would adjust salary to some United States location. So it's still very good salary. I mean, they will not adjust you to some, I don't know, average salary in Eastern Europe, for example. No, it will be just regular salary, normal salary for United States employee.
And you actually touched a very good topic about remote work. Well, luckily for us, you and your company, my company, when we talk to clients, we don't have to sell the idea that working remotely is bad. They already work remotely. So this is not even discussed during the conversation. This is one deal. So pandemic, I mean, well, I mean, how bad it was. Yes, that's I mean, it was pretty bad. But it literally removed those separations between offshoring and onshoring development because there is no difference. And big companies are trying to bring people. They actually put very strict rules right now, free time for a week to be in office. But people, okay, three times. If it's free, then it's true. If it's a two, then it's one. It's still very flexible.
And big companies still struggling with bringing people to the offices. And it's literally more like people. It's viewed more as an exception than as a rule. People do like to work from home, especially like, again, going back to Manhattan and San Francisco, spending two hours to office and two hours from office and working from home. Eight hours, I'm sorry, four hours per day wasting. No, I will do everything possible to stay home today. Everything. I will work extra two hours just to stay from home. It's already going to be beneficial. So I'm not sure if it's going to be back. I don't know if people are going to go back to offices. They tasted this freedom, and it's very hard to take freedom. Extremely hard. People will be, I don't know, compromising their income, their salary. But they will be working from home. Way too comfortable again. People tried it and now people know what it is.
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.
Well, they actually do come up with some creative ways to synchronize people. They establish like free lunch day, like Wednesday is a free lunch for the entire company. Okay, well, I mean it's not that great, but if you're on the edge, going, not going, lunch might... Yes, some mandatory days, it's like once a month, I don't know, some second Friday, it's mandatory. Everybody must be in office for something. So they're trying to come up, and I think they will, maybe it will be, if it's a three days per week, it's going to be Monday, Wednesday and Friday. And then Tuesday and Thursday you can work from home.
So don't know. I mean, frankly, we don't have such problem. I don't even want to solve this problem. I think big guys will be solving it themselves and we'll just follow them and see how they will convince people to change their heads. It will be very interesting to see. Now, you said that you have multicultural experience and you actually have specific views, opinions about different countries, how people do work in different countries, how some special skills, some special habits. So, can you share with us some of your experience, some of your views?
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.
Okay. Makes sense. This actually reminds me of the Mediterranean style of work as well. I have the story: one of my project managers moved from Eastern Europe to Spain and temporarily lives with his in-laws. And he said, well, Dmitry, I'm not going to work until 7 p.m. for the next month or so until I leave with my in-laws because they will not understand why I work after 6. They will just create a big problem. They will be talking to me, they will be teaching. I just don't want to touch this problem. Once I move to my own apartment, I will do whatever times you need me to be.
So that's, I think that that's it. And that's actually what you just said. It's not fighting, it's not changing. It's actually understanding, it's working around those babies and it's saying it is normal. The fact that you don't like it and they don't accept it, it doesn't really matter. You have your own culture, and they have their own culture. Learn how to work together, that's it. Don't change each other, it just won't work.
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.
Well, you don't talk the entire day in the IT industry. You do need to code sometimes, and actually most of the time, right? Technically, yes, you have other activities: discussing, preparing, code reviewing, etc. But after all, it's sitting on your computer and coding. And you better do it when your brain is working properly, not when you have to do it because it's 9 a.m. or whatever time it is. Yep, true.
Well, good. Because, I mean, from our side, I know some companies they install like screen sharing, screen tracking system, activity tracking system, which track the activity on the system. I mean, from the beginning, for example, we decided no. If I don't trust the developer, why do I have him in the first place? So, I mean, if he screwed up, well, I mean, we'll see what we can fix. If he screwed up three, four, five times, then I guess I made a bad call.
But fortunately, I mean, it didn't happen too many times in my experience. So, it's good that you trust your people and give them freedom. I mean, now, the industry is actually very, very good stuff. But you didn't mention special approaches to work in Switzerland and England.
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.
Well, I think it's more German order, which does affect Switzerland, because I witnessed the same in the Netherlands. When you drive around the country and visit places in the Netherlands, you have a feeling that when they do something, it doesn't matter which industry, roads, houses, or software development. They just sit down and then think it through. The next day they start building, but they're building it properly from the first time, and it's built for many years ahead. They don't need to maintain it because that's how well it's done. That's my overall feelings about the Netherlands. So I think Switzerland is somewhat around the same approach.
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.
The Importance of QA
But the budget is related as well. We have multiple requests why we need QA. Developers will test themselves. Why do we even waste money on this?
It's actually sometimes very hard to explain. Well, it's easy to explain because it's obvious, but it sometimes doesn't get through this wall of not understanding. It's very hard to convince actually and to do at least minimum work because it's just required. From our experience, it doesn't work any other way.
And yes, it does depend on the industry. For example, in the medical industry, I had experienced, in most cases, a ratio between developers and QA is one-to-one. And sometimes the QA team is actually bigger than the development team. And developers do participate in testing with specific requirements, such as you cannot test features you were developing. So it's a more cross-development.
It's okay in the United States actually to change roles. Developers don't mind becoming testers for some period of time. It's not like in Eastern Europe. If you're a developer, the new developer is almost like an elite. You just don't touch testing. It's just below my grade, my position. Is this a vision in your company, or is it easy for people to change roles?
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.
Just appropriately implemented, right? Why do we need that? We've been there. Okay, so Paulo, we're slightly running out of time; not a big deal, but I think this conversation was very interesting. We touched many points sometimes, actually, points we shouldn't have touched. It will be questioned more likely on YouTube, but it's okay. Like you said, I like to poke around and make people jump and think. That is an essential part of growing personally and professionally. So be it.
Thank you very much for your participation. Thank you very much for sharing your experience and your knowledge. I hope we will meet later and talk more.
It was a pleasure talking with you, Dmitriy, till next time.