Scaling Uber with Thuan Pham (Uber’s first CTO)

15:48Thuan Pham:Like the dot-com bust was kind of scary when the correction happened, right? But before that, there was this exuberance that everything is dot-com, right? Pest.com, Fubal.com, everything is a dot-com. Webban. Yeah, all of that. So I still have the webban bin in my garage, actually. And so, yeah. But then there was a checkout. Eventually, there has to be a sound business model that makes sustain profit, right? Growth and profit. Growth alone eventually burn, you know, money, and that's not good. you can grow fast, but eventually you have to turn that into profit to be a durable company. And so in that dot-com wave, there were massive companies that emerged, right?

16:27Thuan Pham:There was Yahoo, there's Google, there's Amazon, all of those companies. There's also a bunch of other company, Webvan and others, whatever that would go under, because they didn't have like a strong value proposition that lasts the test of time, right? So yeah, it's all about what value you deliver and whether or not it's beneficial and valuable to the customer that they're willing to pay, right? And I think that's one thing that we learned. Which one is like a real fundamental strong business, even though it might not be a profit initially, but which one that's just a me too, right? Just put a.com on something and it's hot.

17:01Thuan Pham:There may be a lot of.ai things that's going on right now, right? Eventually, some of these things will consolidate. Some will go under. Some will become really awesome solutions and all that stuff. But the market will sort it out. In the end, the customer will vote on what they want to spend their money on.

17:18The Pragmatic Engineer Host:Speaking of building things that last versus things that don't, one thing that always separates the two is code quality. And that's what our seasoned sponsor, Sonar, is all about. Sonar, the makers of SonarCube, is deeply rooted in the core belief that code quality and code security are inherently linked. High-quality code is naturally more resilient, and as agents start to write code at a massive scale, that verification layer becomes your most important security perimeter. This is where solutions like SonarCube Advanced Security are valuable. With this new malicious package detection, Advanced Security provides a real-time circuit breaker, automatically stopping agents from pulling in unverified or risky third-party libraries before they ever hit your pipeline.

17:58The Pragmatic Engineer Host:The impact is measurable too. Developers who verify their code with Sonar are 44 % less likely to report experimenting outages due to AI, as per Sonar's State of Code Developer Survey 2026 report. It's really about closing the gap between the speed of AI and the reality of production security. What else is Sonar doing to help reduce outages, improve security, and lower risks associated with AI and agenda coding? Head to sonarsource.com slash pragmatic to find out. With this, let's get back on what Tuan did after the dot-com boom and bust. And there was a lot of layoffs, companies going bankrupt.

18:31The Pragmatic Engineer Host:Did that worry people around you? did that? Were you that, you know, your job could be in danger or you might have a harder time switching jobs or did you not? Was it a very short lived?

18:41Thuan Pham:It lasted a couple of years, I remember. And during that time, it was definitely hard to get a job, especially for new college grads. That's always the first layer that gets hit, right? When everything retrends, people want more experienced people. People want to stress existing folks rather than keep on hiring entry level. So that you have to, you know, continue to invest in, right? So it's just the economy of time. It comes and goes and waves. Yeah, so that was certainly a very scary time. But of course, you know, in the longer range of history, things generally tend to recover, but it caused a rearrangement.

19:21Thuan Pham:And yeah, so during that time, it was certainly tough. However, the way I look at this thing is that talents are always talent, right? So people with really strong talents and who's really hungry is always try to punch above their weight will always be marketable, right? Even in a downturn. Even in a downturn, right? So I think the key thing is how people should, even in peacetime, invest in that skill, never be complacent, constantly try to be better. And then in wartime or in rough time, those things will save you, right? If people just be very complacent, atrophy with the time, and then when rough time hit, It's very, very hard to recover from that.

20:00The Pragmatic Engineer Host:And then you went to VMware this time. Yeah.

20:03Thuan Pham:So let's see. After I went from DoubleClick to that, and then I jumped into a four-person company. Again, leaky roof and everything, classic startup. That business did not succeed. It took about three years or so, got to about 40, 50 people in size, and then kind of ran out of money and then got acquired by another entity that was built with a security appliance product would try to solve the problem of, you know, intermediation of web services, traffic they're going through. And it was a very interesting security niche, but it's not a mass market thing. And so it's hard for a company to kind of break through like that, right?

20:41Thuan Pham:But eventually it went away. But even then, you know, those three years taught me a lot that you can survive even when you do it from the ground up, then you still have skill that you can pick up. despite the fact that that journey might not end in like a commercial success. But your skills still get better.

21:02The Pragmatic Engineer Host:So you are getting better as a professional, even though the company failed. And that's something we have to trust.

21:06Thuan Pham:We invest in ourselves, but of course we invest in the company or vehicle that we are part of. And ideal case, both sides succeed. But if the others succeed, at least if you work really hard, you gain some skill. And then based on that, then you can then leverage all the things that you learned so far and all the mistakes that you've made. It got you smarter and better and wiser. to look for the next opportunity. So right after that, I looked at a bunch of other things when that company was acquired. And then I went into VMware. Again, when VMware was pretty small, not very well known yet. So it was a 40-person organization that built software to stitch together.

21:45The Pragmatic Engineer Host:So VMware was still early.

21:47Thuan Pham:VMware was still early. Yeah, there was three divisions. One division that did the Workstation desktop app And then there was the division that does the hypervisor, which is the OS underneath the OS. And then there was my division that was building enterprise software that stitched together all of the hypervisor into like a cloud platform, a management platform. Right. So I was in one for that. It was about 40 people. And we kind of built the very first product suite for VMware. We called Virtual Center that ties to ESX. So that was a really, really fun. Right.

22:22The Pragmatic Engineer Host:Very smart people. And then VMware really took off. So virtualization as a whole took off in the early 2000s. VMware was core part of it. It was one of the main things. So it was just, was it a kind of hockey stick-ish experience?

22:38Thuan Pham:It was. Not to the extreme of Uber, but it certainly was because it was an industry-changing technology. It was a game changer, right? Before that, there wasn't anything like that. At first, people thought, oh, this is a kind of interesting tool on the desktop for you to run a couple of Mac and PCOS on a PC. But the true power was the ESX, right? Yeah, and then that's what your power data center. And then, of course, that's the hypervisor. But I think the key feature that made VMware so useful was the whole V-Motion thing. When you take a virtual machine and you can migrate it from hardware to hardware without any perceivable downtime of the application on the top, with that capability, unlock the whole cloud thing, right?

23:24Thuan Pham:Because you have a thousand machines, it can look like one. It can look like a machine. And so application inside of a machine will just scale and it will just move itself and it can do whatever you need to do, right? You can do DR, you can do, you know, yeah, all kinds of things with it, right? So that actually make it very much like a cloud operating system.

23:44The Pragmatic Engineer Host:And then at VMware, you also grew with the company, right? So again, it seems you have this history of you were VP of engineering at the startup, you stepped down to a small startup, you then joined VMware, and eventually you became VP of engineering at VMware as well, right?

23:57Thuan Pham:Yeah, yeah. I have this weird thing where when the thing gets large and I start to feel too comfortable, I get nervous. Really? Yeah. And so that's where at DoubleClick, when I got to VP and I managed hundreds of people, I was like, is this a fluke or is it real? So I had to go back to a four-person company and try to see if it's real or not. That didn't succeed really well, but the end of the game was healthy. It was good. And then when VMware, again, it's a smaller company and it go big. And when it gets really big again, when you get to a point where you're just running things rather than breaking ground and doing your thing or your hard learning, then you got to do something different, right?

24:32Thuan Pham:So I keep on going back small. And when it gets big, I might go back small again.

24:36The Pragmatic Engineer Host:Yeah, so I'm seeing the pattern. So you got big at VMware and VMware was doing amazing. What made you look around and how did you find this very small company at the time called Uber? Or it might have been Uber Cab. I'm not even sure how it was called. It was Uber at the time already.

24:51Thuan Pham:Uber Cab was way before that. Yeah, it was when after eight years of VMware and sometimes people change, sometimes company change, sometimes both sides change. And so, yeah, for me, what changed personally for me was I reached to a point where I didn't feel I could do much more there. Right. I'm running 800 % engineering team. We're building this software and it's been like the third generation of that software already. We're tweaking, we're adding more feature to it. I love my team and all that. But, you know, it's just more of like keep it steady, keep it growing and add more feature. And then the company has also changed along the way.

25:30Thuan Pham:You know, the original founder left, new crew came in, and there's a fair amount of changes and personalities and all that. And after a while, it just felt like it's time.

25:42The Pragmatic Engineer Host:So now with your background, like you now have a super impressive background, you probably could have gone anywhere, large or small. What was your search process look like? And then how did you come across it again? Because Uber was still pretty obscure.

25:53Thuan Pham:Yeah. Here's a really interesting thing. People do ask me about what the search process looked like. How did you sit together a career like that? My honest answer is I didn't do any of that. And it wasn't luck that you bumble around and you find one thing after another. It's actually something different. If you try to do a really good job at every company you've been, working well with all the people that you work with, including your own team, your peer, whatever it is, over time, very slowly, you accumulate a decent reputation in people's mind. and people always come and go throughout the industry.

