Intro: Welcome to GO FIGURE. My name is Nadiem Makarem, CEO and founder of GOJEK Southeast Asia's first Super App. GOJEK does ride hailing, food delivery, payments even on demand massages. You name it we do it. GO FIGURE is a podcast dedicated to expose the inner workings of ambitious tech companies in the emerging world. We like to talk about things we like and talk about things we don't like. There are a lot of myths out there that we want to dispell. So keeping it real is kind of our mantra. Hope you enjoy it.

Nadiem: Hey guys, welcome to GO FIGURE.

Niranjan: Thank you.

Nadiem: Thanks for being on the show.

Sidu: Thanks for having us.

Nadiem: I'll do it just a quick round of intro you have here. Niranjan the legend himself, our CTO of GOJEK Corps. Oh, we started from the very beginning

Niranjan: 2015.

Nadiem: That's right. That's right. Uh, during those big, big crisis days. And we have here, Sidu our Head of global talent who leads the India office. Thanks for making it out of here.

Sidu: Thank you for having us.

Nadiem: So these two guys, are I guess, very special to listeners that don't know. I mean, they essentially co-founded the GOJEK the technology company together with myself and Kevin as well, because they created the first basically organisation for GOJEK engineering. They started an amazing company in Bangalore in India that we ended up acquiring and then just became our senior leadership. And that's where all of the history began from. Maybe you want to share a little bit about your backgrounds and what you did before GOJEK and why you decided to join us maybe, a little bit.

Niranjan: Sure. So, uh, before GOJEK, Sidu and I were running a consulting company out of Bangalore. We co-founded the company in 2010 and it was also targeted as a premium consulting company for CPOs who are going to a growth phase and want to solve difficult problems but don't have enough people to solve those problems. And as a part of that journey, we were partnering with Sequoia, we're their technical vendors and then Sequoia was looking at GOJEK for investment. They introduced us to GOJEK and say that, Hey, here's a company would like your help. And..

Nadiem: Meaning, we were in real trouble. You were basically Sequoia's SWAT team. Don't sugar coat it. You came to the rescue when companies needed help.

Niranjan: So April 2015 is when we got introduced to GOJEK and came in as consultants to look at what the problem companies facing at that time. And I still remember those days, the demand from people were so high that the systems were not able to keep up and there was a lot of challenges, systems you have to keep going down. So we started working on the systems and trying to figure out how we can keep them up and running to solve the market demand. That went on for awhile and you know, after a couple of months, we were in the bar and you made me a job offer, why don't you join GOJEK? And my response to that was I would love to, because I can clearly see the kind of things I can do in GOJEK and the big company is growing and I would really love to be part of that journey. But I have a company of my own. And I remember your response was, don't worry about that company, we'll take care of that.

Sidu: So that evening is when he called me saying, Hey, you know, milestone achieved, the client just tried to poach me because that was one of our internal traditions.

Nadiem: So, is that a metric of success? How many companies has tried to poach Niranjan before?

Sidu: I think most of them that he worked with.

Nadiem: Wow. So I couldn't acquire you. So I had to acquire the whole company.

Niranjan: Exactly.

Nadiem: And thank God for that. Turns out your company is way more valuable than you. So, you failed and then I remember negotiating with you and that was one of the fastest negotiations of this to come on board. But I think the spirit was already there. We could feel that there was a shared intellectual alignment about being that curious company to see what we could become. And that was shared even though our methods were very different at that time. And I think none of us here in this room would have guessed we would be this big.

Sidu: Yes.

Niranjan: Oh definitely not.

Nadiem: That's, that's the crazy part. Right? So the topic of today is about the 10x engineer. The Myth, the legend of the 10x engineer, um, you know, GOJEK is now a uh, you know, top 20th private company by valuation in the world. It's a top 20 private company, Tech Company by valuation in the world and we're clocking somewhere along the lines of 9 billion gross transaction value.

Sidu: Yup.

Nadiem: Through our system anually. Um, and then once knowing that when people find out that we actually have, so how many engineers do you have?

Sidu: Three hundred

Nadiem: Three... It's actually a little bit lower than that, but we'd like to stay three hundred just not just to scare people. We just round up a little bit. We have 300 engineers. How does that make sense? How does that make sense and why is it every time I say that number to people outside their jaw kind of drops, right? And half of the people are like, oh my God, these guys must be bunch of crazy quacks. They're set to implode anytime and another half would say like, wow, that's one of the most impressive things I've ever heard. What do you guys think about that? Like, how, how are we, how is this even working?

Sidu: Yup. So, uh, you know, the interesting thing is, I mean, you know, we all get asked this question, right? And my answer is always, surprisingly prosaic to most people, uh, we study the textbooks and we apply them. And if you'll study the textbooks and apply them, what we teach you is that every engineer that you add increases the risk of you failing to deliver completely disproportionate. Most people assume that if you add headcount, it increases the output. But engineering is strange. And that, that's counterintuitive. That with every engineer that you add, you actually slow things down and you slow them down exponentially. So in many ways, and I like to joke about this, right? Like a good finance person, you know, a good finance person because they will look at you and challenge you on every item of spend because they understand that that's how you lose out. And a good engineering leader will challenge you on every addition of head count because he or she understands that while every head count that's added gives you more capacity, it comes at this enormous hidden cost and you'd really want to justify every additional headcount because you do not want to accidentally create liability, hidden liability that comes up and bites you in terms of your ability to deliver quickly and to deliver quality.

Nadiem: What is this hidden cost? How do you know that it's real?

