Why Mediocre Engineers Get Promoted Over Great Ones (CEO Explains)

We are better off with mediocre engineers. At least they will listen to us. Who has moved up the hierarchy? People who are not the best of engineers. Executives will still try and poke holes in that. That's what they're really good at. Seeing if this is bullshit, if this is fluff, or if it's actually thought through will reason.

As a great engineer you should not aspire only to remain a one man army unless you want to start a startup and change the world The minute you say no. I want to handle the most important and the complicated part first. Almost 50 percent veins of it. Don't try to give a business cage in a tech language, just make it simple. Today I'm joined by Anan Sahai, Global CEO over at CVR. And on that executive level, we discuss what great engineering leaders do that really makes them excel.

Next to that, we discuss career paths for great software engineers and we discuss what is more important now more so than ever for tech people. I was talking to Gregor Hope also on the podcast, and he said something that really stuck with me because he says the people on certain executive levels, their time is limited. So as a software engineer or an architect in this case, when you pitch to them, make sure your

idea is sound. Start with the most important part, and then executives will still try and poke holes in that. That's what they're really good at seeing if this is bullshit, if this is fluff, or if it's actually thought through, well reasoned. And it's not necessarily to poke holes, but just to actually see. Go deeper. Trust it. That's the best way. Just go deeper.

Yeah. And you do that on a like a level with with regards to the people you interact with. And that's where my tech background helps so I can go deeper if you want into an idea of tech. Why? Why do you think I should do this? Why should we start this? There's always thing like we should start this, OK, but why? Why not what we have? Let's put the money on what we have again, starting something new. Because then what we have, we'll get less funding and what is

new, we'll get that. So what is the why? Why this? Why should I do it? And that's always complicated because the passion is showing up. We must start it. So and they usually talk to different guys and say there is business. So again, we must start it. And then you see the passion in their eyes of wanting to do it. And this is where you make those calls.

I don't like it, but I'll still give it because the guy is too passionate about it sometimes because I'm like OK, 100K, he's too passionate about it. This group of people to cut this off, although I'm not understanding what they're saying, we'll be demoralizing to the to those guys. Might as well just give it. But then the other guy like 250K5, half a million. Why don't you do a smaller cut

off it proof to that. So quite a lot of times you are investing just to keep the morale high and keep people feel that, you know, they are, they are hurt, whereas they haven't given a compelling reason. It's not compelling, although passion is showing, but it's not compelling. Yeah. And so those are the calls you have to keep making. Gotcha.

In the engineering leaders or in the conversations that you have with engineering leaders, what do you see that makes them really excel in what they do for others to learn from? So when you use the word engineering leaders, how would you CT? OS, engineering managers, people that are quite technical and that have made it up quite high on the hierarchy career. Level keeping it simple the the

lucidity of explaining why this needs to be done and how it will give you a real outcome changes the game. Really. Yeah, so simple as that. Because complexity. You can always make me go mad with complexity and which is a problem with lot of good engineers that it almost becomes a tech talk and you don't get it that exactly what is he trying to get at, right? I mean, I always give the example of micro services,

right? So I mean micro services not fit in every place because I understand service mesh and micro services. So I'm like, do you really need a micro service here? Yeah. But every tech is is excited to write micro services. I'm talking about two years back. Let's trade in micro services. But why? Right. So these are the kind of things people who talk too much tech, I get very, very worried at a senior level. Yeah, do not try to give a business cage in a tech language.

Just make it simple. And some people are very good at it trying to achieve this. This is the right tech for it, because also comparing and contrasting against some of the other tech. And then say if you do this, these are the savings which can naturally come for the customer. OK, at least you can visualize what is it. And then obviously we go back and do do our own work. It's not that we heard and we are saying, OK, then we go back and then we do a bit of searching, Googling on some of

the ideas. Because you even when it's lucid, there are few things which you are not fully aware. So there's a lot of homework for us. If you ask me. It's not that it just you tell me and I'm like, OK, let's put 100K on it, right? I mean, it's we'll go back and of course, and sometimes you give call to another guy you respect in tech and say, hey, is this something you are also following?

And once you see your own reading and these couple of good guys, and then, you know, I think the guy was exactly spot on. Very interesting. I feel like a lot of people that are early in career, they do try and reason a lot from a tech level. So when you're saying as you move up and as you go more senior, keeping things simple and I think also tailored towards your audience, even though I think your reasoning needs to be sound and well argued, there is a risk nowadays

