#228 - Leading Transformational Engineering Teams with Craft in the AI Era - Mohan Krishnan

[00:01:26] Introduction

Henry Suryawirawan: 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.

Mohan Krishnan: 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.

[00:02:08] Career Turning Points

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:06:03] Things We Should Learn in the AI Era

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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?

Mohan Krishnan: 100%.

[00:09:53] AI as a Pair Programmer

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:13:58] The Danger of Outsourcing Our Thinking to AI

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:17:29] The Dopamine Hit of Using AI

Henry Suryawirawan: 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.

Mohan Krishnan: Yes.

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:20:36] Building a Successful Transformational Engineering Team

Henry Suryawirawan: 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.

Mohan Krishnan: 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.

Henry Suryawirawan: 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?

[00:25:33] The Discipline Rigor in An Engineering Team

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:29:14] Understanding & Delivering Outcomes for the Business

Henry Suryawirawan: 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.

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:32:21] Having a Tough Approach as an Engineering Leader

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

Mohan Krishnan: A hundred percent.

[00:39:07] Going Back as an IC at Google

Henry Suryawirawan: 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.

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[00:45:40] The Importance of Being Hands-On with Recent Technologies for Leaders

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

[00:52:40] Hands-on vs Micromanagement

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

Mohan Krishnan: A hundred percent.

[00:55:11] Engineering Talents in Southeast Asia

Henry Suryawirawan: 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?

Mohan Krishnan: 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?

[00:58:06] Building Tech Talents in Southeast Asia

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

So some of it comes down to salaries, of course, right. We need to be more competitive. Ironically, like to your point, Singapore has become too expensive that more and more companies are actually outsourcing out of Singapore. Which is the complete opposite of what we want, right. But the good news maybe is that they’re outsourcing to, if they’re at least outsourcing to regional countries within, I see there’s still an opportunity. So that’s where the collaboration opportunity, I think arises, right? 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.

[01:01:17] Bridging the AI Gap in Southeast Asia

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

[01:04:03] Should We Still Pursue a Tech Career in the AI Era?

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

[01:07:24] 2 Tech Lead Wisdom

Henry Suryawirawan: 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?

Mohan Krishnan: 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.

Henry Suryawirawan: 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.

Mohan Krishnan: Thank you so much, Henry. I really appreciate you, you know, enlisting me for your podcast and hopefully this was useful for folks.

– End –