Sidu: So the way the... The thing about software is when one person works on software, it scales in terms of the effort that person puts in. But when you have more than one person collaborating on software, it turns into fundamentally a communication problem. So now in a team you map the number of communication and I hear according to textbook, right? There's a 40 year old textbook on the topic, every person you add exponentially increases the number of combinations of communication that you need in order to agree on what exactly it is that you're building. And the most foundational aspect of the communication is the code itself. How one engineer communicates with another in terms of what they're trying to build is best encapsulated in the code itself. So now this combination of increasing exponentially increasing communication channels with the primary medium of communication being the code itself means that as you add engineers to a team working on a project, their productivity starts going down exponentially. And we actually tracked and map this one uh, you know, many years ago where we saw we, uh, you know, this was a very person, I have enormous respect for product manager. He started tracking the output of teams and he tracked it while tracking the additional headcount. And what he found was that up to four people on a team, it's scale linearly, then it started plateauing five, six, seven, eight and then it starts dropping and then it starts dropping exponentially. And so he came up and this varies depending on team to team.

Nadiem: And the threshold was about five people...

Sidu: It was about five people though, you know, I should calculate that, that depends on the context, but it doesn't go up significantly beyond that. It doesn't get, there's no context where, you know, 500 people can collaborate. Right? So it, it's very low. It's shockingly low. And so what he did was to slice and dice the system in such a way that at any point in time, each subsystem had a team of four people working on it and no more. And this meant that he was literally defining the system architecture to ensure that he had small teams, which at the time was mind blowing for me. Right? Why are you deciding system architecture based on team structure? And it took me many years to slowly start internalizing the true that your system architecture and your team structure are the same thing.

Nadiem: I remembered we had this debate about this many years ago and I was extremely surprised to see that you are choosing to map out system architecture based on what a five person team can do.

Sidu: Yup. That's exactly why.

Nadiem: Instead of mapping, okay, here's a task, we need X amount of people for this task. Which to me seemed super weird initially and I only learned about the benefits later on. But, um, I find that extremely fascinating.

Sidu: Yeah. It's like, it's a communication problem fundamentally.

Nadiem: And okay, so that's on a team basis, right? But as an organization, do you find that there is a similar diminishing return with the number of pods that you have? So what, what's the reason that GOJEK grows? It's good, it's engineering department in a very, very paced way. Like, is it, is it because we just can you have an infinite number of teams of five and you'll still get great returns? Or do you then hit other types of diminishing returns?

Niranjan: So once you essentially start having multiple pods, just the way you have to worry about in a larger team how many communication channels exists between team members, then you have a large number of POLS (Principle of Least Astonishment/Surprise). Do you need to worry about how those POLS communicate with each other?

Sidu: And remember these POLS are still communicating primarily through the medium of the underlying software itself. Right. So as the complexity of the system itself increases, your ability to add pods is, starts to get limited by the ability of two spots to understand the system.

Niranjan: So number of distinct problems you can create where there are multiple pods who are working independently and how to collaborate. You know maybe once in two weeks or once in a month to get on the same line, but when your systems are small and as things are growing, if there are multiple pods we need to work on the same problem, then it becomes problematic because then everyone is trying to step on each other's toes and everyone is trying to evolve the system based on their understanding of their part of the problem without understanding what is the larger picture.

Sidu: And there are local goals. Which may be very different from the overall global goals for the system.

Nadiem: So are you trying to say that there is a natural rate of on-boarding at that, the whole organism meets the half, the organism call it, the organism of the engineering department.

Sidu: Yeah. That's a great analogy.

Nadiem: There is a natural rate of on boarding of an additional resource because of this communication and complexity prompts and as your organization becomes bigger, the complexity is driven by the interdependencies. And as those become higher, you actually have to be a lot even more careful. Absolutely. It's just super counterintuitive though because as you've seen many types of four and we had massive, massive fights about where I've come in and I'm just like, look, we have a hundred things to do. Why can't you guys just fricking hire smart engineers? I mean, and I couldn't understand it. It's like, like everything else in life when you need something, it's like we had funding, we had the ability to hire. Why aren't you doubling your engineering capacity? We're looking at smaller companies than us with double our head count.

Sidu: I remember one argument where you were literally like, don't slow me down. Why are you slowing me down?

Nadiem: Yeah, yeah. Yeah. I took it personally because I feel like you guys were this idealistic pie in the sky. You were like these philosopher, poet, engineer. Right. Okay. At least that's how it felt like in the beginning and that you are so idealistic that you did not have an empathy to the, to the business goals that were Gargantuan to our challenges and only over time that I quickly realized that no, it's actually you are trying to get to the same place that I want it to. You just have to educate me about this is not how it works. It's not two plus two plus two plus two plus two equals like 10. It's like it can, you could actually go negative.

Sidu: Yes.

Nadiem: That's super interesting.

Niranjan: Yeah. So typically what I've seen is growing your doubling your organization or maybe even stretching it or tripling your organization in a year is healthy. Going beyond that essentially starts adding all those problems because people don't get on boarded fast enough. They don't have clarity on what they need to work on. And you can't even slice the systems appropriately and fast so that you can create those independent pods to evolve.

Sidu: So, so one of the constraints that that problem ads is there are certain scaling thresholds in terms of headcount and system architecture because those are tightly coupled where to be able to support the next level of scaling in people will require a fundamental re-architecture of the software stack itself. So there was this pivotal moment for us, for example, with the introduction of Kafka into our stack. The reason that was so critical is that enabled a restructuring of the entire system to reduce the number of communication channels between teams to solve problems. And until we were able to pivot the entire stack and re-architect it to use Kafka, adding more people would just cripple us.

Nadiem: Why?