that a lot of people can cut corners because you have this magical box, which is large language models. You ask a question, it pops out with an answer. I feel like the better you do your homework, the more credible you will be because the people that will cut corners, they will actually fall through in the cracks, will show in their story. Because I I see it all the time. People use the LLM to give me an answer. You read and you know the structure and you know this is

coming out of somewhere else. The problem is the answers from the LLM are always well structured that it all looks true. Of course. Right. And there's enough prompting to be done to get to the core of it. And some do it great, but some just give you a superficial, very well written so you are more impressed by the well written part. And now I question it because I know it's coming from somewhere who nobody understands.

And so I'm like, OK, this won't work for me because then there has to be a better so. But people who, who know what they're talking, their structure of talking and sending you a, a, a, a mail is very different than those who which comes from LLM. It's almost instantaneously. I know. Yeah, yeah. I think, I do think it's going to get better, but so simple and simplicity and that's one of the key factors there. Anything else? I think this, I mean, for me this has all.

And then obviously I'm hoping the person also knows that the simplicity with which you explained me a problem and the solution which you are giving makes sense against the problem you are solving with respect to money, right? I mean in for example in Western world, in Netherlands, if it reduces 5 people as a because of the automation of putting together that application, value of that is totally different. If you have the same application in India to be built, cost of

resources are different. Yeah, it's just a fact. Yeah. And if you're not aware of that, so within the same problem statement in one region, a bank in India, their way of looking at that problem will be completely different than A than a bank in Netherlands. But the cost structures are different. So you ACIO must also or C level people must also have that

understanding. It's not about automating when 10 humans are cheaper than that automation and and and the automation creates certain risks. Unless you tell me the full picture. Yeah, how to mitigate it? Yeah. Otherwise, and that happens a lot. That happens a lot. You go to a, a customer in Vietnam and talk about, you know, how I can help you with reducing the, the, the check frauds, right? And give you the risk that XX will X percentage will not work.

The guys will say, yeah, but I have 50 people in that department. And humans are much better in identifying a fraud because of certain things, how you pay and everything, whereas an automation can miss it. And then you'll keep a team of five people who will constantly improve. So my total cost of ownership of this is much higher. So contextually you always have to see what are you solving and what is the advantage. Yeah, I feel like in my career I've always seen two types of

engineers. So the engineer and I see myself in there that is very curious, not just about tech, but also business and outcomes. And I get way more energy of

achieving certain business outcomes than necessarily how we do it in tech. But then in the inverse, people that grew up with tech that maybe have started coding when they were 10, they really love how they code and it's a big part of their skill set and it's a big part has become part of

their identity. And I feel like the latter might not be well equipped to actually then move up the career ladder because you do need to compromise on certain quality aspects of the tech you are creating to actually see how you can accelerate your business outcomes and more. Think from a problem standpoint and not from a solution standpoint. So you you hit a extremely

important point. Great engineers, those who started at 10, are absolutely the ones who you love when they are in the initial part of their thing because they are showing magic. But they quickly become a bit of a difficult people when you try to see it in the context of outcomes because all about them, it's all about what is interesting to them. And business outcomes actually

takes a back seat. And then over a period of time you begin to see, and I'm talking about non tech management that we are better off with mediocre engineers. At least they will listen to us. And potentially because they are not great in their engineering hand, potentially they, they begin to start appreciating the business outcome more and hence together they seem to look better.

But in the reality they they look better to finish a program, to finish a project at a certain cost in which management works. But have they given the optimal solution? Have they given us what was possible gets lost?

And that is why I always say unless good and great engineers don't grow up the ladder and some going to CINTO and some going into general management is crucial for the actual impact of building great software with the business outcome mindset because they are the ones who will be able to achieve that. Otherwise a non tech manager by and large becomes a business money money guy. And for him, yeah, for him, a tech guy is a necessary evil because these engineers are

difficult. My God, we have to retain them. So the discussion from outcome becomes more about can we keep them happy till the project ends and that has to change. It's it's it's a necessity and the loss to the world because of

this is enormous. And I have been thinking about it for quite a number of years that good guys and imagine, I mean, I'm just thinking if Elon Musk and some of these guys must have been awesome techies with an brilliant mind of being an outcome thinkers see how they're changing the world, look at the impact of them on the society. And I think every great engineer should be should try to see what they can do about it.

There should be great engineers mentoring them to think like that and not quickly take it towards culture. I'm not happy. It's not me. They have to get away from these things. And if they begin to learn this early and they are great engines, I mean you have to mix it up in some way or other and somebody needs to mentor them. The impact the the net impact which can happen of these people growing up to become senior management is enormous and exponential in my view.

