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 Tuan Pam joined Uber as the

company's first CO 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 the CTO of one of the most complex

engineering organizations ever built. In

today's conversation, we discuss Tuan's

interview with Travis Kellik 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 appreite 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 it

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 Tuan

was a CTO. And Tuan 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 Work OS. Tuan, 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

we worked together for almost four years

at at Uber. Probably my first month I

already met you in like some really like

fun slashstressful 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 but in life? You had a

pretty rough start.

>> Yeah, I I I grew up in I was born in

Vietnam and uh 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 uh of the south

and uh when the when the country was

unified, right? The the south has lost

and north is one and there were a fair

amount of repercussion, 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 the the way it was at the

time. That's not necessarily true right

now. Uh but uh that was and my mother

then made a very bold decision that she

wouldn't want her two son growing up

with no opportunity. And so um we had to

flee the country. And at the time there

was a massive wave of exodus called the

boat people uh where people just get

onto rinky boat uh fishing boat or

whatever thing they can get their their

their place in and uh escape the country

in the middle of the night. People did

not know at the time and nobody thought

about it that but the chance of survival

was about less than 50%. that about two

million people left, about million

people survived the crossing because

this these boats are not sea worthy and

we crossed the ocean and um yeah, but we

were the lucky we were lucky half

really. But no one thought about if

people think too much about it, they

probably wouldn't do it. Uh but everyone

just like well we need to escape we need

to you know give ourselves a shot of a

better life and so we did. So we we left

Vietnam. It took many try and took it

depleted the entire you know saving of

my parent because it was a scam. People

were say 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 have a really good captain who

actually navigate through storms and and

all that and we survived even pirate

from from Thai. I was around I think 11

12 somewhere and so we crossed that uh

and we survived three uh three day four

nights of um the crossing of the South

China Sea uh to Malaysia then we went

into Malaysia we thought we were done a

week later we got tow back out and dump

it in Indonesia a few days later and

that's where the government there uh

accepted us in and put it on a deserted

island at the time and we formed a

refugee camp there. So, and then we were

waiting to be processed. We got

interviewed by all the different

countries and the the US gave us a

refugee um settlement uh because we were

tied to the old regime that were

supported by the Americans. So, we were

very very thankful to to get here the

land of opportunity and uh we didn't

know any English. We didn't have any

penny to our name. Uh we were sponsored

by a church. the first set of clothing

we got was from the donation closet at

the church. And so um and so but we had

to build from the ground up and uh so

that that was how I grew up and that's

how I got here.

>> And then from this like 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 is by happen or

luck. Um I I was pretty good in math and

science as most kids in in Asia. We were

growing up. We learned that. And uh when

we got here um I had a friend in high

school uh who had uh received a gift

from his dad uh an IBM PC. That was when

one of the very first one the one with

like two floppy disc.

>> Was this in ' 80s or '7s?

>> This was in the 80. 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 you know

writing little basic program and playing

game and all that stuff and we learned

how to use word processors and lotus and

word stars and all that and I started

coding in basics and then I just

realized that oh it come very natural to

me I can think very algorithmically and

then there's another weird thing I 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 a creative part.

After that, I get bored. I got to do the

next problem. And so, writing program

was like the perfect fit for me.

>> You do not duplicate your code.

>> Yeah. I don't like duplicate the code. I

don't like to do the same thing twice.

Uh and so, yeah, when you write it and

then it execute way faster than you can

do it by hand. So, that was really

wonderful. I just taught myself that.

And then I volunteer 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 uh DBA3 with all the scripting

languages and automate the entire

financial accounting and reduce the the

the workload. At the time the two

accountant had to spend about 3 weeks or

so every quarter reconciling everything.

I did all that stuff with a purchase

button uh and took about three hour for

the whole batch to run. And so they were

so happy when I graduated high school. I

think they they wrote me a really good

recommendation letter. Uh, and with

other things that were going on and the

good grades and everything else, I I got

accepted MIT and then I got there and I

really learned computer science like the

fundamental of computer science. Back

then I was just like a kid who just, you

know, write programs. So,

>> and then during or after MIT, what was

your first professional job where where

you got paid and you worked full-time on

on techn with technology?

>> Uh, one thing lead to another. I was uh

when I was um at MIT, there was a

multi-year co-op program uh with uh some

of the best company tech company in the

world at the time. AT&T, Bell Labs, uh

Xerox Park, HP Labs, and all these

company Bor all over the country

actually. And so we applied for it and

um and then the best the the kids with

the best grade got prioritized. Then the

company had to go through a selection

process. They rank all the kids and then

the kids all ranked the company that

they got ranked and then there was a

matching process and I end up um coming

to Hill Packard Laboratories and AP was

one of an awesome company at the time.

>> Back then they were massive and like

very

>> very innovative laser printers you know

workstation computer systems all of that

stuff. I was in the HP lab which is the

research lab where a lot of the really

innovative stuff happened and so it was

a dream job. uh as a student I get to

work on cutting edge research with all

the other PhDs around um I get to write

the joint thesis for my bachelors and my

masters with the work there that was

part of the arrangement and uh when I uh

u graduated HP just hired me straight

into that research lab so I became one

of the researcher although I didn't have

a PhD and after that that were uh a few

years of that then I went into the

industry and write code that uh people

would actually use I really enjoy my

time at HP lab because you get to do

cutting edge stuff. We were working on

medical informatics at the time where

right now you go to every doctors all

your recctors following you. Back then

we actually have a network distributed

system architecture where every

physician workstation that you go to

right had your your X-ray and everything

follow and then you have like knowledge

base that actually look at for drug

interaction. Oh, we actually did that

research back in the mid late 80s

actually. And so like these are cutting

edge stuff. But then the the thing that