26:29Thuan Pham:But if you're good with them, to them, whatever, they tend to remember that. And then when you become available, then people come to you about this, how about this, how about this, how about this? And then you actually look at all those things and then you can dig in and you can decide. And so that played out multiple times for me in the Valley. And especially, I think the biggest breakthrough was Uber. Again, when I left VMware, I didn't plan to do anything, right? I'm saying, well, let's sit back and take a look to what's going on. And then Bill Gurley from Benchmark Capital, who invests in early investor in Uber.

27:04Thuan Pham:And guess what? His tie was, he knew me from that net gravity startup a decade before. And so we kind of knew each other. And then, but of course, when we know someone, you follow their reputation. And it was Bill who come to me after he knew that I'm leaving VMware. Hey, can you take a look at this one? I'm investing. It could be really interesting. So I went up to his office in Sand Hill and he shared with me the board deck and how the company is growing. And then I understood the business model, right? To all of you back then, when I was trying to recruit some people, it was like, why, Tuan, why are you joining a taxi company, right?

27:41The Pragmatic Engineer Host:Yep, I remember everyone's asking me as little ones I joined. Exactly.

27:45Thuan Pham:And so, but I knew that. And of course, then we have to go to like a pretty rigorous interview process with Travis. And yeah, but ultimately it's about the connection that leads to the right thing. But that connection and opportunity basically tied to your reputation.

28:04The Pragmatic Engineer Host:And then back then, as I looked it up, and you also helped me with this, Uber just raised a Series B, which was$30 million, it was a value of$300 million, which was sizable, but still not nearly the gigantic company that it later became. And one fun fact that I read about is you had this very rigorous interview, Travis, process, which was tens of hours or something like that. Can you talk about how that went?

28:30Thuan Pham:It was impressive that he did that. He committed over 30 hours interviewing me one-on-one.

28:38The Pragmatic Engineer Host:Wow. Yeah. That's like several days of like long.

28:41Thuan Pham:It was two weeks worth of interviewing every single day, a couple hours each day minimum. Yeah, with passion, with intrigue. And we end up, after a while, I kind of forgot that I was being interviewed. It was like two people kind of sharing ideas, like changing ideas, and sometimes disagree something and then kind of work it out.

28:59The Pragmatic Engineer Host:And then you showed me, you took a photo of like some topics that you talked about. Can you like summarize what those were?

29:05Thuan Pham:Yeah. My very first meeting, I drove up to San Francisco in South Travis in the office. And we immediately went to the whiteboard and he wrote down all the topic on his head that, you know, he want to talk about with me. That was a really long list. There's a big long list of general topics about, you know, hiring and firing and communications and all of that stuff. Org design, everything else. And then there's a shorter list of very engineering specific stuff. What about quote quality? What about QA? What about design? All that. And then there is also a list of shorter list of the five things that he wants to see in an engineering team and the culture of engineering team.

29:47Thuan Pham:And yeah, and so that was the list. And so after we wrote the list, we started talking, picking up some item off the list and talk. Of course, you know, in two hours, I was supposed to meet him for an hour. It lasts two, which is actually good because we got totally into it. Time ran out. And then as soon as I drove out of the office, I barely get to the exit. I got a call from the exit recruiter saying, Travis, we want to see you again and talk some more. And so we did that. And of course, he's very busy. He's traveling around all the regional offices to run the business. And so we set up a Skype session every single day for two hours each day.

30:26Thuan Pham:And we will pick one of the topics. That's why I took a picture, a photo of that whiteboard, and he did the same thing as a list of topics to talk about. And I still have it on my phone today.

30:36The Pragmatic Engineer Host:It's so impressive to me that because we'll share that list in this episode as well, that screenshot. But that the fact that the CEO would go into things like code review, the hiring topics I understand, but that he was so injuring-minded. Or did you get a sense that he had the vision that technology and engineering would be just key to Uber?

30:57Thuan Pham:Oh, absolutely. I mean, he knew that. And it was very clear from the very beginning that he viewed the business has two major engines that powers it. One is the operation, you know, bits and atoms, right? You got to have real physical thing moving around the world. And then there's technology. And technology is a key part of that, right? No one side is superior to the other, but it requires both of those. Yeah. And so that was very key. And I think he also knew what he wants also and what he wants in whoever it is. And so I think this list and this serious conversation was for him to vest that.

31:37Thuan Pham:Yeah. Later on, I think either he said something or I figured out that it was actually a simulation of what it's like to work with another person in that capacity. In the end, when we're inside, we're all working with each other all the time. And can we disagree on something? Can we work things out? Do we have generally similar philosophy and principle? And he did it himself. Yeah. And so, yeah. And the level of passion and commitment he showed was just really impressive from this side. I can tell you, for example, there's some session when we're totally, you know, in the middle of that and two hours gone by.

32:17Thuan Pham:And he had to like stop and catch a flight to go somewhere else. He literally stopped and told me, just wait. And he picked up his phone, called his EA and said, can you move my flight? And continued the conversation. Who had that level of commitment, right? And passion and stuff like that. And when you see that, it actually draws you in.

32:37The Pragmatic Engineer Host:Yeah. So I guess it was not a question that you joined, but can you recall what was it like from the inside, especially from an engineering point of view, from a systems point of view, from like what was going on?

32:47Thuan Pham:So it was still pretty small. It was about 30 ,000 rides a day. When I pulled the data, the weekend, which is always the busiest time when people move around. Yeah, that weekend, the day, the Saturday or Sunday before I joined, I joined on Monday, was about 30 ,000 rides a day. And Uber was, I don't know, 20-something cities around the world at that point, 20, 30. And so it was very modest. There are certain things that were going for it already. The engineering team was very young, but pretty scrappy and pretty committed and talented where whatever we need to get done by hooker by crook, they're cobbled together.

33:25Thuan Pham:Right. And so and as a result, though, the service was beautiful. Anybody who ride, we only had black car service at the time, but the experience was beautiful when for all the people who ride it. That's why word of mouth is, you know, raging around. And yeah. And so that was the really good part. Now, the thing that maybe Travis had foreseen or whatever it is was the next phase, which as the company grow faster and faster, what happened, right? And by the way, the 4D engineer were very, very young, I think in the 20s, all of them. And the system was built not to scale, right? It would build for functionality.

34:04Thuan Pham:It's actually made it work. It's torn together and it's worked. Yeah, and it worked and it worked beautifully, right? But it wouldn't scale and it would crash and burn all the time, multiple times a week. And that was our lives in the trenches. If the hockey stick actually happened, yeah, everything breaks. And we have to basically race against time to actually figure out what was the next most critical thing that would break and how to get ahead of it. And one of the things that Travis always told me, even from the interview days, is you got to see a round corner. So I try my very best to see a round corner.

34:35Thuan Pham:And one of the first things I did in the first couple weeks beyond getting to know the engineer and build relationships and build trust was to start examining what we currently have and what we need. And dispatch was the first thing. Without dispatch, there is nothing, right? That's where you match the riders and drivers.

34:54The Pragmatic Engineer Host:Yeah, it's our matching service, right? When it has the drivers, the riders, and it doesn't match.

34:59Thuan Pham:That's right. And without that, there's no business, right? There's nothing. There's nothing. was the first system I looked at. And I asked them, I reviewed the architectures, I reviewed the implementation plan, and it was very obvious that it wasn't going to scale. It was a JavaScript, it's Node.js, and it was a single-threaded thing. And the engineer at the time, where when the city gets larger and larger, they need more out of that piece of code to power that city. They would move that piece of code into a larger machine with a faster processor.

35:33The Pragmatic Engineer Host:Vertical skilling only gets you access. so far.

35:35Thuan Pham:So my role also is to do things, but also to teach people along the way. And so I was just asking leading questions to the team, and the team only has three people, three or four people at a time. And so I asked the engineer, okay, what would happen if the city gets larger and you have to support that? Because every city is getting larger, the right volume is getting larger and larger. Then the engineer base said, oh yeah, we just move it to a more powerful processor. And say, what happened if you get to the fastest processor you can Oh, there are multiprocessors, and then you can get a four-way box, and then you can put multiple of these processes on them.

36:11Thuan Pham:And then you say, well, you've got three or four of these things surfacing the same state. Do they talk to each other? Do they share the same state? Not really, right? So it becomes very partitioned. So pretty soon by asking those leading questions, the engineer now discovered a flaw that this thing would not scale, right? And then I had to establish the limit of where is the brick wall. And I basically said, what's the biggest city that we currently have in terms of the right volume, and they say New York City. And I said, okay, when is New York City going to run our capacity, even on the biggest box that we can get our hands on?

36:46Thuan Pham:It's about October, and this is around May, okay? And so I was like, well, we have to rewrite it, don't we? And we have to write it in a really scalable way. And I only have two requirements that I, all I need. One is a city has to be powered by multiple boxes.