Yeah, I've been wondering within organizations and within enterprise. I me personally, I have a lot of

ambition and I have no clue what I want to do with my career. So I turned 30 this year. So especially 30s like a mid midlife crisis. I was thinking either I'm going to stay with an enterprise Oregon, I'm going to do startup, or even maybe content creation outside of enterprise.

But within enterprise, I think it's good if you get into a position where you're incredibly valuable, where you are a multiplier and the people that are really good in tech, there is now a career path where you can stay as individual contributor and you will still be, I think a really good multiplier because people will come to you for answers. You will still enable other people and you will be hands on. And then there is the other path, which is the one you're

mentioning. You move up the career ladder, you either become a manager or you become AC level tech person. And from that aspect, I think it's still a multiplier, but it just is amplified even more towards an organization. And from that perspective, there's only so many people on C level. I feel like you become irreplaceable in that way to an organization.

Oh yeah. Yeah. And I think every large company today, if you look at at the top of the pyramid, you'll find those tech tech guys, those engineers who just understood how the world works, how the company is funded, where is the money coming from? What is important to the customers, what is important to society. Those kind of people are the ones who are at the top of the play.

And I think that should be a single most important aspiration for all birding techs who are, who love the idea of writing, you know, the the craftsmanship in natural in them, right? Who who naturally want to do something great with the software, but have a larger view or have built a larger view of how the company functions. Who begin to appreciate.

You know, one of the other thing which you'll see, Patrick, is quite a lot of soft engineers have a problem that they're so good in what they do that they begin to get a blind spot that I know better how finance works. I know better how managers work.

I know better how ACEO should work. It's arrogance. Yeah. It almost borders arrogance. So I think it is very important to understand that the people who are in the other field and have grown, they must also be have some having some intelligence in their field and can I learn their point of view. I think that itself very quickly will allow other functions to

invite them in their problems. Today, the senior management or the managers of different departments want to avoid it because they think the conversation will go nowhere. If someone is very headstrong. Yeah. Or if I discuss my real problems, he will go out and say, wow, this company, yeah, they talk like this. Money seems to be the only thing which matters to them. Well, how the world works, right, What is A tag, What is a

CapEx investment? What is the OpEx investment has a direct bearing of how softwares are built. Yeah, yeah, definitely. And you have to appreciate it. You you cannot just say that I don't care about these things. These are so somehow opening their minds to how the world works, how the money flows. What is the financial architecture Yamil Financial architecture of software is crucial and it's not tough to appreciate.

You just have to be. You know, I almost want every awesome engineer to get those one week as finance as finance function go and see what they do and if they are open to learning. These guys will become the future very quickly. Yeah, this is a, it's a big if, right? And it's very interesting because software engineers, it's hard for me to compare to other industries, but they can be like mini entrepreneurs.

They really take a task, a problem, they create something and it has direct sometimes impact to users, to customers, to financial parts of industries, which also means that, yeah, that there is kind of an innate arrogance that grows with people. I've seen it. I feel like, and maybe this is a personal trait. I like to be humble. I like to say I this is kind of what I know or what I think I know. I like to talk and say very explicitly, these are

assumptions that I have. I like to be explicit with my language and it's very inviting to then another person to chime in and I like to Co create for me. It's very daunting to say I am the only person that knows. And if I fall back, then the whole organization crumbles. From an engineering standpoint, I don't think that should ever be a case. That's a risk for an organization, 100%. Yeah, yeah.

So I I think if, if we can get an ecosystem running in the world where we can create, I don't know if it has to start with education where you can sort of encourage great engineers. And I use the word great engineers all the time because mediocre engineers by and large are more aware of some of the systematic issues because one, they don't want to be confrontational.

So they begin to understand the point of view either by the choice that they don't have a choice or because they listen more because they know I'm not I'm not a no all person. And as a result become natural. You will see them being pulled up into the hierarchy, but what is happening that sub optimality is growing up the hierarchy. Yeah, that's also a risk. And that's a huge risk. So by the time they're hitting ACIO function, you can imagine what is the devastating impact

on the organization. And and I always use the word society at large because we have to see with every function become tech, common becomes tech. Unless we get the right people there and if you allow sub optimal engineering mind to go there, even if they are humble, it has a direct impact of how you are solutioning the larger

problems of the world. And I think that must be understood by the best of them, the best of the techies that in the end, I want to be an engineer when it makes the impact to the society and I I want to really encourage. I mean the more I talk to other engineers who I who are quickly spotted and in ZBI think we have a lot to quickly understand this aspect. Culture. Yeah. And I see that when they hear it, they quickly go back and do their research, right.