Sidu: The the, the way, uh, what Kafka did was it, uh, it's sort of applied a reverse Hollywood principle.

Nadiem: What's that?

Sidu: What ended up happening in, in GOJEK in that at that point in time was you would have all these teams with these interdependencies, right? So for example, I want to ship live tracking. Hmm. And in order to ship live tracking, I need to know driver locations. Now I'm not the only team. There are 10 teams, you know, including pricing, including incentives that meet the exact same data. Now until we can re-architect the system to give all those teams the data in a manner that doesn't block the team, that owns the driver location system. Adding more people to the old system would just bottleneck it even worse. Because that's crucial data. Everyone needed it. And putting Kafka in allowed us to get to a point where it's like, look, now we have a feed of all of the data. Whoever wants it can tap into it without coming to me and asking me for the data.

Nadiem: So it seems like there are these lists of enablers that allow your engineering organization to scale. The first is what we just identified is creating system architecture that allowed for five person pods to take discrete chunks of your system to do it. The second thing that you're alluding to is actually re factoring entire monolithic systems to begin with. Because as with all startups, when you start, everything's monolithic. Everything's this one gigantic ugly architecture. Because everyone is just trying to race time. You know, you got to show your numbers that you're building on this highly inefficient monolithic model. And so until that gets refactored and broken again into different components, you just can't put more people on it.

Niranjan: That's a classic example. And actually if you look at how GOJEK has grown, that's exactly how we have grown. For example, GOJEK started with our monolith codebase called Stan Marsh. And we first pulled out allocation system out of it, which matches driver to a customer.

Nadiem: Yes, the market what is now called market place.

Niranjan: And once that system is pulled out, now you can staff a complete team on that because they can focus on it. Similarly, GO PAY initially got built into Stan Marsh, which is a monolith, we couldn't staff more than two people on that because they had to understand the entire monolith. But we essentially de-factored and launched GO PAY 1.0 where we separated GO PAY out of the entire monolith and now there is 40 people team just working on GO PAY which is then further, you know, segregated into multiple components. So that's how we have grown historically. And that's how we'll continue to grow as well. We identify a problem, pull it out, and then establish a pod around that.

Nadiem: And how, I mean is it inevitable to grow that way? I mean that created so much tension between us in the beginning of how do we get out of the system and every time we want it to grow and do something else. You are always telling me, no, we got to get rid of Stan Marsh first. We've got to get rid of this monolithic system first. And is every startup or tech company doomed to repeat the same thing or is it actually possible to get a right from the beginning?

Niranjan: Oh No, it is not possible to get it right from the beginning.

Sidu: Or if I may, it's inefficient.

Niranjan: Exactly. Because when you want to start, you want to start as a monolith because then you have one codebase and one monolith, it is easier for an engineer to whole entire context in that..

Sidu: And it's what's calling out there. At this stage of the business, you have maybe 10, 15, 20 engineers.

Nadiem: And they're all sitting together.

Sidu: They're all sitting together.

Nadiem: They know exactly the reasons of why a decision was made.

Sidu: Exactly. Right. They have full context. So the communication overhead is very low.

Niranjan: And extending that further, right? Uh, you essentially carve out certain system from monolith, over a period of time that becomes monolith. For example ride service, right? Because an auto management system for our transport then we pull out ride service out of Stan Marsh it was pulled out as a small system to just handle transport. But as transport grew, a number of use cases in transport kept on increasing ride service became another monolith

Sidu: It was the new Stan Marsh

Nadiem: So it's almost like you create these extremely fat cellular structures within this organism and the more people that connect to with the fatter it gets. Until it reaches that critical mass where you have to break it apart. And so on. And this is happening in parallel in real time across multiple shared services in the organization.

Sidu: Yes, so you're refactoring your teams and your codebases in lockstep, which is what makes this so hard

Nadiem: And so, well. So what's happening if we imagine that we had a set of monolithic engines, which we did and stuff like that, what would have happened if before those got broken down and before the pods got segmented in the way that we did? What would happen if we threw like another hundred, like say another hundred engineers on these problems. Like run me that scenario. What would actually happen in the day to day?

Sidu: So in practice, what ends up happening is I'm sure what actually cause this. Here's an interesting term by Shobit, he's a colleague of ours.

Nadiem: We're going to have him on the show.

Sidu: So he jokingly calls it "relationship as a service", right? So what ends up happening is I have a dependency on your stuff. Now I need something done in your system. You have your own priorities. Now I need to convince you to prioritize something that I need. So I'm unblocked. Hmm. Now this, this set of demands starts growing and growing and growing until you're no longer able to do your work, you're completely bottleneck trying to un bottle neck other people

Nadiem: Cause people are trying to access my system. I get an email from you or WhatsApp saying hey man I really need this so I can't get my, my stuff done

Sidu: Exactly and then what ends up happening is because I know you I'm going to come to you and at a personal level convince you that what I need is more important. So now this starts critiquing what is relatively a simple system and starts turning it into a bureaucracy with back channels and then you start having what Shobit calls "relationships as a service". There are certain people in the system whose relationships allow other parts of the system to scale by giving them a back channel or priority channel to jump the queue, but this inherently doesn't scale because eventually all the other people who do not have access to the relationship as a service start to get extremely frustrated

Nadiem: and they start calling the organization political. That's when he's out, which, which we experienced that. Even at our very modest rate of growth. Yeah. We've noticed how very quickly those privileged access people and the lack of access by a certain other set of people created the perception of politicking. When it's actually just traffic congestion.

Sidu: Yes. Everyone's just trying to do their best and because they're trying to do their best, they're going to use everything they have unconsciously, which includes those relationships like you know, because I hang out with you, you have more empathy for my problems, so you're more likely to prioritize my requests.

