 I can't really think of someone better than you who actually has gone through the journey of a company that's going through from 1x to 10x, 10x to 100, 100 to 1000 and kind of going through these different stages and see how things have scaled in different ways. So I want you to, so let me kind of just go down there. So for everyone, I think many of you already know Sidhu. Sidhu works as SVP Engineering for internal products in Gojek. He has been part of the Gojek journey from I think pretty beginning. So he started consulting with them as C42 Engineering and then soon C4 was acquired by Gojek to become Gojek India and since then he has been working with Gojek scaling them since then. I think would better hear from Sidhu directly. So Sidhu, could you please kind of start with kind of explaining like how was your journey, like how did you kind of get started in Gojek and then we go into more details. Yeah, awesome. Thanks so much for having me, Anand. Highest Geek team, always a pleasure. You know, let me give you a little bit of sort of an outline. I think what's probably relevant is there are two aspects to the growth journey to contextualize it, right? One is what was the overall the product scale that we ended up dealing with, the changes there. And the second I think is what were the personal changes that I ended up dealing with in terms of you know, how I saw myself and what my focus areas were. From a product standpoint, at the time we first started working on the Gojek business as consultants. I think Gojek was doing about 8,000 orders a day. And if you fast forward about two years, if my mom is taken in two years from there, Gojek was doing two plus million orders a day and had launched about 15 more products. So roughly speaking what we ended up dealing with as a team and you know, I'm definitely not implying that I had a significant contribution to this, right? There was a pretty scary team of really, really good people that made all of this happen. But as a person who had a front, you know, front row seat, what we ended up doing was we roughly launched one new substantial product every month on average. So you're talking about substantial products by which I mean, you know, you're talking about something like food or adding or launching taxi transport when you only have two wheeler transport. Substantial, like we had the urban company equivalent, right? We had Swiggy, we had PTM, we had, you know, all the Indian stalwarts in the O2R spaces. We launched one of those types of products more or less every month for almost 18 months. So 15 odd products across 18 months. We had three orders of magnitude of increase in the scale. That means the total transaction volumes jumped up almost 1000X. And we had to reduce downtime and issues by three orders of magnitude. So when we first started out, we were looking at four, four hours a day of downtime. By the time we reached two million transactions a day, we were probably looking at an hour, hour and a half a month. And that's still pretty bad, by the way. But eventually it went down two minutes, right? But that is kind of the overall scale. And in terms of valuation, the company went from having just raised series A to becoming a post-unicorn company in that exact same 18-24 month period. That was quite a rapid growth, I believe. I don't know if any other company had that kind of growth. Yeah, I think we were very uniquely positioned to do this, to experience this because one of the reasons we agreed to get acquired is because at that time in 2015, when we were doing this, we could not think of a single other such a fast-growing company in a developing country. Like all of the stories I heard were either from the Bay Area or were from China. There were literally zero other examples at the time. Even if you look at India, all the companies grew over six years, seven years. So for all of this to happen in just a year and a half was a very big learning opportunity for us. So what does it mean for tech? So there were a few things which came out of that, which I think are worth calling out, which became sort of operating tenets for us. We named them after the people who came up with them. One is Niranjan's Rule. Niranjan's Rule states that any system that is pre-MVP must be developed in such a way that you are always two weeks away from a ground up. The reason for this is we realized multiple times that you say that we are seeking MVP and therefore you pile on TechTech and that's the right thing to do. Pre-MVP, you should not care about TechTech because if the product doesn't have traction in the market, who cares what the quality of the code base is or what the TechTech is, it does not matter. But the flip side of this is the moment you hit traction, if you don't have the bandwidth, time and the processes to pay down that TechTech, you carry on trying to scale a completely messed up system. And like divert choices like that that we had to make which haunted us for four years after that. There are systems that literally we got stuck with, which we wanted to kill but we had to live with for four years because in the early days if we had taken that choice, we would have to freeze the world. Usually the reason why this Niranjan's Rule is important is because otherwise you wind up with a freeze the world type of situation. Hey, pause the business for one month, two months, while we go away rewrite this and come back. Possing the business is never an option, especially if you hit traction. So the Niranjan's Rule over there basically states that do your project management in such a way, do your scope management in such a way and delete features like as you're iterating on the MVP what ends up happening is a bunch of functionality you build which you no longer use, customers also no longer use. Keep removing that so that when you hit traction, you just say I need two weeks and in two weeks, boom, you clear the decks, rewrite the whole thing ground up, you have every artifact, you have your requirements, you have all those because really what is important is the discovery process. What are the learnings that led you to traction? So when you have all of those captured in a very, very thoughtful manner, typically no MVP product takes more, like you used to joke about this, right? Sure, it's a transport application with whatever millions of transactions a day, it's a four-page app. End of the day, the core workflows four screens. Now if your MVP honestly 99% of MVPs unless you're talking about a deep tech MVP, they all fall into this category of four screens. You should be able to rewrite it in two weeks, that's the engine's rule. Akash's rule is if it isn't already in production, don't depend on it, right? It is very easy to form dependency chain saying I'm building this which will but I don't want to build a scope X because that I don't want to duplicate scope that someone else is already solving for. No, no, duplicate like crazy, it's okay, right? It is much better to duplicate your implementations rather and then resolve those differences later than to say build a dependency chain because those dependency chains if one thing breaks, suddenly your delivery is now four months late. Yeah, I think one of the go rules is little duplication is better than little dependency. Yes, yes, that's a very nice way of putting it. So those are a couple of examples. I think the other key learnings were design and tune your entire hiring process to only hire people who like the job, right? Like don't hire people who don't like the job. I mean, it sounds silly, right? But I mean, how do you kind of, how do you kind of find it? I mean, the face of it, people would say like, yeah, they like the job, right? I mean, you had to kind of find for the hints. Yeah, it's interesting. I was literally having the exact same conversation just before this with somebody I know. I jokingly call it proof of work, right? Because the concept is the same. What you start designing your entire interview loop, not even your interview loop, for that matter, we even upstream from that, your marketing processes that generate your intake, top of funnel for candidates, everything is designed to ensure that you are orienting on people who can give you proof of work, whereby proof of work, I'm just stealing the phrase from crypto. But what I mean over here in this context is it needs to be something that is impossible or nearly impossible to forge without expending substantial amounts of time. So if at all they have forged it, they have forged it by putting in usually hundreds of hours of effort. And if somebody is going to put hundreds of hours of effort into forging that credential, then that's a very unlikely proposition. Like those are people who would have put hundreds of hours of effort into doing the job itself, and therefore they didn't have to forge it. So these would be, I'll give you a trivial example, that's a favorite. Most programmers would have like one or two languages that they genuinely prefer over everything else, for whatever reason, it doesn't matter. This is not an objective discussion saying that this language is better of us. You have a preference. Now tell me what are the technical problems and limitations with your language of preference? Every single legit programmer I know will have a length of complaints this long about their favorite language. They'll be able to tell you why it's their favorite language, then they will crib even longer about the shortcomings of their favorite language. It is very, very rare that you will find someone who has forged their interview process to a level where they will give you an in-depth nuanced, first they will explain to you why they love a language, in-depth nuanced, and then they will give you a critique of their beloved language, in-depth nuanced. Almost impossible to forge. That's good at first. Other things would be in terms of the actual work itself. I think the industry does a very bad job of looking at portfolio outside of design. I think when you're talking about people who are creators and pretty much every function, whether you're talking about data science or engineering or product managers or product managers or whatever, all of these people have a craft output which contributes to the work. The PM will have PRD templates which they treasure. They will tell you this is my favorite PRD template, but for these use cases I have these slight variations on them. Everyone has artifacts which contribute to their work. The engineer will tell you I have this particular style of designing readings. Now, these are not the direct like a PM ultimately has to move a metric. The engineer has to ship scalable systems, but when you look at the intermediate steps of the work that goes into achieving that outcome, there is a craft aspect. And if you orient or interview process on digging into the craft, those are again credentials which are very hard to forge. Like a PM can steal a PRD, but they cannot explain to you why they think this is the best PRD and what are the limitations of this PRD and this template of PRD in which context. If they've stolen, they'll be like, yeah, here is a great B2C PRD. Why? Very hard to explain unless you have iterated on that PRD over years. Or someone engineer will tell you I prefer, good old question, I prefer Emax. Now, it does not matter whether I prefer Emax or Wim or I think Emax is stupid or great. Like that's not the point. The point is someone who genuinely prefers Emax can explain why in a manner that is very hard to forge. You may disagree with it entirely. That's a different issue, but it's an unforgeable explanation. So that would be iterated a nutshell. Just keep looking for these things, these proof of work things and build it into your interview. Very interesting. Give people a take home coding problem. Keep it very simple. Make sure that it takes no more than an hour or two because what are you really checking for? There are two kinds of people in the world. When you're talking about hiring engineers, engineers who look at a coding problem and it starts and engineers who look at a coding problem and say, listen, I want to go send an email instead. I don't know why I got into this. You don't want to hire the second kind. Now, when you're dealing with the first kind, of course, you can't run a recruiting team that's like a blunt instrument. You have to be very nuanced because, okay, does the person have a baby at home? Do they actually have the time to do two hours of coding? They will want to do it, right? But is your process supportive of letting them find the two hours any time flexibly to be able to do it peacefully? You have to do those things. But when you are segregating, a person who genuinely enjoys coding is going to really struggle to turn down a request to code provided it is not operationally onerous, right? Don't give them a week-long problem. What are you trying to gauge for? You're not assessing the coding capability that they'll come into the office for an interview. You can assess that. What are you really looking for? Do these people like to code? You're just looking for the initial response, right? So these are the little tweaks that I think really, really, because I'm sure like you would kind of knock out like 90% of the requests that you probably get, I guess. So typically, by the way, this is a very important operational problem as you scale up because what ends up happening is if you're not running the right filters top of funnel, your delivery teams will come back to you and ask you this question, saying, listen, do you want me to ship the product or do interviews, right? Because if you're not tuning the top of funnel on interviews, it's very easy to start generating 40 hours of work for every engineer, every product manager, every week doing interviews. And they will come back to you and say, listen, you're getting me people who are extremely subpar, none of them are clearing the interview. I have production issues. So this initial filtration process to ensure that when you actually get your team to do interviews, you have high quality, highly aligned candidates is actually operationally crucial. Otherwise, your scaling gets bottlenecked on this, this, this, this issue. Cool. It's very insightful. So one thing that I want to kind of understand is actually, let's go into actually the nuances of actually, like how was Gojek like, where you kind of start to work with them? Okay. So what was the business process like? Okay, then what kind of software you had to write? And then what were the challenges? Sorry, what processes? And since I mean, like the joke, no processes. No, I mean, I think they were doing it through a phone line, right? When you kind of join? No, no, no, but it that was, we were already past that stage. What had happened was that around January 2015, Gojek had launched the digital product. And we got involved around, I think, April or May, because the moment the digital product was launched, growth became crazy. So if I remember the numbers right, the offline call center was running at 500 orders a day. The digital product went to 4000 orders per day in, I think, three months from lunch. And then started scaling very rapidly. So by the time we engaged, we were looking at around 8000 orders a day. So the, the, the, the product had been scaled from 0 to 8000 orders already. So, so what were the challenges when you kind of, when you started working, right? You had to rewrite the platform? So what were the kind of tech challenges that were there? So, see, what ended up happening? See, the original system that was doing this was a MVP type Java spring system. Okay. And it broke every spring convention. Right? There were underlying spring features that were trivial to use, that had been re-implemented. You had dead if ladders, like a page long of if ladders where 25% of the branches are never hit. Okay. Right? It was just slapped together. Like the point was it needed to run and it ran. Yeah. There was, nobody had designed that system thinking that, you know, this needs to run hundreds of thousands of orders. That's my point. Right? It was cheap best got the job done for 500,000 orders. The problem was that that system now was being forced to scale. Yeah. And what this meant is there was absolutely no production support kind of a process around it whatsoever. Like I remember honestly that the first jump from 8000 orders to like all sorts of things were like the, it was a Java system, you know, there was a very strong push to rewrite it and go in order to scale. But I remember that when the team landed there first, the first scaling unlock came because they went and looked and did profile the whole system and said there's an index missing. Yeah. Like you're running, you're not talking about doing PhD thesis level stuff to solve problems. Yeah. Like at the end of the day, the problem is there's a critical path, obvious issue that has been missed. Yeah. Right? Adding the Db index if I'm not mistaken, double the scale. Okay. Just think about it. No, like what is about a week's time to kind of think about the problem, right? And it is five minutes work. Yeah. Right. Where is the actual solution everyone is going towards is less redirect the whole thing in Golang. Yeah. Right. This is because we are dealing with four hour downtime is Java is not scaling. Like, yeah, somewhere there was a Db. And all you realize is step by step by step, there is one after the other the equivalent of the Db index being missing. Yeah. Right. I think one crucial step that Niranjan took in between was this and this is a monolith. Yeah. Right. And our push towards microservices came out of a very pragmatic situation in that the original monolith was unusable from a iterative development perspective, building on top of it was not an option because it would have been very, very dangerous. There were no tests, there was no automation, no page or duty, no metrics, no nothing. Yeah. Right. So the only solution there was to start carving pieces of that system or that system is called Stanmarsh, the original system. Okay. And to this day, you will find in every Gojek office, there's one room called Stanmarsh because people have spent so many nights and days and weekends logging because of Stanmarsh. Right. So in a way, you could say that it became almost a four year journey of piece by piece, cutting things out of Stanmarsh and moving them into standalone systems. But that's something that was kind of built over a couple of months, right? I mean, it's not something, it's a big system. That's why Nirenjan's rule and Akash's rule are so important. Yeah. Because if your business is genuinely scaling. Yeah. And sustainably scaling, something that's built in two months will take four years to remove. That's literally, it just goes everywhere, right? Someone will put a dependency on it, then if I'm not mistaken, by the way, Stanmarsh is still running somewhere supporting some of the smaller products, somewhere it is still like, we have never been able to kill Stanmarsh. Because it's just sitting there running somewhere, somebody will have a dependency on it. So what did you end up doing, right? I mean, so how long, so you said like you kind of carved into microservices, okay. So I think the first one was what we call the allocation service, if I remember right, which the tactical problem we were facing was we were dealing with the four hour downtimes every day. So Gojek was seeing these two peaks. So morning rush and evening rush. Okay. And the peak is a substantial jump over. And the servers were melting. And the choke point was the allocation algorithm, which was matchmaking the driver and the customer. So Niranjan, Sumit, a couple of other of my colleagues who were on the ground in Jakarta at that time. I remember they took a decision saying, listen, we can't during the day, what you're doing is morning rush, evening rush, you're basically just gloat looking at the graph, getting ready to step in and reboot machines or do whatever if you should see any signs. So they were not getting time to actually code. So they said, okay, now we don't usually do this, but now we're going to pull like go hardcore on this, we're going to war is everyone up for a three day binge. And these guys just slept on the couch in the office and worked at night and extracted and rewrote the entire allocation component of Stan Marsh into a standalone Golang microservice and delegated out to it. And that took them three days off like proper wartime hack. And that mitigated a lot of the immediate burning issues. Then step by step, like this piece after piece, piece after piece, we just started pulling out. And all of all of the thought process, I must be forthright in that phase, right, was much more driven by pragmatic scaling issues rather than upfront design. Okay, where is the bottleneck shifting right now? Which part of the existing system is not able to handle load? Okay, carve that out, move it out. Then we reached a place where the overall, all of this was synchronous HTTP, right, pragmatic choices, no complex architecture. We didn't even have circuit breakers in those days. When we started introducing circuit breakers, we were all synchronous, then we realized the whole synchronous API calls themselves are the source of bottleneck. So then we started a big push to, by this time, you're probably post a million transactions a day, where you start a big push to move everything from synchronous to async on top of event pipelines, which basically shifted to Kafka. So when, so I want to kind of understand, like, I think it's 15, I think even Docker under these things were kind of pretty, I don't know if it was there or not. It was there, but it was very early. It was not, yeah, everything was on VMs for us. So I mean, you used to kind of run each Microsoft is a different VM, is it? Yes. And was it? Chef, okay, cool. And that also, that stack also has seen a substantial evolution over the years, right? Again, it's not my core area of expertise, but I think that entire stack has completely changed now over five years. In fact, for a lot of the systems, we've now reached a place where on the Gojek side, not the GoPay side, these tend to be two ecosystems because of regulatory reasons, right? Because the payments thing has to be isolated from everything that's on the Gojek side, which is a transport food, et cetera. Now we have a infrastructure platform team called Colonel. And increasingly, most of that layer is abstracted away. Okay. Like you no longer have to deal with any of this stuff directly yourself if you're going to put out. I think I want to come back to that, but I'll come out later because like, I want to touch upon like, what's the right time to kind of do this kind of changes, dog structures, okay? But let's kind of go on, cut to the thread that we're kind of discussing now, right? I mean, you started with carving out the existing system into small microservices to scale up, okay? So I want to understand the timelines there, right? I mean, so you started when you were having about 8000 to 16000 orders per day. Yeah. I think we started, if I'm not mistaken, the first microservice was extracted at, I think over 50k a day. Okay. And that itself, the exact number that I don't remember, one of Niranjan probably would remember those numbers more accurately. But if I remember right, the first microservice extracted at 50k per day. And then the second must have been at 200k. And then it became a steady sort of stream of, okay, pull this out, pull this out. So was it always been like you would change the bottlenecks and then? Yeah, see, the thing is, if you look at this from an India market perspective, right, you will almost never see anybody that has gone through this process. For us, nothing was driven primarily by us in the sense of us planning. Yeah. We were in reactive mode for two years. Okay. And everything that was done was a reaction to literally every, so you have the morning peak, evening peak and your Friday rush. Friday, without fail, every week, Friday, the overall volumes will jump 10%. Right? What is your typical half-life of any subsystem you build is six months. If it is a core system, it's three months. Because you're looking at an order of magnitude of scaling happening week on week cumulatively within three months. And you can't design systems to, like, how much scale are you? You can't sit today and say, I'll be building a system which was scale 100x in six months. So it was just this never-ending process of reactivity, which you will not typically run into in comments. So that kind of brings into this interesting question, right? I mean, I'm sure like when you were running C42 and working with other clients, the way you design systems, I mean, you would actually sit and brainstorm and actually have iterations and then agile processes, what not, okay? That was cute. It was very cute in hindsight. You're like, oh, I have this like, this, like the way I think about it is it has this small town charm, right? Yeah. The way we used to operate before. Yeah. Very, none of that has survived contact with scale. The core principles remain, but now there is a very, very heavy reinforcement of pragmatism and operations. These are the two things that come in. I think at a smaller scale that we used to deal with before, you never dealt with what it is to operationalize something when there's a lot of scale, either at the code level or the people level. When you're dealing with five member teams, 10 member teams, a few thousand transactions, a half a dozen servers, you just don't deal with the operational overhead. The operational overhead is brutal. So there is that very clear shift in thinking now that, okay, if there is a problem, what is the operational approach to this? Like if you look at how I write a document now, every document comes with a philosophical component and an operations manual, right? Because here's the philosophy, here's the theory. Here is operationally what you need to do, step one, step two, step three. Without the two, it's like I'm wasting my time, I'm wasting your time. So now operations has just become like this core pillar of everything. Yeah. So when you can say that, I mean, I think some of that comes because you've gone through that scale, the hyperscale going to like one to thousand, okay. Now, it may not be convenient for someone who's kind of an early startup, okay, or just about this scale or seeing a somewhat attraction. So how would you, so what would you recommend for someone, let's say starting, start up kind of building product, it's kind of just found a product market fit now, okay. So now you said that you needed Gojek in a particular way because, because the scale is basically driving everything, you're not in the driver's seat, right? You're always reacting. You're always reacting, okay. No, let's say if you're, if Gojek was not, the scale was not driving it, okay. Would you have done things differently? Very differently. Would, and do you think it would be a better way to do that? No, no. Because the thing is, okay, there's a nuanced answer to that, right? Because one of the things that comes with being reactive rather than proactive is your pylon debt, right? So if you pylon technical debt, you pylon organizational debt both, right? So you do have to be thoughtful about that. But I think one very crystal clear difference from before to after is, you know, before we had Yagney as a principle, you aren't going to need it, like don't build it if you don't need it, right? But you don't really understand it until you have to live with something you have built at scale. Now, there is a very relentless thing saying, do we really need to do this? Do we really need this? What is this? Why is this? Good idea. Why, why do we have to do? Basically, you just become relentless about saying, look, waste is waste. Let's not do something that's waste. We have enough other problems in life. So my point is like, let's see, if you have to advise a startup, a spawned product market fit, and they haven't seen the scale, okay. I'm sure like, they may actually do the small town approach that you said, right? It will have planned weekly iterations and actually design for scale and all of that. So what do you, I mean, what do you advise? I think the weekly iterations and all of that are actually probably the most powerful lever that you can retain. But planning for scale is, I think, unnecessary if you do your engineering approach correctly, iteratively, look, the way you want to structure yourself is to be efficient at reaction. Most people try to do planning. The truth is, if you look at, I mean, basic complexity theory, right? If you're dealing with a complex system planning, your planning horizon is extremely short. And if you look at a startup, you have three very obvious complex systems interacting, which is the market, your market dynamics are a complex system and hard to meaningfully project on your software, the actual code base itself is a complex system and hard to meaningfully, which is why it's so hard to estimate scope timelines, all those things, right? And third, the moment your headcount crosses more than 50 or 60 people, your organization itself is a third complex system, which is hard to, now you are sitting at the intersection of these three complex systems, right? So if you think you're going to do planning, then you're already done for what you want to do is to design a process or methodology and approach, which is fantastic at reacting efficiently. Interesting. So you want to build for a very high level of reactivity and you want to minimize your planning on any complex system. I'm not saying don't plan on the not like, I'm not saying don't have a strategy plan. But when you're talking about any of these things, you want to be super effective at reacting, nothing else. So there's a question from audience. Deep Narayan Tiwari has this question. What's your thoughts on any scaleability as a major requirements? Then which language is the better choice for implementation? I don't think it matters. I think if you're talking about scale at maybe a Google level, I suppose it would be a consideration. But if you're talking about a scale at pretty much any Indian Unicorn level, as long as you're not going and using something that is inherently like you're not going to go pick up Ruby from 15 years ago, right, which was inherently a broken runtime, I don't think the language matters. You can scale anything. I suppose your infra budgets would matter. Because if you're looking at cost of infra, some languages will consume more infra by, you know, 5x than other languages would. But you should be picking the language based on fitness of task. My rule of thumb for this is, if I'm doing domain rich, complex business implementations, then I prefer a language, high level language with a lot of abstractions. So my preference would be like my colleagues, like my personal preference is a little limited because I'm no longer anything like a hands-on dev. So my programming language arsenal has frozen about seven, eight years ago. But if you look at what Gojek would do today, the language of choice would either be Clojure or secondaryly it would be Ruby for complex business domain. If you're talking about very, very light domain, that means the rules are not complex, but you're talking about substantial throughput, then the preference would be for Golang. But I would not, I have not seen many people try to build complex business domains in Golang because Golang's abstractions are not very, it's not a very high level language, right. So really what you're looking for is fitness for task. I think any language skills. Having said that, of course, I think that practically managing a JavaScript or a TypeScript code base in production is non-trivial. Like I think that the one thing that I've observed is unless you really, really understand what you're doing and the, like if you're in a situation where you are picking Node.js as your runtime because everybody knows Node.js, that's probably a bad way to make the decision. Let me put it that way. There are very specific situations where a JavaScript base back in runtime is appropriate because we all know Node.js and like JavaScript is not the way to do it. That's the only exception I will flag for this rule because Node.js deployed in this way has become the PHP of this era, right, like how PHP used to be for us 15 years back. Just about that PHP to it. Great language, great runtime, but should be deployed if you know what you're doing, not because you only know that. Yeah, I mean, but I think it's probably I kind of shared similar concerns about it. But so one reason why I try to stay away because I mean, personal preference really is I find it's too difficult to kind of the ecosystem, you have to install so many libraries to just do simple tasks. It just puts me off, but not really about scaling, but yeah. No, the thing is I have reached a place now where I'm like, okay, listen, whatever shit the runtime asked me to shovel, I will shovel. Like my perspective is like, okay, take a deep breath, whichever language runtime you pick, there'll be some nonsense there, right. But that nonsense has to be embraced for a good reason, whatever that nonsense may be. Just look at some more questions. So at what point, so Satish has a question, at what point does the operational cost say hardware start mattering? For example, at what point you say, let us stop silent scaling issues by throwing hardware and start thinking how best can you place hardware resources. So the actual answer to this question is tangential, right? And this is one of those changes which has happened to me. This falls into another before after category of questions, right? Yeah, when I before I never thought about a budget. Yeah. Now I started the question, the budget, what's the budget? When do you need to manage your infra is not a fun, is not an absolute checkpoint? It is, it's the answer is when does it, when it starts of materially affecting your budget is when you start managing your infra cost, right? If you have a thousand dollar budget, then when you used up 20, 30% of it, you materially manage it. If you have a 10,000 dollar budget, there is no answer which is absolute. It is a function of what your budget is. How is the budget going to grow? And what are the factors that influence the budget from a engineering operations standpoint or a product operations standpoint? Yeah. If you're looking at understanding how to scale, start with, remember that your mind has to shift on two axes. One, ask about what it takes to operationalize something in terms of processes and overhead. Second, ask what is the budget? Solve a budget first. Yeah, that's interesting. I mean, I think we engineers tend to kind of see only the technical set of challenge, how do I scale, which language to pick, which I think it's more important thing is basically like see somebody said this in a very simple and succinct way, though he was talking about it in a larger context, right? I'm cherry picking for this thing. Yeah. He was like, the difference when you become a vice president, he was generalizing it across the board. But this I think especially true is, you know, when you become a VP of engineering, in fact, forget whether you have the title or not, when your budget is your number one consideration. The day this question is constantly in your mind, what is my budget? What is left in my budget? Where is my next budget coming from? You have reached a situation where you're thinking about the problems that a VP thinks about. That's great. There's some more questions. Let me see if we can take any one of them. Aditya Shinde has a question. What about Felt.js? I'm afraid I don't have any hands-on experience. Yeah, but can you let me kind of add to that? And I don't think tech and what language you're using really matters that much. I think it's one level above that, I believe, right? I mean, it shouldn't really, when we tech people kind of give too much importance to actually the actual tech, okay, what you can scale with Go, you may scale with Python by actually throwing 2x hardware. But if your budget permits that, you can probably differ the nation of worrying about that by an year. I mean, basically, if you're owning a budget, then you will realize that your payroll budget far exceeds your infra budget until you are at substantial scale. So the moment you're looking at your budget holistically, you are more interested in developer productivity and developer cost than hardware cost. There is a scale at which that inverts, but that scale is quite substantial. And doesn't it work? It equalizes. Just looking for questions. Okay. I think I'll take some more. So now I want to kind of switch gears and kind of look at, get back to your journey again. So you can start it with scaling the tech and all that, right? But at some point, you've kind of grown, right? I mean, so I'm sure like you were thinking would have been evolved throughout the process, okay, and would have kind of taken different ways to kind of scale rather than kind of doing everything yourself, work with the teams and all that. So how was the process been? And what are the some of the insights that you kind of gained in the process? Yeah, let me put it this way. If five years ago me met current me, we would have some very violent disagreements, right? Like five years ago, me would say that, oh, you are a bureaucratic, you know, idiot who does not value genuine work and, you know, you no longer are hands-on and how could you, you know, how dare you, you know, think that, you know, things like operations and all that other core and what is this organization, organization stuff you go on talking about shut up and write code, right? So I can definitely say that philosophically, five years ago me and present me are dramatically different people. And I think the key differences over there are one is a certain pragmatism that has come out that says that at the end of the day, getting anything done requires money, people and agreement, right? And all problems of getting things done can be abstracted out to these three broad categories. Do you have money? Do you have people with the requisite skill sets and commitment? And do you have the power to get everyone to agree on what to do? Alignment, right? Alignment is the polite way of putting it, but the more blunt way of putting it is power, right? So power, money, people, everything abstracts up to these three. If you have a fundamental weakness in any of these three buckets, your overall ability to get anything done is gone. Doesn't matter how beautiful the code is. Most dramatic shift in my perspective. Now, my top line reasoning on any problem starts with these three things, right? I think that's probably the single most crucial difference. I think at a smaller level, somewhere along the way, I finally accepted that I'm not an engineer, I'm a manager. I think I had to, when I started realizing that I'm going through the psychological, honestly, I think people outside of engineering don't appreciate how difficult it is, that when your entire identity, self-esteem and self-worth come from your image as being an engineer who can create code, moving away from that self-image and that position is enormously destabilizing emotionally. I think people don't realize how far it goes. Like it is borderline a mental health issue. You start questioning your self-worth, you start questioning your contribution, you feel useless. It is crippling. And somewhere I realized that I was going through this and eventually I had to accelerate the transition and acceptance by literally, Anand was telling you earlier, right? I reached a point where, you know, when I started doing my introductions and slides and talks, and I don't mean this in some fancy way or something. I would just put this thing saying, you know, in my introduction, I'm a manager at project and my audience never knew how much pain it was for me to put that on a slide and then put that slide up on a wall, on a screen in front of hundreds of people. I mean, I remember your keynote at PyCon India. So I think at a personal level, that was a big change where I went through this internal acceptance that the sad truth is now I'm not an engineer, I'm a manager, which means I'm a bad engineer. I'm a bad engineer. Oh my God, because you can't be a good engineer if you're not hands-on and constantly in the profession, right? So I think the interesting point here is now, I mean, you have to wear different hats, the different parts of your journey, okay? So when did that happen and why you think it's important? I mean, I think it's important to kind of... See, I think at a philosophical level, there are two ways of reasoning about personal growth, right? And I think a lot of it starts with the question of what is growth? Because I teach every single grad higher in Gojek has gone through me, right? I teach the onboarding bootcamp for all the grads, I think, except for the last year or so, every single batch has gone through me personally. And the thing with grads, especially this question is very common because they are still early in the career and everything is about growth. Of course, that remains true across the board, but the conversation becomes more nuanced. And which is why I like to ask in the question, what is growth? And if you look into it, in interviews, everywhere people will tell you, I'm changing my job for growth opportunity. What does growth mean? And there is no good answer to this that I have found, that is universally applicable. And the closest I have come to is a very simple one, which is growth is the ability to consistently make happen what you said you would make happen. When you're a junior dev, what you're committing to is to taking a requirement and shipping stable production code based on that requirement. How often are you able to fulfill that commitment? What is your consistency on that, that is growth? As a CEO, you say that I'm going to review increased revenue this year by 10%. How often are you able to keep those? So in a way, it is saying that I envision a future reality, which is different from the present reality, which I am going to create. Your ability to make that future reality come true again and again and again consistently is growth. Now, if you look at growth through that lens, the question simply becomes one of saying, how do you reason about growth? Are you thinking about growth by thinking about somebody becoming somebody? Or are you thinking about growth in terms of doing something? I think both are equally legitimate. But I think people confuse the two because they produce dramatically different results. It is very important to be clear about, are you aiming to be somebody? Are you aiming to be a CEO? Are you aiming to be an engineering manager? Are you aiming to become the next Bill Gates? Because these are all people that you want to become. Or are you saying that I'm going to reduce dependency on fossil fuel by 10%? Or are you saying that I'm going to ensure that the failure rate of loan repayments in this sector of the industry is going to be changed by this to this? Because that is doing something. Your approach on becoming somebody and doing something are dramatically different. And the results and the impact and the personal experience you will go through are dramatically different on both parts. Don't mix them. Be very conscious. Is your growth strategy becoming somebody or is your growth strategy doing something? And if you'll bear with me for just one more moment, there's a reason why this differentiation exists. The reason this differentiation exists is because if you say I'm going to do something, then you have to be willing to become whoever you need to be to do that something. The reason I gave this long story is the reason I'm okay with becoming a manager is because I want to do something. And in order to do something, and I never looked at it that way, but over my career, I've done something different every 18 months. I've done sales, I've done marketing, I've done cold calls. I've roamed in the hot sun being rejected by VPs of engineering in many different startups as I went there to sell. I've cleaned the toilet. I've opened the office. I have written code. I've written requirements. I've done project management. I've done product management. I've done evangelism. I've done recruiting. I have done all of these professionally, not even casually. My actual title is head of recruiting for tech global. I have actually handled global recruiting for tech for coaching. And one thing I've realized in all of these is that the reason I went through these and I never thought about it at that time is because I wanted to do something. I will be whoever I need to be to do what I want to do. This is the framing. If you want to do something, you have to be willing to be whoever you need to be to do what you want to do. That's how the acceptance came from. So some of the insights that I get from speaking to you is about the organizational structure. When the organization grows, when you want to scale the tech, when you can't really do it as a person, you have to do it as a team. And the way that happens, you have some insights about, you mentioned some things about how our structure is very important in actually achieving those outcomes. I think it's important. It's nice if you can actually speak about that. Yeah. So we discovered something called Conway's Law the Hardware. What most people don't tell you when you get into this whole scaling business is that your architecture, your overall system architecture is tightly coupled with your org structure. And your org structure is tightly coupled with your architecture. And there's a feedback loop between the two. If you have a front-end team and back-end team, this will dramatically impact your architecture in the long term. If you instead run a full-stack team, this will dramatically shift your architecture in the long term. If you draw a boundary saying that, for example, in a marketplace-type problem, if you say you have a demand team and a supply team, that will dramatically change your architecture. From an architectural standpoint, if the engineers decide to design the marketplace product as a demand side and a supply side, and the org structure has not changed to match, you will have major issues. You cannot treat architecture and org structure as two separate problems, one handled by HR, one handled by engineering. Whoever is making the overall product roadmap and product decisions needs to directly drive architectural changes through engineering and directly drive org structure through HR and product management and make sure that both of these are going in lockstep. Otherwise, Conveys Law will completely ruin your life. I mean, the TLDR summary there is org structure and architecture are the same thing. They are two sides of the same coin. Do not ever make the mistake of thinking of them as disconnected. So a lot of questions. So I'll go over the questions now. So Sagar Majore has this question. How do tackle technical debt with ongoing features at scale? So this is one of those questions. It is a very good question. It is one of the questions that has no answer. Because if you had a universal answer to this question, I would be somebody who is enormously wealthy and sitting on an island somewhere. There is no good answer to this question. In fact, if you want to judge the capability of a CTO and a team, the real test of that organization isn't how they answer this question. There is no one answer to this. Isn't wave engines rule is an answer to this question? That is one answer. But if you go to a different ecosystem, let's say you go to a deep tech situation, like let's say your product is a database, it's arguable that Nirenjan's rule would not be a good fit. My point is it's highly contextual. You can make certain generalizations. But the real trap is the point at which the generalizations fail and the specifics of your situation manifest and how the team handles those specifics is where that's the whole game. That is why these skill sets are rare and hard to find because there is no universal answer to this question. Zumot has this question. Should I outsource or build MVP myself for a startup idea? It depends on where you are. If you are pre-traction, you should ideally not be building software at all. Again, exceptions exist. For example, if you're building a database and of course you're building software. But two important rules of thumb, one is typically you should be using software to scale a manual process that already works. If you don't have a manual process that already works, don't write software. Use Google Sheets, docs, whatever, run a manual process. Make money. Get money flowing through the system. Once you have money flowing through the system, you figure out how to scale it with software. And second is remember that every line of code that you write that isn't making you money is a inventory that you're carrying that is a liability. So if writing code is a very expensive way to solve a very cheap problem, make sure that that cost investment is justified. And it does not matter whether you outsource it or do it yourself. The answer to that question is what is your budget? Swannan has an interesting comment. I had this elegant comparison recently. That is same as any debt. Make sure you at least pay down the interest otherwise compounding is going to kill you. Yeah, for sure, man. For sure. Without a doubt. So what are any horror stories that you went through where you can do this? I told you, let's stand much live for like two, three month developed system, survive for four years. Some of the best engineers in the country are doing their best to kill that system and they're not able to kill it. It's the nature of tech debt. Like our founder used to say he was like, there would be an outage and he would be like, you guys better not tell me this is Stan Marsh again. It's been two years. And our response would be like, Nadeem, I'll tell you what, why don't you take a month off, shut Gojek down, tell people to go away and not make any orders for a month and we'll fix the Stan Marsh problem. So there's another question. At what point you felt that the words of design architecture dealing with higher problems become more than hands on programming and how is it different? The answer to this question is, do you want to be somebody or do you want to do something? For me, the answer was I wanted to do something. So I basically, like I have spent the last six months doing hands on coding on a crowd rails, architecturally, etc. There's nothing significant going on there, at least like given the number of projects I've been on. For me, it's just a question of I will do whatever is necessary to achieve the objective professionally in terms of the work I do. So for me, this question is hard to answer because my mind does not work that right. If what is necessary to achieve my objective is architecture, I will figure out how to do it adequately. If what is necessary to achieve my objective is to sit down and write, you know, just do hands on like dev at a basic level, like at a level which most, you know, 15 year, 18 year engineers would consider boring. I wouldn't find it boring, like I would do it. So I don't have a good way to answer this question. It's a good question. Don't get me wrong. The question is not a bad question. It's just that the way I approach this problem is very different. Let me go back. So how do you manage your own personal learning? What resources you tell someone to learn tech architecture? I think there are just the same old two answers. I don't think I have anything new to contribute here. Surround yourself with people who study. And study yourself. Like don't confuse. Okay, I'll give you my pity one liner for this, which which I always use for this kind of a question, right? Everybody wants to learn, nobody wants to study. So surround yourself with people who like to study and study yourself. That's it. No deep answer there. So any books that you recommend? This is a question from Adesh Shai. But I'm sure like many other people would also like. So I mean, I have a very, without without a specific context, my recommendation list is quite large. What I would suggest is that you Google for Gojek Essential Reading List. There's a blog post that I've put out there with a fairly diverse set of reading across functions. And, you know, hopefully the books there will be helpful. But if you're looking at something very specific, then it's highly situational. So I don't have like, oh, just you must always read book X, no such thing. So Sagar Majira has an interesting question. Siddhu, what are the books from an engineering perspective change your life? Sure, I can, I can remember the ones which dramatically shifted how I look, look at things, right? I think the first and foremost was the pragmatic programmer. Like these are all books where at some point or multiple points in the book, I was just like mind blown and my entire perspective shifted, right? Pragmatic programmer was arguably top of that list. Structure interpretation of computer programs essential, right? Like completely changes the way you look at, look at everything. Refactoring, Martin's refactoring, like suddenly I realized that all of this code which I thought was like really neat and cool was actually that I was writing, right? Like what I thought was obvious, best, you know, obviously nice ways to write code were demonstrated to me to be obviously bad ways to write code, right? Like dramatic shift. I think there are a couple of papers which this is a more nuanced topic specifically for people who are into approaching problems with TDD, writing code with TDD, which is there is this humorous blog post called The Way of Testivius, right? It's a humorous post. Again, all of this is linked in the Gojek essential reading list. So if you just go to that blog post, you'll find all of these. That again, you know, you keep swinging between being an extremist to being a relaxed attitude on certain approaches, right? So when it comes to unit testing, I've swung from being a Nazi to being relaxed to being a Nazi again over time. And Testivius was a very funny, simple blog post that helped me find a balance. So I like to recommend that. I think No Silver Bullet is an essential paper to read, right? And that dramatically changed a lot of perspectives out of the tar pit. Again, was a fantastic paper. Again, a must read. I think off the top of my head, these are the books which, from an engineering perspective, dramatically changed how I looked at the books and papers. So there are a lot of other interesting questions. I think some of them are not really scaling, but I think they're quite interesting in sense. So kind of going into philosophy now, I guess. So what are your first principles at work and life? This is by Satya. Sure. My first principle in work and life is I need to know what I want. Figuring out my volition is my hardest problem. Once I've sort of reached some fuzzy idea of what I want, and I'm very accepting of that being irrational, right? I don't need it to be rational, is what am I willing to give up for it? This basically is the core balancing act in terms of my high-level decision making. What is it that I want and what am I willing to give up for it? And this could be in terms of how my verb changes. Like, am I willing to do something which is going to require me to do 10 cold calls a day? Just to give you a dramatically different, last six months I've been sitting and writing Rails code. Do I want to do something the next six months I'm going to be cold calling customers for six hours a day? Yes or no? Right? As a very simple example. But yeah, that would be it in a nutshell. So Gopal has this question. These are some interesting challenges. If your work doesn't offer this to you, can you please give some tips on how an individual can practice them? If your work doesn't offer this to you, change your work. See, I'll give you a more generalized statement, right? Don't try to create a sandbox. Everybody always tries to create a sandbox. Don't try to create a sandbox where you will get the experience you want. Always try to make the reality match the situation where you get the experiences that you want. It's not the easy answer to the question, but it is the correct answer to the question. If the work doesn't give you what you need, change the work. Don't try to create a sandbox where you will get what you want. Quite interesting questions. I think Krishna's actually coming in. Let me kind of, I think we are 730. So do we have like I always leave a buffer for these sessions. So I think we'll kind of go over some of the questions for some more time. Everyone, if you have any more questions, please put in the chat window. I'll answer them. So you have taken different roles at Gojek, which has been the most challenging role and what are you going to expect when you join Gojek now? I think for me, all of the roles where I had a hands-on engineering delivery component got very hard because one of the problems with the way my life has progressed is by the early 2010s, it became increasingly obvious that I was moving into solving all the sales marketing business side of things. Automatically that meant the amount of hands-on dev work that I did kept dropping. So for me, it always became very hard when I had to get deep into hands-on engineering at scale because I was very rusty. So it was very, very difficult. Not that don't get me wrong, not that I didn't do it or not that I did not figure out how to do the work. But to be bad at something that at a deep level, you believe is your core competence is a very difficult situation to push yourself through. And that's why. It's very difficult to sit around people who are half your experience, but are better engineers than you. When you truly believe deep down that you are an engineer. So I think those are all the more difficult parts of my time at Gojek. I guess as an engineer, we're kind of trying to see very limited way of how to build things like writing code, but I think it's a bigger picture. So once you can look at a bigger picture, then you're still engineering what in a different way. I mean, the way I sort of salve my conscience is I say that look, the definition of engineering is reality engineering. An engineer is somebody who takes and non-engineers please don't mind that this is my engineering background hubris speaking here. But pretty much the definition of engineering is that is the profession where people engineer reality. Everybody else is often solipsism. Finance makes our budgets, balances books, but when does it actually reconcile to reality? Somewhere through engineering. Right? Product management, design, everybody end of the day, the people who touch reality, that job, that is engineering. Now your actual job title may say sales, your actual job title may say XYZ, but if what you are doing manipulates reality, physical reality, then you're an engineer. This is how I think about it. And so if you ask me like what's the best scalable program that I've seen, I would say it's HTTP. That's protocol. It's not a program really. It's not a code. But that's the most ever scalable system I've seen on this planet. So in that sense, like, but that's not a program. It's not a program. I mean, you can still call it. But it physically affects reality. Reality is dramatically different because of it. Human beings built it and consequently changed reality at scale. That's engineering. But it's actually a system designed for scale, but it's not built as with writing code in a program language. But it's an analog. It's an analog that has the exact same effect, right? Yeah. So there are more questions. So Satish has an interesting question. How do you make optional concerns like metric observability into software development process? I'm not sure I'm going to, I have understood the question correctly. So my answer might be off. Okay. So bear with me here. Assuming that you already have the instrumentation in place that the numbers are coming out, right? The first problem always is that I have found that for most teams, getting the numbers out takes more effort than actually doing anything with the numbers. So I think the first important thing here is to make sure that your systems are instrumented in a way that generating the numbers doesn't take you days, hours, days or a week. It should be on a dashboard, right? Now, assuming that you're already in that situation, it's extremely important to ask yourself who makes what decisions at what cadence on those numbers, right? And which of those numbers need an evented response? These are your two buckets of assessment. So for example, the second one is very straightforward, page or UT, right? Like your disk users crosses a threshold or your memory users crosses a threshold. Someone needs to get a phone call so they can address it. That's a very straightforward use case. But I think the more subtle one that is more powerful is you ask yourself, if I'm looking at, for example, exception count, how many exceptions are being logged, right? Who makes a decision based on that number? And at what frequency do they need to look at that number to make that decision? So based on this, the way I organize this is my, there are certain metrics that I will review with my team every day at standard. There are certain metrics that I will review with my team every week. There are certain metrics that I will review with my team every month and there are certain metrics I will review every quarter. And then there are other metrics which are event based like pages, where if it happens, the systems will call us. So you, my philosophy is if you hire good people, those good people, if you give them the right numbers to look at will drive all the decision making. You don't have to make any decisions. As a manager, your job is to say, what numbers am I putting in front of my team at what frequency, right? That is the decision you need to make. So Krishna has an interesting question. If at any time, did you compare the cost of redesigning for scale versus designing for scale from day one? Yes. If yes, was it justified? Designing for scale from day one is a waste of time and money, right? Basically, it's a fantasy. It's an exercise in fantasy. Always be reactive. Your point is to make reaction cost effective. And there are, I mean, most software engineering strategy is this, right? Like, I'm not talking that there's some exotic thing here. Pick up any good software engineering textbook. The whole thing about software engineering is effective reaction. I think you don't know what you're doing, right? I mean, that's a basic You cannot predict the future. What you have to be very clear is what your planning horizon is. Depending like Gojeka planning horizon was two weeks, because honestly, like the system, the scale, everything would change in two weeks. But even in a relatively slow growing system, your planning horizon is in more than six months. So if you're operating and making decisions, pretending your planning horizon is longer than six months, then you're setting yourself up for failure. Honestly, beyond a certain point, it just becomes an exercise in creative thinking, right? When you start designing systems for scale larger than what you have, which is an interesting thing to do on the side, but please don't do it on a production system. It's not worth it. Yeah. So there are some more low level questions about like renewals of Kubernetes and the TDD, etc. I think I'll leave them for now because we're running short of time. Sorry. I'll give you my quick answers. I'll give you my quick answers as a non practitioner, right? Yeah. Kubernetes matters if you're seriously operating at scale and you need the flexibility. Otherwise, the situation is, and this is all second hand, right? So I could be wrong about this. But the situation is still evolving so rapidly that if you already have a system running on VMs, it's probably not work, and you're not at massive scale. It's probably not worth making the investment right now, purely from a cost standpoint, right? Your cost benefit isn't there. And for TDD, see, there are two kinds of engineers. If you're not doing TDD, you're the kind of engineer who's a brilliant thinker, like super brilliant thinker. You are able to run all the code, write the code in such a way that every bug, every edge case, everything is in your mind, right? Remember, TDD is not a testing solution. TDD is literally the way in which computers do page management, right? Because memory runs out. TDD is the same thing for the program but the TDD process says, load this piece of code into your mind and you can ignore everything else, right? So either you're the kind of programmer who can load most of the code base into your mind and run it and manage all of the ramifications. Or if you're like me, if you're an average programmer, please do TDD. So I mean, I have a slightly different take on that. So one thing that we tend to do is like we kind of take a process and try to stick to the process without giving a thought to it. And that becomes your way of doing things, whether or not that's the right thing. So like what you said, it's a buffer that you're writing your thoughts on a page, paper and then that kind of helps you completely get that. But let's say it also depends on what kind of system you're building. Let's say you're building actually a script that you don't run once. I would probably run it, actually run it, fail and then fix it rather than actually doing TDD. Yeah, yeah. This is assuming that the system is something that has longevity, right? Absolutely. Like there's no, so yeah, if you're being with those nuances, if all of this matters, if the design matters, if you're building something where the design does not matter, then TDD does not matter, right? Like so throwaway scripts or single use scripts are a classic example. The second thing is I know programmers who have fantastic memory management without TDD, through just practice, right? So if you're able to load and unload pages of code in your mind without this, you don't need this. You will produce the exact same results without doing TDD. Yeah, I would kind of ask like that question like from first principles, why do you need TDD, right? I mean, if you ask that question, okay, I think then you get the answer. And most people have cargo cultivated it, right? And most of the debate around this comes from a cargo cult. My answer is very straightforward. If you're able to load and unload code from your mind in such a way that you're able to track side effects and you're able to make changes in a manner that tracks all those side effects and mitigates them, then that is the point of TDD. So if you're able to inherently do that, then TDD is a crush. That's simple. Yeah, I think thanks. I think we'll cross almost 10 minutes. I think we'll stop here. I think thanks to do, I think it's one common theme that I see this is like, I think we kind of see engineering as a narrow writing code perspective, but I think building scale systems is much more than writing code, much more than picking a parallel programming language. It's more than looking at that and kind of looking at the larger picture, right? Like I said, I think it's more useful to think about it as reality engineering. Right? The whole point of engineering at every level is to change reality. When a customer is able to pull out their phone, tap a button and a car or a bike shows up to pick them up in five minutes, you've changed reality. That is engineering. Everything that went into it is engineering, not just the code or a second way of framing it that I think is helpful is most people think of the product as being the app, either the app that's running on the phone or that they see through the webpage, right? But that's like looking at a cube and seeing a square. That app is not a static artifact. That app is the expression of an artistic, creative and engineering process, right? It is the end result of a pipeline and the whole pipeline, the entire process is the product, not the square. The cube is the product, right? And the cube is everything that went into giving you the app that is in front of you, that is updated every two weeks, right? That entire process is the product. So when you are thinking about building a product, as an engineer especially, the worst thing you can do is think the product is the code base. It is everything that creates that code base, that updates that code base and puts that code base in the hands of the customer. That entirety, that whole system, the processes, the culture, the policies, the people, pick anything, all of those inputs together simultaneously, that is the product, not that slice that you see in front of it. That's a two-dimensional view of a three-dimensional entity. Thanks, Sintu. I think it's quite insightful and I'm sure like everyone would have enjoyed as much as I did. Thanks a lot. I know there were a lot of questions that we couldn't cover. So I'm at Panapa on Twitter. My DMs are open. So if people want to reach out to me to chat or ask questions, I'm very happy to take questions over Twitter either in public or over DM. Yeah, so we also have a comments page on the Haskeek event page. You can also post questions there. We'll see, we'll coordinate with Siddhu and then get them answered as well. Absolutely, happy to. I'm sorry if you haven't answered some of your questions. I think we're running out of time and I tried to pick as much as I could. And thanks for joining. Thanks, everyone. Thanks, Anand. Thanks, Josna. Thanks, everyone from the Haskeek team. And of course, thank you to the audience. Thanks, everyone.