37:01The Pragmatic Engineer Host:Yes.

37:01Thuan Pham:And a box has to power multiple cities. That's it. So you can have N by M. You gave them these two constraints. No new feature necessary. Just make sure that we can do that. And then that allowed the business, the company, to just pour a whole bunch of hardware behind that. And it will scale. Technically, it will scale infinitely, right? And so the engineer did that. And because the requirement is very simple, we have to do it really, really quickly before we run out of time, run out of runway to survive. And so they did that. And we actually deployed that right around August, September, right before it's actually, and then on to the next problem, database, it's going to be the next choke point, right?

37:38Thuan Pham:And then the API monolith is going to be the next choke point. And we keep on identifying all these things. So there's all these threats coming at us and we have to establish like how much runway we have until we like really get in serious trouble. There's no way out and then get ahead of it.

37:52The Pragmatic Engineer Host:And so this was then the reason that we had so many rewrites. I joined later, but rewrites were still continuously happening. And I think when you come in, you ask, like, why could they not written it properly the first time? But I guess, do I understand correctly that it was because, A, sometimes you just build a system to solve your problem. And B, you don't always know how big this will fail. A good example is the New York problem. And then you take those constraints and then you build a system. And then if those things change later, you might need to build a different system.

38:25Thuan Pham:Yeah. It also depends on how fast you're growing. That dictates how you make. And because the faster you grow, the shorter runway you have to survive, right? Given whatever architecture and system that you currently have. And yeah, the question about how big it can possibly grow, nobody knows really. But it's actually not fruitful to pontificate on that. It was all about how much time we have to live, right? We hit the brick wall and there's no way out, right? So yeah, and if that time is really short, then don't overthink it. Just survive that and give yourself enough runway to then live to fight another day is what I like to say.

39:04The Pragmatic Engineer Host:Growing fast like Uber did is a good problem to have for startups until it's not. And the pain points that come with fast growth is a good time to mention our season sponsor, WorkOS. If you're building any SaaS, especially an AI product, surprisingly, you reach the need to build enterprise features like SAML edge cases, directory sync, audit logs, and all the things enterprise customers expect quickly. Building that infrastructure yourself takes months. WorkOS gives you APIs to ship it in days, authentication, SSO, SCIM, RBAC, audit logs, and more, all designed to integrate directly into your product.

39:39The Pragmatic Engineer Host:That's why companies like Entropic, OpenAI, and Cursor already run on WorkOS. Skip the rebuild, keep shipping. Visit workos.com. With this, let's get back to Twan's team rewriting the dispatch system and the short breeding space that this first rewrite gave them.

39:53Thuan Pham:So that's what with dispatch, we knew we had to do it very quickly, maybe buy ourselves another 12 months. And after we get through that point, then we have another 12 months to think about the next phase of survival for that team. That's why the system needs to be rewritten several times. Let's say if my requirement for the engineer was build a system that will scale infinitely to the rest of time, it might take a year. We never get there. We'll die before then.

40:17The Pragmatic Engineer Host:Speaking of dying before, you were given in 2014 a seemingly impossible task. Travis told you you have two months to launch in China. And apparently launching in China was not as simple as just like opening your API and allowing the firewall. What was that project like? I heard it was an absolutely manic and crazy. Can you take us back what it was like?

40:37Thuan Pham:Yeah, that was one of the craziest things we've ever done, but it's also one of the most amazing things we've ever done. And now I'll explain why that is so. So I remember very, very clearly right around Christmas time, 2020, 2014, we were all hanging out in the big room in 455. And Travis made a declaration that, okay, come the new year, I'm going to light it up and we're going to go into China. Okay. And then he turned over to me. It's like, I want that. And one of the requirements at the time was that we have to run our services on China soil, right? And data center physically there. Physical data center needs to be there.

41:22Thuan Pham:Until then, we kind of dabble into the water by powering it from the U.S. Okay. And we have a limit of time to do that. But he's going to light it up. I'm going to do that. And he's like, two months. And I said, well, that's really tough. And he's like, why is that? Because I can go rack all the machine and copy the software over. and it takes more than two months. And then I have to like explain that it's not that easy because when you do that, then it work on day one and then the two drift and then how you're going to maintain that, right? We don't have twice the engineering team to actually manage two different systems that deviate.

41:53Thuan Pham:So the right way to do that is you build re-architects, whatever you need to do to kind of build one system that can be partitioned, right? So I think there's a huge security concern, right? Because anything that runs over there cannot pretend to have any level of privacy or anything like that. But over here, we have to protect everything, right? So we have to build that same system that has completed partition of data and controls and everything else so that, yeah, nothing bleeds across. But it has to be, every time you deploy code, you have to record code everywhere, right? So you have to rebuild a lot of things.

42:27Thuan Pham:And so I went to the TPM team and asked the team to actually scope it out.

42:33The Pragmatic Engineer Host:The TPM technical program manager. Yeah, technical program manager.

42:36Thuan Pham:And I think the best path for us was about six months. And that was the fastest we can even imagine, right? I benchmarked with a few of my friends in industry and they kind of laugh at me and it's like 18 months minimum, but, you know, that was Uber. So we just like, we didn't think too much about it. It was like, well, let's do that. And then drive it in like the six months. So we are kind of set around four months, right? So, and so we just split the difference. We didn't know anything, but we just want to head down and start getting to it. And so we look at all what needs to change given like this is the, the end goal and the requirement.

43:10Thuan Pham:And then everybody start getting really busy, working a lot of hours to start making these changes. And four months come and we are still a month or so short. So we slip. And we're into Travis and he's not too happy about that, but it's fine. And then five months comes around and we're very close, but we're not there. We're about to slip again. And so it was definitely not happy then. But we actually talked it out. And I said the team feel very confident that within a month we can launch. But he had to give us something. That means give us an ability to incrementally launch. Instead of lighting all the city in China all the way we want, let us do it in phase, right?

43:55Thuan Pham:Every single week we'll launch a number of cities. And then we're going to do it in the process of a few weeks. And then we're done with that. And he said, okay, that's reasonable. but he won the biggest city first, and that's Chengdu.

44:08The Pragmatic Engineer Host:So he agrees to the incremental launch, but you need to start with the biggest city. Start with the biggest first. That's so Travis, no?

44:14Thuan Pham:Yeah, exactly. But it is brilliant, though, now that you think about it. I thought a lot about that over time, and that was the most brilliant thing because by doing the hardest thing first, once you launch that, everything else is downhill from there. The team had this swag. Like the team know it would go into the next set of city with confidence. Had we done the traditional way, let's start with the safest one, the smallest one first, the next one we step it up. On the surface, it seemed like, oh, it's a very good risk control measure. But every single week we'll be holding our breath. Until it's done, it's not done, right?

44:48Thuan Pham:But this time we did everything we can to do the hardest thing first. And after that, it's just the routine process to roll out the rest. And that it worked out exactly like that. And so, yeah, we got it done. And a bunch of people were really burnt. And then they take like a month off, go to the beach and did nothing except tear the water. I know some other entity did that. But after that, though, we're not fearful of anything. We did kind of the impossible.

45:15The Pragmatic Engineer Host:I talked with a friend at Rupert who worked at the IT team at the time. And his job was just to get the servers physically set up. And he said that the timeline was so impossible. I think they had two weeks from start to finish. They had a little bit of time to plan, but they were on the side. They were just, and when I gathered stories from the software engineers who worked on it, everyone had their own impossible task and project, and they all thought it could not be done. And then somehow it all came together. That's right.

45:42Thuan Pham:None of us thought the whole thing that could be done, but we just got our head down and we just, you know, break it apart and just do it one step at a time.

45:50The Pragmatic Engineer Host:And then I think needless to say, but the China launch was a massive success. Uber started to compete head-on-head with the leading Chinese provider, Didi. And there was pretty much head-on-head, very intense competition, all the while competing with the rest of the world as well. That's right. Yeah. So that was something incredible.

46:07Thuan Pham:That was something incredible. And I think just the experience, having gone through that and doing things that initially you didn't think was possible, just increases everyone's confidence and range. And that's what stretching is all about. And I think that's a saying that Travis likes to say, that sometimes you have to be willing to redline yourself a little bit, right? And that's how you prove that you can actually do a lot more than you can. That was the fearlessness and the risk-taking culture that he won in the company in the first place.

46:33The Pragmatic Engineer Host:One thing that Uber has been very, very well known about from the outside is microservices. And from the inside, one thing that has been very talked about is a program and platform split. Can you tell us which one came first? And how did we get to as many microservices as we did?

46:49Thuan Pham:The program and platform came first. Yeah. And the microservices came later. And the platform and program platform as an organization structure came first out of necessity. When I came in April of 2013, we had 40 engineers and three product managers. By the end of that year, we had about 100 engineers and a dozen or so product managers. Even at that really small size, we ground ourselves to a halt. with a functional org structure. Imagine, although it's on an engineer, there were about up to eight or 10 mobile developers, a number of infrastructure engineers, and a bunch of backend engineers, et cetera, et cetera, and five, eight people or so at dispatch now.