I find unsatisfied uh unsatisfactory at

the time for me was we published great

paper and then didn't go anywhere. It

was not productionized and I'm just like

I want this is so cool. Why can't we

bring it to the user? But that wasn't

the setup. The setup was research lab

worry about research and then we would

have like a a tech fair every year and

the general manager of every product

division swing by and then decide what

they want to pick up and productize. And

so I didn't feel empowering beyond the

research phase. So I just had to go find

a a 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 um interactive TV

where back then now we could take for

granted a streaming video video on

demand online game right cooperative

game. Back then we didn't have cell

phone internet yet and we can cobble

4,000 um homes together in an 18 trial

that has cable and then we invent like

network protocols and all these things

and we actually formed a set top which

is like tube TV not even a flat screen

TV with a set top box on top which is a

silicon graphics box and we can

implement online shopping uh um movie on

v video on demand and you're building

all of that without having any of this

stuff right here like we and and

celebrity like Michael Jackson came by

and saw demos and we saw Spielberg, we

saw everybody. We thought really believe

that was the future and it was the

future. The problem was it's way we way

way ahead of the time. Right. Then I

learned a big hard lesson. It's not

about just a technology. It's about

whether the world is ready for it,

whether it's economically feasible.

>> And and back then what was the point

where you realized like this is not

going to work even though we're doing

this awesome stuff

>> after a year, right? because um it took

like $100 million back in 1994

just to provision the head end. Silicon

Graphics love it because they sell all

these massive server to pump out video

and then the settop itself is a silicon

graphics workstation that cost $45,000

right people would not buy that right

>> especially like like in today's money

that would be like 10 $20,000

>> people would not buy that the early

adopter enthusiastic maybe right but not

for the mass market and so when we and

we we did that trial incredibly

successful we definitely all saw the

future and then we did the same trial a

similar trial with a different set of

software that we wrote for NT nippon

telephone in Japan. We went to Japan

deploy 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 a technology

right you got to be at the right place

at the right time and the right price

point and then uh 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 then mosaic browser search came

out uh Netscape was being form and um

yeah in the early days of Netscape and

so we saw very clearly that the the

advertising model worked for TV so it

has to work for the internet right

because all these content people would

use it if it's free but then who has to

pay for it the advertising so we we I

joined a company initially we call

ourselves netvertiser which is like you

know very and then ch it changed it name

quickly to net gravity and then it's so

uh enterprise software to put ad banners

dynamic ad banners ers on CNN on

Netscape site and all that. I was one of

the very early engineer there. I was the

fourth engineer I believe. Yeah. And so

um people don't know this but a buddy of

mine we were the first pup engineer to

put the first dynamically targeted ad on

the on the Yahoo page on the internet.

>> And dynamically targeted meaning that it

showed different ads based on different

or or like whatever.

>> Yeah. The version before I came in was a

script that crawl through and just put a

stick static banner ad and rotate it

through every hour. But then we it's

like we got to target it and then we

started using cookie we started you at

first it was a content of the the page

and and the person and then we actually

use that to actually target different ad

and then we have ad sequence and all

that stuff and that was the very first

one of course uh we had some success

there that company went public but

another thing that I learned was um

sometime you got to seize the market

right there's a company that formed

right much later than us but did an ad

service bureau And that took off because

it take a lot less investment for people

to you just stick a banner a tag on your

HTML page and then revenue just come

your way, right? Because the the the

service bureau kind of stick the app

there dynamically or 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 get to profit

first before you expand. Oh, and we went

down the profitability path and we then

becomes like you know a bigger robust

enterprise solution where the other one

is and try to get profitable and the

other one is just expand through the

internet like raising Wi-Fi then after

that years later got bought by Google.

So that was the journey there. There's a

lot of lesson there about how to build

things.

>> So, so this was do I understand that you

you you saw that what happens when

there's a big market and you you focus

on profitability which which should make

sense but a player focuses on growth

even at being nonprofitable. It might be

able to swallow you in the end.

>> That's right. Look at what happened to

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

that from my inspiration at the Silicon

Graphics day 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 uh 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 com bust happened right

of that time and then uh 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 just one thing on the

dotcom bus because you kind of swept

over it because you you've now seen a

lot of like ups and downs but can you

take us a little bit back what actually

happened with comb bus because the

people I talked to especially were new

grads it sounded very very scary what

what did you feel like and what did

people professionals engineers all

around you feel like

>> the com bus was was kind of scary when

the correction happened right but before

that there was this exuberance that

everything is.com right pest.com

fubar.com everything is a.com webban.

Yeah, all of that stuff. I still have

the webb van bin in my garage actually.

And so, yeah, but then uh there 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. Uh

you can grow fast, but eventually you

have to turn that into profit to be a

durable company. And so in that dot 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,

web van and others, whatever that would

go under because they didn't have like a

strong value proposition that last the

the test of of time, right? So, yeah,

it's all about the what value you

deliver uh 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 and it's hot

there. There may be a lot of AI things

that's going on right now, right? Uh

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 the

market will sort it out. In the end, the

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 cold quality. And

that's what our season sponsor Sonar is

all about. Sonar, the makers of Sonar

Cube, is deeply rooted in the core

belief that code quality and code

security are inherently linked.

Highquality code is naturally more

resilient, and as agents start to write

code at a massive scale, that

verification layer becomes your most

important security parimeter. This is

where solutions like Sonar Cube 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

thirdparty 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 experimenting outages

due to AI. As per Sonar states of code

developer survey 2026 report, it's

really about closing the gap between the

speed of AI and the reality of

production security. What else is Sonar

doing to help reduce outages, improve

security, and lower risks associated

with AI and agenda coding? Head to

sonarsource.com/pragmatic