And then the next thing is how your their natural instinct of feeling of finding fault in other departments, of finding sub optimality in other departments can be seen in a way to improve. And rather than saying, yeah, it's useless, useless. So you'll hear that word a lot, right? And and and and this whole aspect of what is in it for me now you're solving a problem and what is the need for the people who are going to use it is most important. It's a real mindset shift.

I feel like this path, I don't think it's for everyone because there is a lot of people interaction and some people just they it drains their energy interacting with people getting by and thinking about political credit. When do I apply something or when do I actually say not my battle this time, but the people that can, I do think they are going to make a real big impact. But I would I would add one more aspect. A lot of awesome engineers have a think about being solving alone.

Team is not naturally. And even if I want to create a team, everybody should be like me. But I don't think even if you work, if you don't like the idea

of managing people, the idea to appreciate what you're trying to achieve or what companies are trying to achieve itself can take them up to hierarchy. They're done in part of the think tank, so I would say as a great engineer you should not aspire only to remain a A1 man army unless you want to start a startup and change the world. Which is very achievable nowadays. Please do it. Please do it. But then if you are of that kind, then absolutely don't try to remain in a enterprise

organization. Go start something and change the world. And I'm pretty sure as you will build that thing, you will again need a different guy to run it as it becomes bigger. And maybe yeah, because then it is best that you slightly move and start another one, because the minute it becomes bigger you have the same problem, even things that you start. And they are very successful.

Very successful and not a bad idea, but if you're a great engineer and you want to remain in enterprise, you will. And if you're not learning these, then you slowly become a liability because everybody knows he's awesome, but every nobody wants to really. Interact. Interact with you at all and you slowly become a person who who's a, hey, I don't know till when he's going to stay because you're not really impacting anything. It's the negative energy which is pulling through.

I like what you mentioned that even though you might not manage people, you might not move up the hierarchy. If you are an individual contributor, very senior, you will still have influence and you will be part of an organizational think tank. Because I've had another person on, he's responsible for his VP of engineering at Samsara Praveen and he used to work at Uber as well.

And he's saying that from projects that we have, some projects just have risk innately and the projects with low risk, we can put an early in career person backed by an engineering manager. So to mitigate that risk. And early in career people, they can actually excel and learn on the job and actually thrive in projects, being responsible for that project and that piece of work, the work where we cannot afford any risk that close to the highest level staff

engineers that we have. It doesn't mean that the senior level is not good enough. It's just the risk mitigation factors. It's all business. So we want to really mitigate risk. It goes to a staff engineer. That person is still responsible for individual contribution, can carry projects over the finish line, but they are not managing other people necessarily.

And they are probably very happy with that because that is organizational impact to the highest degree where we cannot afford risk and you're responsible. Yeah, that's impact. Yeah, you always need some of those. And those people were good enough to start their own companies by. They will. Yeah, exactly. So you have to keep them happy with interesting work. But that has to be a smaller percentage in an org. Yeah, it cannot be everyone. Because the people.

If you create an org which is full of those then the chances are it it will have a counter effect. They will leave, I also think, because you will not have interesting work for everyone if that's your whole. They will leave engineering force and you will not get the outcome than few who can take you to the finish line. Yeah. So you have to balance that.

Interesting. You always have had kind of a background in in engineering, but you very consciously moved to CEO, your CEO not CTO, Yeah. Why is that? So yeah, I started as a tech, right.

So I think it helped me later. But you know, I as I grew, you know what I began to see that I'm able to understand what customer is saying and was gravitating more towards that part and little bit of, you know, destiny that, you know, I did my MBA. And in those years, early 2000, once you do an MBA, your natural outcome was more towards, you know, selling customer interaction, solving customers problem and build the business. And that's what led me to more

sales. So from tech to, you know, little bit of a pre sales in between then my studies and then moving into sales And what I realized that my my natural ability to understand what sales, what, what customer is asking and my small experience, 3 or 4 years. That's all of doing tech is coming very handy because I'm understanding him and I'm able to explain how he should be thinking in a in the systems way was better than in the guy who

would only sell. And that gave me the first confidence that this seems to be a phenomenal area because I know tech enough to understand how to apply to solve this problem. I'm pragmatic, I'm not, I'm not overdoing it. So when I hear that how much funding he has, you know, he's funding it's is it a maintenance kind of a thought process or is it revenue generating application?