Nadiem: Hmm. It's really fascinating. It's almost like a lot of people accuse organisations of being bureaucratic and political when even in the most well intentioned and non egotistical organizations, structural failure leads to the perception of favorite.

Sidu: Exactly.

Niranjan: Yup.

Nadiem: That's super, super interesting. But we're, I mean we're talking about an engineering organization here, but then you know, what are, what are some of the things that we can do to unblock or to de-bottleneck? You mentioned the stuff on architecture, you mentioned stuff on pods. What about the people themselves, the engineers themselves, like is is the quality, is there such a thing as a 10x engineer? Is this a myth? Is this like how does this factor into why as our acceptance rates for engineering so low among the lowest in, in in various comparable industries and other ones. Does that play a part also in, in increasing the efficacy of once they get on boarded? I mean, why are we so selective?

Sidu: So, so through to two axes that are relevant to to answering this question, right. The first is, you know we talked about how as the system complexity grows for you to meaningfully contribute means you need to know the system. Now there's one scale of, one axis of development, which is an engineer who can grasp large complex systems and understand the implications of design choices on scaling that system.

Nadiem: That's a really tall order man. How can a 21 like 21 year old either eat ITB (Bandung Institute of Technology) or IIT (Indian Institutes of Technology) grad understand complex...?

Sidu: I'm actually glad you brought that up. And that's why at this stage we, we're doing GO CLOUD and I'll circle back to that. Right. Okay. So what is happening now is our systems and read sufficient complexity. That's someone who's relatively young and inexperienced, cannot meaningfully on board onto that system quickly. It takes months and months and months and months because the complexity is so high. So what ends up happening is one axes of capability that you need to hire for is the ability to deal with deep system complexity, to know what the ramifications are technically and to understand how to mitigate those ramifications. That's a core technical skill. The second access is the communication channel and that that's actually equally interesting to me personally. Right. This is the first, first channel is broadly what we would call computer science.

Nadiem: Sorry, just when you say it, cause you're using some jargon here called channel. You're talking about criteria.

Sidu: Yes.

Nadiem: Internally we call it channel. So criteria to select an engineer. Yes, go ahead.

Sidu: The first, so the first criteria is what broadly we would call computer science. The second set of criteria is what is popularly called software engineering. Now I mentioned earlier that the primary tool of communication between engineers, aside from your stories and your documentation, etc, those are the minority. The majority form of communication is the code itself. The way the code is organized, the way the code is written, and the focus here, the first set of criteria focuses on how well you can write code so that the computers run it well. The second set of criteria focuses on how well you can write code so that other human beings can grasp it well. How well do you communicate through your code? And this impacts architecture, you know, it has very wide ramifications and as your system grows and scales from monolith and outward from there, your ability in the second area is extremely important to scaling the organization system. Because otherwise, again, you wind up at traffic congestion because badly written code is one of two things. Badly written code is code that doesn't run well on a computer or it is code that cannot be easily understood by other human beings. So it's a communication problem.

Nadiem: And so on that second point on the communication problem, a badly written code is, is can, can you just double click on that? Does that mean that when I look at your code and it's a badly written code, I didn't understand the why.

Sidu: Yes. You don't understand my intent. You don't understand my objectives. You don't understand what I was trying to achieve. Why?

Nadiem: So conversely, well written code provides contextual logic.

Niranjan: Yes

Nadiem: Wow. I had no idea about that.

Niranjan: And more than just the pile, the other part of it is if you look at the software specifically software in a startup like GO-JEK where the ecosystem is changing so fast, one of the most important criteria for the software is how fast you can change it. If you cannot read that code and understand what it does, your ability to change it as the market demand changes, is crippled.

Nadiem: And that's a reading exercise. It's literally like reading like a, like a book and understanding. Okay. It's the syntax, the grammar, the lodging, just choice of word. The diction.

Sidu: Absolutely, so when we, when we, you know, we run a bootcamp because of this complexity. When we onboard young engineers, junior engineers onto the system, we, one of the first things we teach them is the importance of naming. Because the first thing that someone else is looking at your code sees is what you've named things. And when you read a name you take away meaning from it. And if you've made something unwisely, the conclusions that the reader draws could be very, very wrong. So you, you'd literally the, it starts at that foundational level where you need to name things in your code well, so that, and the concept is called express intent. It's a rule. When we say when you write code, it must express intent.

Niranjan: So on this point, right? Like we hardly pair these days, but back in the days when they used to pair, I remember we are spent 15 minutes, 20 minutes, half an hour just arguing about what this method should be called.

Sidu: And the return on that investment is immense because the return on that investment plays out over the entire life cycle of that codebase, which could be years.

Nadiem: But I don't understand because that's just, that's a shared terminology between people that work with each other all the time. How does a new comer come in and be able to understand the vernacular of that specific engineering department?

Sidu: So, so one of the things, so we'll make the best practices that we attempt to drive and follow is every code base comes with the glossary because there is a term which means something specific in this code base, and it may be a business term, it may be a technical term and it's a label. At the end of the day we're picking a label from the English language and we're loading it with meaning that is very specific to this context. If that label is poorly chosen, then your communication breaks down for the entire lifecycle and it starts with something as simple as that.

Nadiem: When you, I know. I think for those that don't know and in GOJEK engineering, if you, if you apply for a GOJEK engineering position, you are essentially forced to take a written test as part of the, and then you also have stuff that's the first step and you also have a pair programming test. And part of the, you know, I think one of the things that I've noticed that we encountered a huge amount of friction with seniors, senior programmers initially that were, you know, forced to take this kind of pretty, not rudimentary, but it's a, it's a standardised coding test.

