Mei 6, 2019
Intro: Hey guys, welcome to GO FIGURE. My name is Nadine Makarim, CEO and founder of GOJEK Southeast Asia's first Super App, which recently became a Decacorn. GO FIGURE is a podcast dedicated to expose the inner workings of ambitious tech companies in the emerging world. Hope you enjoy it.
Nadiem: Welcome to our go figure podcast. Thanks for being here.
Raditya: Thank you for having us.
Hans: Yup, glad to be here.
Nadiem: I'll just do a quick round of introductions. So you guys, um, so we have here Hans Patuwo our COO of all of GOJEK. Uh, Hans currently leads a team of roughly 2000 people. Is that correct?
Hans: That's correct.
Nadiem: 2000 people and counting, uh, across all our driver operations, customer service operations across how many cities, Hans?
Nadiem: 88 cities. Oh my goodness. Okay. Um, and uh, Hans is actually also from McKinsey, just like me. Before previously you were a partner, um, and now you're joining the tech world. So welcome to the show, Hans.
Hans: Thanks man.
Nadiem: And I'd also like to introduce Dito. His name is Raditya Wibowo, but we call him Dito. Dito is a whiz kid. He's also ex McKinsey. All right. He went to university in Indonesia locally ITB (Bandung Institute of Technology), which is the kind of like the IIT of Indonesia and Dito, uh, is only 27 years old and now leads the entire product group, uh, for transport, which is our GO-RIDE, car or motorcycle transportation ride hailing and our car ride hailing. Um, who's just recently launched Singapore. Congratulations.
Raditya: Thank you.
Nadiem: So, Dito manages about roughly around 3 million transactions per day at the moment. And Hans over here, uh, basically manages around 1 million active drivers across Indonesia. Uh, and also now Vietnam and Singapore. And so Hans handles operations, Dito handles product. And the topic of today is a very, very hot topic, a very messy, messy, hot topic about how technology and product engineering can collaborate effectively with operations. How do we mix and interact between the digital arm of the company that is user facing and the operational arm, which is very human intensive, labor intensive, messy and spans across such a wide geographic area. Right. So I'd like to kind of kick off the discussion with kind of some of your principles, uh, of what you've learned, uh, across your journey working together and what you found to be some of the mistakes that you've made and some of the insights that you've had. So I kick it off to you. Dito you want to start?
Raditya: Sure. So, um, yeah, I guess, you know, the main thing you need to remember when working with ops, is to basically talk to each other. But it's really easy to forget that today. Right? You know, especially you were, you know, you're working with the developer team and you're not always there on the ground, right. And you have an ops team that's basically there to listening to the driver's complain, looking at weird things happening on the driver's phone. And you know, it's almost easy to forget that, you know, whatever you're coding and whatever you're deploying actually gets to use by real people at scale sometimes. Right. And I think with Indonesia in particular, the drivers are particularly interesting because um, at least when we started out, for a lot of them it was kind of their first exposure to a smartphone. Right? Or if they're doing something on an APP. So a lot of, um, a lot of the things we had to do to make the APP usable for them had to be learned through, you know, a lot of, we basically you have to keep talking to them a lot. Right. I mean, an example of where I failed here is one of the things I tried to do was redesigned the Driver App for package deliveries. If you're remembered our GO-BOX days
Nadiem: I remember that.
Raditya: Yeah. I tried to be smart and I was like, oh, the current design isn't that great. Like this is how it should be. So I tried to design it myself like, uh, there was a little map that showed it on the bid screen. Right. The two of the pickup and the drop off and when that actually went the drivers, they didn't understand it at all. The team actually has..
Nadiem: And that was because did not first talk to the operations team,
Raditya: Correct. That was, that was when we fail to do that. And we assume that, you know, drivers would just get heard if it's intuitive, but that's not how it works. Right, right. Changing habits is very, very hard. Right.
Nadiem: And when you, when you talk about like, you know, just communicate, what do you think is the primary root cause that, you know, engineers and product managers don't talk to operations? Like what actually happening there? Why is there not? Why didn't we not collaborate much quicker in our first time of our evolution? And what did you guys do to kind of fix that?
Hans: Yeah, I'm happy to take a stab at that. Right. Um, I remember when I first came in, I think what I felt was there was quite a big divide between ops, which was very much in the trenches day to day. Uh, highly anecdotal, uh, not perhaps the most analytical and savvy with data and what I'll call quote unquote, for lack of a better term, the online world. Which is product and ..., which were very, very proficient with data are very, very savvy but lacks a little bit of the understanding of what's happening on the ground. Right. So the reality is that there was a gulf, there was a divide and there were not enough, let's say, people or processes to help bridge the two. Yeah. So what will happen is that we will be talking different languages
Raditya: And I think something unique here for GOJEK because we were literally talking different languages
Nadiem: There's Indians, Singaporeans and the Indonesians..
Raditya: Correct. Um, so if I, if I were to, to look back and I were to think about it, um, we will get into these situations where, let's say the ops, the field team will come back with insightful observations, but highly anecdotal and not maybe the best backed up by data. On the other hand, the product team or the tech team will come in with a ton of data, strong inflammation, but perhaps, uh, translating information into the appropriate insight was a little bit of a finding a needle in a haystack
Nadiem: Because they didn't know how things operated on the ground. Right?
Nadiem: Just seeing bits.
Hans: Yeah. Or they saw the data, but sometimes the data doesn't tell the complete picture. So for example, when, um, if, let's say we look at the impact of rain, right? In certain cities in Indonesia, whenever there's rain, the completion rate of our two wheels, a motorcycle, uh, transportation service drops quite significantly. So that's a piece of information. But there can be multiple insights to this. One insight would be, or you know, drivers to want to get wet. Uh, so the solution is let's give them more money. But in the reality there is also another insight
Nadiem: So that they would be more willing to take that order getting wet.
Hans: Exactly. Right. Uh, but then in reality, that could be another explanation, which is in southern cities, in Indonesia, infrastructure's not very good. And so the roads are just flooded. Even if you wanted to, you could not go out. Right, right. So same piece of information for different insights, which was the right one. Right. So it's melding these two anecdotal insights and data driven information that always seem to be the gap somewhere.
Nadiem: So that data driven solution, which seemed correct on paper would have led us to spend unnecessarily a lot more without any further, uh, drivers actually willing to get out there
Hans: Or it would have, yes. Or would have helped us in only select the cities and not in others.
Nadiem: Right. Yeah. Okay. And that's because of some local knowhow. Correct. Was there, right. Let's talk a little bit more about the different languages. And I'm not only talking about literal languages, but also the different kinds of paradigms and nuances of how ops people tend to behave and how to product engineering people tend to behave. Because of their work is so different. I'm sure there are some behavioural differences between them. So what have you noticed about that? Maybe that's interesting.
Raditya: Good point around, you know, um, anecdote based information versus, you know, being purely data driven. Right. Because there is always some middle ground that you need to find, right. It's kind of like the anecdotes are super useful, but you know, taken in isolation, they're not, you can't use them to be correct things, but on the other hand, the data's not useful unless you actually go there and see what it's causing on the ground. Right. Yeah. For example, um, there was this one time where we were debugging this issue where drivers were complaining about getting multiple bids at once. Right. And I think the engineering team spent a lot of time, you know, looking at it and it was kind of hard to figure out what was going on. Right then, um, it came to Jakarta. I took them to this Pangkalan uh, near my apartment. Right? So basically, uh,
Nadiem: You took the engineers down to the street,
Raditya: Yea I took our tech lead, right. Then he had a driver phone and he turned it on and he could see that the orders were like coming in one after the other. They were stacking and we go down and meet the drivers and they say the same thing, like they were all showing us their phones and it's all happening on their phones. And that I guess is what kind of made him realize that it's a, it's a big problem. Right? So then the next day she'll be then Niranjan paired and fix it. So, you know, actually just getting them to come and see what's happening on the ground is very, very powerful.
Nadiem: So, so like interaction and face to face interaction is not just important for alignment basically. Right. But I think the key takeaway there is that actually things get done when there is a clear buy-in
Nadiem: Across both product engineering and ops. Right. And so, so the problem is when product engineering doesn't see things on the ground, the level of buy-in is also extremely low on the things that ops thinks are like super critical items.
Raditya: Yeah. There's some times, uh, you know, sometimes there are issues that keep popping up that are kind of hard to fix. Um, from, from the tech side of it. For example, one of our top complaints at some point was no orders. Right. And you know that that could have been a tech issue. It could also just have been over supply.
Hans: Correct. Yep.
Nadiem: You mean drivers are just not getting any orders suddenly.
Raditya: Yeah, basically drivers calling into our call center and complaining they are not getting any orders. What's wrong? I'm like, yeah, but some of the cases where like legitimate cases, right. Like their pings got stuck or something. But you know, a lot of the other, like most of the tickets, I think from the analysis, we're actually, um,
Hans: Repeat offenders, right?
Raditya: Correct. Yeah. They weren't actually be facing a technical issue. They just weren't getting enough orders. Right. So either they were standing by in locations where there weren't enough orders or something else, but you know, sometimes it's hard to separate, uh, you know, what's actually a technical issue versus what is actually a behavioural issue. Right. So that's kind of the balance you always have to strike.
Hans: I think, uh, if I may add one more thing. Um, one thing that we've been looking very hard on also on the ops side is to be able to speak with data convincingly, right? Cause we also have the responsibility to provide relevant insights and information in an actionable way so that product and tech can work on it all right. Right. It doesn't help if we keep coming up with, uh, anecdotal comments only. And on the flip side, uh, to your point, right, once that is this, uh, once we talk to each other and if we realize, for example, that this problem actually will may take some time to fix from a product perspective, then I think the onus is on the ops team to figure out, okay, how, which other ways can we skin this cat? Right. Cause the other leavers or hacks or whatever way they wanted to, to think about it to kind of temporarily improve the situation. Right. So it's kind of more like collaborate with compassion. All right. As opposed to, hey, I see this, you're not listening to me. And vice versa.
Nadiem: I think, you know, in the beginning I think we need to be honest that you know, a lot of people in operations, both driver operations and customer service operations felt that they were kind of orphaned from a priority perspective for a product engineering needs. Right? Because they also had, they had, you know, product engineering needs. They needed automation. Yes, they were doing things super inefficiently in the beginning, etc. But they seem to struggle to get the attention of the product group and to get their needs prioritise. Now, I do not think this is a GOJEK only problem. I think that in almost all tech companies, when there is a major operational component, you've got this kind of a bias towards uh, working on things that are kind of shiny and affecting consumers. And really because it's consumer driven and but in reality there are mission critical components of operations that will in the end affect consumer experience. So, for example, if the team cannot onboard drivers using a self service platform then we simply cannot manage demand and supply in the most efficient way and therefore customers will get no driver, right. In various situation. So yeah. So how, how do we reconcile that? What's, what's been going on there and where have you felt the trend moving towards?
Hans: Okay. So I'm glad that you brought this up and um, you know, really I give lot of credit to Vishy and Param. So Vishy is the group product manager of ops tech and Param is the tech lead. I recall, um, about 11 months ago. And the ops tech team indeed was in certain cases a much of an orphan. We had very few GOJEK developers working on it. And I will say that over the past 12 months, 11 months, it has really, really improved significantly. Uh, let me give you a summit, but rather than going through the whole journey, let me give you some examples of what has been created. When you talk about ops, we have 88 locations outside of Jabodetabek. Right? And we have hundreds, multiple hundreds...
Nadiem: For those listeners that don't know Jabodetabek is a way of describing Greater Jakarta, which is the capital of Indonesia.
Hans: Yep. Got It. And No, we have uh, hundreds of GOJEK employees. So, GOJEK agents what we call GO TROOPS scattered throughout the archipelago. And if you would walk into one of these locations it would seem like we were a non tech company. Right? Well it's all paper, desktops and...
Nadiem: That's an understatement.
Hans: It's like you were looking around and say hmm...
Raditya: Super long lines, long lines
Hans: Super long lines and you're there scratch your head. Um, in the past quarter what has happened, we have rolled out two products, uh, that significant, I will say like the, probably the first ever products that helps with on the ground field operations. So of them is a collaboration with the driver platform team where drivers who want to get service in on one of our walk in offices can actually book an appointment slot ahead of time so they don't have to all come in early in the morning and wait for four hours.
Nadiem: Like a doctor appointment. Right?
Hans: Exactly. Yeah. Right, exactly. They can choose and select the day, they can select the time. That helps us tremendously on, on our end as well, like providing good service to the drivers and reducing the amount of time that we take them out from the, from being a driver, uh, first time ever. The second thing that we have recently launched is what we call an agent APP. So first time ever, right. So now, uh, our field agents actually have an APP that will help them to allow them to onboard and acquire drivers. And this is what the beginning of adding more and more functionality to this APP. So I'd say that we've taken a, perhaps a little bit delayed, but we are certainly have taken a massive stride forward to using tech to enable our frontline operations as well.
Nadiem: Fascinating. But then when you get to the debate and it, let's see, we have a finite amount of resources and there's two different priorities and one is it has to do with like, oh my God, you know, like, uh, we have this major issue, uh, whereby we can't, for example, edit destination. Yeah. And that car that to a major operational, how do you even win that battle? How can ops even win that battle?
Raditya: You know, at the end of the day, you know, at least for us the most valuable resource for lack of a better word is developer bandwidth. Right? Uh, you know, the thing is operating in a country like Indonesia where honestly like labor is relatively cheap means that, you know, sometimes it's actually more efficient to throw people at a problem as opposed to actually building a smart solution for it
Nadiem: And I think a lot of, a lot of our listeners out there don't, don't understand that that actually in various different economies like it's actually cheaper to deploy human resource.
Nadiem: As opposed to a actually deploying tech resource in the short run.
Raditya: Yes. And the short run is a very tempting for product managers to just go with that option. Right. It's finally, okay, I can ask my developers, build this cool new feature that will solve a lot a lot of problems or make life easier for the operations team. But you know, I think they've got it handled for now. Right. But the thing is that doesn't last long, right? Like after a certain point, all those manual, like you know, the Google sheets and the way we keep track of issues, it just explodes. Right? So at the end of the day,
Nadiem: I think we upgraded from Excel sheets, Google Sheets, and now we finally have an APP. Right? That was kind of that evolution of it
Raditya: Because you know, the manual process, there's no matter how good the people working on them are you hit a natural limit once you reach a certain scale because it's just not manageable to maintain a massive spreadsheet with all of the issues and all right. So, you know, um, the thing is like once you let it get to that, to that scale, then it's much harder to fix.
Hans: My take on that is, um, I think the discussion is going to shift more to going far versus going fast. Say when you're trying to go fast, just close your eyes and throw people at a problem, right? But at some point in time you go fast, but you won't end up going very far. Right. So as we think about how, GOJEK is scaling up both in Indonesia as well, outside of Indonesia, and we think of all the things; increasing scale and all the things that we're trying to do in on the platform. Um, once we skew that conversation to what's going far, which requires things to be interconnected, to be scalable, to be friction free. Then I think that that to me, is the real driver of the debate. So it's not so much, is it ops as a product? It's more far or fast, right?
Raditya: Yeah. Agree. I think you know, below a certain scale It's absolutely fine sometimes
Raditya: If you have ops processes that work and you're not getting overloaded. Correct. You'd rather use the div bandwidth for other things, that's fine. Right. The thing is, once you hit that certain, once you hit that then it blows up.
Nadiem: I think a lot of people would be shocked to hear you say that Dito, that you shouldn't automate everything, especially people from the tech world. But what's your argument against, you know, automating everything? Like what, what things should never actually be automated.
Raditya: So an example would be experiments, right? Things like, you know, like in Singapore, we're doing a lot of this right now. Um, when we test new driver incentive schemes, we could spend, you know, one or two weeks actually coding them and automating everything. Or we could kind of run an experiment, have someone manually calculate, you know, the driver, uh, progress towards its target and kind of send them that to an SMS and kind of see how they respond, right. So, and then if you see you're getting good traction and it's actually working as intended, then you can automate it. Right? So I think, you know, one situation where, um, you might not want to automate it immediately is when you're just testing things out. Yeah. Right. Second is again, like when you are not kind of reaching the, a level of scale where you're hitting that limit where it just blows up if you don't automate it. Right. And I think like, um, a lot of other, I mean when I talked to friends who work at other startups in Indonesia, you know, sometimes this is where they are, right? It's kind of like they're still trying to figure it out, product market fit. So they try a lot of different things. And because of developer bandwidth is so scars, sometimes it's easier to experiment using manual ops processes. Right. And you know, uh, as long as it doesn't, as long before we get to the scale of written blows up, at least my opinion is it's actually OK.
Nadiem: Right, right. Yes. So I want to kind of dive a little bit deeper into the cultural differences of product engineering teams and operations teams and ask you guys, like what are specific things that you felt had massive impact in bridging these cultural divides?
Hans: Okay. Um, my point of view, right? And maybe this is controversial, but I think that the fundamental differences between product tech ops, it's really not that different. Now what I mean by saying no, we each have our different domain expertise, right? We're designing a product or feature be it coding, be it implement something in the field. But I think the one underlying theme that cuts across two themes that cuts across all of this one is really, really have to be sharp shooting for greatness and problem solving. Right? And the second one is with compassion So when we talk about, um, really, really sharp in problem solving, it means sometimes what I tell the guys is that, look, if you can solve the problem, you have no business being here, right? But that's table stakes. We're not trying to solve the problem, what need to solve the problem in the most optimal manner possible. So for example, if we take, take fraud or take think gps, take any of these controversial, uh, cross cutting big problems and if we are not very far in problem solving, we tend to solve it using the domain expertise that we know, right? So if I'm on a, in the traditional, let's say, old school ops point of view, we feel that all drivers are good people and our tech is not good enough and screwing them up. We tend to solve things by being lenient to drivers.
Nadiem: That's fascinating. So you tend to gravitate towards the solution that your natural bias moves towards.
Raditya: Correct? Right.
Nadiem: Your natural, I would say prejudice, right? Your national judgment. Yeah.
Hans: Well maybe it was something that you're more familiar with. Right? So if you're on the tech side or the product side, especially if you're, let's say haven't spend a lot of time on the ground in Indonesia interacting with drivers, you think that all these guys, all scammers, right? Right. But the reality is, is neither and both. So if, let's say all these parties were to hold a high buying problems, so he's okay, I want, I want my bar is to make sure that I get every single fraudulent driver who is intending to do fraud. And I make sure that I don't care anybody else, any other innocent driver without the intent committing fraud, which is a very, very high bar. Then I think the team will have to work together and they will find more creative, more challenging, maybe takes more time, but ultimately more robust and much more aligned solutions versus a, this is what it should be versus what it's, what it should be. So that's what I mean by really, really sharp high bar problem solving.
Nadiem: So does that mean that defining that problem and the metric that will determine whether that problem is getting better or worse is the most important thing.
Hans: That plus defining what success looks like? So not just the metric, right? But what are the metrics? What are the scope and, um, and what would success look like? Right, right.
Raditya: Although I think it also like to add rate. Um, a big part of it is also empathy. I feel like it's kind of like the ops team, you meet drivers way more often than like the product engineering team right. So naturally you have more empathy for them because you meet them every day
Hans: on some less.
Raditya: Right. But you know, like when you're meeting them every day, you know, there's a lot of drivers who are, you know, they're not, they don't intend to do fraud, but it looks like they are. Right. So I think, you know, when gap, the bridge is basically building the same level of empathy in teams that don't interact with drivers as much face to face. Right? So I think, you know, some of the things that, what we've done like, you know, uh, visiting driver houses or getting people to standby in the ops offices, those are actually really, really important.
Nadiem: Yeah. I'd like to double click on that on that point because I think it's really interesting. Um, to what extent does empathy actually translate into excellence in problem solving? I like to deep dive there because we've noticed this happen again and again and again. When teams actually go to the ground and see things as they are, whether they are engineers, data scientists or a product managers, right. Even some members in ops that mean I'll get out there as often. Right. Uh, you were kept telling me how stories about when you travel with an just, wow, you got these. I did just completely different to what I thought it was the same. Same with me as well and you know, when I take GO-RIDE, GO-RIDE is our service, ride hailing for motorcycles, I take it about three times a day. I take GO-CAR maybe more like five times a week because I like getting everywhere fast and the more I interact with the drivers and some of them that notice who I am will start complaining about issues that I, that they're facing, you know, it is the probability of addressing those problems when you have a firsthand interaction become exponentially increase. I just keep noticing this trend, like when key decision makers get closer to a problem, the probability of that problem being solved becomes higher. I've noticed. I don't know. Do you agree with that?
Raditya: I agree with that. I mean, you know, specifically on the empathy front, right? I mean, you know, when you are using the product every day, right? And you hear from the driver every day, it just, you know, at least for me, it feels worse when someone not related to the company is complaining to you about, you know, about your work and how it's affecting their lives and kind of, you know, makes me want to move faster. Right? I wish everyone could have the same experience. Right? You know, we live in a distributed, we have a distributed working environment. So I guess this is a problem. We still kind of need to solve this together, right? Which is basically how do we make sure everyone specifically in the product engineering team has these kinds of interactions. Right. Um, you know, I think, uh, again, going back to Singapore, uh, we ran a few weeks of internal testing, right? And we got, you know, people to fly you in and just, we don't take rides everyday and we actually uncovered a lot of issues that way that were already there even before he did this. Right. But because you don't experience it until you start using it yourself or until the driver starts complaining to you and you hear it with your own ears, um, a lot of issues about fixed right. So, I mean, you know, it's definitely very powerful.
Nadiem: I think for the listeners that don't know, it's like GOJEK has a multi location product engineering team. We've got a big, big, uh, kind of data science, and data engineering center in Singapore. And we've got a very big, Bangalore Development Center full of, engineers and product managers as well. And so a lot of those people, they do travel to Indonesia, but they don't live in Indonesia where the core part of our services is. Yeah, some of them now Singapore launched. So I would love to talk about in relation to this empathy now that Singapore launch, what do you think was the impact of being able to experience our service to the engineers and the data sciences locally in Singapore?
Raditya: I think one thing, one of the, one of my developers said to me is, um, you know, uh, now it feels real, right? Like when you're just like, you're looking at numbers on the dashboard, you worry the current bookings goes down or something goes red, but when you're actually there in the market and using it yourself, it's like; "Wow, I see my code in action." That is a quote, I heard. You know, I think that's really powerful, right? Um, and you know, uh, another good thing about Singapore is that people speak English. So now they get to hear feedback about the products they work on in a language they both speak, right? But in Indonesia it's tougher, right? There's not a lot of our drivers speaking English, but you know, in Singapore you definitely get the direct feedback.
Hans: My sense on it, on empathy is also goes both ways, right? Um, for some of us who are out in the field and we may not fully comprehend that, we may see some glitch or some issue, but we may have no appreciation of how many man hours it will take to fix this or that if maybe it's really not so fixable on the tech side at this point in time. Yeah. Right. Yep.
Raditya: Right. Or just simple, why can't you just add these two fields to the driver...
Hans: Yeah, exactly. Right.
Nadiem: That's not just apps. I encounter that all day, every day, every day.
Raditya: So, so I think empathy goes, goes both ways and, but I think to me, when I think of empathy as how it relates to problem solving, the way that I think about that is that having more empathy doesn't necessarily, de facto gives you a better solution. But what it does is it makes you more intellectually curious, right? Yep. Right. And it opens up your point of view to exploring various different angles to any and it opens up, your willingness to redefine or re-scope the problem. And in so doing that increases the chances of having a higher actionable impact.
Nadiem: But why is that, what is the connection between empathy and intellectual curiosity? What do you think is the mechanism that is happening there?
Hans: Yeah, so I think it's, um, okay, simplest way that I can think about is that we are, we don't know what we don't know. Right. So, and if you're intellectually curious, we are aware that they are unknown unknowns to us, but that it is actually could be happening out there in real life. So when we're intellectual, because we have empathy, we hear enough anecdotes that something triggers off in my mind that, hey, actually, I don't know everything that I think I do. So when a problem comes up, when somebody gives an anecdote or gives an input, I don't shut it down. Right. Or I don't gravitate towards whatever I'm more familiar with, but I'm willing to sit down and think it through food, do a couple of queries, at least let it, let it percolate. So it basically helps you prioritize the issue to solve, or at least you don't, you don't kick it out immediately. You don't deprioritise it immediately.
Nadiem: And is that because you just care more when you empathize? Is that what's, what's happening?
Hans: I think that is, that is that human element. Uh, but sometimes just caring more, it doesn't necessarily give you a better outcome. Right. In fact, sometimes caring in an inappropriate manner will lead you to a less optimal outcome.
Nadiem: So I have many examples of that, that I've been responsible myself. Yeah. Right. So obviously I have a group, uh, where I'm in with a bunch of drivers. You're both in that group. And you know, in the beginning part of that, I would hear all of this chatter and I would get so emotionally invested and in their complaints that I would start firing off instructions, right? Hey, fix this right now. Top priority, everything. And basically I created this big, kind of a vicious cycle of demotivation and the product teams who could get nothing done because I was constantly reprioritizing what they were doing.
Raditya: I remember these days.
Nadiem: And so there's, I think there's a difference here between a constructive empathy and reactive empathy. Yes. Right. I think these things are, are two different things and reactive empathy is in many ways emotional, whereas constructive empathy is more reflective and thoughtful. And you kind of, and that's to your point about information, like when we capture survey or complaints, etc, just feeding them through like a forum in WhatsApp is probably the worst way you can absorb information. Yeah. Because humans are naturally not systematic with how they decide what's important. Yeah. They see something really bad and they're like, no, that's the worst one. Right? Right. So, you know, having a structured approach to giving feedback and quantifying it in a very rational and systematic way is the best way to go away from reactive empathy. And move into constructive empathy.
Raditya: I think there's a word for that.. ruinous empathy, I think?
Nadiem: Is that, is that it?
Raditya: You know what I mean? If, if you remember when we launched the PERFORMA system. Where you know, so...
Nadiem: Yeah, for, for those of you that don't know, a PERFORMA system is an incentive program for our drivers in order to make sure that they are not canceling their orders or rejecting orders. Right. So to make sure the user experience is the best. Yeah. So basically you have like a metric, a marker, a ranking.
Raditya: Corrent. So basically as a driver, you only get your bonus if you complete at least X percent out of all of the bookings we send you. Right. And previously there was no system. Right. So, you know, uh, obviously there were a lot of complaints and you know, I mean, you could empathise with them, right. It's kind of like, um, you know, like, uh, previously I could choose the orders I wanted, the ones that went near my house or the ones that are shorter distance, it helps me make more money faster if I can just, you know, accept whichever order that you want. It's better for me. But you know, like, so you can empathize with that and a ruinous, like an unhealthy way of empathizing with that would be to not do the PERFORMA change right. But on the other hand, uh, picky drivers, like if drivers are picky, it leads to a subpar customer experience, which means you wait longer to get a driver. And when customers wait too long, then they'll stop using the APP and drivers will get the less orders over it. All right. It's kind of like, you know, yes, we empathize with the concern and, we totally acknowledge that now you have less flexibility, but we have to be able to explain why you're doing it and stay on track.
Hans: Exactly. Right.
Nadiem: And therein lies kind of the, you know, the dilemma of leading very, very big organizations, right? And, and you guys have, you know, you've risen up in the ranks to be, you know, like, uh, one of the most powerful people in the company and you're only 27 and sorry, so, so have you, you know, running possibly the biggest operational network out of, out of most of the tech companies in this region. Um, and here's what I hear. I hear that there are some theories that say that the higher you go in responsibility and authority in any position doesn't have to be in tech companies in any position in life. Actually, the lower empathy you have. Now, this is super interesting, right? It's a little bit counterintuitive. I heard about this theory that, that people at the higher levels of kind of responsibility, power authority, however you want to call it, the systematically have less empathy. Um, I guess for many reasons, the theory is that they have to balance so many different opinions that they cannot be equally empathetic to every single stakeholder that they have to please and so on. So I wanted to know as you evolve and as you gain scale as a personal leader, what are the trade offs that you have had to make with empathy?
Hans: It's a good one. So first of all, I'll be the first to admit, right? I get feedback that people tell me I forgot what it's like to be the, be younger or more junior problem solver, problem solving person. Right. Uh, so I'll, I'll be the first to admit to that. I think if I, if I think about this, I think two things comes to mind, right? Um, and not quite sure yet how this connects, but that the two words that comes to my mind, one is trust and the other is mission. So, um, what triggered off in my mind is that, um, I think as we move, let's say, I wouldn't say up, but as our responsibilities increased so to speak, uh, the mission must gain an ever bigger proportion of our mind share, right? And it's up to us on what that mission is. If that mission is to improve the wall and the mission is to give our drivers a better life, right? The empathy becomes secondary to that because it becomes secondary to the mission, right? So if let's say the mission is to improve drivers' lives, then of course the empathy towards the drivers will be very high. But the empathy towards everybody else could be less. Right? Um, or vice versa. If the mission is to improve the wall, then maybe we get so sucked into that mission that our empathy to everyone around us, you know, it takes second fiddle. So trading off, uh, the sense of mission and purpose versus empathy to the people around us or to the constituents. That's one trade off that I've had to juggle. The second one is trust. And what I see it as because you know, arguably trust and empathy is like a Venn diagram, right? There's some crossover. Um, but when I have people in the team, if we trust the team, right? And Trust is not just a function of I think that you are a good person, it's also a function, a spectrum that plus that you are capable and that you're dependable, right? But if there's trust in the team or if there's trust across teams, then that helps to offset, uh, let's say the declining empathy, uh, s we kind of expand to bigger, bigger roles cause they, the amount of capacity of the human brain has to constantly juggle and handle 50,000 things on to same time, uh, you know, you will get short. No, you have to get your very short attention span. And so trust in the team, trust in the group, trust in the mission, trust in the company will help to offset the declining empathy quite a bit. At least. Those are the two things I felt.
Nadiem: I at this stage, any decision, in my case, any decision I make will 100% create some level of dissatisfaction. Like there's literally now at my stage, no decision I can make that does not make me look un-empathetic to one group or another. Yeah. And I think you guys are already at that stage as well. And I think this is one thing that I think they don't really teach you in the theories of leadership, right? When you're, when you're starting out and it's, and it's a super, you know, you need a lot of mental resilience to be able to take the flak for every single trade off that you have to make. Invariably, it's very easy to appease people at small stake decision making at big stake decision making. Even if it's the correct decision and you hope to God it is the right decision, you will invariably create a very discontented portion of, of your team that sees you as being super un-empathetic.. Right. And I think a lot of discussions about leadership, don't mention the fact that, you know, this is normal, like you just gotta you just gotta own it. It doesn't mean that you're necessarily doing a bad job. Yeah. Right. Yeah. And I think that that's, that's an important thing. It's, uh, I hope, I wish someone told me that when I was starting up because I was really bugged about it. I was really demotivated. Why is everything I'm deciding causing such a huge amount of resentment in some people? You know, even though I feel like this is fundamentally the correct thing to do, I don't know.
Raditya: Yeah know, I think like, going back to Han's point, right. You know, um, uh, at the end of the like, you use empathy like empathy oh, low and doesn't really help. It's the problem. At the end of the day, it's how you solved. It's how you do problem solving. Right? So, you know, like empathy informs you of you know, like what, um, how you prioritize the issues to tackle? Right. You know, based on whether, you know, based on empathising with your users, be empathizing with the drivers, empathising with the people on the team who were overworking themselves. Right. Because there's some crazy ops thing going on but the product hasn't solved yet. But you know, at the end of the day, making that trade off to me has to be purely rational. Right? I mean obviously empathy plays a role there, but um, you know, since as you said, any decision you make will seem un-empathetic to someone anyway. That's why you like, you know, to make the trade off, you have to be good at rational problem solving. Like, you know, if you want to keep everyone happy, sell ice cream.
Nadiem: don't lead, don't lead. Oh Man. I want to kind of, uh, use the last part of our section to kind of ask you like, what's the craziest story or experience that you've had in this, in this crazy journey we've had. Out there in the world. What's the craziest thing that's actually happened to you guys?
Hans: Dito, go ahead. I think one, you know, definitely in the top three was when we switched from a bidding allocation model to one to one allocation. Do you remember that? So, um, okay, so a bit of context
Nadiem: just to explain to the listeners, um, uh, before we were sending drivers orders and they could pick yeah. And then we had to shift to actually just giving them one at a time.
Raditya: Yeah. So like this was what, four years ago? Yeah. Three and half to four years ago. Right. Um, so, uh, we had this model where, um, when you make an order, we send it simultaneously to all of the drivers within a certain radius of your pickup location. And the driver who wins is the driver who accepts first. Right now this didn't really work beyond a certain scale cause one like there was too much concurrency. Right. So drivers were getting flooded with bids, but also conceptually, you're not getting the driver who's closest to you. You're getting the driver who has the fastest fingers, the best data connection and the best phone. Yes. Right. And this created more issues where at the time, um, uh, some people modified our driver app and added this feature called auto bid, which would automatically accept every incoming bid, which meant that if you don't have a moderate APP that has auto bid in it, you'll never win a bid. Right. Because it automatically accepts. Right. So that was something we had to deal with. Right. Then we decided to... It was so bad that, you know, you remember the last time we rolled out...
Nadiem: Yeah, the whole office probably the size of this room.
Raditya: Yeah. He was sitting there looking at drivers hanging outside in the yard, like waiting for an order and I would try and book and it would go to no driver found. It's ridiculous because I see five drivers in front of me waiting for an order.
Nadiem: And I was yelling a lot during that period because I kept trying the same thing. Like I created hell for the team.
Raditya: Yes. And you were only making it worse because you're just adding more and more to load into the system, which made it worst right. So we switched that. Right. So, um, now we switched to a system where, um, you only send the booking to one driver at a time, right. Meaning that, um, uh, you will get the driver that's nearest to your pickup point. But the trade off here is you might have longer dispatch time. Right? Right. Cause now you have to wait longer until you find a driver who will accept previously if you sent the 10 drivers, probably one will accept. Right? Right. Uh, so this is why we introduced the PERFORMA system. Right. And when we announced this, uh, there were demonstrations. I remember,
Nadiem: Just to give some sense, how big were these demonstrations?
Raditya: I remember drivers basically, you know, blocking the roads in front of our office and there was like a pickup truck and they were playing like, you know, songs. And there was a guy with a megaphone and it was pretty intense. Yeah. I remember at some point we had to go to the police station to meet the drivers. Remember that?
Nadiem: Oh yeah. I had to, I had to step and it was mediated by uh, the police department. Where, where I had to, you know, come in and have a discussion and, and bridge as a mediator to the drivers. And I think my team, were so scared for my safety that they were like, no, no, maybe you shouldn't walk in.
Raditya: No, you, you had a few bodyguards. There was a puddle and like Nadiem jumped on to one of the bodyguards ....
Nadiem: And it was so funny because as soon as soon as I walked in and my team were like telling me, no, no, you shouldn't. I mean, I'm like, okay, whatever guys, it's going to be fine. I'll just go inside. And then I saw the drivers get up and come towards me and I thought I was dead. But in reality, actually what happened was they came towards me and started taking selfies. This is like the moment when I realized that, okay, okay these, these drivers just to really want it to be heard and we needed to be there to be heard and I needed to be there face to face. Exactly.
Raditya: Emphaty, right? We made a few slides on, you know, how this is ultimately better for them cause they get more orders...
Nadiem: Exactly. Which is true actually. We had to show the why. Right. And I think uh, you know, riot or demonstration management has been a key skill that I think only GO-JEK is quite unique in this. I think a lot of tech companies and founders out there, you know, when they do something about pricing or a change in policy, you know, they might get social media complaints. We have demonstrations and riots quite often. So I think that's, that's a huge challenge for us.
Raditya: It boils down to what you mentioned before, right? That you know, any decision you make will seem un-empathetic somewhat. Yes. And oftentimes when it's related to incentives or pricing, it looks un-empathetic to our drivers. Right? Even though maybe we made that decision with our customers in mind ensuring they have the best experience, which ultimately benefits drivers as well.
Nadiem: That's right. Yeah.
Hans: I think, Nadiem, I think for me. It's been one heck of a ride. Yeah. It's, it's, uh, and again, thank you to two of you and everybody else for inviting me and accepting me to the organization. I really mean that in a very heartfelt way.
Nadiem: Same here, man.
Hans: If I were to think back about the craziness. Oh my God, we would be here all day. Uh, I think two things I like to share, right? So one is as a general theme, I am, I'm lost of words at just how resilient and how amazing our drivers are.
Nadiem: That's crazy. Yes.
Hans: Absolutely insane, right? I mean, look, there are also drivers who are not right or not bad drivers let's say. But no, the stream of information we get.. I know drivers rushing towards a burning building, literally. Yeah. Yeah. To help fight the fire. Yeah. Drivers who took their savings and when the earthquake hit in Palu...
Nadiem: When, when there was a terrorism attack in Jakarta, the bomb... And we had that photo of that GOJEK driver going into this site and pulling a lady out of that bomb site. Uh, I mean, truly heroic.
Hans: It's, it's just, it happens, you know, it happens every day or every week. Right.
Raditya: The way they take care of each other. It's also very inspiring.
Hans: Is it is amazing.
Raditya: I mean there's, there's this thing that they set up to, you know, an organization to take care of the kids, orphan of drivers who passed away. I found that very, very inspiring.
Hans: And plus you know all the other creativity you know, I was, I almost fell off my chair. There's one driver, a motorcycle driver right at the back of his jacket his GOJEK jacket. He put in like a small TV screen. Right. he was screening Mission Impossible or something. On the back of the jacket.
Hans: Yes. I have to, I'll forward it to you guys. Um, and you know, how drivers would give very small pieces of note saying thank you for taking my call. I mean, that whole theme about, um, you know, just how generous, how amazing, hard working or resilient of our drivers and that, that's one thing that continues to, uh, I just feel very humble, right. And I tell my wife and I tell my son about this every week. I think the other thing, you know and if you don't mind me to, I'd be a bit selfish, is I am just so proud of the way that the whole ops team and the Indonesia region team and the ops tech team has just pulled together throughout the year. You know, it's, it's, it's been a journey, right. And there were some, some highs and there was some lows.
Nadiem: Yeah. A lot of lows
Hans: A lot of lows. Yes. A lot of lows. And I have, wow. You know, I think, and I think, um, 10 months later, at 11 months later, no, we have, we really have something special, right? Um, and you can just feel it. The team's coming together, the team is bonding, the team is stepping up like crazy. And um, and I really feel good about that. So I think those are the two kind of crazy themes for me, so far.
Nadiem: I think that, you know, I think a lot of people don't realize out there that, you know, GOJEK is the name of a company, a technology company that provides all these ride hailing two wheel or four wheel or food delivery payments and so on. We're a super APP, right? But there is also this thing called the GOJEK community of drivers that has really a completely separate life outside of our company. Yes. They have their own institutions, they have their own events, they have even their own like kind of parties. They have their own, uh, ecosystem. And the thing that connects all of them together is the fact that they're all GOJEK drivers, right? And there is this kind of, uh, they're a cottage industries that serve them all right? There's a whole other internal economy there that is completely independent from GOJEK the company. Right? Uh, and, and I think that a lot of people don't realize that. Yeah. And I think it's beautiful when you, when you create a platform that truly creates other ecosystems that independently grow outside of actually whatever you do on your side. Right. And I think that's what kind of makes our jobs everyday, even though hard, really special. Okay. Guys, thanks so much for being on the podcast. Hope to have you back again soon.
Hans: Thank you.
Raditya: Thank you having us.
Hans: Thanks a lot.
Outro: Hey guys, hope you enjoy the podcast. If you liked it, please hit like, subscribe and follow us on social media. Thanks so much for tuning in.