to find out. With this, let's get back

on what Swan did after the 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 your job could be

in danger or you might have a harder

time switching jobs or did you not did

was was it a very short-lived?

>> It lasted a couple years. Uh I remember

and during that time it was definitely

hard to to get a job. uh especially for

new college grad that's always the the

the first layer that get hit right when

everything retrenchs people want more

experienced people uh people want to

stress 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 it comes and go in wave um yeah

so that's always a certainly a very

scary time u but of course you know in

the longer range of history things

generally tend to recover But it it

caused a rearrangement and yeah so

during that time it was it was certainly

tough. Uh however I the way I look at

this thing is like yeah talents are

always talent right so people really

strong talents uh and who's really

hungry is always um 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 peace

time invest in that skill never be

complacent constantly try to be better

and then in wartime or in rough time uh

those will save you right if people uh

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 um let's see after I went

from double click to that uh and then I

jumped into a fourperson company again

leaky roof and everything classic

startup that business did not succeed.

Uh 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

with try to solve the problem of you

know uh intermediation of web services

traffic going through and uh 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 uh and um but eventually

it it uh it went away but even then you

Those three years taught me a lot. Um,

okay. That you can survive even when you

do it from the ground up. Uh, then you

still have skill that you can pick up

despite the fact that that journey might

not end in like a commercial success.

Uh, 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 oursel 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

uh 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 uh to

look for the next opportunity. So uh

right after that I look at a bunch of

other thing when that company was

acquired and then I I went into VMware

um again when VMware was a pretty small

not very well known yet um so it was um

40 person organization and so that build

software to stitch together

>> so so VMware was still early

>> VMware was it's still early yeah there

was two there was three division um one

division that did the the workstation

desktop app and then there was the

division that does the hypervisor which

is the OS underneath the OS. Uh and then

there was my division that was building

enterprise software that stitched

together all of the hypervisor into like

a 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 virtual center that tied

to ESX. So that was um that was a really

really fun right people

>> and and then and then VMware really took

off. virtualization as a whole took off.

Uh in the early 2000s, VMware was was

core part of it. It was one of the main

things. So it was just uh was it a kind

of hockey stickish experience?

>> It was um not to the extreme of Uber. Um

but uh 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 in on a PC, but the true power

was the ESX, right? The Yeah. And then

that's what you power data center. And

then of course that's the the hypervisor

but the the I think the key feature that

made VMware so useful was the whole

votion 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 with 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, uh yeah all kinds of

things with it, right? So that's

actually make it very much like a cloud

operating system.

>> And then at VM where we also grew with

the company, right? So, so again I 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 I get when the thing get

large um and I start to feel too

comfortable, I get nervous

>> really.

>> Yeah. And so that's where when at double

click when I got to VP and I managed

hundreds of people, I like is this a

fluke or is it real? So I had to go back

to a fourperson 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 when a VMware

again is 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 how 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

you got big at VMware and VMware was

doing amazing. What made you um look

around and how did you find this very

small company at the time called Uber or

it might have been Uber Cab I'm not even

sure how it was called.

>> It was Uber at the time already was way

before that. Yeah. Mhm. Yeah. It was

when after 8 years at VMware um and

sometime people change sometime company

change uh sometime both side change and

so um 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%

engineing team. We're building this that

this software and 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 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, 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 and then

how did you come across again? Cuz Uber

was still pretty obscure.

>> Yeah. Uh here's a really interesting

thing. People do ask me about what the

search process look like. How did you

sit together a career like that? My

honest answer is I didn't do any of

that. And um and it wasn't luck that you

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 this, 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 uh that played out multiple time

for me um in the in the valley. And

especially I think the biggest

breakthrough was Uber. Again, when I

left VMware, I didn't plan to do

anything, right? I'm said well let's sit

back and take a look see what's going on

and then uh Bill Gurley from Benchmark

Capital who invests in early investor in

Uber and guess what his tie was he knew

me from that net gravity startup a

decade before and so he 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 uh 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 uh his

um office in um San Hill and he shared

with me the board deck and how the

company is growing and then I understood

the the business model right to all of

you back then when I trying to recruit

some people it was like why Don why you

joining a taxi company right

>> yep I remember everyone's asking that

question exactly and so but I I knew

that and of course then we have to go

through like a pretty rigorous interview

process with Travis uh And uh yeah, but

ultimately it's about the connection

that lead to the the right thing, but

that connection uh and the opportunity

is basically tied to your reputation.

>> And then back then as I I I looked it up

and you also helped me with this, Uber

just raised it series B which was $30

million is value at $300 million which

was sizable but still not nearly the the

gigantic company that it later became.

And one fun fact that I I read about is

you had this very rigorous interview

traveler process which was tens of hours

or or something like that. Can you can

you talk about how that went?

>> It was impressive on that he did that.

It was he committed over 30 hours

interviewing me oneon-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 we

end up after a while I kind of forgot

that I was being interviewed. It was

like through people kind of sharing

ideas like exchanging idea and sometime

disagree something and then kind of work

it out

>> and then you you showed me you took a

photo of like some topics that you

talked about like can you like summarize

what what those were?

>> Yeah. uh my very first meeting I drove

up to San Francisco and saw Travis in uh

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 um all that and then there is

also a list of shorter list of the five

things that he want to see in an

engineering team and and the culture of

the engineing team and yeah and so that

was the list and so after we wrote the

list um 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 uh as soon

as I drove drove out of the office. I

barely get to the exit. I got a call

from the the recruiter say, "Go Travis,

we want to see you again and talk talk

some more." And so we did that. And of

course, he's very busy. He's traveling

around the all the uh regional offices

um 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 picture a

photo of that whiteboard and he did the

same thing as a as a list of topic to

