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.
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.