47:35Thuan Pham:But every feature that we want to put out has to be queued up on mobile development bandwidth, dispatch bandwidth, and it'd become impossible to navigate trade-off because every feature you want to do, you have to go negotiate with so many teams, right? And so then the team went to move fast and started to feel that friction and complain right away. And that's a good thing, right? We raised the concern. And so I remember Travis and Jeff Holden and I saw that and we got together for a couple days, actually. And I remember we had a sticky note of all the different colors. Each color represent a different function, engineering, product, designer.

48:15Thuan Pham:and we put one person name to each of the sticky note. And then Travis gave a talk about what are the most important area of the business that he thinks, right? And at the time there were like 17 area that he can think of. The world of Uber can cover in 17 area. It turned out to be a lot more than that, but at the time it was 17. We didn't have enough to fund 17. We had enough to fund seven plus a few more, right? So we fund seven with partially the next four. And that's it. And the rest can remain empty until we hire more people and we fund it. And so that was the thing. But then as part of that process, we then put sticky note onto each of these areas.

48:58Thuan Pham:It has to be a cross-functional team because we can no longer afford to run it. No, yeah, cross-functional team rather than a functional team.

49:04The Pragmatic Engineer Host:Which means that there's like a back end, a mobile, and whatever else they need, like a design if they need to, et cetera.

49:09Thuan Pham:The concept is that team has to have all the skillset necessary to just take their business. Whatever they need to do, they just go off and they do that. So that was the principle behind that decision. And then we call some of those programs and some of them platform. So programs are the team that build things that the end user actually use. And the platform are the thing that build tools and layer that other program team use. And that was it, sort of horizontal versus vertical kind of thing. And that's that. And then after we define that, then we start putting the right sticky note onto that box.

49:43Thuan Pham:And then that's how the first version of program platform came about.

49:46The Pragmatic Engineer Host:And then how did microservices start and how did they blossom as much as they did?

49:51Thuan Pham:Yeah, again, none of us wanted to go through that extreme. But lots of time when you are under a lot of pressure and no time to react, other than just to survive that scale that keep on coming at you, you have to make a decision that increase speed and velocity because speed and velocity allow us to build things quick enough to survive. And so we knew right away that the backend API, which is a monolith, right, is the thing that will prevent speed from happening. So we made a declaration, anything that is new needs to be built outside of that as a microservice. Okay. And then there's a team that's dedicated to decompose that that monolith, that API monolith into a bunch of services.

50:35The Pragmatic Engineer Host:Yeah, we used to call it API, right? Exactly, we called it API, right?

50:39Thuan Pham:And I think that project name is called Darwin.

50:42The Pragmatic Engineer Host:Yes, Darwin. Oh, I remember.

50:44Thuan Pham:Yeah, and interestingly, had we freeze time, that piece of code could be decomposed in a matter of three to six months. But it took us two years to do that because as we peel out a piece of code, the business keep on going forward, right? These hockey sticks are laying on top of each other now as we launch New City. and happening faster and faster.

51:03The Pragmatic Engineer Host:New city and new product, UberX.

51:05Thuan Pham:Feature has to be added on, right? And so the philosophy we all operated at the time was no one should be blocking anybody else. No one can block anybody else. And so when a team that needs to build feature and nothing hasn't been pulled out of the monolith, they add to the monolith, right? And then the team that pulls it out, do the best that it can. And then we kind of keep chasing our own tail until eventually, you know, something gets completely pulled out. And as it happened, it bulges up like this, the monolith, right? If you pull out one thing, the remaining stuff grew even faster than the start that you pull out.

51:37Thuan Pham:So the code base gets larger and larger, eventually reach to a certain point when it starts to come down. And that's why it took two years. And meanwhile, everything that is new must be on because we don't keep on adding stuff, right, to the monolith. And so that's how it came up to like, you know, thousands of microservices. But that was out of necessity so that we can just fan out and solve every problem all at once. And then over time, after things stabilize and so the business more mature and growth is not as violent like that anymore. Then the team, we actually have a project called Arc. We're going to look at this stuff and how do we clean it all up.

52:11Thuan Pham:So we put like domain interfaces on top of a whole bunch of microservices that are within the same domain.

52:17The Pragmatic Engineer Host:It's funny because I remember that around like 2016 or so, there was a published Uber block post that Uber had about 5 ,000 microservices. And I just saw about a few months ago, Uber published another one, and they have about 4 ,500. So in that 10 years, the number has gone slowly down, right?

52:35Thuan Pham:It should go down. But even then, we put it later on. Uber has so much more complexity, right?

52:40The Pragmatic Engineer Host:It's so interesting.

52:42Thuan Pham:The process took a little while. But yeah, the team had to look at everything and how do we simplify that, right? And then to make sense out of that, a new tool has to be invented by us. Jaeger, the tracing tool, all of that stuff. And so that'd be a really great tool that we open sourced.

52:57The Pragmatic Engineer Host:And let's talk about how and why Uber built so much internal tools and also open sourced a bunch of them. Jaeger was one of them, but internally we had Schema-less, a trip data store, T-channel, an RPC protocol, Ringpop, Gelspacial Placing, Clay, Service Framework, U-Monitor, Observability. And there's like hundreds of others. Some of them open, some of them not. How were you thinking about that? Like, does it not seem like a lot of waste for us to build this? Or was it, again, necessity?

53:21Thuan Pham:It was mostly necessity. I can't claim that every single one of those things were absolutely necessary, but all the important ones were absolutely necessary. The thing is, when I started, Uber used pretty much all the open source stuff. We used Redis, we used everything, right? Because the engineer there just focused on putting together a service that actually moved cars. But then as we scale, we kept on pushing the boundaries of the capability of those open source stuff. And to the breaking point. And at a certain point, if we don't invent something, the power I'll need. By the way, this is 2013, 14, 15, 16.

54:01Thuan Pham:It's not as mature as it is right now.

54:03The Pragmatic Engineer Host:We did not have the big tech investment in open source back then. That's right. There was very little. And most of the big teams like Google and Facebook, they were keeping their things inside.

54:13Thuan Pham:I remember, for example, a very painful example of that we had to face early on was we used Postgres. All right. and we get to a certain scale that Postgres would randomly fail and that take our services down randomly. We don't understand. It's inside the kernel. I remember the time where I had to go on LinkedIn begging people who anybody on LinkedIn that has any knowledge of Postgres to be our consultant, to help us diagnose this problem. And we spent several weeks and during that, it was terrifying because I don't mind if we think we can do something about our own problem. It's terrifying when we have a major problem and we depend on somebody else and we don't know because open source, there's no single person, no single company, I'd be willing to pay anything if someone can give me an answer.

54:59Thuan Pham:But there was no one, right? And so that was one of the motivator to kind of build our own data layers and all of that stuff as well. So that we would use this generic database and we ended up using MySQL just as table data store. All the logic on top we have to build for our own use, right? Because then we control it on this thing. And we only build the feature that we really need. And so that was one of many examples. And eventually we run into other brick wall of scaling. I remember in 2015, right around the holiday, I was taking a holiday trip and I go to the airport. And I took an Uber ride as usual.

55:37Thuan Pham:The receipt didn't come for two days after that. Why is that? Things were queuing up. We weren't processing things enough. Right. And so, yeah, but that's not a deal breaker for many people because they just write and then receipt come later. That's fine. As long as the billing and all the stuff, even when you build people late, they don't really mind that either. Right. But as long as the write happened, the rest of the stuff can be processed later, but it's still not great. Okay. When I dug into it, like our data processing capability is at capacity. Right. So we have to rewrite a bunch of stuff.

56:09Thuan Pham:and then our capability to monitor things is reaching a breaking point with the open source tool that we use. So the M3 has to be invented, right? And all of that stuff. So we have to do things because we're at the scale where we broke all the open source stuff that we use.

56:24The Pragmatic Engineer Host:At Uber, we did unusual things. One of the most unusual projects, which is where you and I met when I joined Uber, was internally called Helix. It was completely writing Uber's app. And as I understand what happened is Uber's user experience was starting to degrade because it was really cluttered. Travis got a bit fed up with it. The designer team came up with a solution, which was a very nice and clean UI, which kind of the engineering team looked at it and it would have been a full rewrite. And then we just did a full rewrite. Back then, I remember we had a million or two million lines of code.

56:55The Pragmatic Engineer Host:We had two or 300 mobile engineers working on this. This was a massive business and there was an extremely tight deadline set. Can you take us back on, why did we even do this? because it didn't feel, it felt existential threat from the inside, but it was not like a Google Plus versus Facebook existential thing. And how did we decide on that short deadline?

57:18Thuan Pham:Yeah, it seemed like a recurrent theme that keep on coming up with a tight deadline, right? Everything we do had a tight deadline. It's just, yeah, that's just how the culture rolled. Anything we want to do, we want to do as fast as we can. But going back to why Helix, Actually, Travis has a vision, right? And it's actually not just the designer. Travis and Yuki, the lead designer at the time, they pair up and all these storyboards and everything else. And he has a vision where the current app back then was too limiting. Yeah, it's really good. Push a button, get a ride, all that stuff. But if you want more services to hook in other things, right?

