Hello, and welcome to another episode of CTO Talks. My name is Dmitriy Stepanov, and I am a Co-Founder and CTO of Glorium Technologies, an international technology company hosting tonight's event. This video podcast is for technical leaders and those who want to become them at some point. We have guests with extensive technology experience, and tonight's guest is Edgar Escobar, CTO at Grupo Alta. 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 Edgar Escobar, a practitioner in multiple industries within North, Central, and South American businesses, as well as a practitioner in the European market, specifically in risk management, data management, and IT solution within the banking, logistics, communication, retail, and service industries at a different level, including analytical, strategic, technical and operation, data governance and officer at the security level. Wow, what a vast and rich experience you have, Edgar. Now, Edgar, tell us a little bit about your international experience. Since you work in so many locations, something about, I don't know, some teams, some specific experience, some stories about one of your teams in those locations.
When a Single Word Matters
Thanks, Dmitry. Thanks for having me. Thanks to everyone for taking the time to hear for a few minutes. Yes, I've been around for some years now, around 15 years now. It's been quite a ride because probably only a few of you know, but when you are in South America, you have over 15 countries, each of which is very different.
One of my main challenges as a leader was building a team in a different culture or country from the one that I was born in and from Colombia. About 15 years ago, I was asked to build a team in Venezuela. At the time, it sounded really easy. Well, it's the same thing that I've been doing in the past. Just get to a specific place, find some curriculums, and make it happen.
And the reality is that that was the first time that I realized that building teams is more than just finding people. It's about finding a fit. It's about ensuring you have the right people for the right jobs. And as you do that, you have to build a culture. You have to develop DNA. So that was quite a story. I don't know, Dmitriy, if we have the time, I can tell you about that.
So, tell us about Venezuela’s DNA, I guess.
Sounds interesting. And that's just one example. So I remember I used to go to the South American culture. It's very different from North American culture and European culture. South Americans tend to be very ‘we don't tend to know what “no” means.’ Culturally speaking, we're very hard-working but sometimes not very direct.
I remember that in my previous company, we decided that building a mathematically functional consultancy team would make much sense. We were meant to build scorecards; we were meant to build relational models. At the time, they were not called machine learning or artificial intelligence where. They were called nonlinear models or data with non-structured data models with non-structured data. So, we decided to build a team and found Venezuela the best place to do it because they had great professionals. So, I remember that I didn't know what to do the first day I got to Venezuela. I didn't know how to find people and reach them. And after a couple of months, probably three months of going to universities, talking to people, there we had it. We had around 15 professionals, 60% of them had their Ph.D. either in mathematics or engineering, and we were ready.
And I decided that it was a good moment to tell them how I felt, how I felt about building a team. So I tried to do something different. I hired a place, a great place, great food. And when we were all together, I made a mistake. I did not realize that Colombian Spanish and Venezuelan Spanish was different.
And you would say, well, that doesn't make any sense. Well, it does. Some words mean something different. After three months of hard work, I had my 15 people, and I said a word that I could not tell you what it actually means in Venezuela, but it didn't mean the right thing. And I had 15 people just quitting on me. It took me about 20 minutes to explain what I wanted to tell them: we would be a great team. But they heard something different because I said something different.
So, it's amazing how after three or four months of hard work, just a single wrong word could destroy so much. That’s really important. When you are building culture, when you are making the team, every word matters. You have to create a fit. You have to create a culture. You have to know what you want to build, be very discreet, and know exactly what you're doing for your team.
Tame Your Ego
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.
It takes time to understand such ideas because, especially from the technical background, you immediately reject them.
Exactly. Five years later, I understood, and it was awesome.
I haven't. Tell me something about that.
Well, it's totally different. So, remember, like in the previous PMBOK, they have structure, or the risk management, resource management, all stuff, like very structured, matrixes, responsibilities, sections. In the latest one, everything is gone. It's all about team motivation. It's all about soft skills. It's all about working with a team. As you said, my initial feeling about this book: why? Why did they break everything? They noted that everything we're putting in the new revision doesn't conflict with our previous revision. Our previous revision still needs to be implemented, but we are focusing on this stuff.
So, well, they went a little bit too far. It's always something in the middle, which makes sense. We'll see the next revision, but that's precisely what you're saying. Forget about technical. We need to think about people. We need to think about building the teams because that brings value to you, clients, customers, companies, and everything. Well, it resonates with this idea.
When We Need the Latest Technologies
Good. You said that the real objective of a CTO, apart from building the teams, is to build a strategy for the technical part of the product, company, or whatever you're working on. Can you give a couple of comments on this topic?
Sure. So let me start by being disruptive. Everyone is nowadays into ChatGPT, and everyone is into artificial intelligence. And it's great. But the reality for us that have been building models, artificial intelligence, especially machine learning, came before linear models. If you look at the books, actually, people in the 40s didn't have the technology; they were building non-structured models. So, for mathematicians, the models that are harder, well, not harder, but those that came later were linear. When people come and start talking about artificial intelligence, they start talking about machine learning, yes, we need to know the new technologies, but it's not something that is that new.
Why am I saying this? Because now everyone is hyped about artificial intelligence. Do you need to work? Do you need to build an artificial intelligence model? It really depends on the problem that you have. For instance, let's say that you truly understand your variables, both your responsive variables and those with which you will explain your model. In that case, an artificial intelligence model is probably not the best fit. And even though you can get the best fit from an artificial intelligence model, it's going to take you longer and a bigger effort than just doing a linear fit or a logistic fit.
I’m trying to say here that, by example, it doesn't matter to use the latest technology. What matters is to really understand the problem and build a solution around that problem. So said, when you are a CTO, a lot of us make a mistake, and we feel we have to find the latest technology and the best thing out there. And the reality is that, yes, maybe, but it's more important to understand your problem truly. Sometimes the best way to reach something under the table is to find a stick and reach it. You don't have to find a lever, bring up the bed, and make something difficult.
So, as a CTO, your objective is to understand your problem and set up a strategy. It's really easy to spend many resources and not truly find a solution. We believe CTOs are meant to build the latest tech, just to build the latest team. And I think it's more than that. Let's look at it from another perspective. When you look at CTOs, sometimes you feel they're the ones that are behind fixing laptops. And yes, it's true. You think they're the ones that are behind maintaining your infrastructure. Yes, that's true as well. But all of that is operational. All those things happen daily - 20, 50 times a day. You cannot imagine how often your health team has been fixing stuff. However, if you fail one time, if only one time out of those hundred times you make a mistake, everyone around your company would go like, oh, your CTO and your company are not doing a great job. They don't understand how to do it. And well, you burned yourself. So, you have to move away from that.
Again, as you said, Dmitriy, it's important. It's part of our job. That 80% is what we have been talking about for the last 20, 30, or 40 years. Today we're talking about the other 20%. So yes, one part is building teams. The other very important piece is building a strategy. Make sure that you are part of creating value. Make sure that you know exactly where you want to go. When you start working on your team, on the first day, try envisioning yourself what your objectives will be five or ten years forward. What are you going to do differently? Please don’t go around saying, hey, I want to build the latest neural network. That's going to happen naturally. You have the skills, as we said. You know how to do it. But what is going to be different is how you're going to embrace the problem. Make sure that you understand what is happening. Make sure that you build a strategy around it. And, of course, if you have the right methodologies, it makes sense.
Just as an example, when you were talking about PM, I remember doing PM; I don't know, 15 years ago. And I remember after PM, everyone was talking about Agile, and everyone was talking about Scrum. And now everyone again is talking about Agile models. And all of them are really cool. All of them make sense. At a point, as a good CTO, what you have to understand is how you make the right mix. So, for example, in my company, we are not PM, we are not Scrum, we're not Agile, we're a combination. We're taking the best out of each, trying to solve our problems. And with this, I'm not saying everyone should do the same. Again, you gather knowledge and information and build the best thing for your specific problem. Build a strategy and then build a team around the strategy. I don't know if that makes sense.
Yes, it makes sense. And, well, I do have a solution to the problem. So, the problem is that most CTOs came from a technical background. And, I mean, we have this itching inside of us to play with the new toys, with the latest, greatest, put our hands on something. There is nothing wrong with this, by the way. But it can lead to some failed solutions.
So, what I actually do, at least, I mean, trying to do, running small, scant projects. So, this is the latest solution. Sure, no problem. This is a small, separate project. Try it out and see how it fits. Maybe it will work out; who knows? But you're not putting everything on the latest and greatest. I mean, no, that would be a great mistake. Ignoring the greatest and latest is also a kind of mistake. I mean, you're risking staying behind. Playing in the controlled sandbox environment, I think that works. This is the best solution. I mean, you're limiting budget, you're limiting risk and negative outcome, but at the same time, you're keeping your hands on such things. So that's, as you said, it's always balancing. It's always balancing between different solutions that seem to be weird and seems to be too risky sometimes.
Internal Team vs. External Team
Okay, so I guess we are on the same page here. Internal or external teams. No better and no worse decision here. So, I think you're sending a message. It doesn't really matter. Is it an external team? Is it an internal team? It all boils down to what? To final team composition, team building efforts, or to what?
Exactly. So, let's go again through the same. You said something really important, which is don't be afraid. And the reality is that technology is moving way, way, way too fast. And this doesn't mean in a wrong way. It's awesome. It's great that every couple of months, something new is coming in. So you have a great challenge: how are you going to make sure that you keep up to date? And that's really hard.
So like we said, I wonder if people are getting the message behind this because, as I said, we have to do about 20 things at the same time. We have to build a team. We have to make sure that people are coming in through human resources. People are going out because we haven't talked, and I don't think we'll have the time to talk about, for example, the great resignation that happened in the US last year. You have people coming in, coming out. There are plenty of things happening at the same time, technical pieces and administration pieces. You have budgets or finance if you are in a specific kind of company. So as a CTO, you have to worry about a lot of stuff, like 20 different things.
Now we're talking about teams and team building. Let's say you are in this huge tornado, and you have to decide which teams you want to have. It's either an internal team or an external team. Again, it’s not about saying, oh, I'll only work with internal teams because they're cheaper, or I'm only going to work with external teams because they have the newest technology. It’s about balance. It’s about understanding, again, what your problem is and what your strategy is.
I've done both during my life, and I'll give you a couple of examples. I remember a certain moment in my career when I wanted to go through new technologies. At the time, I wanted to start working with PHP. I didn't know how to work through PHP, and I didn't have the time to build a team around PHP. It took longer. So, instead of going to my cave and learning about PHP, I found the right partners, and it was great. We were faster. And something that someone could have said, hey, it's more expensive; having a 10-people team costs X, and hiring an external team costs 2X. Actually, it was way cheaper because we had people helping out, we were learning things faster, and we were building solutions better. Many of you guys who do technology know that you can build great code, but it doesn't mean it's the best code. Having the best code requires iteration, requires experience, requires doing it wrong so many times. So when you go through an external company, you get that. You get that experience. And the cost of having that team is lower than the cost of having an external team.
So now, on the other side, you might need an internal team. You might need people that are 24-7 looking at your problem. So, as I said before, it's about balance. I wouldn't say external teams are better than internal teams. I wouldn't say internal teams are better than external teams. What I would say, again, is understand your problem, understand different relations that you have inside of your company, and around that, try to build a team that is very dynamic.
I do something in my companies every year, and you mentioned a sandbox; I tend to build a couple of, let's call them, innovation projects with external teams in my sandbox. So probably two times that I use external teams nowadays, or three times. The first one, as you said, learning something new. The second one, everyone knows it, when I need something to be fast, go through an external team. And the third one is how you can, and the one that I wanted to explain is how you can mingle and how you can make or create better teams. For example, if you have a sandbox with a couple of people that are from your external team and a couple of people that are from your internal team, that's great. You create great relations, you create knowledge, you create a better culture, and well, that's something that I believe creates great value.
Do you know what's funny? I've been in, I don't know, several dozens of discussions about the pros and cons of the internal, external, outsourcing, outstaffing, all kinds of different models. And during those conversations, conversations immediately would go in the direction of what are benefits, what are disadvantages, and it was obviously arguing this is better, no, this is better, some objective description, subjective description.
But frankly, I don't recall when the conversation went in that direction, hold on, guys, let's discuss what you are trying to solve here. Let's discuss your problem and let them discuss how this problem should be solved with internal, external, outstaffing, and outsourcing. It always was, for some reason, backward. And frankly, even if you Google it and read articles, for some reason, it's backward. That's actually a very interesting perspective. First, look at the problem, see what you're trying to solve, and then move in this direction. This specific. All other topics, yeah, describe the problem and move solution. But for some reason, staffing is not discussed in this way. It's interesting.
Well, actually, I have another arrangement with my clients, and I will need to run soon. But we have time for the last question - CTO. CTO is a bridge between technology and people. I know, Edgar, you had a specific opinion about this and wanted to discuss this specific topic. So why don't you start?
I don't know if many people around here today know about Colorado Canyon, and that's a good relation. So, in Colorado, well, California, there is this canyon. A lot of people have been there. It's amazing. And one of the things that I like the most is when you are on one side and move to the other side; there are around 30 kilometers from where you are to the other side of the canyon.
But at that moment, it looks like you could jump the other way. And I'm exaggerating, but it seems really close. And that's what happens in companies between technology and business. The first time, you feel that they're close. You can't grasp them. You can do it really simply.
But in reality, it's a long, long distance. As we said, there's knowledge, there are processes, there's technology, and there are new technologies. And I put this from a different perspective. You have operations, you have innovation, you have development, you have data analytics, you have computer science, you have software development, and it could go on and on and on.
And as I speak, the problem is going to be just bigger and bigger and bigger. So, we have a great problem and you were talking about it. Business, usually when they start, they want to explain what they want. They tend to tell you their vision. And business is really good at explaining its vision. They know where they want to go. They know if you ask them where you want to be in 10 years, 20 years, they'll go and talk to you for hours of how beautiful and how amazing it looks.
Now, on the other side, when you go to your technical team, they won't be able to tell you ten years from now, but they'll be really, really good at explaining their code, at explaining the very small specifics of what they're building, new technologies, new ideas, how they're going to make it more efficient. And there, a gap starts to build because in reality, if the business was developing the solution or tech was envisioning or going to your clients to operate, it doesn't matter, but we are a team. So as this happens, a bridge starts to build. So, our work as CTOs is to become a bridge. So one of the things I've realized is that when you talk with a business, they could be better at making specifications and definitions. Again, they tell your vision, oh, I would love to be happy. Okay, awesome. How do you want to be happy? How does that happen? And probably after three years of expending a lot of money, you realize they're happy by having food and the specific food they want. They love meat, and they love meat during the afternoons. And as you speak with them, you understand that their vision of being happy could be solved a hundred, 10,000 times, but they have an idea of how to be happy.
So our work is actually to try to understand that. Something that is really funny about my job is when I talk to the business, I am very technical. When I talk to the business, they say, “No, you're a very technical guy. It's really hard to talk to you because, well, you're always talking about code, and you're always talking about how hard it's going to build these, blah, blah, blah.”
And when I go to my team nowadays, it's the other way around. They go like, no, you're very superficial. You're only talking about definitions. You're only talking about methodology. You're only talking about how we focus. And remember that it was great talking to you before because we would spend hours talking about new technologies. So I'm right there in the middle. I'm not very technical for my technical team, which is great, but I'm very technical for my business team. So, my point is that we have to embrace that. We have to understand that we are a bridge. We are the people responsible for ensuring that that vision and that capacity to build actually fit. So that's what I mean about being a bridge between technology and people. We have to make sure that people understand each other. As I said, business nowadays, for example, love artificial intelligence. Hey, that's awesome. We can do great things around artificial intelligence. We should be doing more. We should not be afraid of them.
But at the same time, we have people that are already experts on that. People that have been working at artificial intelligence for 10, 15 years. So how do we make sure that we listen to each other? How do we make sure that we build solutions around the capacities of our people, the needs of our people, the needs of our team, and try to make things happen? So yes, it's a great challenge that we have as CTOs.
Many see us as operational people who make sure that the computer works and the laptop works. And yes, that's part of our job. But we have to make sure that we do more than that. We have to make sure that the strategy of the company, that we have to make sure that the value of the company is aligned with where and what kind of value you are building. And by being a bridge, you can do that. Making sure that people understand, again, how you want to explain how you want to solve any specific problems makes a totally different perspective, makes a totally different solution. That also works if you make sure you find the right people. If you make sure that you find the right technologies, well, that's a must. So you have that obligation of finding different pieces and making them work so you can connect the two sides of your business that, let's be honest, are very different. A business person and a technical person have different objectives, even though it's the same company, even though they have the same objective as the company, as people have different objectives. So one of your main challenges is ensuring they see that and we get the best out of the two worlds.
Well, that's actually funny. Every single topic we have discussed today was defining the problem, discussing the problem, in this specific case, with the business people, and then slowly transitioning it to the solution with a technical person. But again, connecting them together makes sure that even the problem definition is properly defined, so it should be feasible. So it's a topic about this conversation should be, I mean, it was supposed to be. Define the problem and then solve it—the only way to be successful.
Well, Edgar, unfortunately, I have to go. It was very nice talking to you. See you later. Bye.