talk about and I still have it on my

phone today. It's it's so impressive to

me that cuz we'll we'll share that list

uh in this episode as well that

screenshot but that the fact that the

that the CEO would go into things like

code review like it's the hiring topics

I understand but but that he was so

engineering minded or

>> 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 he knew that

and it was very clear from the very

beginning that he viewed the business

has two major engine that powers it. One

is the operation you know bits and atom

right you got to have wheels physical

thing moving around the world and then

there's technology and technology is a

key part of that right no one side is

super appeal to the other but it require

both of those uh yeah and so that was

very key and I think he also knew what

he wants also uh and what he want in

whoever it is and so I think this list

and this this this series conversation

was for him to to vest that yeah Later

on, I I 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

inside, we all working with each other

all the time and can we disagree on

something? Can we work things out? Do we

have generally similar philosophy and

principle? And he did it himself. Yeah.

And so that Yeah. and and the the level

of passion and commitment he showed was

just really impressive from from this

side I can tell you uh for example

there's some session when we totally you

know in the middle of that and two hours

gone by and he had to like 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 had 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 um

about 30,000 rides a day when I pulled

the data the the the weekend which is

always the busiest time when people move

around. Yeah. That weekend uh the the

day the the Saturday or Sunday before I

join I joiner Monday. um was about

30,000 rides a day. Uh and Uber was I

don't know 20 something cities around

the world at that point uh 2030 and so

it was very modest. The there's certain

things that were going for it already.

The the engineing team was very young

but uh pretty scrappy and uh pretty

committed and talented where whatever

need to get done by hook by group they

co together right and so and as a result

though the the the service was

beautiful. anybody who ride we only had

black car service at the time but the XP

was beautiful when for all the people

who ride it that's why word of mouth is

you know raging around and uh yeah and

so that was the really good part now the

thing that maybe Travis had foreseen or

whatever it is was the next phase which

as the company grow faster and faster

what happened right uh and by the way

the the the 40 engineer were very very

young I think in the 20s all of them and

um the system was built not to scale,

right? It was built for functionality.

It's actually

>> 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. Um yeah,

everything breaks. Uh and um and we have

to basically race against time to

actually figure out what would be the

next most critical thing that would

break and how to get ahead of it. And

one of the thing that drivers always

tell me even from the interview days is

you got to see around corner. So I try

my very best to see around corner this

that's and one of the first thing I I

did when the first couple weeks were

beyond getting the getting to know the

engineer and build relationship and

build trust was to start examine 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 writers and

and drive

>> yeah it's it's our matching service

right when when it has the drivers the

writers and does the match

>> that's right and without that there's no

business right there's

And so yeah and I I start that was the

first system I looked at and I asked

some I I reviewed the architectures I

reviewed the implementation plan and um

it was very obvious that wasn't going to

get scale uh it was a JavaScript it's

NodeJS and it was a single threaded

thing and the engineer at the time where

when the city get larger and larger uh

they need more out of that piece of code

to power that city they would move that

piece of code into a larger machine with

a faster processor.

>> Vertical skilling only gets you exactly

so far.

>> So my role also is to do thing but also

to teach people along the way and so I

would just asking leading question to

the team and the team only have three

people three or four people at a time

and uh so I asked the engineer um okay

what would happen if the city get larger

and you have to support that because

every city is getting larger the ride

volume is getting larger and larger. Uh

then entry base said, "Oh, yeah, we just

we just move it to um a more powerful

processor and say what happened if you

get to the fastest process 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 got three

or four of these things servicing same.

Do they talk to each other? Do they

share the same state?" Not really,

right? So it become very partition. So

pretty soon by asking those leading

question, the engineer now discovered a

flaw that this thing would not scale,

right? And then and then I had to

establish the limit of where is the

brick wall and I basically said what's

the biggest city uh do we currently have

in terms of right volume and uh they say

New York City and I said okay when is

New York City is going to we can run our

capacity even handle New York City 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 uh and we

have to write it in a really scalable

way And uh and I only have two

requirement that I 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 byM.

>> You gave them these two constraints.

>> No new feature necessary. Just make sure

that we can do that. And then that allow

the business the company to just pour a

whole bunch of hardware behind that and

it will scale. Technically it will scale

infinitely right. And so the engineer

did that and because the requirement is

very simple uh we have to do it really

really quickly before we run out of time

uh run out of runway to survive and uh

so they did that and we actually

deployed that right around August

September right before it actually

>> and then on to the next problem database

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 uh so

there's all these threat coming at us

and we have to establish like how much

runway we have until we like 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 I joined later

but rewrites were still continuously

happening and I think when you come in

you ask like why could have they not

written it properly the first time or

like but but I I guess do I understand

correctly that it was because a

sometimes you just build a system to

solve your problem and and and b you

don't always know how big this will say

a good example is the the New York

problem And then you take those

constraints and then you build a system

and then if those things change later

you might need to build a different

system.

>> Yeah. Um it also depends on how fast

you're growing that dictate how you make

and because the faster you grow the

shorter runway you have to survive right

given whatever architecture and system

that you currently have. And yeah the

the the question about how big it can

possibly grow nobody knows really. But

it's actually not fruitful to

pontificate on that. Yeah. It was all

about um how much time we have to live.

>> Yeah.

>> Right.

>> We don't we hit the brick wall and it's

no way out. Right. So yeah, and and if

that time is really short, then don't

overthink it. Just survive that and give

yourself enough runway to then live to

fight another day is what I like to say.

>> Growing fast like Uber did is a good

problem to have for startups until it's

not. And the pain points that come with

fast growth is a good time to mention

our season sponsor, Work OS. If you're

building any SAS, especially an AI

product, surprisingly, you reach the