57:56Thuan Pham:Messaging and all these other things as people were riding, the new architecture was much more open. right to all those things uh and so that was the division behind that and then when we're doing that the aesthetic is really important the icon change and all of these things change oh yeah and so but that is yeah it's beautiful right that's actually Travis and Yuki right they were and then of course when when that fleshed out their certain amount um then the engineering team the mobile team get involved and it's not just the mobile engineer the back end has to be written to everything we we

58:28The Pragmatic Engineer Host:We changed from the heartbeat where every five seconds we would pull. And it was pretty painful to an actual push channel.

58:35Thuan Pham:This path, by that time, it's called real-time system now, right? Yes. Yeah. It has to change, backend has to change. Everything has to change to support the new flows and all that stuff. And so, yeah, it took, I don't know, 600, 700 engineers all told, seven, eight months to actually do it. Then we put it off and it still lives today. It's still on that same architecture. It was so far well thought out. It's almost like future proof in that design. It's still beautiful today. And if you compare that with the previous version, it's actually definitely the right.

59:06The Pragmatic Engineer Host:Yeah, and it was scalable user experience. I take no credit in that.

59:09Thuan Pham:It's like the genius of Travis and Yuki.

59:11The Pragmatic Engineer Host:You every now and then sent emails to all of engineering on different things. And I remember this really, really emotional email coming from you about naming.

59:19Thuan Pham:I see all this and I understand young engineer want to have fun. We were having fun. Yeah, and name things in a goofy way. I think the trigger for that was a service named Mustafa. I have no idea what it is, right? I look at that stuff, and by that time, we were already very complicated, right? And we had to onboard new engineer all the time. We want builders to ramp up quickly, et cetera, et cetera. And I can imagine an engineer come in here, and all these weird names have no context to it. At the time, our tooling wasn't that great either, right? Ublame didn't come into existence yet, right?

59:52Thuan Pham:And so there's no mapping to discover what this really means. And then those weird naming schemes. So I got to the point where I'm kind of fed up. So I send that email out. Of course, you know, those nice emails, sometimes you'll regret after you send it out. Because it has some effect, but it didn't really solve it.

1:00:07The Pragmatic Engineer Host:And I think it was very quoted because you specifically wrote, this is not a Mickey Mouse shop.

1:00:12Thuan Pham:Exactly. We're not Mickey Mouse. And yeah, it was, again, it was a growing up phase for everyone in the company. But it was my frustration at the time was, look, at this scale and size, we got to take ourselves seriously. We got to do things better, faster. And this is not helping.

1:00:30The Pragmatic Engineer Host:Twan's been talking about improving things as the org scales, such as moving to a more mature naming policy. Introducing new and better approaches as the company matures leads us nicely to our presenting sponsor, Statsig. Statsig built a unified platform that enables both experimentation and continuous shipping. Built-on experimentation means every rollout automatically becomes a learning opportunity with proper statistical analysis showing you exactly how features impact your metrics. Feature flags let you ship continuously with confidence, roll out to 10 % of users, cache issues early, roll back instantly if needed.

1:01:04The Pragmatic Engineer Host:And because it's all in one platform with the same product data, teams across your organization can collaborate and make data-driven decisions. They have a generous free tier to get started, and pro pricing for teams starts at$150 per month. To learn more and get a 30-day enterprise trial, go to statstig.com slash pragmatic. With this, let's get back to Twan. We started to do better names. One other thing that was very, very unique to Uber across the industry and it caused a lot of confusion from the outside is Uber's senior level. For a while, Uber had a senior engineering level called L5, which is common.

1:01:37The Pragmatic Engineer Host:And then at some point, you or the leadership team cut it into two. There was L5A and L5B senior, one senior, two. Can you tell us about why you did that? And where did you get the idea from?

1:01:49Thuan Pham:I did that. I'm not apologizing for it. I think it was a good move at the time. And the principle was we want people to grow, right? But we have a very clear definition and expectation of what it is at the staff engineer level. Because we benchmark ourselves to all the great company out there, Google, Facebook, and all that. And then I realized that for many engineers crossing from senior engineer, I mean, engineer two, pass through the senior engineer to get staff, it could be a five-year journey. Okay, it's a long time. And so I just want to break it in two so that people get a sense of progress.

1:02:29Thuan Pham:And then also, not everybody can make it to staff, right? But some people, it's good enough to make it to seniors too. And I think that's a benefit. It's not, right, but versus like not doing it and everybody kind of just get lost in that five-year journey. Yeah, and so that was the motivation behind that.

1:02:51The Pragmatic Engineer Host:So you saw a problem and then this was a solution and it worked, we can say, right?

1:02:55Thuan Pham:It worked for a while, right? And then people were acclimatized to that. And then they start complaining, it's like, oh, why is this too level? We need to get the staff faster. And then while I was there, I held on to that because I was a principal and staff is staff compared to the best of the industry. And later on after I left, I think it got relabeled.

1:03:16The Pragmatic Engineer Host:They got pushed down. L5B is now staff. Yeah, it's just title inflation.

1:03:20Thuan Pham:I didn't want to do the title inflation thing.

1:03:22The Pragmatic Engineer Host:I appreciate that. Another email that I remember from you is in 2016, you sent an email saying, you've heard the feedback that NGRs are unhappy because their managers did not support them. And then what you wrote is like, we are creating a very easy internal transfer process. You can move teams. How was that perceived? And again, how did you decide that we need to do this?

1:03:41Thuan Pham:I look at the talent base And I think it is best for us to create opportunities for people to keep on growing with fresh new challenges within the company. Because if we don't do that, they would leave the company. And then I thought about the next logical step, which is, hey, if people come to us and just resign, they didn't tell us when they interview. And so why the heck do we have like these rigorous process when you have to ask your manager for permission to go to another team? Why do we make it harder for ourselves, right? When our own engineer go from team A to team B, have to ask for all these, you know, permission where they don't have to ask if they interview outside.

1:04:25The Pragmatic Engineer Host:Yeah.

1:04:25Thuan Pham:That just doesn't make any sense.

1:04:26The Pragmatic Engineer Host:Basically, it's easier to interview outside. Correct. It was easier to interview outside. Yeah, so that didn't make any sense to me.

1:04:31Thuan Pham:And so I was like, well, let's not have that, right? And that also has maybe a good side effect where a manager now needs to be incentivized to take care of people great. develop them, grow them, you know, put position, the best view into the best assignment for them to grow. And then they not like to leave their own team, right? If they continue to grow. So there's all of that, you know, that back pressure might cause engineer, manager to be a little bit more responsible too. So that was that. And I remember that get quite a bit of pushback because it'd be radical at the time, but we just did it anyway.

1:05:02Thuan Pham:And so that, that would not be the right thing to move. And I would rather people trust each other. And when an engineer want to go, they should have a really great relationship with their manager where they just talk to the manager hey look I want to do this and the manager should be generally supportive instead of saying no you belong to me that kind of thing which is the wrong thing I have a saying that I share with you guys all the time it's not a jail we can't lock anybody down everybody has free will if they want to work somewhere they should have their ability to do that and we should create more opportunities and then we also to support that we publish internal job boards anything on the outside see we see on the inside so and you should be able to shop within all the opposite have inside the company stay with the company and why make it so hard and then end up

1:05:49The Pragmatic Engineer Host:leaving the company that's just a silly thing i remember at uber in in some of the the meetings either all hands or team meetings you gave talks that were memorable and one of the most memorable i asked around former uber folks and charles specifically he was on the podcast he told me that his most vivid memory of you is this talk or this topic about behaving work in the perspective of death.

1:06:11Thuan Pham:Yeah, I don't remember that exact speech, but I do have that line of thought in my head all the time, right? And sometimes I would share with different audience, different context, but it's all about finding one's purpose and not take oneself too seriously, right? If you look at people, the most accountable people don't take themselves that seriously. The more you know, the more you know, you don't know kind of thing. And people who are arrogant tend to not know enough yet or all that. So I always take the opportunity to remind people to be humble. And the example I use always is myself. I say, look, when you're in an important position, people treat you really well.

1:06:59Thuan Pham:But don't let that get to your head. It's not you. It's the position you hold. And I remember saying this, we were like, the moment I stopped being CEO of Uber, nobody can care or know about me. They're going to talk about the next CEO, right? And that's always happened, right? The world forgets about us, right? So the only thing we can really do is in any job that we do, do the best that we can to help each other, to leave a lasting, positive impression in each other. And one day, everything ends. a job and then I'll get to the morbid stuff like life even in itself. And so then I measure myself, like what is my achievement that I will be most proud of?

1:07:39Thuan Pham:And I say, well, when I'm gone, the thing I'm most proud of is how many people remember how I was good to them or helpful to them. And for some number of years, right? And that is that because I can't take anything with me. And so live in the moment, be as best as you can to everyone and be very, as constructive as you can and and and leave a good legacy behind you so that that that was a whole gist of that