Sidu: Yup. That problem is trivial. So most people were stunned at why are you giving me this trivial problem? It's a high school problem?

Nadiem: Yeah. Yeah. And, and, and in reality that kind of somewhat offended some engineers, but I think, you know, you guys defended it to the death. And why is that? Why were you so adamant that every single person we hire, whether their CTO level or whether they're coming out of Grad, we need to see their code

Niranjan: As a programmer. The best way you can express yourself is through code. That is what you will be doing for years. Now what you're testing in that particular test particular coding problem is not can you solve a complex problem, but we are testing what is your discipline, what are the basic criteria that you have in your head when you express yourself, how you structure your core base, how you commit your code, how you write your test cases, how you write your documentation and the reading. So those are the basic things, there's a lot of hygiene factors. So we are specifically for senior programmers. We are looking at how good is your hygiene because that is the hygiene you are going to enforce on your teams once you come in

Nadiem: As the standard.

Niranjan: Yeah, exactly.

Sidu: It, it fundamentally allows you to assess their ability to communicate through their code. And that is extremely important, uh, for us because the rate of growth we were dealing with was like 10% week on week average. That meant that you know, many of our subsystems, we're seeing a doubling in their overall load every two weeks. And that meant yet again, the half life of some of our subsystems in the early days especially with was one quarter. So now if you have to re factor your systems at that crazy rate, the whole thing is not sustainable if this is missing.

Nadiem: Okay. Okay. So then based on all of your interviews that you've done, all of the pair programming interviews, you've done, all of the code tests that you've done, tell me the difference between a good engineer and a 10x engineers. What are the biggest differences?

Niranjan: Well, okay, let's drill down into that. Uh, the 10x engineer itself and their role in an organization and how that pans out. By definition, 10x engineer is an engineer who can produce 10x outcome than an average engineer.

Nadiem: Yes. By definition, right? Is it meant to be taken literally?

Sidu: Pick the word very thoughtfully and I want to call it out, right. Outcome not output.

Nadiem: 10x outcome meaning the impact.

Sidu: Correct.

Nadiem: As opposed

Sidu: to be amount of code they churn out for example.

Nadiem: So it's the quality of it. The APP impact. Okay.

Niranjan: Now, if you look at this particular activity specifically in the early days of startup, when you're five people or 10 people, having these kinds of engineers are definitely useful because you can move fast. They just riding on that. But as your organization grows, what do you care about is not that individual person's outcome. You care about the team outcome so even if you have 10x engineer. But if that person is going to piss the entire team off and cannot work with them, that person's outcome is...

Sidu: diluted.

Nadiem: How much would you discount an individual contribution in engineering department? In our engineering department? Is there any value to a solo performer or is it really their, their team output and how they can contribute to the team? How much of it, the, how much of a team sport is this?

Niranjan: It's completely a team sport. So there are areas where you can isolate a particular problem and give it to that person who cannot play with the team. But they're very, very small number of problems because one of the term which is constantly used in software engineering is this term called truck factor.

Nadiem: Cut factor?

Niranjan: Truck factor. Right. How many people in your team if got hit by a truck the entire thing to collapse?

Nadiem: That's why it's called a truck factor? Okay. Sorry to say how many people get hit? Sorry sorry...

Niranjan: So if you have,

Nadiem: Why is it a truck? Because it gets hit by a truck. So if a truck factor of three is .... ?

Niranjan: is good, Truck factor of one is really bad.

Sidu: That means that if any one person on the team drops out, they fall ill, they leave whatever you grind to a halt. Okay.

Nadiem: So it's redundancy, it's a factor of redundancy, right?

Sidu: Exactly. So I also want to call out here that the individual contributor aspect needs to be nuanced, right? Because there is individual contribution, which where the person works alone, but their software fits with everyone else's. So you can have a deeply, deeply technical person, extremely capable. Who has immense, immense contribution without working with the team on the people side. But because the team and the software is tightly coupled, as long as the software fits with everything and evolves, co-evolves with everything, you're fine. There's nothing wrong with that. What Niranjan was talking about is let's assume the situation where that person is hostile and toxic, right. And is contributing to communication breakdowns by their attitude. That's a problem. But an individual contributor who says, look, I work best alone and I'm going to work best alone because I'm deeply, deeply capable in this area and I can kick ass as long as what that person's building fits, melds and co evolves well with the overall system. That's perfectly fine.

Nadiem: Okay, so you're talking about a disruptive force. Negative chain force. How do you spot that in a new hire, what are some of the telltales?

Niranjan: Well, one of the biggest thing is every good engineer is highly opinionated. What we look for is you have strong opinions. Are they weekly held or are they strongly held? You feel strong opinions which are strongly held which means that if I presented evidence that your opinion is wrong, you're still don't budge. That's a problem. Where as, if you see a rational argument when you say, oh now I see my opinion was wrong. Let me change it. That I believe people change and muted is very, very critical.

Sidu: The other thing that we look for is because as a developer what ends up happening is your cord represents you. It's like an artist's painting represents the artist. It's very close to your ego and your self image. If you are unable to deal with criticism of your code, that's a smell.

Nadiem: You'll never get better, like a script writer. If they're not open to getting feedback from other writers, etc, they will never be able to get that beautiful final edit. Right?

Sidu: Exactly. and, and one of the simple hacks that we use is we just ask someone junior to interview that person

Nadiem: and just seeing that reaction of like a young kid talking to the senior guy. How offended or how, how gracious he can be in front of that kid

Sidu: Yes, that's the main objective and yes it's extremely crucial.

