Kent Beck actually said after he saw like Gen AI for the first
time, he realized that 99% of what he knew became irrelevant,
but that 10% that he had learned became a thousand times more
important. There's a danger sometimes, even
if you are pairing two persons, you would still outsource your
thinking a lot to the AI. I definitely think there's a
danger in doing this. AI, at least the way they're
currently trained today, they love producing code.
Most of that code sometimes without the right guardrails, is
gonna be gibberish. The next programmer who comes
and looks at it, they're gonna go, why are we doing this?
Code is read more by humans. It's meant to be read by humans
more than it is meant to be run by the machine.
Really what you're trying to design is for human.
And that aspect still applies. This week on the Tech Lead
Journal, meet Mohan Krishnan, a transformational leader who has
transformed engineering teams at Grab, Bukalapak, and BBM Emtek.
How do you actually think about making a successful
transformational engineering teams?
My philosophy has always been that you wouldn't get trained by
a tennis coach that doesn't himself play or herself play
tennis. I think that applies to
technical management as well. High performing engineering
teams are very similar to high performing sports teams.
All of this needs to be supported by a foundation of
like some level of discipline, which is not something we
normally associate with our line of work.
When I see tech forums within this region, people are now
questioning should I still be in tech?
I know there's a lot more focus, are we getting rid of juniors
and all that? I don't fully buy into that.
I think what we mean we are raising the bar of what a junior
engineer should be capable of. Do you think the Southeast Asian
engineering talents are ready for this?
Hey, Mohan. Welcome to my next in-person
podcast recording. So you know, I've been starting
to doing this for tech leaders in at least this region,
Southeast Asia, first. So I'm very happy to have you.
It's been a long time coming, I think I've always been wanting
to invite you. And so yeah, here we are.
So thanks for doing this. No, thank you Henry.
I, I'm really appreciative of you, uh, choosing me to be on
your podcast. I hope I'll be able to share
something useful to your listeners.
Right. So Mohan, maybe in the
beginning, I always love to ask my guests first to share a
little bit more about yourself, right?
What type of leader you are. And maybe looking back from your
career, any highlights or, I don't know, turning points that
shape you as a leader today? Yeah, I mean I think there are
definitely a couple of career pivotal points, that kinda
shaped me into both, like maybe my appreciation for engineering
and yeah, I guess you could say my leadership approach as well.
The first was definitely, you know, taking the plunge to join
Pivotal Labs in Singapore in 2011-2012.
I had been working for a Malaysian startup up to then,
that was focused more on the logistics space.
And it was good and I was running a small team and all
that. But a lot of the things that I
had learned were very much southland.
Like, so we kind of read stuff, we try to practice it.
Pivotal Labs was the first organization that I joined where
I learned a lot from. I'm not sure how much people
know about it, but like, so Pivotal Labs are in San
Francisco and then they, at some point they had set up a office
in Singapore that was working very much in the same manner,
working with startups. And they are an XP shop, extreme
programming shop, true and true. And experiencing, I had read
Kent Beck's books on extreme programming before that, right?
It came out around there so late nineties.
So, you know, I picked it up from the shelf.
A lot of it looked like, wow, can you actually do this, pair
programming all the time, test driven development.
And then I joined this organization, which pretty much
lived and breath it on a day-to-day basis.
And it was amazing. Uh, I learned a lot there.
So that was definitely a pivotal moment.
Happy to talk through some of the stuff that I learned at that
point. But very quickly, then I did
another pivotal inflection point in my life was taking the plunge
to move to Indonesia. I worked for a startup.
I did that with a close buddy of mine from Pivotal Labs as well,
Tommy Sullivan, who's still there.
Maybe one day you'll have a chat with him.
And that was really an experience as well where we had
the opportunity of taking a lot of stuff we learned in Pivotal
Labs and trying to practice in a completely different culture.
I mean, completely different is probably overstating it, but uh,
Indonesian culture is different, right?
The Southeast Asian countries have their own distinct flavor,
approach to work. So taking this like very
disciplined focus approach to work and applying it in that,
and it mostly worked. And it actually had a lot of
benefits as well. So that was quite an experience
as well. Lastly, also related to my time
in Indonesia, I think was the BBM experience where the company
I was working for back then Emtek decided to make a very big
investment and buy what was remaining of the Blackberry
Messenger user base from Blackberry or RIM, but by that
point it had been renamed Blackberry.
And like relaunched it in Indonesia as like a local
messenger. It was very ambitious.
It was a crazy idea. It involved a lot of hard work
and it was a really, uh, eye-opening experience in terms
of kind of working, again, across cultures, like working
with a Canadian team, working across time zones.
And then there was a big technical challenge as well in
terms of doing a on-prem to cloud migration to Google Cloud
back then, which was also very new in the region.
So that was also quite an experience, kind of like taking
a bet on a new cloud provider, building relationships,
understand technical problems, solving tough technical
problems. Yeah, I think those three
things. And then I've had, I've been
very lucky, right? Like my move to Grab has been
quite exciting. I've been learning a lot as
well. But if I were to look back and
say like, okay, which were experiences that really shaped
who I am today from a career professional standpoint, it
would be those three aspects. Right.
Thank you so much for sharing this story.
I know you have had long, more eventful, you know, highlights
in your career, right? So I think thanks for
highlighting these three. I'm a bit intrigued by your
sharing about Pivotal Labs experience, right?
Because you were saying that you were immersed in the practices
that they have, you know, XP, extreme programming, maybe a
little bit flavor of Agile, and more on the core technical
practices. These days, actually many people
get exposed a lot more on the AI tool stuff, right?
So not necessarily those kind of technical practices.
In fact, it's more like a shortcut, like you can ask
something and it will give you the result, right?
So for people who are maybe starting in their journey, what
do you think still relevant? Looking back from your career
experience, right, when you studied first-hand those kind of
practices. For those people who are more AI
native, so to speak, right? Is there anything that you want
to convey to them such that they can have a more better way of
learning? Yeah.
It's a really good question. It's definitely very topical.
Something that we discuss a lot at Grab, and with other friends
as well. You know, Kent Beck actually
said, and I'm paraphrasing here, that after he saw like GenAI for
the first time, he realized that 99% of what he knew became
irrelevant. But, or was it like 90% of what
he knew became irrelevant, but that 10% that he had learned
became a thousand times more important.
I'm paraphrasing here. Don't quote me on it.
But essentially what he was saying is that like a lot of
core skills are still extremely important, if not more important
in this, in this realm. And I agree 100% there.
I think if you think about things like, especially test
driven development or pair programming.
And there's lots of material on this, I'm gonna repeat it.
But like, I think these are the type of techniques and
approaches that are going to help people use AI better.
I am not convinced that we're gonna go full autonomous just
yet. I think Andrej Karpathy talked
about it in his YC Combinator talk where he talked about this
sliding autonomy, I think we're very much still in a stage where
AI can help us accelerate lots of work, help us with debugging,
but the human's still gonna be in the loop.
So the question then is how do you make that loop something
where the human's providing guidance in a way that makes the
AI do its job better. John Ousterhout actually talked
about this in the Pragmatic Engineer podcast as well, where
he talked about the value of good system design and system
architecture will probably get increased as we try to build
these AI systems. Because now the role of the
engineer is to kind of think about the architecture and the
design. Because the cost, the
incremental cost of producing code has, I mean, practically
gone to zero. The question now, are you
producing the right code? So I think a lot of these all,
like I wouldn't say it's all, but like a lot of these more
foundational skills around system design, test driven, uh,
like how do you apply tests to help with design?
How do you think about a feedback loop where you can
write some tests, write some code, refactor?
These are all very fundamental thinking that actually becomes
even more relevant in the AI world.
So I would definitely recommend folks who are looking at this
space. And yes, of course, everybody
enjoys their session of vibe coding.
And just kind of generating this cool apps without giving it too
much more. And I think that's great.
Yeah. But I think I do agree, I think
Simon Williamson also talks about this.
That's a different type of coding.
The type of coding that you wanna do, that you wanna put in
production probably is not gonna be vibe coding.
Right. So definitely, I mean from my
experience as well, I can see that the value of fundamentals
become much more important. Simply because now like what you
said, producing code is so much easier.
Especially if you're a junior, right?
Even though you don't have much knowledge, you can still produce
like so-called good code, I would say.
But whether the coherence in whether the terms of
architecture, design, performance, security aspects
and all that probably needs a little bit more fundamentals,
right? 100%.
And you mentioned about pair programming.
Many people associate AI as like my pair programmer now.
And they think even like pairing with AI can give maybe the same
benefit. I know that the pair programming
is not just having another person or thing working side by
side with you. I think it's the conversation,
the social aspect, maybe the two perspectives talking to each
other and getting the best idea, right?
So do you think pairing with AI can give you the same benefit?
So it depends. So if you think about pair
programming, there's several reasons why you do it.
If you go back to the original reason Pivotal Labs did it was,
uh, they wanted to all, they felt the best way to teach
someone was by teaching them on the job.
So what we would typically do is when we had an engagement, we
would be pairing between a customer engineer and one the
Pivotal Labs consultant. I think that's that goal of
pairing. I mean, of course, when you're
talking about AI, you can't really teach AI.
We don't, we've not, we are not at a point where these models
can really take that feedback loop.
Yeah, you can write Cursor rules and stuff like that, but it's
very different. I think that role of pairing is
a bit different. It's very relevant for
organizations that are trying to upskill.
So like when we were in Indonesia and applying pair
programming, that was one of the main reasons why we did it as
well. It was just we could onboard
someone onto a project within a week.
And they could be productive. Just accelerated learning and
exposure. Of course, there's cultural
aspects and stuff like that that they need to gel with.
But if they did, you could take someone who's a fresh hire and
they could be committing code into production before the end
of the week. They could be writing a feature
and driving stuff by next week too.
Of course, you know, complexity and stuff like that.
So I think that's one aspect of pair programming.
Now, the I think the aspect of pair programming that is
probably a place where AI can play a role is around having
like a rubber duck where you have something that you can
throw ideas to and you can provide some feedback to the
ideas. So for example, like maybe you
have a design approach and you ask it like, hey, what about
this? The AI is pretty good at coming
back with suggestions. Now, not all the suggestions are
gonna be great, so you're still gonna need to apply your
thinking. But even in the programming
world, you know, there's this concept called rubber duck,
rubber ducking, where you just have a rubber duck and you talk
to it. Of course, the AI is better than
a rubber duck. So just process of being able to
have something to bounce ideas off and get feedback on is very
powerful. And AI is a great way to do
that. Thirdly, I think AI as a, this
also happened in pair programming where sometimes we
work on a project where someone, one of the pair has maybe more
domain knowledge, more technical knowledge about the space.
So say for example, someone was working on a project and now we
need to like go and maybe build a feature that involves some
front end work. Now I might be more stronger on
my backend skills. I might not be so good on CSS or
styling. The other person might have more
skills on styling. So inevitably what you'd have is
a situation where the, pairs are supporting each other to kind of
get the work, unit of work done. But also one pair is driving
more when it comes to certain domains.
And this is where, I think, AI pair programming works really
well. With AI pair programming, what
you see is that, folks can now write code in languages that
maybe they're not super familiar with.
That doesn't mean they're not good engineers, they're still
experienced. So they can look at a code,
evaluate it, understand whether this looks like good design,
good taste. But they might not know all the
syntax. They might not know, okay, this
is the Pythonic way of writing it.
Or in TypeScript, this is what you do when you try to build
this type of interface or structures.
That's why AI is also pretty useful.
So I think, yes, you're right. In some areas, AI can be very
helpful as pair programming. Some areas, it's serving a
different function. Right.
So definitely the last point that you mentioned, I
experienced it myself as well. So I used to come from like
heavy Java background. And then, you know, these days
there's so many exotic language, all the youngsters want to use
those languages. So obviously, uh, there's a
little bit of learning curve to understand those, you know, more
exotic programming languages, right.
So definitely using AI can help a lot.
So one thing that I foresee, I haven't done a lot of pair
programming these days especially as I move up into
more management role as well. I would say maybe the type of
pair programming people do now is not a pair but like three
things, you know. Three people and then with AI.
And I feel that there's a danger sometimes maybe, even if you are
pairing two persons you would still maybe outsource your
thinking a lot to the AI and you kind of like, wrangle the code
that is generated by AI. Do you think there's a danger in
doing this? Uh, and what should people do
better if there is? No, I-definitely think there's a
danger in doing this. You need to be conscious that
the AI is just going to try as much as possible, at least the
way they're currently trained today.
And like, you know, I use Claude 4, I don't program as much as I
would like to. I don't program as much actively
at work, but outside of it, I do play around with this, with
Cursor. I enjoy using Cursor and Claude
4, and Google Gemini. Now the thing about these models
is they love producing code. So they'll produce as much code
as they need to kind of answer the question and move on.
And the reality is, most of that code sometimes without the right
guardrails is gonna be gibberish.
Gibberish not in the sense that it doesn't work, but gibberish
in the sense that the next programmer who comes and looks
at it, they're gonna go, why are we doing this?
Now again, it's a very common thing to say, but it's
definitely true, is that code is read more by humans, is meant to
be read by humans more than it is meant to be run by the
machine. Now, of course, you need it, you
need the machine to run it. That's how you get business
value out of it. But the reason why we have so
many programming languages and different things is because we
are always looking for ways to express these concepts and ideas
in a way that the machine can understand, which at the end of
the day is like, you know, you take it down to, you know,
microcode and you run it in the CPU after all the compilation or
interpretative steps. But really what you're trying to
design is for humans. And that aspect still applies.
And I'm not sure if the AI models today are trained enough
to have that point of view. They can definitely be guided to
ensure that code is well written and stuff like that.
But you need to play an active role in ensuring that happens.
So I think what I've seen and what I've heard and what
I've-tried that works is like, you know, the work needs to be
done very incrementally. Like this zero shot build an app
thing, it can work. And I have to agree, it's
addictive. The dopamine hit of-being able
to go from idea to something that you can run in a Replit
window or deploy with Lovable is amazing.
But yeah, I, I just don't know. I think it's good for zero shot.
Like, oh, I need to build like a quick guest registry for my
wedding. Or I want to, you know, build
something to keep track of bookmarks.
Yeah, for sure. Those throwaway apps.
But anything that you want to kind of build a business around
and maintain, you're going to need to be more involved.
Yeah. I think it's a very important
point that you mentioned, you know.
The code will still be read more by humans even though produced
by AI or what, no matter what, right?
So in the end, someone needs to reason about the system,
especially for systems that evolve, right?
If like what you said, you just need to build it once, you know,
like maybe wedding planner or whatever that is right?
Maybe you are not going to read it ever again.
But if, uh, we build software that is more like evolving,
serve a business purpose, I guess it will still be read a
lot by human. And we should not forget the
aspect that even though AI produce the code, someone needs
to understand what is being written at the end of the day.
The dopamine hit, I think, is really interesting you
mentioned. I personally find find it very
uh, addictive as well, right? Because maybe a long, long, time
ago we used to think like, oh, I want to be able to solve the
problem and write the algorithm myself, right?
But now it's more like the objective I think slightly
changed because of this dopamine hit.
I wanna write a prompt such that AI can produce the code that I
want. Yes.
I think this is also dangerous to me.
So we kind of like lose the aspect of, you know, actually
producing the code, the algorithm and the thinking
process behind it. But kind of like trying to find
the best prompt to get AI to produce it.
So again, like, I don't know whether you feel the same.
That's the first thing. And like what should we do in
order to restrain ourselves from outsourcing a lot more of these
things? Yeah.
Uh, again, I, I, I don't think it's so much about one being
right or wrong. It's more like, okay, what's the
purpose? If the purpose is to kind of
build a quick weekend app, then yeah, you should spend as much
time as you can to zero shot what you want out the door.
I think that's great. You know, it's...
But if what you're trying to do is build something for your
professional work or you, like, you said, you wanna build a
system that's gonna continue to need to evolve, right?
It's not just a zero shot system that kind of is deployed and
done, then there are lots of folks who have shared
approaches. I think the one that's worked
for me, and I think based on what I've read also works for a
lot of other people, is being very deliberate.
Like so spending time to first like kind of lay out a bit of an
architecture or a design. Of course, at that point not
producing any code, just kind of laying out what the design and
architecture should look like, how you think about things.
And then only producing code in very incremental fashion.
So saying like, okay, now that we've figured out this is what
we're gonna do, let's start with this piece here.
I wanna build this screen and I want a controller that'll be
taking these inputs and let's also have a test for it, right?
I think doing those steps in increments is the right way to
do it. I've heard of some people who
have been more successful with like a TDD approach with AI.
So getting AI to write the test first, I'm not as sure.
I mean, my personal experience is it hasn't.
I haven't been able to be as successful in it as much as I
enjoy TDD. I actually find it more
practical for me maybe to write the test.
So maybe that's just more on how we think or push things.
But definitely, test writing is an area where AI is very, very
good at. And like, you know, it, it'll
help with a lot of the, sometimes, the more tedious
aspects of like, you know, keeping the mocks up to date,
updating stuff. So like things that you would
normally write macros to go in, like quickly do refactors now,
now you can just get the LLM to do it.
So yeah, I think more incremental, more deliberate
thinking. Definitely, for the second
category of work. Yeah.
And not to mention, these days people are building more agentic
way of coding and even like submitting a task asynchronously
and then they'll just create a pull request that we just merge.
I think the advancement here is really rapid, I would say.
Sometimes I also fear that I'm obsolete.
But yeah, I think let's move on to the next segue, because I
know that you have been in multiple different companies and
you're kind of like considered very successful and people find
you a very inspiring tech leader, right?
So one aspect that I would want to for us to learn is how to
build that transformational engineering teams, right?
So maybe if you can, I don't know, summarize a few key
points. How do you actually think about
making a successful transformational engineering
team? That would be great.
Yeah. So first off, you're being very
generous. Thank you, Henry.
I think what I have been, over my career, is I've been very
lucky to work with very capable people.
So that has definitely helped. Having said that, I do have a
point of view on what makes good teams.
Of course, it's based on my experience and experience will
vary, right? People have different approaches
for these sort of things. And it's probably also because
of the Pivotal Labs, extreme programming type thinking.
But I feel like high performing engineering teams are very
similar to high performing sports teams.
What do I mean by that? Firstly, especially when you're
talking about like complex engineering problems, which
can't just be solved by one, two person teams, it's a team sport.
You need all the different players.
They're bringing different skills or capabilities to the
field. Similarly in an engineering
project, there's gonna be the person who goes deep.
There's gonna be the person who is very good at kind of
communicating and being the bridge between teams.
Uh, you know, there's gonna be someone who's able to rally
people when things are down. So you need all sorts of
characters in the group. A diverse set of people is
important. On the back of that, of course,
you have things like frank and open communication, discipline,
respect, and all these sort of aspects as well, which I guess
is common for most high performing teams, whether
they're software engineering or not, right?
But what I think is maybe a bit more distinctive is all of this
needs to be supported by a foundation of like some level of
discipline, which is not something we normally associate
with our line of work. I think highly effective teams
are disciplined. Now that doesn't mean everybody
comes in at seven o'clock in the morning and all that kind of
stuff, although that's what they did do in Pivotal, there was
like fixed timings of the day. It does mean though, there are
certain bars of expectation that everybody adheres to.
So maybe things like, okay, the, our code quality, our testing
approach, uh, how we respond to incidents.
That's what I think sets the best teams apart.
There are other aspects, so like, so when you have like a
high regard for like engineering quality, you naturally are also
aspiring each other to push your limits.
That's something I felt is very important.
So when you have like strong engineers on the team, it lifts
everybody else as well. And it creates a feedback loop.
So now everybody gets better. So now people push harder to, to
learn even more, to solve problems in an even better way.
And that feedback loop of learning from each other,
teaching each other, that's really important.
So another thing that I think is really important is having a
good mix of juniors, medium folks, and senior folks on
teams. I know there's a lot more focus
now, like, oh, are we getting rid of juniors and all that?
Like I don't fully buy into that.
I just don't think that's a sustainable way to set an
engineering team up. You can maybe do that for like
very small teams. Okay.
Like I've got a very small team of just like, super elite
engineers. Sure.
But like if you're talking about like, you know, 30, 40, 50
person org, you're gonna have varying levels of skill and
experience. And people are going to kind of
go up the chain. I think what we mean when we say
stuff like, we are not gonna hire junior engineers anymore,
is that we are raising the bar of what a junior engineer should
be capable of. But when you raise the bar at
the bottom, of course, the top moves up.
So the relative skills, I think, gap between these different
levels will still be there. And that in that you'll create
an opportunity for good team dynamics of mentorship,
coaching, and learning, which I think is very critical in good
teams. And that's what I've seen,
right? Like, my experience is that
people who join and stay with teams, especially at a younger
age. The more junior folks who come
in, they, they're just more hungry.
They're willing to do anything to kind of learn.
Especially, if there's an opportunity to learn from
someone who's a mentor or a coach.
And then the more senior folks, maybe they're a bit more
specialized, so there's certain areas that they want to kind of
go deeper on. But they're more willing to
teach as well and to get a reward from doing that.
So yeah, those are some aspects I feel of like highly performing
teams. Yeah.
And not to mention, like many people associate also software
engineering, like a apprenticeship model, right?
Where you have someone senior coaching you, bringing along,
solving problems together until a certain point where they
become, I dunno, much more senior and then they can go on
by themselves as a leader, right?
So interestingly, you mentioned about discipline and associate
that with like sports team, I think in a physical sports team
is very clear. Discipline is about, you know,
time, physical conditions. You can even measure and look at
it very concretely, right? Whether you're fit, not fit, fat
or you know, like muscular. I think it's very easy.
But for engineering team, probably it's a little bit more
abstract and very hard to see. And in fact, many people try now
to also measure the effectiveness of their
engineering team, the productivity and all that.
Sometimes it's arguable this measure against the others.
But in your point of view, if you can distill this discipline,
right, what kind of things that you would measure or would you
set as the high bar? Yeah, so some aspects of it is
engineering culture, like what we talked about, right?
So like things like, okay, how do you... like code quality, how
you're, uh, which is both like in terms of like readability of
your code, design of your code, testing.
Also like, just, yeah, your entire deployment process.
Like how do you, like how effective are you around
deployments? How does team responds to
incidents or issues in production?
What's the culture? Is it a blameless culture?
Is it a culture of learning, right?
I think another aspect that I feel really set teams apart, and
something that we try to instill early on when we, when I've run
teams together with other leaders is that you must instill
a culture of wanting to get into the technical details.
Like no issue is too deep. So, you know, in Indonesia, we
used to like to say, uh, no magic.
So what that means is like let's say there's a bug in production.
And it's flaky, and it sometimes happens, it doesn't happen.
When we took over the team, there was some older engineers
around, they'll say like, oh, I don't know, black magic.
And so we, we just were like, No!
No magic! Let's find out what's wrong
here. Let's put in the right level of
debugging logs. Let's make sure there's enough
observability. Let's try to reproduce this
locally. Let's try to like, okay, no,
this is in the C code. All right, let's read through
the C code. Let's get the open source
version of this application. Let's look through the code.
Let's see if we can modify it. Oh, you mean it's a language of
framework you've not used? Okay, you got two weeks.
Go figure it out. Like, go deep.
Don't stop at just the surface level.
And, you know, sometimes it'll feel like, wow, so much effort.
It's like this doesn't really affect.
But like I think that's what differentiates the teams that
have the right type of rigor and discipline around focusing on
their craft and really understanding how things work.
Another thing is like investment in tools.
I think that's another area. The discipline to kind of go
like, hey, we're not just gonna jump from one tool to the other
tool. Like we have a tool, we're gonna
go deep on it, we're gonna maximize it.
And then if we figure something else comes along, if it's really
that much better, then we'll kind of be more deliberate about
it, right? So like getting really good at
your tools, that's something Pivotal did really well as well.
They just super invested in Rails and Ruby back then. but
they got so much mileage out of it.
Just cause they were super experts and they knew how to
make it do anything they needed to do and they knew the best way
to kind of build it. So yeah, I think those are some
aspects that I would say separate those teams.
Yeah. So definitely culture and still
kind of like the code quality aspect, the deployment aspect,
the incident management aspect. The blamelessness thing,
obviously, right. So I think that goes back to the
culture. And I like the no black magic
thing, right? Because sometimes, you know,
software and distributed systems is very hard to reason about
sometimes. But yeah, I mean at the end of
the day I think we can always find an explanation even though
sometimes it's maybe, I dunno, concurrency or some random
things could happen. So I like that approach that you
mentioned. The other aspect of engineering
team obviously is to deliver results for the business, right?
And I think, I know that you have a few thoughts about this,
like always understanding about outcomes, small team.
Maybe a little bit on these aspects as well when you build
engineering team. Yeah, this is definitely
something that has become very much more focused for me now in
my time at Grab. Cause I run the platform
engineering teams here. And within our platform
engineering teams, we don't really have too many product
managers. We have and they're helpful and
they're good and it's a growing group and we enjoy working with
them. But what we typically find is
the engineers need to be the ones also kind of thinking about
the customer. And the customer here being
internal service teams. Now, in a way that should be
easier because you should be able to understand that persona,
cause you are that persona too. But it's interesting how hard it
is sometimes for engineers to kind put themself in the shoe of
the customer. I think there's a tendency to
get very fixated on the solution.
Like oh this is a cool solution or we can build it out this way
build out that way. And you end up in this trap of
just building widgets. So you got all these different
widgets and like, look at all this cool stuff we've built.
Now is that really solving the problem that we set out to
build, that you want to solve in the first place?
And many a times when you ask the engineer that, you know,
they go like, oh, I haven't really given enough thought.
Or they might anchor one thing, oh, this so and so told me this.
That's why I'm building this. And all well-intentioned, but
this is where I think, you know, really focusing more on the
outcome. Like what is the problem we're
trying to solve? What are the different ways to
solve it? And then like, you know, from an
effort standpoint, how much effort we're gonna put into
this? And okay, will this, and then
circling back again, right? So, you know, sometimes people
say product thinking. So I think especially in this AI
world, the role of the software engineer and the product manager
to some degree is melding, right?
Like, uh, I think there's this phrase called tiny teams is
becoming more popular. The Latent Space guys kind of
popularized it with their AI welfare.
They had a dedicated track on tiny teams.
And yeah, I think what that means is now that you have a
system that can help you produce a code, you should be thinking
more about the design, more about the customer problem.
And it's definitely a muscle. We would love to have more
engineers build. Yeah.
I can actually see as well, if the engineers having that this
business mindset, wanting to understand the actual problem
user is facing, it's like a multiplier effect, right?
They understand the technicals, but they also understand like
the actual business outcomes that needs to be produced.
And especially these days, you mentioned right, tiny teams, you
can kind of like outsource a lot of mundane work to something
else like AI, right? I think it becomes more crucial
that people don't just focus on the cool stuff, but actually
solving the problem, getting the right outcome for the team.
I think that's very important. And some of these is the kind of
like the responsibility for leaders to kind of like guide
them, right? And I know uh, as a leader as
well, you have a lot of experience in this area.
So interestingly enough, um, you know, like when people say about
you inspiring leader, transformational, a lot of
things, they mentioned about the tough approach that you have as
well, right? So tell us a little bit more
about your personal style as a leader, right?
How do you actually set the standards very high to the team?
How do you communicate that? How do you actually train them
or mentor them to become the best software engineering team
that they could be? Yeah, it's a very good and
relevant question as well. You know, we're going through
our review period, so I'm sure I'm gonna see a lot of feedback
on stuff like this as well. Listen, I think, to be
completely honest, I think I'm also kind of calibrating and
figuring out what works best. I think a lot of like this
notion of like being a strong, a tough leader, a lot of it, many
times comes from also like your experience learning.
So like when I was in school and when I was in the debate team
and when, and also like, you know, subsequent to that, my
experience has always been around coaches that I kind of
like sports coaches. Like you, you know, you think
about sports coaches, they're also kind of like very strict.
Like, you know, because it comes with a discipline regime.
That's kind of the type of teachers I've had my entire
life. My most effective teachers were
strong. Very clear on like, okay, this
is what we need to get done. This-is-how we're gonna do it.
And then if you don't do it, it's not so much like admonish
you, but like saying like, no, you can do better, right?
And I've, I guess, you know, very consciously, unconsciously,
I've kind of modeled some of my approach to that as well to
varying different levels of success, to be completely
honest. I think when you have this type
of approach, you tend to attract a certain class of folks to join
your team as well, because people who don't kind of gel
with this style, they'll, they'll leave.
They'll move on. Now, the good thing though is
coincidentally, it has been a good filter, I would say.
I've been able to retain strong people as a result of that
because they also are driven by this thing.
They also want the clarity. They want the strong execution.
They're willing to put in the work.
I think though, where it might be like a bit of not as
effective, it's like, okay, can I help people be more effective?
Or is this filter going to mean that you either fit into the
mold or you don't? And that's where I think I'm
trying to calibrate as a leader as well.
Like, okay, if you don't normally gel with this style,
can I calibrate my approach so that I can still make you
effective or maybe two different means.
Yeah, it's a growth part for me, I think, yeah.
In my mind as well, I mean, like, it's always hard, right?
Whether you wanna go hard on certain things or whether you
kind of like, you know, let the team kind of like solve it, set
the standard by themselves. It's always very tough because
people these days, you know, talk about, I don't know, like
giving them trust, psychological safety, you know, they are not
like a physical sports team. They're more like a knowledge
worker. It's always a tough balance
approach, I would say. But when you say you had some
failure stories as well, right? Like what kind of things that
maybe don't work well with this tough approach towards software
engineering team, right? Like what, what exactly that you
learned from those experience that you kind of like tweaked
along the way? Yeah, so I think sometimes when
you take like a tough approach, the signal to noise ratio gets
warped, because people anchor a lot on how you say things as
opposed to what you say. So the tough approach works
really well when... You know it's like radical
candor to some degree. I know the tough approach and
radical candor doesn't necessarily mean the same thing,
but it overlaps. Because if you're being very
frank with someone, it means that if you're like frustrated
with them, you kinda share the fact that the thing is
frustrating you. And that's sometimes is seen as
tough. Now, I think for it to be really
effective, you firstly need to have established enough trust
that the person who's receiving the feedback knows that your
intention is good. Your intention is to help them
on their project. If you don't have that
foundation in place, anything you say in this like tough
approach will be taken as an attack to them.
So you don't have that counterbalance.
Now to build that trust though, it takes investment and time.
So, it's a high, it requires high bandwidth communication.
So I think it's more effective within like a smaller circle of
people who you can establish that personal connection with
and that trust with, as opposed to like a more broader, wider
group. Because for the wider group,
they're only gonna hear the times when you make a lot of
noise. They're not gonna be there when
you're like in the one-on-one, kind of like explain, okay, this
is why this didn't work out, or this is why I'm frustrated this.
Or like you tell me like why you think that way, right?
Like it's just not there. So that's where I think the
calibration is required, like just being more conscious of
what message are we getting across?
Is it the most effective way? Also, I mean, I'll be frank with
you, like you know, it's, I think it's a lot about ego as
well. Sometimes being tough and like,
you know, grandstanding is, is an ego thing as well.
And I'm trying to make sure that I don't fall into that trap
where I myself wanna say this this way because it makes me
feel good. Trying more to focus more like,
okay, what is the most effective thing to be able to get the
outcome we need? And that takes effort and
discipline too. So yeah, definitely, I think for
those leaders who are also like kind of like contemplating the
approach themselves, because I think you learn it throughout
your experience, right? There's no doubt like what you
mentioned, you learn from childhood.
Maybe after certain years of your career, you also learn
along the way. Maybe you meet somebody who
teach you different way of doing things.
Obviously there's no right or wrong answer.
It's highly contextual as well. Maybe sometimes the team needs
this kind of more disciplined type approach.
And I like that you mentioned, you know, leaders have the
responsibility to have this high bandwidth communication and
building trust, right, because you can't just, you know, using
tough approach to get certain results.
I think building the trust is definitely still one thing.
And the ego aspects, I think in every kind of debate within
software engineering team, right?
I think there's always some kind of ego, I feel, like maybe this
tech stack that you really love or maybe this approach you
really love or whatever solutions that you think is the
best way. I think, yeah, putting ego aside
is definitely very important. I mean, it works not just within
software engineering team, I think in the real life as well,
I would say. A hundred percent.
One aspect that I see that I think in your career that I
think very unique and maybe interesting to learn from is
like, there was a point in time where you go back working to
Google, right? Um, so I've seen your career,
you have been like, I don't know, CTO, you know, senior vice
president, you know, managing big, large engineering team.
And then you took a decision to actually go back as an IC,
right? When you go back to Google.
And that was kinda like a short stint.
So, and for many people, especially leaders who have
been, you know, in the 15 or 10 year of their career as a
manager, right? Sometimes they wish to go back
as an IC. But sometimes they have so many
different thoughts. Maybe if you can outline to us,
like what was your thought process back then?
Was it difficult for you to move back from management to IC?
And yeah, maybe we start from there.
Sure, no, absolutely! It's, it's a question that I've
gotten before. Okay, so firstly, for me, was
first and foremost an opportunity to work at Google.
I know you, Henry, you've worked at Google as well.
I wanted to experience, take a view of inside the Googleplex,
okay, what it is. Unfortunately, I joined during
COVID, so it wasn't the best experience.
But all kudos to Google. I think they, they did a really
good job with onboarding. They went out their way.
And that was great. So the opportunity to be an IC
and kind of like bootstrap and learn like, okay, what would it
mean if I was like a software engineer or like a, back then
the role of solution architect within Google, that was really
alluring because I wanted to learn again.
I wanted to see how these big companies do it.
They've done fantastic stuff. Also, just the pedigree, right?
Like the ability to kind of like look through code commits from
Jeff Dean or Sanjay Ghemawat or like, you know, look through the
code for Bigtable. I didn't understand a lot of it,
but it was just the experience of being immersed in that.
So the IC role for me was almost secondary to the opportunity.
Having said that, I think, the IC role was also an opportunity
for me to kind of test my own skills.
Like, while I had been leading teams all the way up to like
2014, 2015, 2016, I was still kind of working on code as well.
Cause the team wasn't that large.
We were like, when I was in Indonesia, and we were probably
2014-15, it was like a 70 person team, 70-80 person team.
So still below the Dunbar number.
I could go in the morning, we'll do stand up.
I'll spend a couple hours pair programming.
So we, with someone on the team. It was very common.
Tommy did the same thing. Like we spent more time, we
spent very little time in meetings because the team was
firstly self-organized. We had the different touch
points a day. We'll have a standup in the
morning, teams, company wide stand up.
So we'll have all the engineers kind of do it.
Then we'll have a team stand up and then we'll break.
And uh, you know, I was lucky to, Emtek was relatively hands
off in a good way. They kind of just let us do our
stuff. We had product team members who
would work more closely with the business and we were somewhat
firewalled from that for, which was great.
We didn't have too many meeting. So I was very involved in the
code up to like maybe 2014, 2015, I worked very close.
Before we hired more senior people in the DevOps team, I was
practically like the tech lead for the DevOps team.
And then only like 2017, 2018, where I really kind of rolled
off code again and was more, not actively writing code, but
definitely involved in some of the technical aspects, which is
kind of the role I play today as well.
So going back to an IC role was an opportunity to kind of
reconnect with some of that, especially given it was solution
architecture within Google Cloud, it was like DevOps and
stuff like that, which is an area that is close to my heart
and something I thought would be good at.
So that was the hypothesis going in.
I think couple of things happened, some internal to
Google which is not important, but I think more externally,
what I quickly realized is that I wasn't getting the dopamine
hit of being able to drive a lot more outcome.
I realized that my ability to kind of scale my impact as an IC
was very limited. You know, I would literally go
around looking for projects to kind of contribute to, and there
were some projects that I could, and it was great and it was fun.
But I just very quickly realized that Google's a large
organization and they have swim lanes for people and they're
very happy for people. Or at least not, I wouldn't say
very happy, but the-sense was people wanted to stay in their
swim lanes. So in my swim lane, I had only
so much to do, so much impact to drive.
And my manager was okay, my managers were happy, but I
wasn't enjoying my work as much. So when Suthen got in touch with
me again, he said like, okay, there's this interesting
opportunity. We really want to do this.
I think you'd be a good person. I had interviewed at Grab
before. He said, you know, if you're
keen, you have to come now. He said, like, you know, this
role is gonna be open only for a certain period of time.
I was like, damnit, I was, we were just to have my second kid.
So the Google paternity would've been great.
Grab's paternity back then was only two weeks, but he was like,
no. Uh, I mean, he was nice about
it. He wanted to see how to make it
works and I was like, I was definitely keen on working on
bigger problems. And for me, bigger problems.
Again, it's more a reflection of my skillset.
I'm not saying an IC can't drive bigger impact.
It's just, you know, my ability, if I look at my strengths.
I think Peter Drucker says it, right?
Like, sometimes people focus a lot more on their growth areas
or weaknesses. But actually in your career,
especially in your latter part, you should focus on your
strengths and drive that up more.
So kind of some of that thinking, like I realized like
I'm probably stronger as like a team lead, tech lead type,
engineering leader type role. And there was a big opportunity
at Grab at that point. So I went.
Took the plunge. So definitely, it's very
interesting to learn from your experience, right?
Because there are some people who just really love hands-on
and maybe can drive impact, you know, building a scalable
solution or whatever that is, right?
Unique, innovative, and that could still work, right?
But for some people who are born as leaders, I would say, right?
So I think the dopamine hit is to actually drive impact through
people, right? So I think that is maybe one
thing that we can learn from this story that you just shared,
right? See what makes you tick.
I mean, if you love making an impact through people you know,
creating, I don't know, business objectives or outcomes through,
you know, leading teams. I think there could be aspects
that maybe suits you well in the management.
And I think one thing that you mentioned about leaders, and
wanting to be hands-on again, right?
And I know these days, it is the fear of many leaders, including
me, right, with the, again, coming back to AI, right?
So a lot of more stuff now can be leveraged through AI.
And, and that also means like teams getting smaller and maybe
you are required even to use AI to actually do more hands-on
work. And this goes back to some of
your rationale trying to be hands-on, right, in your career.
So do you think it's really important for leaders these days
to come back to being hands on and, you know, learn all these,
you know, recent technologies, advancements, and those stuff?
It's a really good question. It's a question that I think I
agree with you. It's becoming even more relevant
in this AI, you know, AI infused software engineering career now.
My philosophy's always been that you wouldn't get trained by a
coach, a tennis coach that doesn't himself play or herself
play tennis. I think that, as a basic rule of
thumb, applies to technical management as well.
Now, the tennis coach might not be as good as you in tennis, but
they know techniques. They've been around long enough.
They've seen enough plays, and they're also kind of like
continuing to watch games to see new approaches and techniques.
They're trying it out on their own.
They're probably not gonna go for the next grand slam
tournament, but they're there. They're plugged into it.
I think that same thing applies to technical management.
You have to be plugged in. You cannot just be, maybe it's
more the sphere or the space that I've been focused on, which
definitely has been more on the platform, infrastructure side.
But I just don't believe, I think it's hard for someone just
to be a 'manager' manager. Like there's a role to play,
don't get me wrong. Especially when it's a lot of
like business contacts and like customer contacts, but then
you're kind of playing a role almost like a product manager,
engineering manager. And maybe for some type of
problem, some type of companies that works.
But generally, my preference is always to find someone who's
more of a technical manager and help them build those other
skills. Especially if there's already
like a job function or role for someone to be product manager.
Cause otherwise, it just ends up like overlapping.
Or they become like project managers, right?
They just kind of, I wouldn't even say, I think TPMs do more
interesting work, but like you know, like, yeah.
Just like a project manager and I feel that's also not
productive. So then the question is like,
okay, how do you find the time, right?
Especially if you're managing people.
That's a good question. And I agree.
It's a real challenge if you want to do it justice.
It's a real challenge. You know, at Grab, we have this,
we have like in our career ladder, we kind of say that,
okay, managers, like line managers should be able to
operate the ICs on their team as well.
Meaning that doesn't mean they contribute code actively on a
daily basis, but they can contribute at that level of
capacity. It's a bit of a controversial
statement, we've gotten all sort feedback on it, but I think it's
still the right framing. Now what does that practically
mean for a manager at that level?
I think it means like, you know, ensuring and working with your
manager to ensure that you have enough time set aside to be able
to review code, to participate in RFCs and all that.
And if you find yourself just doing people management
throughout the day, that's broken.
Like I feel I see some people who like have this accelerated
part into management. I mean, and typically these
people are, these folks are very good.
But they spend, they don't spend enough time doing enough
hands-on work. So if you think about your
career, like, okay, if you start working like, I don't know, like
22, 23, right? And let's say, let's say, okay,
you're lucky you can cash out at the age of 50, right?
You're talking about 27, 30 years.
If you've only spent like, let, let's say 30, maybe 35 years,
right? If you are a junior engineer and
then you are becoming an engineering manager within like
the first five to seven years of a career, how much time have you
spent really building any type of foundational knowledge?
I just feel it's a very... And then you're gonna spend all
the other time just as a manager.
I just don't think it's the right way to approach these
things. I think people should dedicate
more time kind of building out the IC skills or in situations
where. So like I, my career was a bit
like that. Like, you know, I kind of spent
six, seven years as an IC, but then kind of very quickly
shifted into like leading a small team and stuff like that.
I think that's okay. If the team small enough that
you can still be hands-on, you're contributing.
So you're doing a bit of both. It's a bit like a tech lead
manager type of setup, which lots of people, and at Grab, we
don't really promote it as well. And there are good reasons why
it's not a great model, but if you find yourself in that setup,
and I think it's still okay. So how do you kind of create
this opportunities, where you have enough bandwidth to still
spend time being close? And then also I think picking
problems which allow you to continue to grow in that
direction. So you could be a manager, but
you pick technical domains or scopes that allow you to get
more technical. Like pushes you and you apply
your technical aspect of your skillset in that domain.
And you don't just focus on the people management side.
I feel that's really important. What about those roles that is
really high up, like CTO, SVP, do you still think they need to
be hands-on picking up for certain problems to chase,
technically, not just like people management?
I again, I think, you know, I don't wanna speak on behalf of
everyone. I definitely I think different
roles, uh, different companies vary in terms of type of
problems they want their CTOs or their VPs to solve.
Having said that, I think it depends on the individual again,
right, and the problem. So a lot of it will come down to
the company. So for example, when I was hired
into BUKA, there was a very clear mandate.
Okay, Mohan, you come in, we need to migrate from on-prem to
the cloud. So my mandate coming in was the
technical mandate. Okay, we need to get this stuff
done. And you know, there was this new
cloud that nobody had ever used. It was a team that was used to
only managing stuff on-prem before.
Okay, so there was a, there was both a social aspect, but there
was also a technical aspect that needed to be brought together
and solved. So I think CTOs or VPs, that's
kind of the type of problems you're solving.
So you need to have still, you need to have enough technical
knowledge. You need to be able to answer
the question, like, okay, what type of skills that maybe before
this my team had, and now they're gonna need to have?
What does that mean practically? Because otherwise people can
come and just like gas you, right?
They'll come and say like, oh, this is too hard.
It's gonna take a, we need to hire five more people to be able
to do this. And you're gonna go like, how do
I challenge question this person, right?
Yeah. So I think within like that,
those capacities, you need to be close enough to be able to put
forward a credible counter-argument or review what
is being shared with you and not just kind of rely on proxying
out. Cause you are a, I mean, there's
a T in the CTO, right? It's technical, technology.
Obviously, that's got, that's gonna mean something.
For some people, I don't know like you mentioned a few
practice that I don't know whether you have, you are still
doing it now, like reviewing code, reviewing PR, for example,
uh, pair programming with them, or maybe chasing a certain
particular bug during incidents, right?
Some people will treat this, especially if you are like a
higher up management, treat it as a micromanagement.
Yeah. So what is your view on this?
No, I, listen, I think if you have a structure in place.
Let's say, for example, you're a CTO of a 400 person org.
Yeah, I don't expect you to be sitting down reviewing the MR.
But I expect you to be sitting in the team post-mortem review
and providing feedback. I expect you to make sure that
your delegates are ensuring that the bugs are being closed.
And I expect you to understand the root causes, maybe through
the postmodern review of why maybe, oh, this thing has been
happening again and again. Is this because this team has
taken on too much technical debt?
Like forming more strategic views on top of this.
But like this strategic lens can only be built on the details.
So you, you, you, you're absolutely right.
You shouldn't be micromanaging, but that doesn't mean you don't
know the details. You know, AWS has this
leadership principles. My favorite of all the
leadership principles is leaders dive deep.
I feel that that really sets the tone the type of leaders, right?
So the leaders dive deep, they're auditing, they are
balancing like data with anecdotes.
They're doing the investigation. I agree with you, you shouldn't
be micromanaging. But there's lots that you can be
doing that's not within the realm of micromanagement.
Especially if you have people who are already empowered to do,
you know, some of the more ground level details.
And by doing it this way, you're setting the tone for a team.
So you're saying like, this is important enough for the CTO to
be aware of. And I think that really matters
to setting the right engineering culture.
Yeah, and it goes back to what you mentioned, setting the right
bar, right? Because if you actually don't
understand the technical details, definitely, the bar
will be just low, right? And I like what you mentioned,
right? Comparing data vs anecdotes.
Sometimes when you are higher up, you, you can just hear
anecdotes, right? People talk about certain
things, maybe through proxy, maybe even directly, right?
Because they don't know the actual problems.
And I think having a leaders that actually understand the
details, right, dive deep is really crucial, especially in
the technical team, right? No matter whether you are higher
up there or not. A hundred percent.
So maybe I wanna set aside time as well for us to talk.
Because you have been leaders within this Southeast Asian
region. You know, you've been managing
team in Indonesia, Singapore now, maybe Malaysia.
Back to your, where you are from, right?
And maybe a little bit of Vietnam and so many different
countries. One unique thing about Southeast
Asia is all these different countries have very unique
culture. Different languages as well,
different working practices and things like that.
And now coming to the, you know, the advent of AI, right?
So many people talk about AI. Do you think the southeast Asian
engineering talents are ready for this?
Yeah, it's, uh, it's definitely a topic very close to my heart.
As you know, and this is one of the reasons why I enjoy working
at Grab, because Grab is totally Southeast Asian first, and we
are plugged into it and we have engineering teams across the
region, which is exciting. So let's talk facts.
I think from pure raw talent, capability, we are there, right?
Like if you think, we have the potential.
You know, Southeast Asia, and they they just had the ASEAN
Conference in Malaysia, two, three weeks back.
Singapore PM was there. Our Malaysian PM was there.
They talked about Southeast Asia collaboration, right?
And then they kinda shared some numbers.
So, I think Southeast Asia in total is like 700 million
people. Still pretty young, demographic
wise. By total size of economy, I
could be wrong here, but like maybe fifth or sixth in the
world. The trick though is it needs to
be seen as a whole. The strength is when we can
figure out how to collaborate as countries, leveraging our
different strengths, right? If you are taken apart
individually, all bets are off. That's my sense.
Even Singapore. Singapore I think is probably
definitely on the forefront. I mean, that's part of the
reason why we are both here, right?
I think the quality of the institutions, the schools are
there, right? Like the amount of folks I, I'm
sure if you go and look at like, you know, research papers and
you kind of look at like, where you'll find lots of folks who
did their either undergraduate or masters or or PhD in
Singaporean institutions, and you'll find folks who are from
all across Southeast Asia as well, right?
Like, you have lots of Malaysians doing stuff here,
also Indonesians, right? It'll be great if we can build
more local entities that are really harnessing all these
different talent and applying them on more complex problems.
Of course, Grab has a role to play here.
I won't speak on behalf of Grab, but I think we have definitely
been trying to do more of that. You know, other large regional
companies like S-E-A, Sea, I think is also doing some
interesting stuff. I don't know, have you seen any
other regional company doing some interesting stuff?
I mean back then when there used to be a lot of investment coming
to Southeast Asia, you know, tech startups are booming, I can
see a lot of investments. But these days, you know, the
situation is quite tough, right? And everyone having layoff.
Uh, maybe outsourcing to different countries for, I don't
know, for whatever reasons. Maybe it's talent, maybe it's
pay or whatever that is, right? And I just see us in Southeast
Asia is a bit tough in terms of situation.
And when you mention about collaboration, I don't know
whether it's happening now. I would say even people are
putting them back into silos, right?
Maybe focusing more on the country rather than
collaborating with each other. And what can we do as a tech
community? Probably, that's one question,
which is also sometimes I think about Tech Lead Journal, right,
how can I serve this mission of, you know, building upskilling
the tech talents within the region, right?
So maybe in your view how can we approach this as a tech
community, right? Yeah.
So I think that regional tech players have a role to play.
So like the Grab and Sea, right? Like, we really need to be
looking at how can we create opportunities for, you know,
really high potential talents to come and join and solve deep
technical problems. From my experience kind of at
Grab, like I think like the quality pool is there, coming
out the door, coming out the gate.
We have high potential individuals.
It's just subsequent to that, can we give them the right
opportunities to continue to grow and stay within the region.
I mean, I think government has a role to play here, right?
Like how do they set up the right type of investment
structure so that companies, regional companies can kind of
invest and build talent in other countries, but also kind of
somehow accrue it back to the country that's supporting that
investment? So some type of like
multilateral Asian framework needs to come out of this.
I don't think we're gonna be able to solve this individually.
And then I think the regional tech companies have a role to
play. Lastly, I think also the
schools, the institutes have a very important role to play.
Like, you know, we need to be better plugged into the
industry. I think things are improving.
Like I look at the internship programs that we have, Grab has
with, in Vietnam, in Malaysia, and even in indonesia.
And it's much better than what it was maybe in 2012, 2013 when
I was also looking at it closely.
And giving people, so like for example, Waterloo University in
Canada. It's common for a software
engineer, a CS graduate there to have like four, five
internships, and they kind of learn so much through the
process. Why can't we have something
equivalent here? I think partly, it's the
companies, like we need to have the mindset.
Right mindset. But I think this is where the
institutes can go to companies and say like, okay, this is what
we're hoping, these are the type of programs we're hoping to
create for our students. Are you guys willing to kinda
engage at the same level, right? No point in getting an intern
who then comes in and like, this, and that.
Like just pushes paper, that's pointless.
So those are some things I think that will need to change and
this is where like some type of collaboration, I think, is gonna
be key. Again, I wanna emphasize a point
that like I have been impressed by the quality of people coming
out the gate. Now it's really a question of
how do we create the right opportunities.
You also mentioned one thing very interesting right?
Because I've been also thinking about this and trying to find
observations, right? This region seems to lack a
little bit of deep technical problems and challenges
probably. And that's why maybe more
people, you know, going out to other countries, US maybe, or
even China these days. And even if you just observe,
right? Like for example, AI, right?
There are not many people building AI solutions within
this region. There's a lack in developer
tools kind of a product being built around here.
And you mentioned talent is there actually.
So what is the gap actually for us to actually, you know, bridge
to that stage where we want to deep, invest deep into these
kind of technical challenges as well?
Or is it just difficult for us to have this kind of
opportunity? So first off, so I agree, it's
definitely a problem, but it's not just a Southeast Asia
problem. If you look at it like outside
of like the China and US, maybe some small parts of Europe like
Mistral in France, the AI like agglomeration of companies are
very concentrated, right? So I think it's a, it's a more
wider problem, but it's definitely pretty acute in
Southeast Asia as well. Again, I think it comes down to
our opportunities, right? And an investment, like
investment to be able to do something like a foundational
model is huge as everybody really knows.
And that itself means that only like, I think, within the
region, like it's only governments that can really fund
these type of things. Now the challenge then for
government to kind of fund these things is like, what's the ROI?
And it's a good question to ask because there's no point just
doing these things for the sake of doing them.
That's one dimension. Where we've been very good at is
more on the consumer app side. Like what you're saying, right?
So less on the deep tech side. But what is hopefully going to
happen is there's gonna be a confluence.
So as we work out what type of use cases AI is really good at
and we bridge it back to solving customer problems, these two
worlds will converge again, where solving consumer problems
via AI will just be the norm. Today, I think we're still at
the early stage curve, where we're almost looking for
problems to solve with AI. But we are shifting, right, like
of course, there's like the coding use case, which is pretty
clear. And then there are gonna be
other use cases as well where... and that will kind of land into
more clear ROI and we'll be able to get there.
But it'll take a bit of time. And it will take us kind of
fixing some of the fundamentals, but that's the only way to do
it. I think we need to merge this
consumer app problem, or consumer space problem back with
the AI problem. The use cases need to become
clearer. I mean, anecdotally when I see,
you know, tech forums within this region, people are now
questioning should I still be in tech?
You know, should I still study computer science?
Should I now thinking about something else?
And for tech leaders as well, should I now think of, I don't
know, moving to some other industries?
In your view, right, as a tech leader and also being hands on
with this AI thing these days, do you think we should start
thinking that way? Or do think we should even
double down on this? It's a good question.
I'm opinionated about this. And of course, this is my
opinion. I'm not, so like, I think it
depends on what motivates you. If you took up computer science
or if you're in this space because you want a good salary,
there's nothing wrong with that. It is a completely human and
logical thing to do. Then yes, you might question
these things because I think salaries are gonna be depressed.
I think there's gonna be a correction.
There's been over hiring, there's be more layoffs, there's
gonna be efficiency gains that come out of it.
But if you are in the space because you enjoy what it means
to build good software, you're in it for a craft, you care
about what you do, you should keep doing it.
Because if anything, those things are what matters even
more now. And this has been true all this
while. It is just that in the past, the
value was more on the generation of code.
Can you get this stuff done? So then someone who didn't
really care about it, but did enough work to kind of cut the
website, get it out, build something quick for an agency,
that was still valued. What you're seeing is all of
that values going almost to zero now, right?
We talked about zero shot. Like, you know, image
generation, website generation. So now those people who are kind
of operating, I think, at that level they are feeling this
existential threat. Maybe the answer to them is,
yeah, if this is what you want to do in software engineering,
then yeah, you, there might be better ways to make money.
Now, of course, this is gonna be displacing people.
There's gonna be, you know, economic costs around retraining
and stuff like that. So I'm well aware of all those
things and I don't think we should take this sort of things
uh, willy-nilly. These are, they're real
ramifications to some of these things.
But personally, I think it's, it's, it's, that's probably the
direction we have to go. So in other words, to answer
your question more directly, I think if you care about software
engineering, you should double down on it.
But if you're just looking for very efficient ways of accruing
wealth or earning a paycheck, maybe there might be other ways
to do it. And I think we have kind of like
discussed it earlier as well, right?
I mean, the standards would definitely elevate, right?
So for those of you who are just doing, I don't know, mundane
tasks, you know, generating code through hand, by hand, right?
So I think those skills probably will be, you know, lesser
valued. And I think I like the point
that you mentioned that Kent Beck mentioning right?
A good software engineer, the 10%, right, the skills that you
actually have will actually be amplified in this era.
And I still think, I'm betting as well myself, that hopefully
with all good talents in software engineering that we
have, right? Those 10% can still be valued in
the market, right? And just double down on that
aspect rather than the 90% percent which is probably the
more mundane stuff. So I'm very well conscious about
the time, Mohan. So as a tradition in my podcast,
I only have one last question. I call this technical leadership
wisdom. Think of it just like advice
that you want to give us, to the listeners, right, as your last
advice. So what would that be?
I think for people starting out early in their career, go wide.
Don't try to specialize too quickly.
Be willing to pick up anything. Learn, look more for the
opportunities to learn either by taking on challenges that are
gonna stretch you and grow you or by finding the right coaches
or mentors to learn from. That's something I would say.
I think for people maybe in the middle stage of their careers,
this is a great time to become more hands-on, to learn stuff.
I think, again, quoting, you know, venerable Kent Beck, he
said this is the most fun he's been having in like a 50 year
software development career. Can you imagine 50 years of
career? That is amazing!
So yeah, I would definitely recommend people get back.
Get back to your roots. Find time on the weekends, if
you can't be doing office hours. Carve a better time out.
Spend some time here and there. You know, as we discussed, these
tools are really good at giving you what dopamine hits, right?
You get a really good high ROI so find the time to kind of go
in deeper. So it's been a pleasure.
So I think we learned a lot, right?
And especially looking from, you know, your perspective, right?
Like what makes a great leader? How do you build a great
engineering team? And we touched on also like how
do we approach this AI thing, right, that is happening in the
software engineering team. And going back also to the
Southeast Asian talents, right. So I think, I hope all the
listeners here can learn from this conversation.
And yeah, thank you so much for being here today.
Thank you so much, Henry. I really appreciate you, you
know, enlisting me for your podcast and hopefully this was
useful for folks.