1:08:02The Pragmatic Engineer Host:it feels to me sometimes there's talk about how you can network better and grow your network but sounds like this is almost like it's not a hack it's just do the work right do the work and then

1:08:11Thuan Pham:the right thing happens right but you can't do the work in service of that goal because that's very artificial right just be genuine just be yourself become helpful be constructive uplift everybody help people along the way coach being doing it altruistically and let me show you another angle too, which I personally experienced over and over again. It's not only that other people around the industry pull you into good stuff. When you pull in and you don't have people to support you succeed, you would not succeed also. And here is an example at Uber, right? When I came in, again, the engineer we talk about very, very young in experience, did not know how to build system at scale, reliable, all that stuff.

1:08:52Thuan Pham:And the network that I have who really knew how to do that was from VMware, where you're building system software, where you're operating system, right? Rigorous, principal-level engineer.

1:09:01The Pragmatic Engineer Host:Experience, no, like in their sleep, they can do it, right? Right.

1:09:06Thuan Pham:So when I came in, and when I have to work with the team on dispatch, I pull in the first engineer from Uber to lean land on that team. His name is George. And so he there and then he worked for everybody else so uplift everybody there right that and then we're an engineer from VMware yeah yeah yeah yeah and then when I build payment system I have to pull in another a few more one and then when we get to build schema-less it was the Denmark team right I pulled the top four engineer from my VMware team and I moved them down from one floor to the next in Denmark so this is why we had a Denmark

1:09:45The Pragmatic Engineer Host:office which was one of the best infrastructure offices at Uber and they

1:09:49Thuan Pham:They built SchemaList.

1:09:50The Pragmatic Engineer Host:They built SchemaList. They built a lot of other.

1:09:53Thuan Pham:Right. And so now if I weren't a good person doing a good job for them, with them, why would they come?

1:10:01The Pragmatic Engineer Host:They wouldn't answer the phone.

1:10:03Thuan Pham:Yeah, they wouldn't answer the phone. Right. But every single one that I called because I really needed help, they all came. Initially, they all asked the same question, why a taxi company? But when they understand that, they came. Right. But they came because they still enjoy working with you. Right. There are people who work with me for five different companies over 28 years.

1:10:19The Pragmatic Engineer Host:And that always surprised me. And I think this is something that people might overlook a little bit as they're building out offices. I'm talking with founders is one thing is where you can hire. There are things where the good people stay for a long time. And there's a lot of value in that. And Denmark kept being very core critical infrastructure. Sure.

1:10:36Thuan Pham:Core infrastructure software team. And that's one of the things we had to build at Uber because back then when I came in, we didn't build infrastructure software, right? We just used existing open source stuff, right? And we built that. And another thing that I, you know, discovered along the way is great talents are everywhere, but, you know, you have to bring opportunity to them. They don't necessarily relocate from Denmark to San Francisco, right? And so that's why we end up having nine engineering offices around the world, because we have a lot of work to be done. We didn't go to other places because of cost savings and like that.

1:11:09Thuan Pham:We go there because we have need and we have world-class talent and we just cherry pick the world-class talent. It doesn't matter what size it is. And Denmark team was small compared to team in India, etc. But, you know, there was really great talent infrastructure and we'd invest on that. Lithuania, amazing DevOps team. And so we just go to where the talent is and then we bring the great work to the great talent. And then we establish a structure to manage and give people first class ownership of the problem. And then, you know, everybody's kind of equal.

1:11:41The Pragmatic Engineer Host:At Uber, you talked about several times of your three chores of duty. Which ones were these?

1:11:48Thuan Pham:Yeah, again, it comes back down to purpose. So when I do something, I try to be intentional about why am I doing something? What's my purpose of doing that? And so, of course, my purpose to come into Uber was, hey, let's build this business. I just built a tech that supports the business. And so the first couple of years, 18 months, 24 months, we're fixing a lot of the broken stuff. Things weren't reliable, become more reliable, et cetera, et cetera. Rebuilding, basically just getting to work and work well. and then along the way you know these things don't end and beginning on a particular day it just phase in and out right so the phase two uh that was called my second tour of duty was scale worldwide scale that was china that was massive scales everywhere in every dimension uh and so yeah so at each of those phase when you're done with that phase you ask yourself am i still useful do i want to re-up right my commitment and energies and everything else and And so the first two phases were no question, right?

1:12:52Thuan Pham:We're there to do that. And then as phase two, we're about to wrap up, right? About 2017, we actually kind of stabilized. We're really big now. I was actually asking myself that question. Am I needed here anymore? And I was actually about to wrap it up that summer. Because, you know, at that point, we had also another SDP that was higher. And I think he's really, really great technically. And I can like feel very, very at peace. Kind of, you know, there's someone who really take it on even better because the person has done even bigger thing at Google. Right. Yeah. And then, but that didn't work out.

1:13:30Thuan Pham:And then Uber has a really rough year. So then I have to like sign myself to the third tour of duty, which is, and what is the purpose of that? You know, help the company get through the turbulent years. And I had no idea at the time when that phase would end. I just kind of know the condition for that to end, which is whenever the next CEO arrives, right? And then after that, whether that person liked me, I liked that person or whatever it is, that's to be decided. But that third phase, I have to stick it through because, you know, we owe it to ourselves and we owe it to everyone along the way who have built Uber to that point, right?

1:14:06Thuan Pham:To get through that turbulent phase. So we did that. And then now when the new CEO come in and, you know, I stayed on until 2020.

1:14:15The Pragmatic Engineer Host:And so in 2017, I remember it was really turbulent. Travis had to step down for a while. A group of, I think, 14 people who were Travis's direct reports, they took over steering the company. You were one of them. So this is the point where you decided that if everything would have gone smooth, you might have actually just left, but you decided to stay on to help the company, help the team to help us get through.

1:14:37Thuan Pham:Because Uber was built by tens of thousands of people, right? Past and present. The fact that people build somewhere and then left for a rate before the moon, that's so fine. That work was still in there in some way, right? That led to that Uber that we have there. And it was a really important thing that we all built, that many of our lives were.

1:14:55The Pragmatic Engineer Host:And then just to suck it up, we went public, which went good. And then it went okay. And then, of course, COVID happened, which really hit Uber. and a few months later into COVID, you did step down. Why did you leave Uber? And why was the timing when it was and what motivated you to say, okay, this is the time to go?

1:15:17Thuan Pham:Yeah, it didn't have anything to do with COVID really. It, you know, I'm lucky enough to arrive at a point in life where money doesn't matter, right? And so then I asked myself, why am I doing anything? If I wake up every day and spending X number of hours I'm doing something. Why would I do that versus something else? And so it comes down to three things. One is, do I really love the mission and what I'm doing? And the second one is, do I feel like my being anywhere, right, is making a really big impact? And the third one is, am I enjoying the company of people I'm working with, right? And if several of those dimensions are lacking, then at some point it's not enjoyable in totality anymore right then uh then it come down to okay when you wake up and you spend 50 hours a week doing something when money doesn't matter anymore i live very modestly so it doesn't doesn't change anything so uh then why would i do that versus doing some other thing and so i think that was that was the realization at that point where i'm more like okay i'm there doing a big job but more or less running things rather than you know being very much more effective and building a company like in the early days.

1:16:37Thuan Pham:And so, and at that point, I think it's actually much better for other people who take a crack at that job. Again, you know, like everything ends, right? And so you have to decide yourself.

1:16:46The Pragmatic Engineer Host:And it did give opportunities to other people, right? So like, and they did pick it up. Now, after Uber, I remember you did an interview with a publication. I think you said that you're thinking of retiring or you'll see, but then you were not done. Oh no. You did other stuff. Coupon, Nubank, Fair. Can we talk about what happened? What was your thinking? And you never really left for a moment, honestly.

1:17:12Thuan Pham:Well, I blame that on COVID. So seriously, that one, COVID had everything to do with it. So when I left, we had a plan to travel the entire summer because our daughter was between eighth grade and ninth grade when she was about to enter high school. We had African safari plan. We have all the other travel plan. Everything got shut down. Everything got shut down. All the flights that canceled, all the country closed. And so we stuck at home, right? And I remember at the time where I'm the only one who go to the supermarket. And then like very, very sparse to kind of race through it, pick up what you need.

1:17:47Thuan Pham:And you get out with all the masks. And yeah. And so we're kind of bored though. And so I'm bored. So I sit at home and we all got on Zoom call. and lots of people want to kind of chat with me to not surprising. And so I took a bunch of calls and one of them was the founder of Coupon. And we had really great chat and, you know, it's like hard charging person, want to get a lot of things done. And I really liked that. And I think, well, I'm not doing anything here anyway. So might as well, you know, make myself useful. Right. Again, it's about how you spend your time. And so, yeah, as I did that and I, yeah, I joined there.