need to build enterprise features like

SAML edge cases, directory sync, audit

logs, and all the things enterprise

customers expect quickly. Building that

infrastructure yourself takes months.

Work OS gives you APIs to ship it in

days. Authentication, SSO, SCIM, Arback,

audit logs, and more. All designed to

integrate directly into your product.

That's why companies like Entrophic,

OpenAI, and Cursor already run on work

OS. Skip the rebuild. keep shipping.

Visit workhaw.com. With this, let's get

back to Tuan's team rewriting the

dispatch system and the short breeding

space that this first rewrite gave them.

So that's what with dispatch, we knew we

had to do it very quickly, maybe by

ourself 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 need to be

rewritten several time. Let's say if my

requirement for the engineer was build a

system that will scale infinitely to the

test of time, it might take a year. We

never get there. We'll die before then.

>> Yeah. Speaking of of dying before, you

were given in 2014 a seemingly

impossible task. Travis told you you

have two months to launch in China. And

apparently launching in China was not as

simple as just like opening your API and

allowing the firewall. What was that

project like? I heard it was an

absolutely manic and crazy project. Can

you take us back what it was like? Yeah,

that 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.

Um, and now explain why so that that is

so so I remember very very clearly right

around Christmas time 2020 14. Uh we

were all hanging out in the the the the

the

big room in uh 1455 and Travis made a

declaration that okay come the new year

I'm going to light it up and we're going

to go into China. Okay. And then he

turned over to me. It's like I want the

uh and one of the requirement at the

time was that we have to run our

services on China soil, right? And data

center physically there

>> physical data center needs to be there

>> until then we kind of dabble in dirt

water by powering it from from the US.

Okay. And we have a limit of time um to

do that but he's going to light it up.

We're going to do that. And I said he's

like two months. And I said well that's

really tough. And he's like why is that?

because I can go rack all the machine

and copy the software over and shouldn't

take more than two months and then I

have to like explain that it it's not

that easy because when you do that then

it work on day one and then the two

drift and how you going to maintain that

right we don't have twice the

engineering team to actually manage two

different system that deviate

>> so the right way to do that is you build

rearchitects whatever you need to do to

kind of build one system that that can

be partitioned right so I think there's

a huge security concern right because

there are anything that runs over there

cannot presume to have any level of

privacies or anything like that. Uh but

over here we have to protect everything

right. So we have to build that same

system that has completely partition of

data and controls and everything else so

that yeah nothing bleed across but it

has to be every time you deploy code you

have to close everywhere right so you

have to re rebuild a lot of things and

uh so I went to the TPM team and asked

uh the team to actually scope it out and

I think

>> TPM technical program manager

>> technical program manager and um I think

the best path for us was about six

months and that was the fastest we can

even imagine

I benchmarked with a few of my friends

in the industry and they kind of laugh

at me and it's like 18 months minimum

thing. Uh but you know that was Uber so

we just like we didn't think too much

about it. was like well that that um

let's do that and then driver didn't

like the the six months so we kind of

settle around four months right so and

so

>> because he didn't like

>> we just split the difference we didn't

know anything but we just want to heads

down and start getting to it and so we

look at oh what need to change given

like this is the end u uh goal and the

requirement and then with everybody

start getting really busy uh working a

lot of hours to stop making these

changes and four months come and we are

still a month or so short so we slip the

winter trappers and he's not too happy

about that but it's fine right and then

uh five months comes around and we're

very close but we're not there we're

about to slip again and so uh it was not

h definitely not happy then but we

actually

talk it out and I said the team feel

very confident that within a month we

can launch but he had to give us

something that mean give us a ability to

incrementally launch instead of lighting

all the city in China oper once let let

us do it in phase right every single

week we'll launch a number of cities and

then we're going to do it in a process

of like a few weeks and then we're done

with that and he said okay that's

reasonable but he want the the biggest

city first and that's Chungdu

>> so he he agrees to the incremental

launch but you need to start with the

biggest

>> start with the biggest first

yeah exactly but it it is brilliant

though you think about it uh I I 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 swag the team know would go into

the next set of city with confident had

we done the traditional way let's start

with the safest one the smallest one

first and next one we step it up on the

surface it seemed like oh it's a very

good risk control measure but every

single week we'll be holding our breath

until it's done it's not done right but

this time we we did everything we and to

do the hardest thing first and after

that it just the routine process

throughout the rest and that it worked

out exactly like that and so yeah we got

it done and a bunch of people were

really burnt and then they took like a

month off go to the beach and did

nothing except stare at the water I know

some other did that uh but after that

though we're not fearful of anything we

did like kind of the impossible and

>> I I I I talked with a friend at who

worked at the IT team at the time and

his job was just to get the servers

physically set up and he said that

>> the timeline was so impossible. I think

they had two weeks from start to finish.

They had a little bit of time to plan

but they were on the site. They were

just and and when I gather the stories

from the software engineers who worked

on it, everyone had their own impossible

task and project and they all thought it

couldn't not be done and then somehow it

all came together.

>> That's right. None of us thought the

whole thing that could be done, but we

just got our head down and we just, you

know, break it apart and just do it one

step at a time.

>> And then I think needless to say, but

the China launch was a massive success.

Uber started to compete head-on head

with the leading Chinese provider DD.

And they were is pretty much head-on

head uh very intense competition all the

while competing with the rest of the

world as well.

>> That's right. Yeah.

>> So that that was something incredible.

That was something incredible and I

think just the experience having gone

through that and doing thing that

initially you didn't think was possible

just increases everyone's confidence and

range and and that's what stretching all

about and I think that there's a saying

that Travis like to say that sometime

you have to be willing to redline

yourself a little bit right and that's

how you you you prove that you can