Nadiem: You just, you just, you'd like to mess around with people. It's kind of like a psychological test. They're effective though.

Sidu: I mean, it's not just effective. It's part of the playbook. You will find that most mature engineering organizations do this because what ends up happening in reality on the ground at any team is you have seniors and you have juniors and the seniors have to grow and onboard the juniors on this system which has enormous inherent complexity and that has even more complexity on its boundaries, but it integrates with other systems and other teams and if they can't be gracious about it, then those kids are going to stagnate and then go toxic.

Niranjan: That's right. There are times when senior needs to get onboarded by juniors because the senior person joining a team of juniors and you should be okay with that.

Sidu: And in a fast growing business like ours, that's actually the norm. We routinely wind up in situations where you have, you know, younger people owning very complex systems and then you bring in senior talent because you've grown to a point where you need it and then you have to onboard them.

Nadiem: Why does why it is ego seem to be such a recurring theme here. Um, it seems to me even more acute of a requirement to have a, everyone has an ego, but I'm talking about an uh, control, uh, which implies that you still have the curiosity to learn new things and be able to admit when you're wrong. That's essentially what we're talking about. Right? Why is that even more important for an engineer, isn't it? I mean, I think most people coming from outside, we don't understand engineering and would probably just assume, hey, you're either code, it works or code. It doesn't work. You should immediately get feedback on whether what you're doing works or not. But it's not that simple is it?

Niranjan: No, it isn't. It isn't because it's not just about with the code works today or not, it's the question of can you keep evolving that code?

Sidu: And in any given situation for any problem there are at least five, six ways that you can write code to solve the problem, which is the best way is often subjective. And whether you were right or not, it's something that will only play out over years sometimes.

New Speaker: Classic example, let's atalk about Linus. So a classic example of that is the person who build Linux operating system. Extremely opinionated person and at times it's considerately brash when it [inaudible] with community. Because he wanted to evolve the system in a certain way and he was the core contributor and core committer keeping, making sure that each contribution which is just coming in adheres to certain standards and his rules and he heard from multiple people that today you're owning that system but some days system is going to outgrow you. You're not going to be able to hold that entire complexity in your head. And you need to think about that. And was it a few months back when he essentially wrote an email to the community saying that, Hey, when I look back on what I've done over the years today I understand that things are becoming more and more complex and hence I am willing to change my stats. Right. Because the system is bigger than you. The same reason why it is part of our company culture. It's not about you.

Nadiem: Yeah, absolutely. For the audience and the listeners that don't know our first and foremost company value is "it's not about you". Not just for engineering. For the whole company. "It's not about you."

Niranjan: Yep. Same thing applies for engineering as well. All right. Uh, if I have proposed a certain system and certain architecture people don't have to accept it, people should actually, I'd rather, I expect that people will give rational criticism so that I can learn from them.

Sidu: And the challenge here is because this is still more a craft than a science, there is an enormous amount of subjectivity in those choices. So the reason I mentioned Stan Marsh earlier is one of the choices he was forced to make in 2015 was "do I pause everything and take two months to completely kill Stan Marsh and replace it with something else or do I let this system continue to scale and live with Stan Marsh and cut it out piece by piece by piece." Right? And I think it is, it's extremely hard to judge at that point in time what was the right decision. The call he made was "I am not willing to do anything that stalls company growth." I don't care what the longterm cost of that is. Growth today shall not be stalled. And as a consequence, we've paid a price for Stan Marsh living in our ecosystem for two and a half years after that. And it's a very, very difficult call to make today as to whether or not that was the right call. And this is, this is the story of our lives now in this kind of a subjective craft oriented situation. If you do not bring ego management to the table, it's impossible to move forward.

Nadiem: I don't think that only applies to engineering, by the way. I just think it's so much more acutely expressed in an engineering department because your feedback loops are a lot faster. Actually, you know, when you're messing up much quicker. If you had to pick, let's say it, this is an impossible choice and that's why I'm intentionally making you do it. If you had to choose between, obviously an engineer needs to have a certain base level of structure, right? That's just something that you have to have in you. Right. But if you had to choose amazing experience or great behavioral foundations, I know, again, it's an impossible choice, but if you had to choose, what would you pick? If you were forced to choose between these two options?

Niranjan: Well with a question like this, the good answer is it depends.

Nadiem: Dammit.

Sidu: Or both.

Niranjan: Yes.

Nadiem: The problem with dealing with rational people at your workplace. They can never give extreme dramatic questions. Okay.

Niranjan: In situations where you want experience because the person has seen that, the person knows what needs to be done. Getting that person and to build that system out and learning from that person is extremely important. Uh, another side, someone who has a good behavior traits is curious, wants to learn, reads books, uh, can accept critical feedback that person can grow. So it's a choice between, hey, have you grown or can you grow?

Sidu: Also I can add to that that, and this is something if you read the books is not well addressed because most people don't realize that there is only one mature ecosystem on the planet and that's in Silicon Valley. There are very, very few places on the planet where you have four or five generations of engineers who've been attacking this kind of problem. Right. So when you come to, when you come outside of the developed world and you know, our playground is, you know completely outside

Nadiem: outside of the valley, it's not really developed world because you know, it's really there.

Sidu: Yeah. I mean, the reason I said that is there a few pockets where for historic reasons, you know, the Soviet Union for example, you'll find amazingly talented engineers because there were pockets where, you know, 30, 40 years of engineering. But at scale it's pretty much just the valley. And when you come to our playground, most engineers are first are most if they're lucky, second generation. So what this ends up meaning is you do not have a choice about hiring for experience.

Nadiem: Yeah, there is none.