1:18:26Thuan Pham:and I helped some, but I learned also a ton because that's also a very interesting area, right? The Amazon style logistic. And the way Coupang does it is, you talk about five hours, six hours delivery. Wow. Yeah, you order before midnight and the thing show up and your doorstep five o 'clock in the morning, five, six. And when I was there, I joined the delivery truck, putting packages in front of people's home like two, three o 'clock in the morning. And it's brilliant, right? And all those things that you learn and you learn a whole bunch of these things. And so, yeah, it's a really great use of time, right?

1:19:00Thuan Pham:Given the circumstances.

1:19:01The Pragmatic Engineer Host:Yeah. And then you became, was it, is it an advisor or a board member at Nubank? A board member, yeah. And Nubank is, for those that don't know and outside of the U.S. or Europe, it is the most successful and highest valued non-U.S. company. It's the largest growing bank in Latin America. It's extreme. It's engineering culture. I hear amazing things about. You're the first person I'm actually talking about. So what did you learn there? And you're still involved, right?

1:19:29Thuan Pham:Yeah, yeah, I'm still involved, but as a board member capacity. And for a while, I also took on a more active responsibility to mentor the CTO, right? A couple of them. And so, yeah. And so, again, it's all about being useful. We all learn a lot in our journey and working with really smart people, really motivated people younger and impart that knowledge and sharing you know what you see and advice help people move forward better faster and and i find that very fulfilling and so so that was that and the culture there is very vibrant i mean it reminds me of our early days uber when everybody is gung-ho hard charging the founder is hard charging everybody is and when i visit there usually during board meetings, once a year, we kind of go down to Brazil and we will have all hands with the entire company.

1:20:25Thuan Pham:And sometimes I also did all hands with the engineering team and do AMA style the way we all did at Uber. And so it's just very energetic, right? And there are many factors to their phenomenal success. One is like very much like Uber, they actually solve the right problem at the right time. There's a whole bunch of unbanked population before new bank came along and they deliver like leapfrog that of traditional banking just online on the app and the experience is beautiful the nps score is through the roof uh and it ultimately it adds a lot of value to people right life and that's why the adoption rate is crazy high right and and and so yeah well executed um amazing product vision phenomenal cultures and energy and all those factors are very common and like great companies then we experienced one of those things at uber or two in the early days.

1:21:15Thuan Pham:So it's really, really energizing being a part of that.

1:21:18The Pragmatic Engineer Host:And they're doing great. And now you're the CCO at FAIR. What made you join FAIR?

1:21:24Thuan Pham:I took a couple of years off when my daughter was finishing high school because I figured that time would not ever come back when she's gone and she's gone now.

1:21:32The Pragmatic Engineer Host:Was it the right choice?

1:21:33Thuan Pham:Oh, absolutely. I would not take that time back. So that was, yeah.

1:21:37The Pragmatic Engineer Host:I'm so glad.

1:21:38Thuan Pham:Yeah, 10th, 11th grade and 12th grade. I get to stay home, drop her off, pick her up, cook, you know, hang out together, help with college application, all of that stuff. And so the bond we had was really cool. And as I was thinking about her going to college, I was thinking, well, I'm going to have a lot of time on my hand. So what should I do?

1:21:58The Pragmatic Engineer Host:Here we go again.

1:21:59Thuan Pham:Exactly. Right. And so should I join another board, which I was about to. And then at the last minute, some partner at Sequoia asked me to meet Max, the CEO of Fair, and really liked him. very smart again all the same characteristic very smart uh very hard charging want to do all the right thing the business is empowered you know local you know business businesses can we talk

1:22:26The Pragmatic Engineer Host:a little bit about that because from the outside you know when you google fair and you and i look at it it doesn't tell you exactly too much feels a little abstract from the outside it is a b2b

1:22:36Thuan Pham:marketplace right between a big brand wholesalers and retailers so people buy that and then stock their storefront. And so, yeah, and so all the traditional two-sided marketplace dynamic apply. And the mission is very similar to our mission rule, but even though we are B2C, right? This is B2B, but it's all about what can we do to empower local businesses to florist, right? So to buy the right thing, to sell through, make a profit, grow that business.

1:23:04The Pragmatic Engineer Host:So basically this can help small and also large businesses to actually just like grow their business. May that be like just getting inventory.

1:23:12Thuan Pham:More successful demand, more demand, more supply, all of that stuff, right? So yeah, it's like a really, marketplace, this is really fun and very complex. And so I really like that. And I really, when I dig in through the interview process and everything else, and again, this company moved really fast. Within a week, everything was finished, including my homework assignment, right? I have to go and present and everything else. And so the company moved really fast. It's energizing. And the culture is super nice and super kind. You know, like no politics. Everybody's just focused on doing the right thing and work with each other, taking care of one another.

1:23:47Thuan Pham:So it's a trifecta. It doesn't matter if the company is really big or really small, right? But it's got all the ingredients. So I said, well, maybe that's a good place to jump in and help out.

1:23:57The Pragmatic Engineer Host:And can you give us a little context on FAIR in terms of the size of the company, the size of the engineering team, where the hubs are, what the work is like? Is it in person? Is it hybrid? And so on.

1:24:07Thuan Pham:Yeah. The company is about a thousand person. The engineering team, including the data science team combined, is about 300 people. The work, we are in the office three days a week. Yeah, three days on the week. The other two are working remotely online. Yeah, and some people throw up more if they live close to the office. Yeah, the engineering team, there's a portion here in SF, just down the street from here. And a large part is in Canada. They would have a big office in Waterloo and we have a big office in Toronto. So I make the trip there quite often. Every five, six weeks or so, I'm over there.

1:24:50The Pragmatic Engineer Host:And what are some interesting engineering challenges that you're excited about right now that you're solving?

1:24:54Thuan Pham:Oh, right now, clearly, the most exciting thing is AI and how is AI changing everything so quickly.

1:24:59The Pragmatic Engineer Host:Tell me, what are you seeing? What's working? What's not on your teams?

1:25:04Thuan Pham:In my team as well as in the company, we're using AI to boost everyone, effectiveness and proactivities and output. And so that's one. Within the engineering specifically, we use AI to make search and recommendation better. Because the whole job is to help people discover things that would sell really well for their business, etc. And imagine AI as a shopping consultant and all that stuff. And then coding-wise, you know, AI is doing a lot more of the coding now. But we also use different techniques to actually boost engineering productivity. Have you heard of like swarm coding?

1:25:44The Pragmatic Engineer Host:So swarm coding as in the agents?

1:25:46Thuan Pham:Yeah, a whole bunch of agents are swarmed of agents, right?

1:25:49The Pragmatic Engineer Host:It's pretty new, so you're already using it.

1:25:51Thuan Pham:So we are already using it. And we're building orchestrator to orchestrate the action of all this agent. And we measure first the early adopters, and then the bulk of the engineer follows through after we build the more robust tooling. And we see dramatic lift in engineering output. Among the early adopters, the ones are really efficient at thinking this way, right? Because it's very different from a linear kind of thinking. When I write this code right now, it's almost like multi-threaded programming with single-threaded, right? You have to think about all these sort of things. you have to prompt all the action, and then you have all this code that come back at you and you have to review it, you have to sit together.

1:26:28Thuan Pham:Yeah, and it required a different way of thinking and the cognitive load might be a little higher, but the output is dramatic. We have seen our best engineer double their output.

1:26:39The Pragmatic Engineer Host:I know we're talking about that, but just to make clear, we're talking about not the code out, but the actual business out, but the impact of their work, right?

1:26:46Thuan Pham:Yeah, the impact now depends on the evolution of AI, right? So right now, the state of the art right now is it's very easy to make large-scale changes, right? Clean up and everything else, right? So massive productivity increase. Now we're trying to crack the next frontier, which is how we get that level of productivity increase in output, building new features on top of a code base that are older, right? It's not like you and I can just go build something brand new, not entangled anything. It's really fast. The whole thing will generate for you, right? Yeah, but we got millions of lines of code.

1:27:19Thuan Pham:And how do you deal with that and build features on top with all those dependencies and all that stuff, right? Can AI good enough now to help us untangle some of those things along the way of building new things? And so we actually, you know, continue to work on that and figure out how we can actually continue to boost more and more productivity out even building new features with AI.

1:27:38The Pragmatic Engineer Host:How do you think AI will change software engineering and what a software engineer does and what skills we value?

1:27:43Thuan Pham:Yeah, it's already changing. I mean, very rapidly, fast. These changes are faster than anything I've ever seen. including the internet, right? Back then, I remember when we first learned how to do programming, we have to know a lot about the machine architecture. We have to know about virtual memory. And then we have to learn how to like syntax and coding. All of that stuff has been abstracted away now, right? Social AI used to say, I want X, Y, and Z, blah, blah, blah. And it should be this way. And the whole thing gets constructed, right? So it elevated the level of the playing field where people who don't even know how to program can now create good, you know, good, decent code and apps or whatever it is.

1:28:20Thuan Pham:I look on the surface really good. So it is game changing, right? It, it, um, it elevates the playing field. Now, then in that level of, of abstraction, how do you tell the great engineer from the good engineer?