actually do a lot more than you can that

was the fearlessness of the 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 about from the outside is

microservices and from the inside one

thing that uh has been very talked about

is a program and platform split. Can you

tell us which one came first and and how

do we get to as many microservices as we

did? The program and platform came

first. Yeah. And microservices came

later. Um and the platform and and uh

program platform as an organizing

structure came first out of necessity.

When I came in April of uh 2013

uh we had 40 engineer and three product

manager.

>> Yeah.

>> By the end of that year um we had about

a 100 engineer and a dozen or so product

manager. Even at that really small size

we ground ourselves to a halt with a

functional or structure. Uh imagine a

low tone engineer there about up to

eight or 10 mobile developers uh a

number of infrastructure engineer and a

bunch of backend engineer etc etc and um

five eight people or so at dispatch now

but every feature that we want to put

out has to be queued up on mobile

development bandwidth dispatch bandwidth

and it become impossible to navigate

tradeoff because every feature you want

to do you have to go negotiate with so

many team right and so then the team

want to move fast and start to feel that

friction and complain right away. And

that's a good thing, right? You know, we

raised a concern. And so I remember uh

Travis and Jeff Holden and I saw that

and we got together for a couple days

actually and I remember we had uh sticky

note all the different colors each color

represent a different function

engineering product designer um and uh

we put one person name to each of the

sticky note and then Travis gave a talk

about what are the most important area

of the business that he think right and

at the time they were like 17 area that

he can think of the the world of Uber

can cover 17 area turned out to be a lot

more than that but at the time it was 17

we didn't have enough to fund 17 we had

enough to fund seven plus a few more

right so we fund seven uh with partially

the next four and that's it and the rest

can remain empty until we hire more

people and we fund it and so that was

the the the the thing but then as part

of that process we then put sticky note

onto each of these area has to be a

cross functional team because we can no

longer afford to run in no uh yeah cross

function rather than a functional team.

>> Yeah, which means that there's like a

back end, a mobile and whatever else

they need like a design if they need to

etc.

>> That the the concept is that team has to

have all the skill set necessary to just

get it done. Whatever they have to do,

they just go off and they do that.

Right? So that was the the principle

behind that decision and then we call

some of those program and some of them

platform. So programs are the team that

build thing that the end user actually

use and the platform are the thing uh

that build tools and layer that other uh

program team use and that was it sort of

horizontal versus vertical kind of

thing. So and that's that and and then

after we define that then we start

putting the right sticky note onto that

box and then that's how the first

version of programming platform came

about.

>> And then how did microservices start and

how did they blossom as much as they

did? Yeah, again um you know none of us

wanted to go through that extreme but

lots of time when you are under a lot of

pressure and no time to react other than

just to survive that scale that keep on

coming at you, you have to make uh

decision that increase uh speed and

velocity because speed and velocity

allow us to build quick enough to

survive and so um we knew right away

that the the backend API which is a

monolith, right, is the thing that will

prevent prevent speed from happening,

right? So, we made a declaration

anything that is new need to be built

outside of that. Yeah.

>> As a microser. Okay. And then there's a

team that's dedicated to decompose that

that monolith that API monolith into a

bunch of services.

>> Yeah. We used to call it API, right? I

think

>> that's called API, right? And uh I think

that project name is called Darwin.

>> Yes, Darwin. Oh, I remember.

>> Yeah. And interestingly, had we freeze

time, that piece of code could be

decomposed in a matter of 3 to 6 months.

But it took us 2 years to do that

because as we peel out a piece of code,

the business keep on going forward,

right? These hockey sticks are laying on

top of each other now as we launch new

city and happening fast.

>> New city and new product Uber X.

>> That's right. Feature has to be added

on, right? And so the philosophy we all

operate at the time was no one should be

blocking anybody else. No one can block

anybody else. And so when a team that

need to build a feature and that thing

hasn't been pulled out of monolith, they

add to the monolith, right? And then the

team that pulls it out do the best that

it can and then we kind of keep chasing

our own tail until eventually you know

something get completely pulled out and

as it happened it bulges up like this

the monolith right because you pull out

one thing the remaining stuff grew even

faster than the stuff that you pull out.

So the code base get larger and larger

eventually reach to a certain point when

it start to come down and that's why it

took two two years and meanwhile

everything that is new must be auto

because we don't keep on adding stuff

right to to the monolith and so that's

how it came up to to like you know

thousands of microservices but that was

out of necessity so that we can just fan

out and solve every problem all at once

and then over time after things

stabilize and so the business more

mature and growth is not as violent like

that anymore uh then the team uh we

actually have a project called ARC. We

can look at this stuff and how do we

clean it all up. So we put like domain

interfaces on top a whole bunch of

microservices that are within the same

domain. It's

>> it's funny because I remember that

around like 2016 or so there was a

published Uber blog post that Uber had

about 5,000 microservices and I just saw

about a few months ago Uber published

another one and they have about 4,500.

So in that 10 years the number has gone

slowly gone down right to go down but

even then right now Uber has so much

more complexity right yeah it's the

process what took a little while but

when yeah the team had to look at

everything and how do we simplify that

right and and then to make sense out of

that the new tool has to be invented by

us gagger the tracing tool all of that

stuff and so that be really great tool

that we open source to

>> and let's talk about h how and why Uber

built so much internal tools and also

open source a bunch of them. Jaker was

one of them but internally we had

schemaless a trip data store T channel

RPC protocol ring pop g spatial placing

clay service framework you monitor

observability and there's like hundreds

of others some of them open some of them

not

>> how were you thinking about that like

does it not seem like a lot of waste for

us to build this or was it again

necessity

>> it was mostly necessity I can't claim

that every single one of those thing

were absolutely necessary but all the