My idea of how we should approach the solution was naturally very attractive to the customer because they felt OK, he understands a little bit of how we are funding it. So ultimately it was something we discussed earlier. It was all about understanding where the how the money flows, not that I was aware at that time. But you were curious. But I was curious because to sell you must know that. Should I spend time with this person? Does he have the money?

That obviously was making me curious about the money and that eventually helped me because as I grew further into sales, that got me curious more towards why projects fail even after funding, how are we not able to deliver, why tech organization is not able to deliver on that. And that's where my interest in Conway Law and some of those really became what you want to build as a system is totally dependent on the communication pattern of the of the units which are building the system,

right. And I'll give you an example because this is a bit of a archaic concept that if you have a front end team, you want to build an amplific system which has a front end team and a back end team. So how will the system look like? There will be a front end architecture, there will be a back end architecture. And what you really wanted was the more maybe unified architecture.

So basically since you created a silo of front end team and back end team, you actually got a system which has these two and and if you had the security team, potentially you'll have a security after the system is made. So your organization is your. Your system is totally reflecting the communication pattern of the units. Is this also where most projects fail in the research that you did back then? Oh yeah.

So the more I saw that and more like, OK, the more you create teams which definitive structuring, the more it begins to fail. It is failing by the nature of this communication and interfaces. So can there be a better model? And you will see, you know, I mean within our own company and others, we have tried to resolve quite a lot of that issue by bringing units together. In the end, if you want customer outcome, then the team should be

simple outcome, right? So how you create and I think you know, be it on the Spotify models and other models, you will see they have tried to solve, solve these issues that you know, how do you organize? And that is why good tech who are aware of some of this organizational structures and how the systems are made can also be a big plus. If those are the people who grow up to also decide how based on what you need, how the org should be today.

It's a non techie guy or a non software engineer who is deciding how should be the org structure. So the problem starts really early and that is why, Patrick, I'm again saying the best engineers, we have to maybe identify them early and take them into different subject

areas. Gotcha. Yeah. If you really want to make a real impact, otherwise software development will continue to be called an expensive necessity, where all your mind will be not on the outcome, but how to retain, how to keep them happy and almost a entitled. It's like us versus them. Team and that has to end. Yeah, I fully agree with that.

Yeah, in a lot of people that ask questions, I can see they are early in career and they're asking what type of organization should I be in for me to grow and XLS fast as possible, you know, very ambitious. And I think early in career people more so because they have less responsibilities, no house, sometimes no pets, no kids, potentially no relationships. Yeah, on the longer term, so they can focus on their career

and they want to really. And my advice to them is always go to an organization where tech is an asset, is a partner, is treated like such because you will have room to excel. People will give you space and time to grow and you'll have a lot more responsibilities. If you are in an organization where it's really that US versus them and tech is a cost and a liability and we don't really trust them. I think it's too far gone. I wouldn't even know how to

change that in an org. I would just be like, I'm not going to go there, I'll go here. It's that. But it has to start now or start somewhere because with every company becoming a tech company, we have to get that culture of a tech starter where the right tech people are at the right hierarchy levels enabled, yes. Otherwise good, good soft engineers are not coming into companies because they they find the culture bad because the culture has been going on for

years, right? I mean, who has moved up, By the way, I'm not making a very sweeping statement.

By and large, who has moved up the hierarchy? People who are not the best of engineers but had a more appreciation of business, more little bit of being confirmative to what management wants. Those are the people who moved up. Easy to work with. Yeah. So how are you thinking that they will appreciate the best of engineers? No, it's like it will be cascading. Yeah, it has to start. And then and with the world moving towards becoming a tech, it's important that this is this

is resolved. And now with AI coming in, imagine how what is, what is coming, what is staring at us. Whole new way of building software and whole new way of what you want from AI. It's almost becoming human intent and values. Yeah, right. So how do you bring an outcome of human intent and values when you build a build a software imagine the organization needed at that time. I still haven't thought it through, but I I'm I'm very clear responsible AI bias has

not need not be there right. And it's it's less to do with the engineering, it's the outcome which is beneficial to the society or the customers. How should we organize it? Going back to the Congress law, How will you organize the new world of tech organization? What kind of people are supposed to be at the top of the pyramid now?

So these are, if you ask me, are the real thinking, which sometimes I I'm trying to seek from the learned people on the from different places to understand how are people thinking? How are the gurus thinking? And how should we move our own companies to be in line with that, to be productive? I talk to a lot of people and I don't have a single outcome yet. Everyone kind of figures out what works for their own context and the only way they get there

is through experimentation. What I have seen as advice for any engineer, and I also subscribe to that idea, is AI as a tool, right? And your your value on top. If the tool becomes good enough to replace you, then indeed.