Sidu: There is none. Like how many people in India have skill...

Nadiem: Which is why we're so skewed to, to younger, experieced engineers, like two or three years of experience.

Sidu: So, if you read the books, for example, some of some of them, um, powerful for example, talks about saying that, look, you know, you hire people for a role or highly skilled, etc, but the moment they're fitment for that role goes away. Let them go. Because you will always hire another. Don't hang on. Well that only works when you're sitting in one of these very successful companies in the Valley. You know, say you're sitting in LinkedIn and you have Google next door and Facebook next door and Netflix across the street, but when you come to Jakarta or you come to Bangalore, you know, no one's done this before, right? Or the people that have done this before, probably you could, you, you know, in the low double digits.

Nadiem: It's double compounded for us. Not only have we not find people that done it before, no one's done what we've done before as a Super App, right? So you're just forced to say that we will teach. And that means that there is a natural limit on how quickly you can scale people. And so you'll have the strong bias to, to hire a teachable people.

Nadiem: Well, you run our boot camp. Can you describe a little bit about what, what essentially is the experience of our engineering bootcamp?

Sidu: So, um, the engineering bootcamp is divided into several sections. The first section I, it's just what we call core engineering bootcamp because, uh, you know, you need a name, but what it really is, is a structured decision making, uh, basic coding hygiene, like the basic practices that you would need to say contribute to an open source team. These are standard is a community standards, but it turns out these community standards are not common in a young markets, so you actually have to teach them. And, uh, most fundamentally we end up teaching decision making together. So for example, I want name this piece of code, this variable X, this other person believes that it should be named Y, how do the two of us in this subject of conversation where the cost and the benefit will only play out over time. And even that may not be measurable. How do the two of us engage with each other meaningfully decide reasonably quickly. That level of collaboration is something that in most professions is learned over the years. But over here is non negotiable to be productive at our rate of growth immediately. And then we do this for three weeks. Uh, trough coding it's all hands on coding. We use the code as a medium to teach these ideas and concepts. There's heavy focus on cognitive biases in these conversations because fundamentally what blocks two people from agreeing in these situations is we have biases. And then we followed it up with one module from every department in the company or every focus area. So it doesn't matter what you're actually going to work on. Ultimately you spend two weeks learning to build mobile apps. You'll spend a week with our head of design learning to design stuff. You will spend time working on backend, front end, QA, security. So we bring in bring in coaches from every focus area who will teach a one or two week module just to build empathy. Hmm. So now you have an understanding that hey, you know, when I built this feature, I need to loop in my colleague who's focused on security because he or she is worrying about this stuff, which I may not be thinking about at all. And so I need to look this person in because otherwise these kinds of things happen, which are not.

Niranjan: The other interesting thing, which is a soft path aspect. Which is covering boot camp, which I find really interesting is holding two really contrasting ideas in your head about being proud of your craft at the same time being comfortable when someone comes into with your code.

Sidu: Yup. Prie without attachment. Yeah.

Nadiem: Pride without attachment. How is that even possible?

Niranjan: Well, that's what he delivers.

Sidu: I mean the whole point is if you don't have pride, you will not focus on producing really high quality code,

Nadiem: but what are you? How can you be proud of something that's disappeared? You'd have to be proud of the journey of the process. You can't be proud of the thing

Sidu: Exactly, because the thing that you've created because the thing that you've created has to evolve. If you're attached to it in its current form, you will stand in the way of its evolution.

Nadiem: That's a super hard to grasp concept that I think, I mean I've only realized this in the past like two years or so, but letting go of, you know, the actual thing that made you proud, but instead being proud of having gone through that process. It's a, it's a subtle distinction, but it means the world in terms of how you view disappointments. Not just in your work life and your life. I would say, right?

Niranjan: One of the thing which we talk about right, the quality of engineer. Is if you look back on code which you produce six months back, and if you don't think about, what was I thinking? How could I, I write this code, why is this good so crap? Yeah. If you don't have that reaction every six months, then you haven't grown.

Sidu: And this is actually very common. Like this is not...

Nadiem: So going back and noticing how bad you are is a fundamental, it's kind of like going to space and looking at earth again. It's the moment of realization, oh, now I can see the growth.

Sidu: Yes. So we actually make this into the bootcamp in a very interesting way. Where we block one full day every week to work on an open ended problem that's completely unrelated to the rest of the course. It's just a plain vanilla programming problem and it's the same problem. And we make them repeat the same problem every Monday throughout the whole bootcamp. And we start on the first day of the bootcamp. So before we've taught you anything, you write the best code you can. And then we ask them to look back and we ask them a simple question, do you feel more impressed by what you've written personally now? And that's your metric for progress. It's completely subjective. It's completely internal, it's completely self evaluated. And we're like, look, this is what we'll give you. That feeling of progress, I encourage you to continue doing this once a week, every week for the next six months, even after the bootcamp's over, because that gives you that validation, that feeling that my effort is incredible amount of work in practice that I'm putting into this, means something.

Nadiem: So it's, it's, it's a powerful moment, especially for younger engineers that I, cause I, I've been to a few of these bootcamps and I've, I've talked to them and gotten their feedback though I'm not an engineer. I can see the excitement and the feedback about these programs. Part of me is a little bit sad that once they graduate, you know, they don't get to participate in these kinds of bootcamps anymore because they're just in the knee deep thick of things of work. And then you're in there what we call like the inferno, right. The grinder where you've got business heads putting crazy targets. Uh, and then the product teams and the engineers are you know, in the grinder trying to think through and solution the problems under extreme pressure, very little sleep. Like this is not all like, you know, like a utopian environment, you know? Once you're in, even the most high performing teams in GOJEK engineering have to deal with the harsh reality of time based pressure. Right? Um, so what have you learned for pressure? You guys have been through the worst, you've been there with no resource in the beginning together with me. You've been on calls where I've been flipping out at you yelling all kinds of profanities. Someone who has no idea what you do trying to tell you how to do your job, which was like our first year I guess. Right? I was like a de facto CTO of GOJEK which is the worst part of it all. But my point is what have you learnt about what makes or breaks teams under pressure in engineering specifically?