important one were absolutely necessary

the thing is when when I started

Uber used pretty much all the open

source stuff. We use Reddis, we use

everything, right? Because those the

engineer there just focus on putting

together a service that actually move

cars. But then as we scale uh we keep on

using uh pushing the boundaries of the

capability of those um um open source

stuff and to the breaking point and at

certain point if we don't invent

something to power our own need. By the

way, this is 2013, 14, 15, 16. It's not

as mature as

>> we did not have the kind of the big tech

investment in open source back then.

There was very little and and mo most of

the big teams like Google and Facebook,

they were keeping their inside.

>> I remember like for example a very

painful example of that we had to face

early on was we use Postgress.

>> All right. and we get to certain scale

that postquest would randomly fail and

that take our services down randomly

without we don't understand it's inside

the kernel I remember the time where I

had to go on LinkedIn begging people who

anybody on LinkedIn that has any

knowledge of postgrad to be our

consultant to help us diagnose this

problem and we spent several weeks and

during that it was terrifying because I

don't mind if we think we can do

something of our own problem it's

terrifying when we have a major problem

and we depend on somebody else and we we

don't know because it's open source

there's no single person no some single

company I'll be willing to pay anything

if someone can give me an answer but

there was no one right and so that was

one of the motivator to kind of build

our own you know data layers and all of

that stuff as well so that we would use

this generic database uh and we end up

using uh my SQL just as table data store

all the logic on top we have to build

for our own use right because then we

control our own state and we only build

the feature that we really need, right?

And so that was one of many example and

eventually we run into other brick wall

of scaling. I remember in 2015 right

around the holiday I was taking a

holiday trip. I had to go to the airport

and I I took an Uber ride as usual. The

receipt didn't come for 2 days after

that, right? Why is that? Things were

queuing up. We weren't processing things

enough, right? And so yeah, but that's

not a dealbreaker for many people

because they just ride and then receipt

come later. is fine uh as long as the

building and all the stuff even when you

build people late they don't really mind

that either right but as long as the

right happened the rest of stuff can be

processed later but it's still not great

okay when I dug into it like our data

processing capability is at capacity

right so we have to rewrite a bunch of

stuff and then our cap ability to

monitor things is reaching a breaking

point with the open source tool that we

use so the M3 has to be invented right

and all of that stuff so we we allow lot

of we had to do thing because we at the

scale where we broke all the open source

stuff that we use

>> at Uber we did unusual things one of the

most unusual projects which is where you

and I met when I joined Uber was called

internally called Helix it was

completely writing Uber's app and as I

understand what happened is Uber's user

experience was starting to degrade

because it was really cluttered got a

bit fed up with it the designer team

came up with a solution which was a very

nice and clean UI which kind of the

engineering team looked at it and it

would have been a full rewrite And then

we just did a full rewrite. Back then I

remember we had a million or two million

lines of code. We had two or 300 mobile

engineers working on this. This was a

massive business and there was an

extremely tight deadline set. Can you

take us back on why did we even do this

>> because from it didn't feel it felt

existential threat from the inside but

it was not like uh like a plus versus uh

versus Facebook existential thing. And

how did we decide on that short

deadline?

>> Yeah. Um it seemed like a recurrent

theme that keep on coming up was a tight

deadline, right? Everything we do had a

tight deadline. It's just it's yeah it

just that's just how the culture role.

Um anything we want to do want to do as

fast as we can. Um but going back to uh

why Helix um actually Travis has a

vision right and it's actually not just

the designer Travis and uh Yuki who was

the lead designer at the time they pair

up and they all the storyboard and

everything else. So he has a vision

where the current app back then was too

limiting. Yeah, it's really good. Push a

button, get a ride, all that stuff. But

if you want more services to hook in

other things, right, messaging and all

these other things as people were

riding, uh the new architecture allow it

was much more open, right, to all those

things. Uh and so that was the the

vision behind that. And then when we're

doing that, the aesthetic is really

important. The icon change and all of

these things change. Oh, yeah. And so

but that but that is yeah it's beautiful

right that's actually Travis and Yuki

right they were and then of course when

when that fleshed out to a certain

amount um then the engineering team the

mobile team get involved and it's not

just the mobile engineer the back end

had to be written to everything

>> we we we changed from uh the heartbeat

where every 5 seconds we would pull and

it was pretty painful to an actual push

uh push channel

>> yeah this part with that by by that time

it's called real time system now right

yeah it has to change back end has to

change everything has to change to port

the new flows and then all that stuff

and so yeah it it took I don't know 6

700 engineer all told 7 8 months to

actually do it then we put it off and it

still live today it's still on that same

architecture it was so far well thought

out it's almost like 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 scalable user experience

>> I take no credit in that it's like the

genius of Travis and Yuki

>> you every now and then sent emails to

all of engineering on different things

and I remember this really really

emotional email coming from you uh about

naming.

>> I see all this and I understand that

young engineer want to have fun.

>> We were having fun.

>> Yeah. And name things in a goofy way. I

think the trigger for that was a service

named Mustafa. I have no idea what it

is. Right. I look at that stuff and and

by that time we were already very

complicated, right? And we had to

onboard new engineer all the time. we

want builders to ramp up quickly etc etc

and I can imagine an engineer come in

here and if all these weird name have no

context to it uh at the time our tooling

wasn't that great either right you blame

didn't come into existence yet right and

so there's no mapping for people to

discover what this really mean and then

those we renaming scheme so I got to the

point where I'm kind of fed up so I send

that email out of course you know those

mass emails sometimes you regret after

you send it out because it has some

effect but it didn't really solve

>> and I I think it very quoted because you

specifically wrote this is not a Mickey

Mouse shop.

>> Exactly. We're not Mickey Mouse. We and