So if you copy whatever you get from a tool as outcome and that's what you commit to and that's what you engineer and whatever software you're building, then you have no value on top. Then I might as well just have the tool and not have you. If you just copy paste, then it turns out to be incorrect, then you're even worse the liability, right? So you have to take ownership of that, and you have to bring value on top. And you can do so by having really good fundamentals.

So actually seeing what the model has an outcome, seeing how it fits in your context and seeing if that's a good match. Doing reviews and more code reading than ever before. Way more than writing. So your draft. Changes governance. Yeah, yeah, all of us and much, much more. And I think now more so than ever, understanding your business context and the

problems you're trying to solve. Yeah, I mean I was, you know, listening to one of the C level people in USA couple of months back and they are a, they build banking products, lending products and they want to implement AI. And here is the problem, they cannot have a situation because the lending product is priced based on who you are, you're buying power and all different kinds of, you know, series of things. Based on that, the pricing is

done. The worry is if you create this AI model which prices you, it begins to misbehave with respect to minorities. What will happen? How do you take that out? Now? This is becoming a engineers problem. If you look at it, it is certainly becoming a very, very engineering problem. It has to be taught. Ebenezio, not a much later thought. So how we are we going to manage that? Because AI will act now. It's reasoning and acting.

So how are you thinking? So the awareness of great engineers around these aspects with all the previous discussion we did related to how money functions and the org structures all has to come together. So it's even more intense now as I see the way the world is moving. It's interesting, this problem was always a problem in machine learning, like how to how to get rid of bias.

I feel like with the availability of large language models, it's just amplified because if you have better access, all of a sudden these problems also get then highlighted, which we still need to solve. Like all engineering problems are are still there and we have more complexity now more so than ever if we're trying to fit AI into tooling. And you, as you said, you need the best engineers now because they must understand how LLM

functioned. So unless you know the unless you are a great engineer, you can't even understand how to interpret the outcome. Yeah, absolutely. I I had a question for you though, because as engineers going to move out of their day-to-day, if I'm in my day-to-day and I'm individual contributor, I stay on top of a lot of things and I'm productive on the keyboard and I know my tech and I also what what comes out with regards to frameworks or languages or tooling infrastructure.

I keep more up to date with regards to models as well, because that is what I'm responsible for as I move up the ladder. This is where I've seen the biggest risk, where people that have had history in tech potentially five years ago, sometimes even 10 years ago, still really rely on that fundamental knowledge, but the reality changes. So that's a danger for me. When someone has outdated information and they really act according, they might not listen to the signals of current day.

And I don't know how to prevent that other than actually, if people have a solid foundation, moving up the ladder and still very much keeping up to date, either through personal projects or to just hands on things, but really staying up to date. And and Patrick, what I felt because in the early days I used to have that phenomena of saying, let me check. But as you grow, you don't, you will not be able to catch up by having a private project running.

It's too much to see it by hand. And that is when your

fundamental grounding in that system thinking with your ability to engage with your team to make a determination and creating an intuition of what you're approving or what you're saying should be the way forward becomes important. So you will have to become intuitive. But then without fundamental grounding, you can't become intuitive. So what I'm what I feel, imagine a guy who's not a great engineer and has grown up. Imagine how he can create the problem.

So good engineers who are who work hands on, spend a lot of time understand the concept and is able to. And when a new concept comes, he's able to quickly relate and has ability to talk to his team little bit in depth to understand how things have changed. Will be the best ones to govern and move forward. But at some point of time you have to go away from saying that. Unless I check it with my own hand I don't get a sense. It's like micromanaging.

Yeah. So you will have to build that intuition and you'll be surprised because I went through that. Your intuition are not way too off. It's only the amount of homework you do after that to make sure your intuition. What are the adjustment to the intuition? OK. And that confidence, you'll have to take that if a new concept has come, it's not that your historical background or grounding is not going to help

you. When you talk to and get into the, you know, real play and see what people are doing, it's very quickly comes. And that intuition of a senior guy is so much helpful even to the younger ones, despite of you not being the expert of that new new area. I like that a lot. Yeah, from your perspective, you must engage with a lot of C level people, tech level people, especially people that have grown up, that are really senior, they might even be strong headed.

So from your perspective, either you have to say, OK, this is my vision and this is what we're going with, or you have to sometimes agree to disagree, choose your battles accordingly. What makes you actually say, I'm going to agree to disagree and we're just going to go with the person that I trust on the

