Thuan Pham on Scaling Uber: Surviving Hypergrowth, Rewriting Under Pressure, and What Still Makes Engineers Great
The Pragmatic Engineer
Thuan Pham joined Uber as its first CTO in April 2013. The company then had about 40 engineers and roughly 30,000 rides a day, and its systems crashed several times a week. Pham stayed seven years. In this conversation with the host of The Pragmatic Engineer, who worked at Uber for almost four of those years, Pham explains how the engineering organization got through that period: rewrites made against hard deadlines, an org structure invented because the old one had stalled, a China launch that outside peers called impossible on that timeline, and a microservices explosion nobody planned. The same view runs through all of it. Under violent growth, the job is to buy enough runway to survive, not to build the perfect system. Pham also talks about his current role as CTO of Faire, how the company uses AI, and why he thinks the traits that make a great engineer have not changed.
From refugee boat to MIT
Pham was born in southern Vietnam. His father was tied to the southern military, and after the country was unified in 1975, families connected to the old regime had few opportunities, including in education. Pham notes that this is not necessarily true today. His mother decided her two sons would not grow up that way, and the family joined the "boat people" exodus. By Pham's account, about two million people left and about a million survived the crossing, because the boats were not seaworthy. People did not dwell on the odds, he says. If they had, they probably wouldn't have gone.
Getting out took four attempts and drained the family's savings, because several of the earlier arrangements were scams: pay half now, and the boat never comes. On the fourth try they had a good captain who got them through storms and past Thai pirates. Pham was about 11 or 12. After three days and four nights crossing the South China Sea they reached Malaysia. A week later they were towed back out to sea and left near Indonesia, which took them in and placed them on a deserted island that became a refugee camp. The United States accepted them because of the family's ties to the US-backed regime. They arrived with no English and no money, sponsored by a church, wearing clothes from its donation closet.
Pham found computers through a high school friend whose father gave him an IBM PC with two floppy drives in 1982. They wrote BASIC programs and learned Lotus and WordStar, and Pham found that thinking algorithmically came naturally. He calls himself a procrastinator who hates doing the same thing twice, and says programming suited him: you solve the problem once creatively, and then the machine repeats it faster than any person could. He volunteered at a government agency and tied Lotus, dBASE III and scripting languages together to automate its financial accounting. Two accountants had spent about three weeks every quarter reconciling the books. Pham turned that into a batch job started with one button that ran in about three hours. The agency's recommendation letter helped him get into MIT, where, he says, he learned the actual fundamentals of computer science.
Early lessons: research that never shipped, and technology ahead of its time
An MIT co-op program matched Pham with Hewlett-Packard Laboratories. He did joint bachelor's and master's thesis work there and was hired into the lab afterward without a PhD. In the mid-to-late 1980s the lab was working on medical informatics: a networked, distributed architecture where a patient's records and X-rays followed them to any physician workstation, plus a knowledge base that checked for drug interactions. Pham was frustrated that the work ended in published papers. Product divisions picked research up only at an annual tech fair, and he wanted to write code people would actually use.
He moved to Silicon Graphics, which was building interactive TV: video on demand, online shopping and online games delivered to about 4,000 cable-connected homes in a trial. They invented network protocols along the way and put an SGI box on top of a tube TV. Celebrities, including Michael Jackson and Steven Spielberg, came to see the demos. Pham says the team really believed this was the future, and it was, but "way way ahead of the time." About a year in, the economics were clearly unworkable. Provisioning the head-end cost around $100 million in 1994, and the set-top box was a $45,000 workstation. A similar trial with NTT in Japan went well and then fizzled for the same reason. His lesson was that technology alone isn't enough. You need the right place, the right time and the right price point.
NetGravity: when a competitor chose growth over profit
Pham next joined a startup founded by a former SGI officemate. It was first called Netvertiser and quickly renamed NetGravity, and it built enterprise software for serving dynamic banner ads on sites like CNN and Netscape. The premise was that advertising had funded TV, so it would fund the free internet. Pham believes he was the fourth engineer. He says he and a colleague put the first dynamically targeted ad on the Yahoo page, moving from a script that rotated a static banner every hour to targeting based on page content, cookies and ad sequences.
The company went public, but Pham draws a second lesson from it. A later competitor built an ad service bureau: publishers pasted a tag into their HTML and revenue came in, with far less investment required on their side. NetGravity had wanted to do something similar, but a board member pushed it to reach profitability before expanding. NetGravity became a larger, more robust enterprise product while the other company spread across the internet and was eventually bought by Google. When the host sums it up as a growth-focused, unprofitable player being able to swallow a profitable one, Pham agrees and points to Uber as a company that made the other choice.
Over seven or eight years Pham went from individual contributor to VP. He moved into management because his SGI experience taught him that big things require leveraging other people.
The dot-com bust and investing in yourself during "peacetime"
Asked what the bust felt like, Pham describes a period of exuberance when everything was a ".com", including Pets.com and Webvan (he still has a Webvan bin in his garage), followed by a shakeout. Growth alone eventually burns through money, he argues. Durable companies need a value proposition customers will pay for. He expects a similar sorting among today's AI companies, with the market deciding in the end.
The downturn lasted a couple of years, and hiring was hard, especially for new graduates, who he says are always hit first because companies retrench toward experienced people. His advice is to invest in your skills in peacetime and never become complacent. Strong, hungry people who punch above their weight stay marketable even in a downturn, and people who let their skills atrophy find hard times very difficult to recover from.
Going small again, then VMware
Pham tested himself on purpose. After reaching VP at a company of hundreds, he wondered whether his success was "a fluke." He joined a four-person startup, a classic leaky-roof operation, which grew to 40–50 people in about three years before running out of money. It was acquired by a company building a security appliance for intermediating web services traffic, a niche Pham says was hard to break out of. The venture didn't succeed commercially, but he says his skills kept improving, and that you have to trust that working hard makes you better whether or not the vehicle wins.
He then joined VMware while it was still fairly small, in a 40-person division building enterprise software to tie hypervisors into a management and cloud platform. That team built VMware's first product suite, VirtualCenter, which worked with ESX. Pham considers vMotion the key feature: live migration of a virtual machine between hardware with no perceptible downtime. In his view it made a thousand machines look like one and turned VMware into something like a cloud operating system.
He eventually ran an 800-person engineering team. After eight years the product was in its third generation and mostly getting new features, the original founders had left, and the leadership had changed. Pham says he gets nervous when he feels too comfortable, and he decided it was time to go.
How reputation led to Uber, and a 30-hour interview
Pham says he never ran a job search in the usual sense. Doing good work and treating colleagues well slowly builds a reputation, and when you become available, people come to you with options. Uber came through Bill Gurley of Benchmark, who knew Pham from NetGravity a decade earlier. Gurley showed him Uber's board deck, and Pham understood the business model. Later, when he tried to recruit people, the constant question was why he was joining a taxi company.
According to the host, Uber had just raised a $30 million Series B at a $300 million valuation. The interview process with Travis Kalanick is the notable part. Kalanick spent more than 30 hours interviewing Pham one-on-one over about two weeks, at least a couple of hours a day. The first meeting, planned for an hour, ran two. The two went straight to a whiteboard, and Kalanick wrote out a long list of general topics (hiring, firing, communication, design), a shorter list of engineering-specific ones (code quality, QA, design) and a list of five things he wanted in an engineering team and its culture. Pham had barely left the building when the recruiter called to set up more time. From then on, they held a two-hour Skype session each day while Kalanick traveled between regional offices, taking one topic at a time. Pham still has a photo of the whiteboard on his phone.
Pham says that after a while he forgot he was being interviewed. It felt like exchanging ideas, disagreeing and working things out. He later came to see it as a simulation of what working together would be like. Kalanick, he says, viewed Uber as having two engines, physical operations and technology, with neither more important than the other. Pham was struck by the commitment: in one session that ran long, Kalanick called his assistant mid-conversation to move a flight so they could keep going.
Dispatch: five months until the brick wall
When Pham started, Uber ran only black cars in about 20–30 cities. The roughly 40 engineers were young, scrappy and talented, and the product experience was excellent, which drove word of mouth. But the system had been built for functionality, not scale, and it went down multiple times a week. Kalanick had told Pham in the interviews to "see around corners," so after his first weeks of building relationships and trust, Pham started asking what would break first. The answer was dispatch, the service that matches riders and drivers, without which there is no business.
Dispatch was a single-threaded Node.js process. As a city grew, the three- or four-person team moved its process to a faster machine. Pham says part of his role was to teach, so instead of declaring the design broken he asked leading questions. What happens as the city grows? Move to a faster processor. What happens when you reach the fastest one? Use multiprocessor boxes and run several processes. Do those processes share state? Not really. The engineers worked out for themselves that the approach was hitting a wall.
He then asked for the biggest city by ride volume, which was New York, and when it would exceed even the largest available machine. It was about May, and the answer was October. Dispatch had to be rewritten, and Pham gave only two requirements: a city must be served by multiple boxes, and a box must be able to serve multiple cities. No new features. With that N-by-M property the company could add hardware and, in principle, scale indefinitely. The simple requirements let the team move fast, and the new system was deployed around August or September, shortly before the limit. The database and the API monolith were next in line, and the pattern repeated: estimate how much runway remains before a threat becomes fatal, then get ahead of it.
That is why Uber rewrote systems so often, Pham explains. The faster you grow, the less runway any given architecture gives you. Speculating about eventual size wasn't useful, he says. What mattered was how long the company had before hitting a wall. If he had told engineers to build a system that would scale forever, it might have taken a year, and "we'll die before then." A quick rewrite bought perhaps 12 months, during which the team could plan the next phase. His phrase for this is buying enough runway to "live to fight another day."
China: from "two months" to five
Around Christmas 2014, at Uber's office at 1455 Market Street in San Francisco, Kalanick announced that Uber would launch in China in the new year. A requirement had emerged that services run on physical servers in China. Until then Uber had tested the waters by serving China from the US. Kalanick asked for two months and asked why it couldn't simply be done by racking machines and copying the software.
Pham explained that a copied system works on day one and then diverges, and Uber didn't have twice the engineers to maintain two drifting systems. The right approach was to re-architect into one system that could be partitioned. There were also serious security concerns. Nothing running in China could be assumed to have any privacy, while everything elsewhere had to be protected, so data and controls had to be fully partitioned while every deployment still went everywhere. The technical program managers scoped it at about six months, which was the fastest they could imagine. Industry friends Pham benchmarked with laughed and said 18 months at minimum. Kalanick didn't like six months either, so they "split the difference" at four and got to work.
At four months they were about a month short, and Kalanick was unhappy. At five months they were close but about to slip again. Pham negotiated: the team was confident it could launch within a month if allowed to roll out incrementally, a batch of cities per week over a few weeks. Kalanick agreed on the condition that the biggest city, which Pham names as Chengdu, go first.
Pham has come to think this was the brilliant part. Starting with the hardest city meant everything afterward was downhill, and the team went into each new batch with confidence. Starting with the smallest city looks like good risk control, he says, but it would have meant holding their breath every week. After launch, some burnt-out engineers took a month off and "stared at the water." Afterward, Pham says, the team wasn't afraid of anything. The host adds that a friend on the IT team had about two weeks to physically set up the servers, and that every engineer he later spoke to described their own piece as impossible, yet it came together. Uber then competed head-on with Didi. Pham connects the episode to Kalanick's idea that you sometimes have to be willing to "redline" yourself to find out you can do more than you thought.
The program/platform split
The org structure came before the microservices, and Pham says it came out of necessity. Between April and the end of 2013, engineering grew from 40 engineers and three product managers to about 100 engineers and a dozen PMs. Even at that size the functional structure ground work to a halt. Every feature had to be queued on the capacity of the mobile team (eight to ten developers), dispatch (five to eight people), backend and infrastructure. Trade-offs couldn't be managed because each feature needed negotiations with many teams, and engineers complained right away, which Pham considers healthy.
Kalanick, Jeff Holden and Pham spent a couple of days working it out with sticky notes, one color per function and one name per note. Kalanick listed what he saw as the business's most important areas, which came to 17 at the time (there turned out to be far more). They had enough people to fund seven, plus part of the next four, and the rest stayed empty until hiring caught up. The principle was that each team had to be cross-functional, with every skill needed to get its work done on its own. Teams building what end users touch became "programs." Teams building tools and layers that programs use became "platforms," a vertical-versus-horizontal split. Then they placed the sticky notes into the boxes.
Why Uber ended up with thousands of microservices
"None of us wanted to go through that extreme," Pham says. Under constant pressure, the priority was speed, and the backend API monolith was clearly what would slow things down. The rule became that anything new had to be built outside it as a microservice, while a dedicated team broke the monolith apart in a project called Darwin.
Pham estimates that with time frozen, the decomposition would have taken three to six months. It took two years because the business kept moving: new cities, new products such as UberX, and overlapping hockey-stick curves. The operating philosophy was that nobody could block anybody else, so teams that needed a feature in code not yet extracted added it to the monolith. The monolith grew even as pieces were pulled out, because the remainder grew faster than the extraction, until it eventually peaked and began to shrink. Meanwhile everything new fanned out into services. Once growth became less violent, a project called ARC cleaned things up by putting domain interfaces over groups of related services. The host notes that a 2016 Uber blog post cited about 5,000 microservices and a recent one about 4,500, so the count has fallen slowly while the business has become more complex. That complexity also required new tooling, such as the tracing tool Jaeger, which Uber open-sourced.
Internal tools, born from breaking open source
The host lists some of Uber's internal and open-sourced infrastructure: Jaeger, the Schemaless trip datastore, the TChannel RPC protocol, Ringpop, observability tooling, and hundreds more. Were they all needed? Pham says he can't claim every one was, "but all the important ones were absolutely necessary." Early Uber used off-the-shelf open source such as Redis. In 2013–2016, he says, open source was less mature, and big companies like Google and Facebook kept their infrastructure internal.
His most painful example is PostgreSQL. At a certain scale it began failing randomly, taking services down, with the problem deep in the kernel. Pham recalls asking people on LinkedIn for anyone with Postgres expertise to consult, and spending several weeks on it. What frightened him was depending on something nobody owned. He would have paid anything for an answer, and there was no company to pay. That experience helped motivate Uber to build its own data layer, using MySQL only as a table store with Uber-built logic on top, so it controlled its own state and built only the features it needed.
Other limits followed. Around the 2015 holidays Pham took an Uber to the airport and got the receipt two days later, because data processing was at capacity and work was queuing up. Delayed receipts weren't a dealbreaker, since the ride itself had happened, but it meant more rewrites. Monitoring built on open-source tools was also near its breaking point, which led to M3. Uber, he says, had reached a scale that broke the open-source tools it used.
Helix, and the "not a Mickey Mouse shop" email
Helix was the full rewrite of the rider app, where the host first met Pham. The host describes a codebase of one to two million lines and two to three hundred mobile engineers. Pham corrects the idea that it was mainly a design cleanup. The vision came from Kalanick and lead designer Yuki, who storyboarded it together. The old app did "push a button, get a ride" well but was too limiting to host more services, such as messaging during a ride, and the new architecture was far more open. The backend changed too, including the move from polling every five seconds to a push-based real-time system. Pham says it took perhaps 600–700 engineers across seven to eight months. He notes the app still runs on that architecture today, calls the design almost future-proof, and gives the credit to Kalanick and Yuki.
Pham also recalls an all-engineering email about naming. The trigger was a service named "Mustafa," whose purpose he couldn't tell. As the company kept onboarding engineers and tooling for mapping names to meaning was still weak, whimsical names with no context slowed people down. He wrote that Uber is "not a Mickey Mouse shop." He admits mass emails can have side effects without solving the problem, but says the point was that at that scale the company had to take itself seriously.
Engineering levels and making internal transfers easy
Pham stands by splitting the L5 senior level into L5A and L5B: "I'm not apologizing for it." Uber benchmarked its staff-engineer bar against companies like Google and Facebook, and getting from engineer II through senior to staff could take five years. Splitting the level gave people a sense of progress and a meaningful stopping point for those who might never reach staff. It worked for a while, then people adjusted and pushed to reach staff faster. Pham held the line while he was there. After he left, he says, the levels shifted down so that L5B became staff, which he calls inflation he didn't want.
In 2016 he announced an easy internal transfer process after hearing engineers felt unsupported by their managers. His reasoning was that people who resign to join another company don't ask their manager's permission to interview, so requiring permission to move internally only made leaving easier than staying. He also expected it to push managers to develop their people so they would want to stay. It met considerable pushback, but they did it anyway, along with an internal job board mirroring external postings. His line: "It's not a jail."
Relationships as the real network
The host asks about a talk former colleagues remember, about seeing work from the perspective of death. Pham doesn't recall the exact speech but says the idea is always with him. The most accomplished people don't take themselves too seriously. Deference comes from the position, not the person, and the world forgets you once you leave the role. So he measures himself by how many people remember him as good or helpful to them. It shouldn't be a networking tactic, he stresses, because doing it for that goal is artificial. Just be genuine.
He adds that the relationships also let him deliver. Uber's engineers were young and hadn't built reliable systems at scale, while Pham's VMware network could. His first pull was an engineer named George for dispatch. More came for payments, and for Schemaless he recruited the top four engineers from his VMware team in Denmark, which is how Uber's Denmark infrastructure office started. Everyone he called for help came, after first asking "why a taxi company?" Some people have worked with him at five companies over 28 years. The same logic explains Uber's nine engineering offices: great talent doesn't necessarily move to San Francisco, so Uber brought work to it. That included a small but excellent infrastructure team in Denmark and a strong DevOps team in Lithuania, each given first-class ownership. Pham says cost savings weren't the reason.
Three tours of duty, and leaving
Pham describes his Uber years as three tours, each with a purpose, re-evaluated at the end. The first 18–24 months were about fixing what was broken and making things reliable. The second was worldwide scale, including China. Around 2017, with things stabilized, he was ready to leave that summer. A new senior technical leader had been hired, someone Pham rated highly who had done bigger things at Google, and he felt at peace handing over. That didn't work out, Uber had a very rough year, and he signed up for a third tour: getting the company through the turbulence. He knew only the condition for it to end, the arrival of a new CEO. He says he felt he owed it to the tens of thousands of people, past and present, who had built Uber. After the new CEO came, he stayed until 2020.
Pham says his departure wasn't about COVID. With money no longer a factor, he asks three questions: does he love the mission, is he making a big impact, and does he enjoy the people? When several of those are lacking, the whole stops being enjoyable. He was running a big job rather than building, and felt it was better for someone else to take it on.
Coupang, Nubank and Faire
The retirement didn't last, and Pham blames COVID. A summer of travel, including an African safari with his daughter before high school, was cancelled. Bored at home, he took many calls, including one with Coupang's founder, and joined to help. He learned about Amazon-style logistics with deliveries where an order placed before midnight arrives by 5 a.m., and he rode along on delivery trucks at 2 or 3 in the morning. He also joined Nubank's board and for a while mentored a couple of its CTOs. He compares its energy to early Uber and credits its success to solving the right problem at the right time for a large unbanked population, a well-liked product with very high NPS, and a strong culture. He attends an annual all-hands in Brazil and sometimes holds Uber-style AMAs with engineering.
He then took a couple of years off while his daughter finished high school, driving her to school, cooking and helping with college applications. He says he would not take that time back. As she left for college he nearly joined another board, but a Sequoia partner introduced him to Faire's CEO, Max. Faire is a B2B wholesale marketplace between brands and retailers, and Pham sees its mission of helping local businesses flourish as similar to Uber's. He was drawn by how fast the company moved (the process, including a homework presentation, finished within a week) and by a kind, low-politics culture. Faire has about 1,000 people, about 300 in engineering and data science, works in the office three days a week, and has engineers in San Francisco and large offices in Canada, including Toronto, which Pham visits every five or six weeks.
How Faire uses AI, and what separates great engineers now
Pham calls AI the most exciting challenge. Faire uses it to raise productivity across the company, to improve search and recommendations (imagining AI as a shopping consultant), and for coding. The team uses "swarm coding," many agents working in parallel, and is building an orchestrator for them. Early adopters showed a dramatic lift, and after more robust tooling the bulk of engineers followed. Pham compares the shift to going from single-threaded to multi-threaded programming. You prompt many actions, review and stitch together what comes back, and carry a higher cognitive load. He says their best engineers have doubled their output, meaning impact, not lines of code. For now, he says, AI makes large-scale changes and cleanups easy. The frontier they are still working on is getting similar gains when building new features on top of millions of lines of older, entangled code.
He calls this change faster than anything he has seen, including the internet. Programming once required knowing machine architecture and virtual memory. Now people who can't program can produce decent-looking apps. Still, he reports that great engineers differ from average ones by about 2–3x, because they are more inquisitive, stay at the bleeding edge and keep pushing boundaries, while others settle for the productivity boost the tool gives them. The traits are the ones that always marked standout engineers: fearlessness and willingness to stretch and try new things. "Complacency is death," he says. AI is powerful, but it is still a tool you can use well or in a mundane way.
The CTO's job, and advice by career stage
Pham sees two sides to the CTO role. The first is building a high-performing team: structure, talent development and pruning, until talent density sustains itself because A players want to hire A players and won't tolerate underperformance. Talent alone isn't enough without trust and cultural alignment, and if the organizational side is right, he believes, good outcomes follow. The second is seeing around corners. Pham looks 18–24 months out while his teams handle the six-month horizon, which he considers essentially locked in and a matter of execution. At Faire that means cleaning up an old data ecosystem where upstream changes break things downstream (a problem he also saw at Uber), defining the next generation of AI-driven search and discovery, and working out how AI can double output on feature development. Then he asks whether the team has the expertise and leadership to get there, and whom to recruit if not.
For new graduates, Pham acknowledges it is a scary, bumpy time. Faire no longer hires large numbers of new grads directly. It hires them through a co-op program that brings in a cohort every four months, and the best receive offers, because without them there will be no senior engineers years from now. His advice is staged. As a student, volunteer and solve hard problems early. In the first five to ten years, seek the places where you learn most and are pushed hardest. At senior or staff level, go where you can make the biggest impact, possibly a smaller company with a bigger stage. At principal, senior director or VP level, shift toward coaching and bringing others along.
Uber had about 5,000 microservices.
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 to survive that scale that keep on coming at you.
Travis told you you have 2 months to launch in China.
That was one of the craziest thing we've ever done, but it's also one of the most amazing thing we've ever done and now explain why. So
Let's talk about how and why Uber built so much internal tools.
I can't claim that every single one of those thing were absolutely necessary, but all the important one were absolutely necessary. So I remember a very painful example of that we had to face early on was
When Thuan Pham joined Uber as the company's first CTO in 2013, the company had 40 engineers, did 30,000 rides per day, and the system crashed multiple times per week. He had 5 months before Uber's dispatch system would hit a brick wall with no way out. 7 years later, he left as the CTO of one of the most complex engineering organizations ever built. In today's conversation, we discuss Thuan's interview with Travis Kalanick for the CTO role, which lasted 30 hours spread over 2 weeks, scaling through chaos, rewriting dispatch before it collapsed, launching China in 5 months, and the full app rewrite known internally as Project Helix. Why Uber ended up with thousands of microservices and hundreds of internal tools because existing solutions could not handle Uber scale at the time, and many more. If you've ever wondered what it's like inside the room when a company is growing faster than its systems can handle and what are ways to get things under control, this episode is for you.
As a side note, I've been lucky enough to work at Uber while Thuan was CTO. And Thuan is the real deal. This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors, Sonar and WorkOS. Thuan, it is so good to have you here in person.
It's my pleasure. It's so good to connect with you again after all these years.
And it's so good to reconnect. We worked together for almost four years at Uber. Probably my first month I already met you in some really fun slash stressful circumstances during Helix, the Uber app rewrite, which was a crazy project. Well, before we get into any of that, how did you get started not just in tech but in life? You had a pretty rough start.
Yeah, I grew up in, I was born in Vietnam and I was a child, I would say, of the Vietnam War. So in 1975, when the south of, I was from the south of Vietnam, my father was tied to the military of the south, and when the country was unified, right? The south has lost and the north has won, and there were a fair amount of repercussions, right? People who are associated with the southern regime would not have much of an opportunity growing up. The education opportunity, all these other, that was again the way it was at the time. That's not necessarily true right now.
But that was, and my mother then made a very bold decision that she wouldn't want her two sons growing up with no opportunity. And so we had to flee the country. And at the time there was a massive wave of exodus called the boat people, where people just get onto rinky-dink boats, fishing boats or whatever thing they can get their place in, and escape the country in the middle of the night. People did not know at the time, and nobody thought about it, but the chance of survival was about less than 50%. About two million people left, about a million people survived the crossing, because these boats are not seaworthy and we crossed the ocean. And yeah, but we were the lucky, we were the lucky half really. But no one thought about, if people think too much about it, they probably wouldn't do it. But everyone just like, well, we need to escape, we need to give ourselves a shot at a better life, and so we did.
So we left Vietnam. It took many tries and it depleted the entire savings of my parents because it was a scam. People were saying, you know, pay up half now, half later, and then the boat never shows up. And finally on the fourth try we actually made it, and then we were lucky that we had a really good captain who actually navigated through storms and all that, and we survived even pirates from Thailand. I was around, I think, 11, 12 somewhere. And so we crossed that and we survived three days, four nights of the crossing of the South China Sea to Malaysia. Then we went into Malaysia, we thought we were done. A week later we got towed back out and dumped in Indonesia a few days later, and that's where the government there accepted us in and put us on a deserted island at the time, and we formed a refugee camp there.
And then we were waiting to be processed. We got interviewed by all the different countries and the US gave us a refugee settlement because we were tied to the old regime that was supported by the Americans. So we were very, very thankful to get here, the land of opportunity. And we didn't know any English. We didn't have any penny to our name. We were sponsored by a church. The first set of clothing we got was from the donation closet at the church. And so we had to build from the ground up. So that was how I grew up and that's how I got here.
And then from this absolutely not just unconventional but just extremely hard start, how did you eventually get your interest into computers, into tech?
Just like most in life, it's by happenstance or luck. I was pretty good in math and science, as most kids in Asia. We were growing up, we learned that. And when we got here, I had a friend in high school who had received a gift from his dad, an IBM PC. That was one of the very first ones, the one with two floppy disks.
Was this in the '80s or '70s?
This was in the '80s. This was in 1982. Yeah. So freshman year. So after school I would hang out at his place and he's got a new toy, and so we were writing little BASIC programs and playing games and all that stuff, and we learned how to use word processors and Lotus and WordStar and all that. And I started coding in BASIC and then I just realized that, oh, it comes very natural to me. I can think very algorithmically. And then there's another weird thing. I sometimes tell people I am generally a procrastinator. I don't like to do the same thing twice, so computer programming is perfect for me, right? You solve the problem once, that's the creative part. After that, I get bored. I got to do the next problem. And so writing programs was like the perfect fit for me.
You do not duplicate your code.
Yeah. I don't like to duplicate the code. I don't like to do the same thing twice. And so, yeah, when you write it and then it executes way faster than you can do it by hand. So that was really wonderful. I just taught myself that. And then I volunteered at a government agency to write code for them after school. And so I did that and I went in there and I basically stitched together Lotus, dBase III with all the scripting languages and automated the entire financial accounting and reduced the workload. At the time the two accountants had to spend about 3 weeks or so every quarter reconciling everything. I did all that stuff with a push of a button, and it took about three hours for the whole batch to run. And so they were so happy. When I graduated high school, I think they wrote me a really good recommendation letter. And with other things that were going on and the good grades and everything else, I got accepted to MIT, and then I got there and I really learned computer science, like the fundamentals of computer science. Back then I was just like a kid who just writes programs. So.
And then during or after MIT, what was your first professional job where you got paid and you worked full-time with technology?
One thing led to another. When I was at MIT, there was a multi-year co-op program with some of the best tech companies in the world at the time: AT&T, Bell Labs, Xerox PARC, HP Labs, and all these companies all over the country actually. And so we applied for it, and then the kids with the best grades got prioritized. Then the companies had to go through a selection process. They ranked all the kids, and then the kids all ranked the companies that they got ranked by, and then there was a matching process. And I ended up coming to Hewlett-Packard Laboratories, and HP was an awesome company at the time.
Back then they were massive and very
Very innovative. Laser printers, workstation computer systems, all of that stuff. I was in HP Labs, which is the research lab where a lot of the really innovative stuff happened, and so it was a dream job. As a student I get to work on cutting-edge research with all the other PhDs around. I get to write the joint thesis for my bachelor's and my master's with the work there. That was part of the arrangement. And when I graduated, HP just hired me straight into that research lab, so I became one of the researchers although I didn't have a PhD. And after a few years of that, then I went into the industry and wrote code that people would actually use.
I really enjoyed my time at HP Labs because you get to do cutting-edge stuff. We were working on medical informatics at the time, where right now you go to every doctor, all your records follow you. Back then we actually had a networked distributed system architecture where every physician workstation that you go to had your X-ray and everything follow, and then you have a knowledge base that actually looks at drug interactions. We actually did that research back in the mid, late '80s actually. And so these are cutting-edge stuff. But then the thing that I found unsatisfactory at the time for me was we published great papers and then they didn't go anywhere. It was not productionized, and I'm just like, this is so cool, why can't we bring it to the user? But that wasn't the setup. The setup was research lab worries about research, and then we would have a tech fair every year, and the general manager of every product division swings by and then decides what they want to pick up and productize. And so I didn't feel empowered beyond the research phase. So I just had to go find a place where I can write code and people actually use my code.
So I went to Silicon Graphics. At the time we were also trying to invent the future, and we actually did a prototype of that. There was interactive TV, where back then, now we take for granted streaming video, video on demand, online games, right, cooperative games. Back then we didn't have cell phones, internet yet, and we cobbled 4,000 homes together in a trial that had cable, and then we invented network protocols and all these things. And we actually had a set-top, which is a tube TV, not even a flat-screen TV, with a set-top box on top, which is a Silicon Graphics box, and we could implement online shopping, video on demand, and you're building all of that without having any of this stuff right here. And celebrities like Michael Jackson came by and saw demos, and we saw Spielberg, we saw everybody. We really believed that was the future, and it was the future. The problem was it's way, way, way ahead of the time. Right. Then I learned a big hard lesson. It's not about just the technology. It's about whether the world is ready for it, whether it's economically feasible.
And back then, what was the point where you realized this is not going to work even though we're doing this awesome stuff?
After a year, right? Because it took like $100 million back in 1994 just to provision the head end. Silicon Graphics loved it because they sell all these massive servers to pump out video, and then the set-top itself is a Silicon Graphics workstation that cost $45,000. Right, people would not buy that, right?
Especially in today's money, that would be like $10,000, $20,000.
People would not buy that. The early adopter enthusiasts maybe, right, but not for the mass market. And so we did that trial, incredibly successful. We definitely all saw the future. And then we did a similar trial with a different set of software that we wrote for NTT, Nippon Telegraph and Telephone, in Japan. We went to Japan, deployed that, very cool, had a really great time, but then it fizzled out because it would not be commercially viable. And so that was a really first life lesson that I learned. It's not just the technology, right? You got to be at the right place at the right time and the right price point.
And then after that I went to a startup founded by a former office mate at SGI. So we were doing internet advertising. The internet was about to take off. The Mosaic browser, search came out, Netscape was being formed, and yeah, in the early days of Netscape. And so we saw very clearly that the advertising model worked for TV, so it has to work for the internet, right? Because all this content, people would use it if it's free, but then who has to pay for it? The advertisers. So I joined a company. Initially we called ourselves Netvertiser, which is very, and then it changed its name quickly to NetGravity. And it's enterprise software to put ad banners, dynamic ad banners, on CNN, on the Netscape site and all that. I was one of the very early engineers there. I was the fourth engineer, I believe. Yeah. And so people don't know this, but a buddy of mine and I were the first engineers to put the first dynamically targeted ad on the Yahoo page on the internet.
And dynamically targeted meaning that it showed different ads based on different, or like whatever.
Yeah. The version before I came in was a script that crawled through and just put a static banner ad and rotated it through every hour. But then it's like we got to target it, and then we started using cookies. At first it was the content of the page and the person, and then we actually used that to actually target different ads, and then we had ad sequences and all that stuff, and that was the very first one. Of course, we had some success there. That company went public.
But another thing that I learned was sometimes you got to seize the market, right? There's a company that formed much later than us but did an ad service bureau, and that took off because it takes a lot less investment for people. You just stick a tag on your HTML page and then revenue just comes your way, right? Because the service bureau kind of sticks the ad there dynamically, that kind of stuff. We had wanted to do that in our company, but then one of our board members said no, you should focus on getting to profit first before you expand. And we went down the profitability path, and we then became a bigger, robust enterprise solution, where the other one is, and we tried to get profitable, and the other one just expanded through the internet like wildfire, then after that, years later, got bought by Google. So that was the journey there. There's a lot of lessons there about how to build things.
So do I understand that you saw what happens when there's a big market and you focus on profitability, which should make sense, but a player that focuses on growth, even at being nonprofitable, might be able to swallow you in the end?
That's right. Look at what happened at Uber, right? We did not the right move.
I'm starting to see how these things are coming together. So now you're at the startup which almost took off but not quite. And then what was your next stop?
That company went public and then got absorbed, and after about seven years there I had made it to the VP level. I joined as an IC. Along the way I knew, from my inspiration at the Silicon Graphics days, that if you want to do something really big you need to leverage other people. You can't do it with your bare two hands. So then I
switched over to the management track and I honed the skill and I got up to directors and senior directors and then ultimately got the VP and then after about eight years, seven year, eight year there, the dot-com bust happened right of that time and then I said well maybe it's time to prove to myself whether or not I'm just a one hit wonder or I actually have skill that are transferable.
Just one thing on the dot-com bust because you kind of swept over it because you've now seen a lot of like ups and downs, but can you take us a little bit back: what actually happened with the dot-com bust? Because the people I talked to, especially who were new grads, it sounded very, very scary. What did you feel like and what did people, professionals, engineers all around you feel like?
The dot-com bust was kind of scary when the correction happened, right? But before that there was this exuberance that everything is .com, right? Pets.com, foobar.com, everything is a .com. Webvan. Yeah, all of that stuff. I still have the Webvan bin in my garage actually. And so, yeah, but then there was a shake out eventually. There has to be sound business model that makes sustained 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 company that emerged, right? There was Yahoo, there's Google, there's Amazon, all of those company. 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 last 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 are just a me too, right? Just put a .com on something and it's hot there. 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. And so, but the market will sort it out. In the end, the customer will vote on what they want to spend the money on.
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 season sponsor Sonar is all about. Sonar, the makers of SonarQube, 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 SonarQube 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. The impact is measurable, too. Developers who verify their code with Sonar are 44% less likely to report experiencing 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 agentic coding? Head to sonarsource.com/pragmatic to find out.
With this, let's get back on what Thuan did after the dot-com boom and bust. And there was a lot of layoffs, companies going bankrupt. Did that worry people around you? Did that worry you that, you know, your job could be in danger or you might have a harder time switching jobs, or was it very short-lived?
It lasted a couple years, I remember, and during that time it was definitely hard to get a job, especially for new college grad. That's always the first layer that get hit, right? When everything retrench, people want more experienced people, people want to stretch existing folks rather than keep on, you know, 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 go in wave. Yeah, so that's always 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 and yeah, so during that time it was certainly tough.
However, the way I look at this thing is like, yeah, talents are always talent, right? So people really strong talents and who's really hungry, always try to punch above their weight, will always be marketable, right?
Yeah, even in a downturn.
Even in a downturn. 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 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.
And then you went to VMware at this time.
Mhm. Yeah. 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 3 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, trying to solve the problem of, you know, intermediation of web services traffic 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? And eventually it went away.
But even then, those three years taught me a lot. Okay. 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.
So you are getting better as a professional even though
And that's something we have to trust. We invest in ourselves, but of course we invest in the company or vehicle that we are part of, and ideal case both side succeed. But if the other succeed, at least if you work really hard you will gain some skill, and then based on that, then you can then leverage all the thing that you learned so far and all the mistake that you've made. All it got you smarter and better and wiser to look for the next opportunity.
So right after that I look at a bunch of other thing when that company was acquired and then I went into VMware, again when VMware was a pretty small, not very well known yet. So it was a 40-person organization and so that build software to stitch together
So VMware was still early.
VMware was still early, yeah. There was three division. 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 and management platform, right? So I was one for that. It was our 40 people and we kind of built the very first product suite for VMware called VirtualCenter that tied to ESX. So that was a really, really fun, right, people
And then VMware really took off. Virtualization as a whole took off. In the early 2000s, VMware was core part of it. It was one of the main things. So was it a kind of hockey-stickish experience?
It was not to the extreme of Uber, but it certainly was, because it was a industry changing technology. It was a game changer, right? Before that there wasn't anything like that. At first people thought, "Oh, this is kind of interesting tool on the desktop for you to run a couple of, you know, Mac and PC OS on top, on a PC," but the true power was the ESX, right? And then that's what you 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 vMotion thing, when you take a virtual machine and you can migrate it from hardware to hardware without any perceivable downtime of the application run on top. That capability unlock the whole cloud thing, right? Because you have a thousand machine, it can look like one. It can look like a C machine and so application inside of your 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, all kinds of things with it, right? So that's actually make it very much like a cloud operating system.
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?
Mhm. Yeah. Yeah. I have this weird thing where when the thing get 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'm 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 engine was healthy. It was good. And then at VMware, again, a smaller company and go big, and when it get really big, again, when you get to a point where you're just running things rather than breaking ground and doing this thing or hard learning, then you got to do something different, right? So I keep on going back small, and when I get big I might go back small again, and
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 UberCab, I'm not even sure how it was called.
It was Uber at the time already. UberCab was way before that. Yeah. Mhm. Yeah. It was when, after 8 years at VMware, and sometime people change, sometime company change, sometime both side change. And so, yeah, for me what changed personally for me was I reached to the point where I didn't feel I could do much more there, right? I'm running 800-person 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. 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.
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, again, cuz Uber was still pretty obscure.
Yeah. Here's a really interesting thing. People do ask me about what the search process look like. How did you stitch 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. It's that 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. 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.
Yeah.
Like, how about this? How about this? How about this? And then you actually look at all those thing. And then you can dig in and you can decide. And so that played out multiple time 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 said, well, let's sit back and take a look, see what's going on.
And then Bill Gurley from Benchmark Capital, who invests, early investor in Uber, and guess what his tie was: he knew me from that NetGravity 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 trying to recruit some people, it was like, why, Thuan, why you joining a taxi company, right?
Yep, I remember everyone's asking that question.
Exactly. And so, but I knew that, and of course then we have to go through like a pretty rigorous interview process with Travis. And yeah, but ultimately it's about the connection that lead to the right thing, but that connection and the opportunity is basically tied to your reputation.
And then back then, as I looked it up, and you also helped me with this, Uber just raised its Series B, which was $30 million, valued at $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 process with Travis, which was tens of hours or something like that. Can you talk about how that went?
It was impressive that he did that. He committed over 30 hours interviewing me one-on-one.
Wow.
Yeah.
That's like several days of like long
Two weeks' worth of interviewing, every single day. A couple hours each day minimum.
Yeah. With passion, with intrigue, and after a while I kind of forgot that I was being interviewed. It was like two people kind of sharing ideas, like exchanging idea, and sometime disagree on something and then kind of work it out.
And then you showed me, you took a photo of like some topics that you talked about. Can you like summarize what those were?
Yeah. My very first meeting, I drove up to San Francisco and saw 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, or design, everything else. And then there's a shorter list of very engineering specific stuff: what about code quality, what about QA, what about design, all that. And then there is also a shorter list of the five things that he want to see in an engineering team and the culture of the engineering team. And yeah, and so that was the list.
And so after we wrote the list, we start 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 last 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 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 and we will pick one of the topic. That's why I took a photo of that whiteboard, and he did the same thing, as a list of topic to talk about, and I still have it on my
phone today. It's so impressive to me that, because we'll share that list in this episode as well, that screenshot, but the fact that the CEO would go into things like code review, like, the hiring topics I understand, but that he was so engineering minded. Did you get a sense that he had the vision that technology and engineering would be just key to Uber?
Oh, absolutely. I mean, he knew that, and it was very clear from the very beginning that he viewed the business as having two major engines that power it. One is the operations, you know, bits and atoms, right? You got to have wheels, physical things 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. And so that was very key. And I think he also knew what he wants, and what he wants in whoever it is. And so I think this list and this series of conversations was for him to vet that.
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 principles? And he did it himself.
And the level of passion and commitment he showed was just really impressive from this side. I can tell you, for example, there were some sessions when we were totally, you know, in the middle of that, and two hours had gone by and he had to stop and catch a flight to go somewhere else. He literally stopped and told me, just wait, and he'd pick up his phone, call his EA and say, can you move my flight, and continue the conversation. Who has that level of commitment, right, and passion and stuff like that? And when you see that, it actually draws you in.
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?
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, that weekend, 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 were certain things that were going for it already. The engineering team was very young but pretty scrappy and pretty committed and talented, where whatever needed to get done, by hook or by crook, they got it together, right? And as a result, the service was beautiful. Anybody who rode it, we only had black car service at the time, but the experience was beautiful for all the people who rode it. That's why word of mouth was, you know, raging around. 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 is, as the company grows faster and faster, what happens, right? And by the way, the 40 engineers were very, very young, I think in their 20s, all of them. And the system was built not to scale, right? It was built for functionality.
It's actually put together and it 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. The hockey stick actually happened. Everything breaks, and we had to basically race against time to figure out what would be 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've got to see around corners. So I tried my very best to see around corners.
And one of the first things I did in the first couple weeks, beyond getting to know the engineers and building relationships and building 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.
Yeah, it's our matching service, right? When it has the drivers, the riders, and does the match.
That's right, and without that there's no business, right? And so that was the first system I looked at. I reviewed the architecture, I reviewed the implementation plan, and it was very obvious that it wasn't going to scale. It was JavaScript, it's Node.js, and it was a single-threaded thing. And the engineers at the time, when the city got larger and larger and they needed more out of that piece of code to power that city, they would move that piece of code onto a larger machine with a faster processor.
Vertical scaling only gets you so far.
So my role is also to do things but also to teach people along the way. And so I would just ask leading questions to the team, and the team only had three or four people at the time. 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 ride volume is getting larger and larger. And they basically said, "Oh yeah, we just move it to a more powerful processor." And I say, what happens 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. And then you say, well, you've got three or four of these things servicing the same city. 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 the brick wall is. And I basically said, what's the biggest city we currently have in terms of ride volume? And they said New York City. And I said, okay, when is New York City going to run out of capacity, even on the biggest box that we can get our hands on? It's about October, and this was around May. Okay. And so it's like, well, we have to rewrite it, don't we? And we have to write it in a really scalable way. And I only had two requirements, that's all I need. One is a city has to be powered by multiple boxes.
Yes.
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 features necessary. Just make sure that we can do that. And then that allows 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 engineers did that, and because the requirement is very simple, we had to do it really, really quickly before we ran out of time, ran out of runway to survive. And so they did that, and we actually deployed that right around August, September, right before it actually hit.
And then on to the next problem. Database is going to be the next choke point, right? And then the API monolith is going to be the next choke point. And we keep on identifying all these things. So there are all these threats coming at us, and we have to establish how much runway we have until we're really getting serious Star War, there's no way out, and then get ahead of it.
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 have written it properly the first time? But 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 get? A good example is the New York problem. And then you take those constraints and you build a system, and then if those things change later, you might need to build a different system.
Yeah. It also depends on how fast you're growing; that dictates how you make it. Because the faster you grow, the shorter runway you have to survive, right, given whatever architecture and system you currently have. And 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.
Yeah.
Right. Before we hit the brick wall and there's no way out. Right. So 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.
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 are a good time to mention our season sponsor, WorkOS. If you're building any SaaS, especially an AI product, surprisingly quickly you reach the need to build enterprise features like SAML edge cases, directory sync, audit logs, and all the things enterprise customers expect. 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. That's why companies like Anthropic, OpenAI, and Cursor already run on WorkOS. Skip the rebuild, keep shipping. Visit workos.com. With this, let's get back to Thuan's team rewriting the dispatch system and the short breathing space that this first rewrite gave them.
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 needed to be rewritten several times. Let's say if my requirement for the engineers was build a system that will scale infinitely, to the test of time, it might take a year. We'd never get there. We'd die before then.
Yeah. 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 opening your API and allowing the firewall. What was that project like? I heard it was an absolutely manic and crazy project. Can you take us back to what it was like?
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 I'll explain why. So I remember very, very clearly, right around Christmas time 2014, we were all hanging out in the big room in 1455, and Travis made a declaration: 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. And one of the requirements at the time was that we had to run our services on China soil, right?
And a data center physically there.
A physical data center needs to be there. Until then, we kind of dabbled in dirt water by powering it from the US. Okay. And we had a limited time to do that, but he's going to light it up. We're 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 machines and copy the software over, and it shouldn't take more than two months. And then I had to explain that it's not that easy, because when you do that, it works on day one and then the two drift, and how are you going to maintain that, right? We don't have twice the engineering team to manage two different systems that deviate.
So the right way to do that is you build, rearchitect, whatever you need to do to build one system that can be partitioned, right? Because there's a huge security concern, right? Anything that runs over there cannot presume 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 complete partitioning of data and controls and everything else so that nothing bleeds across. But every time you deploy code, you have to close everywhere, right? So you have to rebuild a lot of things.
And so I went to the TPM team and asked the team to scope it out.
TPM, technical program manager.
Technical program manager. And I think the best path for us was about six months, and that was the fastest we could even imagine. I benchmarked with a few of my friends in the industry, and they kind of laughed at me, and it's like, 18 months minimum. But you know, that was Uber, so we didn't think too much about it. It was like, well, let's do that. And then Travis didn't like the six months, so we kind of settled around four months, right?
Because he didn't like...
We just split the difference. We didn't know anything, but we just wanted to get heads down and start getting to it. And so we looked at what needed to change, given this is the end goal and the requirement. And then everybody started getting really busy, working a lot of hours to start making these changes. And four months came and we were still a month or so short. So we slipped, and Travis was not too happy about that, but it's fine, right? And then five months came around and we were very close, but we weren't there. We were about to slip again, and so he was definitely not happy then.
But we actually talked it out, and I said the team feels very confident that within a month we can launch, but he had to give us something, meaning give us the ability to incrementally launch. Instead of lighting up all the cities in China at once, let us do it in phases, right? Every single week we'll launch a number of cities, and we're going to do it over a process of a few weeks, and then we're done with that. And he said, okay, that's reasonable, but he wanted the biggest city first, and that's Chengdu.
So he agrees to the incremental launch, but you need to start with the biggest.
Start with the biggest first. Yeah, exactly. But it is brilliant, though, if you think about it. I thought a lot about that, you know, 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 has this swagger; the team would go into the next set of cities with confidence. Had we done it the traditional way, let's start with the safest one, the smallest one first, and the next one we step it up, on the surface it seems like, oh, it's a very good risk control measure, but every single week we'd be holding our breath until it's done. But this time we did the hardest thing first, and after that it was just a routine process throughout the rest. And it worked out exactly like that.
And so we got it done, and a bunch of people were really burnt out, and they took like a month off, went to the beach and did nothing except stare at the water. I know some others did that. But after that, we're not fearful of anything. We did kind of the impossible.
I talked with a friend who worked on the IT team at the time, and his job was just to get the servers physically set up. And he said 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 site. And when I gathered the 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. None of us thought the whole thing could be done, but we just got our heads down and, you know, broke it apart and just did it one step at a time.
And then, I think needless to say, the China launch was a massive success. Uber started to compete head-on with the leading Chinese provider, Didi.
And they were pretty much head-on, very intense competition, all the while competing with the rest of the world as well.
That's right. Yeah.
So that was something incredible.
That was something incredible, and I think just the experience of having gone through that and doing things that initially you didn't think were possible just increases everyone's confidence and range, and that's what stretching is all about. And I think there'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.
One thing that Uber has been very, very well known for from the outside is microservices, and from the inside, one thing that has been very talked about is the program and platform split. Can you tell us which one came first, and how did we get to as many microservices as we did?
The program and platform came first. Yeah. And microservices came later. And program and platform as an organizing structure came first out of necessity. When I came in April of 2013, we had 40 engineers and three product managers.
Yeah.
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 a low tone engineer there, about up to eight or 10 mobile developers, a number of infrastructure engineers and a bunch of backend engineers, etc., etc., and five to eight people or so at dispatch. Now, every feature that we want to put out has to be queued up on mobile development bandwidth, dispatch bandwidth, and it becomes impossible to navigate tradeoffs, because every feature you want to do, you have to go negotiate with so many teams, right? And so then the team wants to move fast and starts to feel that friction and complains right away. And that's a good thing, right? We raised a concern.
And so I remember Travis and Jeff Holden and I saw that, and we got together for a couple of days actually, and I remember we had sticky notes of all different colors. Each color represented a different function: engineering, product, designer. And we put one person's name on each of the sticky notes, and then Travis gave a talk about what he thinks are the most important areas of the business, right? And at the time there were like 17 areas that he could think of that the world of Uber could cover. 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 funded seven, 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 notes onto each of these areas. It has to be a cross-functional team, because we can no longer afford to run a functional team rather than a cross-functional one.
Yeah, which means that there's like a back end, a mobile, and whatever else they need, like a designer if they need it, etc.
The concept is that the team has to have all the skill sets necessary to just get it done. Whatever they have to do, they just go off and they do that, right? So that was the principle behind that decision. And then we called some of those program and some of them platform. So programs are the teams that build things that the end user actually uses, and the platforms are the teams that build tools and layers that other program teams use. And that was sort of a horizontal versus vertical kind of thing. So that's that. And then after we defined that, we started putting the right sticky notes onto those boxes, and that's how the first version of program and platform came about.
And then how did microservices start, and how did they blossom as much as they did?
Yeah, again, none of us wanted to go to that extreme, but lots of times when you are under a lot of pressure and have no time to react other than just to survive the scale that keeps on coming at you, you have to make decisions that increase speed and velocity, because speed and velocity allow us to build quickly 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, right? So we made a declaration: anything that is new needs to be built outside of that.
Yeah.
As a microservice. Okay. And then there's a team that's dedicated to decomposing that API monolith into a bunch of services.
Yeah. We used to call it API, right? I think.
That's called API, right? And I think that project name is called Darwin.
Yes, Darwin. Oh, I remember.
Yeah. And interestingly, had we frozen time, that piece of code could have been decomposed in a matter of 3 to 6 months. But it took us 2 years to do that, because as we peeled out a piece of code, the business kept on going forward, right? These hockey sticks are layering on top of each other now as we launch new cities, and it's happening fast.
New cities and new products, UberX.
That's right. Features have to be added on, right? And so the philosophy we all operated by at the time was that no one should be blocking anybody else. No one can block anybody else. And so when a team needs to build a feature and that thing hasn't been pulled out of the monolith, they add to the monolith, right? And then the team that pulls it out does the best that it can, and then we kind of keep chasing our own tail until eventually something gets completely pulled out. And as it happened, the monolith bulges up like this, right? Because you pull out one thing, the remaining stuff grew even faster than the stuff that you pulled out. So the code base gets larger and larger and eventually reaches 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 outside, because we don't keep on adding stuff to the monolith, right? And so that's how it came to thousands of microservices. But that was out of necessity, so that we could just fan out and solve every problem all at once. And then over time, after things stabilized and the business became more mature and growth was not as violent like that anymore, the team, we actually had a project called ARC, looked at this stuff and at how we clean it all up. So we put domain interfaces on top of a whole bunch of microservices that are within the same domain.
It's funny, because I remember that around 2016 or so there was a published Uber blog post that Uber had about 5,000 microservices, and I just saw a few months ago Uber published another one, and they have about 4,500. So in those 10 years the number has slowly gone down, right?
Gone down, but even then, right now Uber has so much more complexity, right? Yeah, the process took a little while, but the team had to look at everything and at how we simplify that, right? And then to make sense out of that, new tools had to be invented by us: Jaeger, the tracing tool, all of that stuff. And so those were really great tools that we open sourced too.
And let's talk about how and why Uber built so many internal tools and also open sourced a bunch of them. Jaeger was one of them, but internally we had Schemaless, a trip data store; TChannel, an RPC protocol; Ringpop; geospatial placing; Clay, a service framework; uMonitor, observability; and there are like hundreds of others, some of them open, some of them not. How were you thinking about that? Does it not seem like a lot of waste for us to build this, or was it again necessity?
It was mostly necessity. I can't claim that every single one of those things was 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 engineers there just focused on putting together a service that actually moves cars. But then as we scaled, we kept on pushing the boundaries of the capability of that open source stuff to the breaking point, and at a certain point, if we don't invent something to power our own needs... By the way, this is 2013, '14, '15, '16. It's not as mature as...
We did not have the kind of big tech investment in open source back then. There was very little, and most of the big teams like Google and Facebook were keeping theirs inside.
I remember, for example, a very painful example of that we had to face early on was that we used Postgres.
All right. And we got to a certain scale where Postgres would randomly fail, and that took our services down randomly, and we didn't understand it. It's inside the kernel. I remember the time when I had to go on LinkedIn begging anybody on LinkedIn that had any knowledge of Postgres to be our consultant to help us diagnose this problem, and we spent several weeks on it. And during that, it was terrifying, because I don't mind if we think we can solve something of our own. It's terrifying when we have a major problem and we depend on somebody else and we don't know, because it's open source, there's no single person, no single company. I'd be willing to pay anything if someone could give me an answer, but there was no one, right?
And so that was one of the motivators to 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 a table data store. All the logic on top we had to build for our own use, right? Because then we control our own fate, and we only build the features that we really need, right? And so that was one of many examples.
And eventually we ran into other brick walls of scaling. I remember in 2015, right around the holidays, I was taking a holiday trip. I had to go to the airport, and I took an Uber ride as usual. The receipt didn't come until 2 days after that, right? Why is that? Things were queuing up. We weren't processing things fast enough, right? And so, yeah, that's not a dealbreaker for many people, because they just ride and then the receipt comes later. That's fine, as long as the billing and all that stuff... even when you bill people late, they don't really mind that either, right? As long as the ride happened, the rest of the stuff can be processed later. But it's still not great.
Okay, when I dug into it, our data processing capability was at capacity, right? So we had to rewrite a bunch of stuff. And then our capability to monitor things was reaching a breaking point with the open source tools that we used, so M3 had to be invented, right? And all of that stuff. So we had to do a lot of things, because we were at the scale where we broke all the open source stuff that we used.
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 rewriting Uber's app. And as I understand, what happened is Uber's user experience was starting to degrade because it was really cluttered. We got a bit fed up with it. The design team came up with a solution, which was a very nice and clean UI, which the engineering team looked at, 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. 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 we even did this? Because it felt like an existential threat from the inside, but it was not like a Google+ versus Facebook existential thing. And how did we decide on that short deadline?
Yeah. It seemed like a recurrent theme that kept coming up was a tight deadline, right? Everything we did had a tight deadline. That's just how the culture rolled. Anything we wanted to do, we wanted to do as fast as we could. But going back to why Helix: actually, Travis had a vision, right? And it's actually not just the designers. Travis and Yuki, who was the lead designer at the time, paired up and did all the storyboards and everything else. So he had 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, messaging and all these other things as people were riding, the new architecture was much more open, right, to all those things. And so that was the vision behind that.
And then when we were doing that, the aesthetic was really important. The icons changed and all of these things changed. Oh, yeah. And it's beautiful, right? That's actually Travis and Yuki, right? And then of course, when that was fleshed out to a certain amount, then the engineering team, the mobile team, got involved. And it's not just the mobile engineers; the back end had to be rewritten, everything.
We changed from the heartbeat, where every 5 seconds we would poll, and it was pretty painful, to an actual push channel.
Yeah, by that time it's called the real-time system now, right? Yeah, it had to change. The back end had to change, everything had to change to support the new flows and all that stuff. And so, yeah, it took, I don't know, 600 or 700 engineers all told, 7 or 8 months to actually do it. Then we put it out, and it's still live today. It's still on that same architecture. It was so well thought out, it's almost future-proof in that design. So it's still used today, it's still beautiful today, and if you compare that with the previous version, it actually was definitely the right...
Yeah, and it was a scalable user experience.
I take no credit for that. It's the genius of Travis and Yuki.
Every now and then you sent emails to all of engineering on different things, and I remember this really, really emotional email coming from you about naming.
I see all this, and I understand that young engineers 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 had no idea what it was, right? I looked at that stuff, and by that time we were already very complicated, right? And we had to onboard new engineers all the time. We wanted builders to ramp up quickly, etc., etc. And I can imagine an engineer coming in here, and all these weird names have no context to them. At the time our tooling wasn't that great either, right? You blame didn't come into existence yet, right? And so there was no mapping for people to discover what this really means, and then there were those renaming schemes. So I got to the point where I was kind of fed up, so I sent that email out. Of course, those mass emails, sometimes you regret them after you send them out, because it has some effect, but it didn't really solve...
And I think it's very quoted, because you specifically wrote, "This is not a Mickey Mouse shop."
Exactly. We're not Mickey Mouse. And yeah, again, it was a growing-up phase for everyone in the company. But my frustration at the time was: look, at this scale, we've got to take ourselves seriously. We've got to do things better, faster, and this is not helping.
Thuan'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-in 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, catch issues early, roll back instantly if needed. And because it's an 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 statsig.com/pragmatic.
With this, let's get back to Thuan. 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, and then at some point you, the leadership team, cut it into two. There was L5A and L5B, senior one, senior two. Can you talk us through why you did that and where did you get the idea from?
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 companies out there, Google, Facebook and all that.
And then I realized that for many engineers crossing from senior engineer, I mean engineer two, passing through senior engineer to get to staff, it could be a five-year journey. Okay, it's a long time, and so I just wanted to break it in two so that people get that sense of progress. And then also, not everybody can make it to staff, right? But for some people it's good enough to make it to senior
Senior two. Yeah.
And I think that's a benefit, versus not doing it and everybody kind of just getting lost in that five-year journey. And so that was the motivation behind that.
So you saw a problem and then this was a solution, and it worked, we can say, right?
It worked for a while, right? And then people were acclimatized to that, and then they started complaining, like, oh, why are there two levels, we need to get to staff faster. And while I was there I held on to that, because it was a principle, and staff is staff compared to the best of the industry. And later on, after I left, I think it got
They got pushed down. L5B is now staff, everything got pushed down.
Inflation. And I didn't want to do a title inflation thing.
I appreciate that. Another email that I remember from you is in 2016 you sent an email saying you've heard the feedback that engineers are unhappy because their managers don't support them, and then what you wrote is, we are creating an easy internal transfer process, you can move teams. How was that received, and again, how did you decide that we need to do this?
I look at the talent base, and I think it is best for us to create opportunity 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 seek that elsewhere. 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 interviewed.
Yeah. And so why the heck do we have these rigorous processes where 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 engineers going from team A to team B have to ask for all these permissions, when they don't have to ask if they interview outside? That just doesn't make any sense.
Basically it's easier to interview outside, or it was easier to interview outside.
So that didn't make any sense to me, and so I said, well, let's not have that. Right. And that also has maybe a good side effect, where managers now need to be incentivized to take care of people great, develop them, grow them, position the best people into the best teams for them to grow, and then they're not likely to leave their own team, right, if they continue to grow. So there's all of that back pressure that might cause engineering managers to be a little bit more responsible too.
So that was that, and I remember that got quite a bit of pushback because it was pretty radical at the time, but we just did it anyway, and that turned out to be the right move, right? And I would rather people trust each other, and when an engineer wants to go, they should have a really great relationship with their manager where they just talk to them: hey look, I want to do this. And the manager should be generally supportive, instead of like, no, you belong to me, that kind of thing, which is the wrong thing.
I have a saying that I shared with you guys all the time: it's not a jail. We can't lock anybody down, right? Everybody has free will. If they want to work somewhere, they should have the ability to do that. And we should create more opportunity, and then also, to support that, we published an internal job board, right? Anything the outside sees, we see on the inside. So anyone should be able to shop within all the opportunities inside the company and stay with the company. Why make it so hard and end up with them leaving the company? That's just a silly thing.
I remember at Uber, in some of 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 viewing work in the perspective of death.
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 it with different audiences in different contexts. But it's all about finding one's purpose and not taking oneself too seriously, right? If you look at people, the most accomplished people don't take themselves that seriously, right? 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 they have to, all that, right?
So yeah, I always take the opportunity to remind people to be humble, and the example I always use is myself, right? I say, look, when you're in an important position, people treat you really well, but don't let that get to your head. It's not you, it's the position you hold. And I remember saying this, like, the moment I stop being CTO, right? And that always happens, 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 on each other. And one day everything ends. A job ends, and then I'll get to the morbid stuff, like life even ends itself. And so then I measure myself: what is the achievement that I will be most proud of? And I said, 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 because I can't take anything with me. And so live in the moment, be the best you can to everyone, be as constructive as you can, and leave a good legacy behind you. So that was the whole gist of that.
It feels to me sometimes there's talk about how you can network better and grow your network, but it sounds like this is almost, it's not a hack. It's just do the work, right?
Do the work and then 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, be helpful, be constructive, uplift everybody, help people along the way, coach, doing it altruistically.
And let me tell 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 get pulled in and you don't have people to support you, you would not succeed either. And here is an example at Uber, right? When I came in, again, the engineers, we talked about it, very, very young in experience, did not know how to build systems at scale, reliable, all that stuff. And the network that I had who really knew how to do that was from VMware. You're building system software, we're building operating systems, right? Rigorous principal-level engineers, all
Experience. Like, in their sleep they can do it. Right.
Right. So when I came in, and when I had to work with the team on dispatch, I pulled in the first engineer to Uber to land on that team, right? His name is George. And so he was there and he uplifted everybody else there, right?
From VMware.
Yeah. And then when I built the payment system, let's pull in a few more. And then when we got to build Schemaless, it was a Denmark team, right? I pulled the top four engineers from my VMware team in Denmark. I moved them down from one floor to the next in Denmark.
This is why we had a Denmark office, which was one of the best infrastructure offices at Uber.
Correct.
And they built Schemaless.
They built Schemaless. They built a lot of other things, right. And so now, if I weren't a good person doing a good job for them, with them, why would they come?
Yeah. They wouldn't answer the phone.
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 understood that, they came, right? But they came because they still enjoyed working with you, right? There are people who have worked with me at five different companies over 28 years.
And that always surprised me, and I think this is something that people might overlook a little bit as they're building out offices, or I'm talking with founders: one thing is where you can hire, the other thing is 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.
Yeah. A 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 discovered along the way is great talent is everywhere, but you have to bring opportunity to them.
They don't necessarily relocate from Denmark to San Francisco, right? And so that's why we ended up having nine engineering offices around the world, because we had a lot of work that needed to be done. We didn't go to other places because of cost savings or the like. We went there because we had a need and there was world-class talent, and we just cherry-picked the world-class talent, no matter what size it was. And the Denmark team was small compared to the team in India, etc. But there was really great infrastructure talent, and we invested in that. In Lithuania we had an 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 everybody is kind of equal.
At Uber you talked several times about your three tours of duty. Which ones were these?
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 in doing that? And so of course my purpose in coming into Uber was, hey, let's build this business. I just build the tech that supports the business. And so the first couple of years, 18 months, 24 months, were fixing a lot of the broken stuff. Things weren't reliable, became more reliable, etc., etc. Rebuild things. Basically just get things to work and work well.
And then along the way, these things don't end and begin on a particular day, they just phase in and out, right? So phase two, what I call my second tour of duty, was scale, worldwide scale. That was China, that was massive scale everywhere, in every dimension. And so at each of those phases, 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 so the first two phases were no question, right? We were there to do that.
And then as phase two was about to wrap up, right, about 2017, we had actually kind of stabilized. We were 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 at that point we had also another SVP that was hired. And I think he's really, really great technically, and I could feel very, very at peace, kind of, there's someone who can really take it on even better, because the person had done even bigger things at Google, right?
Yeah. And then that didn't work out, and then Uber had a really rough year. So then I had to sign myself up for the third tour of duty, and what is the purpose of that? 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 knew the condition for that to end, which is whenever the next CEO arrives, right? And then after that, whether that person likes me, I like that person, or whatever it is, that's to be decided. But that third phase I had to stick it through, because we owe it to ourselves, and we owe it to everyone along the way who had built Uber to that point, right, to get through that turbulent phase. So we did that, and then when the new CEO came in, I stayed on until 2020.
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 took over steering the company. You were one of them. So this is the point where you decided that if everything had gone smoothly, you might have actually just left. But you decided to stay on to help the company, help the team, to help us get through.
Uber was built by tens of thousands of people, right? Past and present. The fact that people built something and then left before, that's fine. That work was still in there in some way, right? That led to the Uber that we had there. And it was a really important thing that we all built, that many of our lives were in.
And then just to sum it up, we went public, which went well. And then it went okay. And then of course COVID happened, which really hit Uber, and a few months into COVID you did step down. Why did you leave Uber, and why was the timing what it was, and what motivated you to say, okay, this is the time to go?
Yeah, it didn't have anything to do with COVID really. I'm lucky enough to have arrived 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 spend X number of hours doing something, why would I do that versus something else? And so it came 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 there, right, is making a really big impact? And the third one is, am I enjoying the company of the 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 it comes down to, okay, when you wake up and you spend 50 hours a week doing something where money doesn't matter anymore, I live very modestly, so it doesn't change anything, then why would I do that versus doing some other thing? And so I think 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 being much more effective and building the company like in the early days. And at that point I think it's actually much better for other people to take a crack at that job. Again, everything ends, right? And so you have to decide yourself.
And it did give opportunity to other people, right? 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. You did other stuff: Coupang, Nubank, Faire. Can we talk about what
What happened? What was your thinking? And you never even left for a moment, honestly.
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's 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 get canceled, all the countries close, and so we stuck at home. Yeah.
Right. And I don't remember at the time where I'm the only one who go to supermarket, and then very, very sparse, to kind of race through it, pick up what you need and you get out, with all the masks and...
Yeah, and so we kind of bored though, and so I'm bored, so I sit at home and we all got on video Zoom call, and lots of people want to kind of chat with me, not surprising, and so I took a bunch of calls, and one of them was the founder of Coupang, 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 like 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, I joined there and I helped some, but I learned also a ton, because that's also a very interesting area, right, of Amazon-style logistics. And the way Coupang does it is you talk about 5 hours, 6 hours delivery.
Wow.
Yeah. You order before midnight and the thing shows up on your doorstep 5:00 in the morning. And when I was there, I joined the delivery truck putting packages in front of people's homes like 2, 3:00 in the morning, and it's brilliant, right? And all those things that you learn, you learn a whole bunch of these things, and so yeah, it's a really great use of time, right, given the circumstances.
Yeah. And then you became, is it an adviser or a board member at Nubank?
Board member. Yeah. And Nubank is, for those that don't know and outside of the US or Europe, it is the most successful and highest valued non-US company, the largest growing bank in Latin America. It's extreme. Its engineering culture, I hear amazing things about. You're the first person I'm actually talking about it with. So what did you learn there? And you're still involved, right?
Yeah. Yeah, I'm still involved, but in a board member capacity. And for a while I also took on a more active responsibility to mentor the CTOs, right, a couple of them.
And so yeah, 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 I find that very fulfilling. And so that was that. And the culture there is very vibrant. I mean, it reminds me of our early days at Uber, when everybody is gung-ho, hard-charging, the founders hard-charging, everybody is. 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, and sometimes I also did all-hands with the engineering team and do AMA style, the way we did at Uber, and so it's just very energetic, right?
And there are many factors to their phenomenal success. One is, very much like Uber, they actually solve the right problem at the right time.
There's a whole bunch of unbanked population before Nubank came along, and they deliver like a leapfrog of traditional banking, just online, and the app and the experience is beautiful. The NPS score is through the roof, and ultimately it adds a lot of value to people's lives, right? And that's why the adoption rate is crazy high, right? And so yeah, well executed, amazing product vision and phenomenal cultures and energy, and all those factors are very common in great companies, and we experienced one of those things at Uber too in early days. So it's really re-energizing being a part of that.
And they're doing great. And now you're the CTO at Faire. What made you join Faire?
I took a couple 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.
Was it the right choice?
Oh, absolutely. I would not take that time back. So that... Yeah, I'm so glad.
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 applications, 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, "Wow, I'm going to have a lot of time on my hands, so what should I do?"
Here we go again.
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 Faire, and really liked him. Very smart, again, all the same characteristics: very smart, very hard-charging, want to do all the right things. The business is to empower, you know, local businesses.
Can we talk a little bit about that? Because from the outside, you know, when you Google Faire and you look at it, it doesn't tell you too much.
It is a B2B marketplace, right, between big brand wholesalers and retailers. So people buy that and then stock their storefront. And so yeah, all the traditional two-sided marketplace dynamics apply, and the mission is very similar to our mission at Uber, even though we were B2C, right? This is B2B. But it's all about what can we do to empower local businesses to flourish, right? So to buy the right thing, to sell through, make a profit, grow that business.
So basically this can help small and also large businesses to actually just grow their business, may that be like...
More successful, more demand, more supply, all of that stuff, right? So yeah, it's like a really...
Marketplace is really fun and very complex, and so I really like that.
And 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 working with each other, taking care of one another. So it's a trifecta. Doesn't matter if the company is really big or really small, right? But it's got all the ingredients. So I was like, well, maybe that's a good place to jump in and help out.
And can you give us a little context on Faire 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?
Yeah, the company is about a thousand people. The engineering team, including the data science team combined, is about 300 people. We are in the office three days a week, and the other two are working remotely, online. And some people show up more if they live close to the office. The engineering team, there's a portion here in SF, just down the street from here, and a large part is in Canada. We 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.
And what are some interesting engineering challenges that you're excited about right now that you're solving?
Oh, right now clearly the most exciting thing is AI and how AI is changing everything so quickly. Tell me how, what are you seeing, what's working, what's not, you know, on your teams?
In my team as well as in the company, you know, we're using AI to boost everyone's effectiveness and productivity and output, right? And so that's one. Within the engine specifically, we use AI to make, you know, search and recommendation better, right? Because the whole job is to help people discover things that would sell really well for the business, etc. And imagine AI as a shopping consultant, right, and all this stuff. And then coding-wise, you know, AI is doing a lot more of the coding now. But we also used different techniques to actually boost engineering productivity. Have you heard of swarm coding?
So swarm coding, as in agents?
Yeah, a whole bunch of, a swarm of agents, right.
It's pretty new, so you're already using it?
So we're already using it, and we're building an orchestrator to orchestrate the actions of all these agents. And we measure the early adopters, and then the bulk of the engineers follow through after we build the more robust tooling. And we see dramatic lift in engineering output among the early adopters, the ones that are really efficient at thinking this way, right? Because it's very different from a linear kind of thinking when I write this piece of code. Right now it's almost like multi-threaded programming versus single-threaded, right? You have to think about all these other things, you have to prompt all the actions, and then you have all this code come back at you and you have to review it, you sit together. Yeah. And it requires a different way of thinking, and the cognitive load might be a little higher, but the output is dramatic, and we have seen our best engineers double their output.
I know we're talking about that, but just to make it clear, we're talking about not the code output but the actual business output, the impact of their work, right?
Yeah, the impact now depends on the evolution of AI, right? So right now the state of the art is it's very easy to make large-scale changes, right? Cleanup 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 and output building new features on top of a code base that is older, right? It's not like, oh, you and I can just go build something brand new, not entangled with anything. It's really fast. The whole thing will generate for you, right? Yeah. But we got millions of lines of code, and how do you deal with that and build features on top with all those, you know, dependencies and all that stuff, right? Is AI good enough now to help us untangle some of those things along the way, 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.
How do you think AI will change software engineering and what a software engineer does and what skills we value?
Yeah, it's already changing. I mean, very rapidly, fast. These changes are more fascinating 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. We have to know, and then we have to learn syntax and coding. All of that stuff has been abstracted away now, right? Especially with AI. It's like, I want X, Y, and Z, blah, and it should be this way, and the whole thing gets constructed, right? So it elevated, leveled the playing field, where people who don't even know how to program can now create good, you know, decent code and apps or whatever it is that look on the surface really good. So it is game-changing, right? It elevates the playing field. Now then, in that level of abstraction, how do you tell the great engineer from the good engineer?
Great question. How do you...
Well, from what we see so far, the great engineers are still finding ways to leverage this and accelerate the output even more. Then we see the difference between the great engineer and an average engineer is still 2–3x 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 are 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 engineers continue to break new boundaries. And so I think that is still available. You can look at people and you can see who are the high performers versus who are average.
So do I hear correctly that the traits that you're seeing in great engineers, we didn't mention, but it's kind of a given, the foundations, plus curiosity, plus innovation?
Fearlessness, willing to innovate, willing to stretch, willing to try new things and break new ground. All of those traits still exist.
Interesting. If I think back to just the Uber days or your startup days, those traits were kind of the traits of the...
Standout. That's right. Those are things that make someone outstanding versus someone average.
So I guess maybe an advice is, well, if you were a great engineer before, just don't be complacent and keep approaching the same way, right?
Correct. Yeah. Complacency is death. I mean, the world will move faster and faster, and the moment we stand still, we are falling behind.
It sounds like if you worked at a fast-paced startup before, which is how it works, AI should be familiar. Welcome to how it was before.
To me it is an incredibly powerful tool, but in the end it's still a tool. And if you can wield the tool properly, you can do extraordinary things, versus if you just merely use a tool in a mundane way, you're not going to be great.
So we talked about standout engineers in this age. I'd like to talk about something that I cannot talk about with too many people: standout CTOs. You have now been CTO at multiple companies, and VP of engineering. You've been at some of the highest engineering leadership roles, at Uber, at Faire. You've done an outstanding job as a CTO. What is the most important job of a CTO?
Yeah, there are a couple of angles to this. One is build a high-performance team. All right, talent, culture, all of that. You know, 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 they're just intolerant of anybody who's not performing, right? 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? Because you put an all-star team together doesn't mean they work really well if you don't have the cultural alignment, right? So that organizational side of things, I've always deeply believed in: if you do that one well, then good outcomes will just happen, right? 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 with great motivation.
The other side is, you have to look into the future and see around that corner, right? For example, I always think about two years out. What does great need to look like? Okay, do we have the key, you know, ingredients, if you will, talents and otherwise, to actually get there, whether it's architects, the leadership, whatever, right? And what problem are we trying to solve? What would the business look like? So, you know, the famous Wayne Gretzky quote is skate to where the puck will be. So you have to envision that future. And I would share this with everyone at every management level: when you're at any level, your job is to see a little bit further out than your folks, right? Because your folks are busy working on the near-term...
things, right? And then you have to see, because if you don't do that, then no one... it's your job to actually do that, right?
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 even in two years, but even in six months?
Well, in 6 months, you know, we know what we need to do. In fact, it's too short, right? It's like these are the things...
Talk about two years. I recently asked OpenAI what they see in two years, and they're like, oh, that's too long, let's talk six months.
But context is everything, right? For them, they're trying to reinvent that future, and sometimes things are changing too fast there, from that context. But from Faire, the business, we know what business result we want to drive, we know what project we need to execute, right? To me, that's pretty much lock and load. It just requires 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, the same problem we saw at Uber too: something changes upstream, breaks things downstream, and how do you really clean it up with all this older code base? Then, what is the next generation of search and discovery that is AI-driven, right? What does productivity look like, right? How can we leverage AI to, like, double output on future development, right? So all of these things: what does that future need to look like, and do we have the horsepower to get there, right, in terms of expertise, management and the planning, all that stuff? And then, if the answer is no, then the next question is how do we actually position ourselves there, who do we recruit? And so that's the job of the CTO on the sort of non-management side.
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.
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 new grads, but they come through our intern co-op channel, right? We're not in the world where we just hire massive numbers of new college grads like the old days anymore, right? But great people are still finding opportunity, right? We have a healthy cohort of co-ops every single four months that come through, right? And the best of the best still get offers from us, because if we don't hire those folks today, what senior engineers will we have years from now, right?
You have to feed the talent pipeline, and great people are great people. They will learn and grow and...
Yeah. And so the opportunity will always be there for great talent. So invest in yourself when you're a student: volunteer, solve hard problems early on. The earlier and harder you work early on, the better off you will be 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 opportunities where you learn the most, that push you the most, because those are the times that you have the most energy to develop your skills and ramp up really fast. And when you get to, like, the senior engineer, staff engineer range, then you know enough to be very dangerous in terms of making a big impact. Then seek opportunities where you can make a big impact. Maybe a smaller company will allow you a bigger stage to actually make a huge impact, right? Take some of that risk and do that. And that phase should be about using what you know and making as big an 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 principal engineer, senior staff, or on the management side, senior director, VP, whatever it is, then at that point you learn to give back, right? You learn to coach and develop people along the way. You'll be leading and responsible for very big things; apply that knowledge to do a really great job, but also teach and bring other people along. So in different phases, you should change the priority a little bit.
Thuan, thank you so much. This was a great conversation, so I hope that everyone will find this useful.
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 the 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 2 years to do something that in isolation would have taken 3 to 6 months. Uber had unusually violent business growth that resulted in unusually fast code growth, and microservices helped Uber tame its growth. 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 Thuan's entire career was shaped by relationships he built by simply doing great work. Bill Gurley reached out about Uber because he remembered Thuan from NetGravity, a company from a decade earlier that didn't even win its market. The engineers Thuan 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.
Finally, Thuan'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 Engineer 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.
Article published