and yeah, it was uh again it was it was

a growing up phase for everyone in the

company. But it was it was my

frustration at the time was look at at

this scale inside we got to take

ourselves seriously. We got to do thing

better faster and this is not helping.

Tuan's been talking about improving

things as the orc 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 stats. Statseig

built a unified platform that enables

both experimentation and continuous

shipping. Built-in experimentation means

every roll out automatically becomes a

learning opportunity with proper

statistical analysis showing you exactly

how features impact your metrics.

Feature flags lets you ship continuously

with confidence, roll out to 10% of

users, catch issues early, roll back

instantly if needed. And because it's

allin-one platform with the same product

data, teams across your organization can

collaborate and make datadriven

decisions. They have a generous free

tier to get started and pro pricricing

for teams starts at $150 per month. To

learn more and get a 30-day enterprise

trial, go to stats.com/pragmatic.

With this, let's get back to Tuan. We 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

senior level. For a while Uber had a

senior engineering level called L5 which

is common and then at some point you

were the leadership team cut it into

two. There was L5A and L5B senior one

senior 2. Can you talk us about why you

did that and where did you get the idea

from?

>> I did that. I'm I'm not apologize for

it. I think it was a good move at a

time. Um and the the the principle was

we want people to grow right but we have

a very clear definition and expectation

of what it is at the staff engineer

level because we benchmark ourselves to

all the great company out there Google,

Facebook and all that

>> and then I realized that for many

engineer crossing from senior engineer I

mean um engineer two pass through the

senior engineer to get staff it could be

a fiveyear journey.

Okay, it's a long time and so I just

want 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 some people it's good enough

to make it to senior

>> senior too. Yeah.

>> And I think that's a benefit. It's not

right but versus like not doing it and

everybody kind of just get lost in that

five year you know journey. Um yeah and

so that was the the motivation behind

that. So you saw a problem and then this

was a solution and it it it worked we

can say right

>> it worked for a while right and then

people were acclimatized to that and

then they start complaining it's like oh

why there's two level we need to get the

staff faster uh and then while I was

there I held on to that because I was a

principal and staff is staff compared to

the best of the industry

>> u and later on after I left I think it

got

>> re they got pushed down L5B is now staff

everything got pushed down

>> inflation and I I didn't want to do a

cytoin inflation thing.

>> I I I appreciate that. Another email

that I I remember from you is in 2016

you sent an email saying you've heard

the feedback that NGS are unhappy

because their managers not support them

and then what you wrote is like we are

creating an easy internal transfer

process. You can move teams how how was

that received and again how did you

decide that we need to do this? I look

at um 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 uh and then I thought

about the next logical step which is hey

if people come to us and just resign

they didn't tell us when they interview.

>> Yeah. And so why the heck do we have

like these rigorous process when you

have to ask your manager for permission

to go to another team. Yeah. Why do we

make it harder for ourself right when

our own engineer go from team A to team

B have to ask for all these uh you know

permission where they don't have to ask

if they interview outside. Yeah.

>> 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 manager now need to be

incentivized to take care of people

great develop them grow them you know

put position the best people into the

best time for them to grow and then they

not like to leave their own team right

if they continue to grow. So there's all

of that you know that back pressure

might cause engineer managers to be a

little bit more responsible too. So that

was that and I remember that get quite a

bit of push back because it would be

pretty radical at the time you but we

just did it anyway and so that that

turned out to be the the right thing to

move right and I would rather people

trust each other and when an engineer

want to go they should have a really

great relationship with their manager

where they just talk to man hey look I'm

I'm 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 the wrong thing I

have a saying that I share with you guys

all the time

It's not a jail. We can lock anybody

down, right? Everybody have free will.

If they want to work, you know,

somewhere, they should have the ability

to do that. And uh we should create more

opportunity and then we also to support

that. We publish internal job board,

right? Anything on the outside see we

see on the inside. So any should be able

to shop within all the opportunity have

inside the company and stay with the

company. And why make it so hard and end

up leaving the company? That's just a

silly thing. I remember at Uber in in

some of the the meetings either all

hands or team meetings you you gave

talks that were memorable and one of the

most memorable I 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

or this topic about behaving work in the

perspective of death. Yeah, I don't

remember that exact speech but I I do

have that line of thought in my head all

the time right and sometimes I would

share with different audience with

different context but it is um it's all

about finding one's you know purpose and

not take oneself too seriously right if

you look at uh 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 like not know enough

yet or they have to all that right so um

yeah so I always take opportunity to

remind people to sort of be humble and

the example I use always is use myself

right I say look you know 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 salt

right And that's always happened, right?

The the world forget about us, right? So

the only thing we can really do is in

any job that we do, do the best that we

can to help each other to leave a

lasting positive impression in each

other. And one day everything ends a job

end and then I'll get to the mor stuff

like life even end itself. And so then I

measure my myself like what is my

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 that

because I can't take anything with me.

And so live in the moment, be as best as

you can to everyone and be very as

constructive as you can and uh and and

leave a good legacy behind you. So that

that that was a whole gist of that. It

it feels to me sometimes there's talk

about how you can network better and

grow your network, but sounds like this

is almost like it's it's not a hack.

It's just do the work, right?

>> Do the work and then the right thing

happen, 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 you being

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 pull in and you don't have people to

support you succeed, you would not you

would not succeed also. And here is an

example at at Uber right when I came in

uh again the engine we talk about very

very young in experience did not know

how to build system at scale reliable

all that stuff and the network that I

have who really knew how to do that was

from VMware. You're building system

software. We're building operating

system. Right. Rigorous principal level

engineer all

>> experience. No like in their sleep they

can do it. Right.

>> Right. So when I came in and when I have