technical level? See, one thing is very clear, as you, you know, get into more and more general management, you have your intuitions, but you also begin to appreciate that there are people who could be thinking which is not naturally in your line of thought and ability to judge it. Make your own assessment, do some digging, spend time and then you have to make assessment that maybe what they're saying is not intuitively exciting me, but it could be right, right.

So that's the first part. It could be right. It could be right of the company. Then the idea is fail fast. OK, give it, but test it you.

It has to be on your one of the agenda on your desk to check if it's happening because it can quickly spill money which could have been deployed at something, something else. Because at every point of time, the money has to be prioritized where which one you want to move to build your company further. Then there are some, which is very I, I don't want to use the word cultural, but it is also about motivational, right? I mean, there are your, your engineers are always excited

about something, right? It could be for a conference, it could be for that we must dabble in say, quantum, right? I want to dabble in quantum should you spend or not, right? So intuitive could be it's for future. Let's try. So I will say yes, but manage it. The other one conference. You don't believe this conference is important to you? But my engineers are super excited. So I, I, I, I don't think this money is well deployed, but that excitement is also worth something to me.

And hence you just say, OK, I, I don't like the idea, but please go ahead and do it. And this is also true with many PO CS which people want to do. You know, many accelerators which people are trying to build, they get very excited. Oh my God, I'm going to build this AI accelerator.

And it is this. And once you go into deeper, like, I don't know how it is really going to be used by our customers because it has fundamental weaknesses, but the excitement of building that allows you to say, OK, let's let's fund it or let's allow them to do it. But sometimes I also say that I also want you to do some offer your time into this. Yeah, of course, because you're excited. Then let it be both ways

interesting. And then as it moves, you want to keep checking if it's really a brilliant idea. If it is brilliant, you want to immediately bring it into your fold and say now I want to move forward. It has happened to us in Zebia all the time. You start with I don't know what he's talking to. This is making sense. Let me show it to some of our customer. See the reaction while they are doing their hobby thing or what you didn't believe in.

And then suddenly you realize aha moment, my God, this, this has to be just hyper accelerated because this is huge value. Yeah. So this is where, you know, sometimes you are intuitive, sometimes you don't. You completely disagree. That's fair. But you say I'm moving forward with it. And sometimes it's purely for the motivational aspect, because that is equally important. Yeah, I looked at a lot if. Your tech guys are motivated about something.

It's worth spending that money. I mean, by the way, I don't want to say that only for my engineers. If tomorrow my IT team wants to do something, I will have the same reaction to it. So I don't want to order other people function team. Hey, why not? So it's I always want to say this is not about only engineers, it's also about every function in the organization.

And is this your your default? Because I feel like if you and I know each other better, if I've worked on things and I've delivered certain outcomes, you have a higher trust relationship in that whatever I'm pitching is going to have that same track record based on the person that you know and based on their track record. If I come in with a blank canvas, we don't know each other. I don't have any political credit with you and I pitch an

idea. Is your default to have that same analysis, excitement or business outcomes? Feel fast. All of that I have the same. I like that a lot. Yeah, so it doesn't matter who's the person you, you just want to, you know, check it out. Nowadays, I also do one thing because quite a lot of our our guys are are reach out to me. Oh yeah, hey, we are. Building this, We are building this, yeah. I mean, my number is available to everyone.

So it's on WhatsApp or Teams and and it becomes sometimes overwhelming to put your own mind. Then I say, OK, can you, So I call my team and say, hey, can you check with that guy? Because the excitement is high and I do did a very quick check in the flight looks like not a bad idea, but I don't know what it means.

So I, I have now began to also ask other people do it, but I 9 out of 10, I want to be involved because this is where you have a little bit of I don't know, I call it micromanagement, but I feel as if I relate with with great soft engineers who are excited about something more than many I see within my own team also. So I feel that I'm able to sometimes I, I get excited by the idea that there's a guy who's coming with this, but I, I want to be as much involved as

possible in those places. It's. Probably like interest and curiosity and background. And it is also I think the culture of our own company, I think our own company has grew through these. You know, we have been a bottom up firm and I have a feeling that some of these as ACEO, it's my job to keep an eye because innovations and the future revenue ideas will come from out of nowhere any part of the world rather than somebody thinking from from the top. It's not going to happen.

And that I have appreciated in ZBR right from day one. So I'm not, I'm not going to miss that. I'm really wondering when I was responsible for product, I had certain people that would pitch ideas that I would think this is not going to work and this is not going to work for XY and Z. But because it's a low risk, I'd be like, OK, there's a learning opportunity for them, right? Either I am proven wrong or