1:28:34The Pragmatic Engineer Host:Great question. How do you?

1:28:36Thuan Pham:Well, from what we see so far, the great engineers are still finding a way to leverage this and accelerate the output even more. Then we see the difference between the great engineer and an average engineer is still 2x in terms of their capability. They're more inquisitive. They're at the bleeding edge more. They're more innovative, right? And then there are people who like, okay, well, here's the tool that you give me. I'm going to be two times more productive, right? Because I'm using this tool. It's great. But the great engineer continues to break new boundaries. And so I think that is still a very...

1:29:09Thuan Pham:You can still, you can look at people and you can see who are the high performer versus who are average.

1:29:16The Pragmatic Engineer Host:So do I hear correctly that the traits that you're seeing in your real engineers is, we didn't mention, but it's kind of a given the foundations plus curiosity, plus innovation.

1:29:26Thuan Pham:Fearlessness, willing to innovate, willing to stretch, willing to try new things and break new ground. All of those traits that still exist. Interesting.

1:29:33The Pragmatic Engineer Host:If I think back to like just the Uber days or your startup days, those traits were kind of the traits of the standout.

1:29:38Thuan Pham:That's right. Those things that make someone outstanding versus someone average.

1:29:41The Pragmatic Engineer Host:So I guess maybe an advice is like, well, I mean, try not, like if you were a great engineer before, just don't be complacent and keep using, keep approaching the same way, right? Correct.

1:29:50Thuan Pham:Yeah. Complacency is death. I mean, like every, the world will move faster and faster. And the moment we stand still, we're falling behind.

1:29:58The Pragmatic Engineer Host:It sounds like if you worked at a fast-paced startup before, which is, this is how it works. AI should be familiar.

1:30:05Thuan Pham:Welcome to how it was before. To me, it is an incredibly powerful tool, but in the end, it's still a tool. And you can wield the tool properly. You can do extraordinary things. Versus you just merely use a tool in a mundane way. You're not going to build great stuff.

1:30:21The Pragmatic Engineer Host:So we talked about standout engineers in this age. I'd like to talk about something that I cannot talk with too many things, standout CTOs. You have now been CTO at multiple companies. I lost VP of engineering. You've been at some of those highest engineering leadership. and at Uber, at Fair, you've done an outstanding job as a CTO. What is the most important job of a CTO?

1:30:41Thuan Pham:Yeah, there are a couple of angles to this. One is build a high-performance team, right? Talent, culture, all of that. Whatever it is that you got to do, put the org structure, develop the talent, prune bad folks out, or whatever, everything that you need to do to make sure that you have really high talent density. Because when you have team A, team A will just want to hire more A-level players. And yeah, they're just intolerant of anybody who's not performing, right? So when you get to, but you got to get to that concentration and then it's kind of just self-protecting, if you will, right? And then, of course, you have to create an environment where people really trust each other and align and work really well together, right?

1:31:27Thuan Pham:Because you put an all-star team together, it doesn't mean they work really well. if you don't have like the cultural alignment, right? So that organizational side of things, I've always deeply believed in that if you do that one well, then good outcome will just happen. It doesn't matter what you want to do, right? They will just be able to come out with great results because we have great talent and with great motivation. The other side is you have to look in the future and see around that corner, right? For example, I always think about two years out. What does great data look like? Do we have the key ingredient, if you will, talents and otherwise to actually get there?

1:32:12Thuan Pham:Whether it's architects, leadership, whatever. And what problem are we trying to solve? What would the business look like? So the famous Wayne Gretzky quote is, get to where the puck will be. So yes, and envision that future. And I would share this with everyone at every management level, that when you're in any level, your job is to see a little bit further out than your folks. Because your folks are busy working on the near-term things. And then you have to see, because if you don't do that, then it's your job to actually do that.

1:32:43The Pragmatic Engineer Host:Well, let's put this to the test, because right now is the most so many people, including me, see it's an unprecedented time with growth. How do you look around the corner? What do you see around your corner right now? Like what will be coming, maybe not if in two years, but even in six months?

1:32:57Thuan Pham:Well, in six months, you know, we know what we need to do. In fact, it's too short, right? It's like these are the things.

1:33:04The Pragmatic Engineer Host:Let's talk about two years. I recently asked OpenAI on what they see in two years. They're like, oh, that's too long. Let's talk six months.

1:33:10Thuan Pham:But in context with everything, right? For them, they're trying to reinvent that future. And sometimes things are changing too fast there from that context. But from there, the business, we know what business result we want to drive. We know what project we need to execute. right to me that that's pretty much lock and load it just require good execution right good adjustment along the way to me 18 to 24 months out is my job to look at while my team is worrying about the six month problem right and so for example there are many areas that we need to clean up right there's the data ecosystem that's been old and you know same problem we saw at uber too you know something changed upstream breaks things downstream and how you really clean it up with all this, you know, older, you know, code base, then, you know, what is the next generation of search and discovery that are AI driven, right?

1:34:01Thuan Pham:You know, something consulting to look like productivity, right? How can we leverage AI to like double output on, you know, feature development, right? So all of these things, what does that future need to look like? And do we have the horsepower and to get there, right? In terms of expertise, management and planning, all that stuff. And then if the answer is no, then it's like the next question, how do we actually position ourselves there? Who do we recruit? So that's the job policy on the non-management side.

1:34:34The Pragmatic Engineer Host:And then finally, what advice would you give to a young engineer, someone, let's say 25 years old or a new grad who is entering the industry right now? Lots of change.

1:34:42Thuan Pham:For folks who are entering the workforce right now, I have to acknowledge it's a very scary time because it's very bumpy. even at our company right now, we still bring in a new grad, but it come through our intern co-op channel, right? We're not in the world where we just hide massive number of new college grads like the old days anymore, right? But if great people are still finding opportunity, right? We have a a healthy cohort of co-op every single four months that come through. Right. And the best of the best to get offered from us, because if we don't hide those folks today, what senior engineer we will have for years from now.

1:35:29Thuan Pham:Right. You have to feed the talent pipeline and great people are great people. They will learn and grow. And yeah. And so, so that will always, the opposite will always be there for great talent. So invest in yourself. when a student, you know, volunteer, doing interesting, solve hard problem early on. The earlier and harder you work early on, the better you will have in the future. If you take it too easy right now, then the road in the future might be a little harder. So I think that's the key. And then when you enter the industry, it depends on, I think, career phases. I would say the first five, 10 years or so, find obviously what you learn the most, that push you the most.

1:36:11Thuan Pham:Because those are the times that you have the most energy to develop your skill and ramp up really fast. And when you get to like senior engineer staff, engineer range, then you know enough to be very dangerous in terms of making a big impact. Then seek opportunity where you can make a big impact. Maybe a smaller company will allow you like a bigger stage to actually make a huge impact, right? Let's take some of that risk and do that. And that phase should be about using what you know and make as big impact as you can. And you will learn along the way too. and then when you get to the next phase where hopefully if you're really good, you're already at this, you know, principal engineer, senior staff or on the management side, senior director, VP, whatever it is.

1:36:47Thuan Pham:And then that point, you learn to give back, right? You learn to coach and develop people along the way. You'll be leading and be responsible for very big things. You know, apply that knowledge to do a really great job, but also teach and bring other people along. So different phases, you should change the priority a little bit.

1:37:06The Pragmatic Engineer Host:Tuan, thank you so much. This was a great conversation.

1:37:11Thuan Pham:So I hope that everyone will find this useful.

1:37:14The Pragmatic Engineer Host:What a conversation. So many of these stories have not been told before, and I hope you enjoyed them as much as I did. The microservices story is such a good one. Nobody at Uber planned to have thousands of microservices. It happened because every time they tried to decompose a monolith, the business was growing so fast that other teams were adding to it faster than the decomposition team could pull things out. It took two years to do something that, in isolation, would have taken three to six months. Uber had unusually violent business growth that resulted in unusually fast cold growth and microservices helped Uber tame its growth.

1:37:45The Pragmatic Engineer Host:But unless you're growing at the speed of Uber, you probably will not need thousands of microservices. Oh, and fun fact, in 2026, Uber has fewer microservices than they had in 2016. I also found it fascinating how Twan's entire career was shaped by relationships he built by simply doing great work. Bill Gurley reached out about Uber because he remembered Twan from NetGravity, a company from a decade earlier that didn't even win this market. The engineers Twan pulled from VMware into Uber came because they genuinely enjoyed working with him. There was no networking strategy, just years of being good to people, compounding quietly in the background.

1:38:21The Pragmatic Engineer Host:Finally, Twan's point about AI was an interesting one. Complacency is death. The traits that made someone a great engineer before these AI tools, curiosity, fearlessness, willingness to try new things, are exactly the same traits that make someone great with AI tools. The tools changed. What makes people exceptional has not. Do check out the show notes below for more deep dives on Uber and Uber's engineering culture, as covered in the Pragmatic Engineering newsletter and podcast. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show.

1:38:52The Pragmatic Engineer Host:Thanks, and see you in the next one.