Niranjan: So there are multiple things, right? Uh, engineers who care about impact their solutions are creating, right? You don't code just for coding sake. You are writing code to create change in the real world. You're typing code to solve the real life problem and you are passionate about it. So knowing how your code is changing the world is very, very important. And that's one of the reasons whoever joins GOJEk, even today no matter which office where they're in Jakarta, Bangalore. Jakarta it's easier because you can see the product here. But if you're joining in Bangalore or Singapore, we essentially make sure that hey, you have to travel within first two months to go and see how it is changing lives of millions of people in Indonesia. And that's what keeps you going.

Sidu: So, so with, with a lot of engineers, if turns out that you don't need to push them, you just need to give them the rush when...

Nadiem: show them.

Sidu: Show them. The beauty of software is it's utilitarian art. I like to joke, right? Like when you create a piece of art, it's consequences in the real world are immediately visible. If you make that, that visible impact accessible to the creator, it creates this loop which makes the person utterly driven in a manner that no external force can.

Nadiem: Much more so than in financial incentives, much more so than anything.

Sidu: It's the drive of the maker.

Niranjan: So we have an apartment in Kemang Village, right? A year and a half back and any person who comes in to Jakarta, if one of us is here. We'd Essentially invite them home and there's a balcony, there was a balcony that overlooks the Jakarta skyline. You'll take them there and see. You see this entire area, every person, literally every person knows about what you do and that essentially she/he has a shock. And then you're willing to go through any and everything. Whether it is working 24 hours a day, seven days a week, it doesn't matter.

Sidu: In fact, the challenge that we have often is to reign that tendency in.

Nadiem: Why?

Sidu: Because what ends up happening is everyone, it gets so driven, the combination of business goals with this kick, this rush can lead to burnout because ultimately creating software and creating product is a creative process and it's asymmetric in that the value you create is not proportional to the time you put in is proportional to your state of mind in that time you put it. So if you've been working 80 hour weeks for three weeks, you're creative impact just crashes.

Nadiem: Of course. The physiology takes over.

Sidu: Yes. So we actually flag that and you know, if you look back on the last three years, the number of times that teams have actually worked weekends or late nights, and you compare that with other companies, you find that it's shockingly low and it's shockingly low because we actually consider that a sign of mismanagement. Temporary periods is perfectly okay. It happens. Maybe there's a critical problem, maybe there's a competitor's pressure, maybe this is the team going, getting super driven, but beyond a few days or weeks, we start to flag it and tried to rein that in. Because if the creativity goes down, it doesn't matter how many hours you work. The point of software is asymmetric impact. Very little goes in a lot comes out

Nadiem: And it's negative virility as well because at the end of the day, this is a human sport, human team sport. And when you see the guy sitting across from you, you know it's like, it's like a, like a Delta force, right? Or like a navy seals team. If you have a mission combined together and you can clearly see your teammate who's life you may depend on is obviously injured or weakened, burned out, frustrated, you are immediately questioning the viability of what your end product's going to be. And so I think that's what a lot of companies do very poorly is understanding that it's not, you know, I don't really like the term work life balance because processes, it's destroyed because of our life and our work. Is this the same thing but it's about brakes. It's about brakes, micro breaks and long breaks. All types of breaks are the essential ingredient to human creativity. Essentially.

Sidu: Well, I mean this reflects in our policy. Yes. This is why we uh, we have uh, uh, you know, on these teams we offer unlimited sick leave on trust. Yes. It's also why in most of our, most of our organization we allow people to take leave without approvals, right? The expectation is there is a certain sensible expectation. You will let people know sufficiently in advance. You've got a backup plan, but provided you've got those two things in place, you are best placed to judge whether you can take a leave or not, not an approver who doesn't have that context. Right? Right. Because at the end of the day, if when you're working, your heart, soul and mind are not completely in the game, it doesn't matter.

Nadiem: It doesn't matter. And I think that, you know, it really offends me sometimes when people criticize, um, uh, tech companies for having quite progressive and a flexible, uh, types of working arrangements. They think it's all, it's, it's, it's this some, some new age crap whereby people are just not working as hard as they used to back in the day. When actually the reason why tech companies kind of pioneer this different, flexible and balanced way of working is because tech companies were the first, because of product engineering realize that to harness creative power to harness innovation, you need balance. You need balance and you need a sense of psychological safety or call. Absolutely. Right. And that requires you to be at your best physical and mental self at all times and it really has very little to do with the amount of hours you put in and has everything to do with what you do with the hours that you are in that state of flow and that you were in full engagement model and there in lies the way of discovering and unleashing the 10x engineer. Cause you can have a 10x engineer in there and you might not ever know it cause you did not give them the sufficient bandwidth. The sufficient space with which to show their art.

Sidu: Yup.

Niranjan: Yup.

Nadiem: Thanks a lot guys. That was a great podcast. We should do another one on this again. Um, it is one of our core passions and we hope that some of these principles get extended to other departments, not just engineering. Um, uh, and, and we hope to have you guys on, on the podcast soon. Thanks a lot.

Sidu: Thank you so much.

Nadiem: Cool.

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.