indeed it's going to fail. And they learn from that not just from a product sense, but also from a technical sense within the team. Sometimes people could not agree on a certain solution direction and we I'd be like, we'll let the person actually try and figure it out because that's the best way to learn, right? Feel fast, but actually do it. Don't prevent someone from making their own learnings based on your experience. The way they learn is to actually sometimes fall on your face.

How do you handle those situations? Because a lot of stuff that comes to you is of a higher scale of magnitude, right? Which means failure can be more costly. But how do you view that? Do you still allow people to learn and fail from that perspective? Absolutely. My only only difference is I try to to to cut that idea into iterations because what I don't want the whole idea of fail fast is about iterative thinking. So I I almost asked them to iterate. What is the core of your thing

that you want to build? Can I check if this is going to

work? And you'll be surprised some of them the minute you go to the core that you have to 1st build this. Then if you want to build this idea, you have to 1st build the difficult part. Almost 50% of the people don't go deep there because the overall idea was exciting. Yeah. The minute you say no, I want to handle the the most important and the complicated part first. Can you iterate on it? Almost 50% wins away. Oh, really?

It's very surprising, you see. Yeah, they will talk for some time and then it will fizzle, fizzle out. And then there you have the rest 50% who are trying, and only maybe one or two are the ones who say that. See, it's iteratively working on. One or two iterations have worked and then you have to make. A call, you have to build it up,

yeah. So that way you're also saving money for the company that you're not just saying, OK, I'm going to invest, but you're also making sure the people with ideas are tested on ideas and tested on their own passion because you have to sometimes test the passion part. I have a final question and it mainly has to do with something you highlighted previously. Sometimes I explain this hierarchy of the organization that I'm in and people say it's

quite flat, right? I have a manager, then I have their managers managing direct of an L, and then I have you basically, and I can send you a message on Teams or wherever. I have no clue because I've never done that, how fast you reply. But the fact that you say people reach out to me and they have ideas, that means you're accessible. That also means you can get swarmed, right? I have a podcast. People are approaching on LinkedIn, on Twitter.

I already get overwhelmed by the amount of people that reach out. So then within a company, specifically the person that you, you are CEO, people will funnel towards you. How do you manage your time in general? You have very important stuff, customer stuff, things that make the business run. You also have people that have excited ideas that you want to enable, that you want to highlight, experiment with a challenge.

How do you manage all of that? Yeah, I think it does overwhelm me and I have to find a way, so I still haven't figured it out. I love that. You know, I still am passionate about people reaching out and giving ideas. Or sometimes they say, can you give me 30 minutes? So they're not giving idea. They say I have something to talk to you for They. Jump in a call.

Right. So, but I do it and I know a time will come as I told you that on idea sometimes I'm forwarding to some of my directs to say can you check it? But I always feel I'm missing that feeling is overwhelming, which also makes you restless. So I sometimes it's better to do it yourself so at least restlessness won't be there. But as we are growing, I will have to figure out a way. Yeah, it's not scalable otherwise.

Yeah, it's not scalable. It's and I also don't want to create hierarchies for it or go to that committee if you have an idea, because then I know it I will kill all the good ideas. So I think as time moves moves by, I wonder if I should delegate more on the core business side and key continue to be focused here or should I delegate here and continue to focus on my core business which is more important?

This is interesting. When my plate is full, I typically de prioritize the things that I actually don't enjoy, which I also don't think they are valuable. Like valuable things that I don't enjoy that I think are very important, I will still do. Otherwise I can't do my job well. I can't just work on what I think is important. But you are in a position to be like, no, I actually do want to focus on this because I think I add value here and this is what I can delegate to these people.

Yes, I've never been in a position like that. I don't envy it because I want to do everything. I think a lot of things that are fun I would like to do, we think, but time is finite, so then you have to make decisions. Yeah, no, I have the same problem. I do have the problem of I haven't seen it, so I'm not comfortable. And that at some point of time has to reduce and it's a learning. I think it's a bit of a learning journey for me.

I think as we become bigger and bigger, I will be forced to think of an idea. Yeah, you might have to let go of something you really like doing. Yeah. Yeah. But I, I do feel that in the job I am listening to ideas from people in different corners of the world might have a higher value than some of the general management running the business part, which I think is more easily delegatable. So that's my current way of thinking, but currently I'm managing. I don't.

Thank you so much for coming on and sharing. Thank you so much this. Was a real joy. All right, off here. If you're still with us, let me know in the comments section what you thought of this episode and we'll see you in the next one.