# Tuan Pam on Scaling Uber, Microservices, and AI Engineering Trends

**Podcast:** The Pragmatic Engineer Podcast
**Published:** 2026-04-01

## Transcript

When Tuan Pam joined Uber as the company's first CCO in 2013, the company had 40 engineers, the 30,000 rights per day, and the system crashed multiple times per week.
He had five months before Uber's this price system would hit a brick wall with no way out.
Seven 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 Kellnik for the CCO role, which lasted 30 hours, spread over two weeks.
Scaling through chaos, rewriting dispatch before it collapsed, launching China in five months, and the full Aperite 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, 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 Tuan was a CTO, and Tuan is a 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 seasonal 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 Uber.
Uh probably my first month I already met you in like some really like fun slash restful circumstances during Helix, the Uber ApriWrite, which was a crazy project.
But 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 uh 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 Vietnam, 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 yeah, the country was unified, right?
The South is lost and north has won.
And there were a fair amount of uh repercussion, right?
People who associated with the Southern regime would not have much of an opportunity uh growing up, the education opportunity, all these other things.
That was again the the way it was at the time.
That's not necessarily true right now, uh, but uh that was.
And uh my mother then made a very bold decision that she wouldn't want her two sons 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 rinkety boat, uh fishing boat, uh whatever thing they can get their their place in and uh escape the country uh 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 percent.
That about two million people left, about a million people survived the crossing because this uh these boats are not seaworthy, and we crossed the ocean.
And um, yeah, but we were the lucky, we were lucky half, really.
But no one thought about it.
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, took many try and took it depleted the entire, you know, saving of my uh parents that because it was scam.
People 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 pretty good captain who actually navigates through storms and and all that.
And we survived even pirates from Thai.
I was around, I think 11, 12, somewhere.
And so we crossed that and we survived three uh three days, 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 um then we were waiting to be processed.
We got interviewed by all the different countries, and uh the US uh gave us a refugee um settlement uh because we were tied to the old regime that were supported by the uh Americans.
So we were very, very thankful to get here, the the land of opportunity, and uh we didn't know any English, we didn't have a 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 have to uh build from the ground up, and uh so that that was how I grew up, and that's how I got here.
And I'm from this like absolutely not just unconventional, but just extremely hard start.
How did you eventually get your interest into the computers into tech?
Just like most things in life is by happenstance 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 where one of the very first one.
The one with like two floppy.
Was it 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, 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 comes 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.
You solve the problem one, that's the creative part.
After that, I get bored.
I gotta 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, D Base 3 with all the scripting languages and automate the entire financial accounting and reduced the the workload.
At the time, the two accountants had to spend about three weeks or so every quarter reconciling everything.
I did all that stuff with a push-up button, uh, and took about three hours 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 technology with technology?
Uh, one thing led to another.
I was uh when I was um at MIT, there was a uh multi-year co-op program uh with uh some of the best company, tech company in the world at the time AT<unk>T Bell Lab, uh, Xerox Park, HP Labs, and all these companies, Belcore, 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 rang all the kids, and then the kids all ranked the company that they got ranked, and then there was a matching process.
And I ended up um coming to Healer Packard Laboratories.
And HP was on an awesome company at the time.
Back then there were massive and like very innovative laser printers, you know, uh 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.
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 uh when I uh uh graduated, HP just hired me straight into their research lab.
So I became one of the researchers, although I didn't have a PhD.
And after that, that was 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.
But we were working on medical informatics at the time, where right now you go to every doctor's, all your rectors are 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 followed, 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 these are cutting edge stuff.
But then the the thing that I find unsatisfying, 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 the research lab, worry about research.
And then we would have like 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 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 found a set top, which is like two TV, not even a flat screen TV, with a set top box on top, which is a silk and graphics box, and we can implement online shopping, uh movie on via via on demand.
You're building all that without without having without having any of this stuff right here.
Like wow.
We and then celebrity like Michael Jackson came by and saw demos and we saw Spielberg, we saw everybody.
We thought really believed that was the future.
And it was the future.
The problem was it's way, we're 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 like this is not gonna work, even though we're doing this awesome?
After a year, right?
Because um it took like a hundred million dollars back in 1994 just to provision the head end.
Silicon Graphics love it because they sell all these massive servers to pump out video.
And then the set top itself is a silicon graphics workstation that costs four or five thousand dollars, right?
People would not buy that, right?
Especially like like in today's money, that will be like 10,000, 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, 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 NTT, Nippon Telephone Telegraph 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 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 uh Mosaic Browser Search came out.
Uh, Netscape was being formed, and um, 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 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 often.
And then change it changed its name quickly to NetGravity.
And then it's so uh enterprise software to put ad banners, dynamic ad banners on CNN on Netscape site and all that.
I was one of the very early engineers there.
I was the fourth engineer, I believe.
Yeah.
And so um people don't know this, but uh a buddy of mine, we were the first pay-up 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 the internet.
Yeah, the version before I came in was a script that crawled through and just put a stick uh static banner ad and rotate it through every hour.
But then we it's like we gotta target it, and then we start using cookie.
We started new at first it was the content of the the page and and the person, and then we actually use that to actually target uh 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've got uh seize the market, right?
Uh there's a company that formed right much later than us, but did an ad service bureau.
And that took off because it takes a lot less investment for people to you just stick a banner, uh, a tag on your HTML page, and then revenue just come your way, right?
Because the the service bureau just kind of stick the ad there dynamically and all 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 and get to profit first before you expand.
Oh.
And we went down the profitability path, and we then become like, you know, a bigger robust enterprise solution.
Whereas 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, the click got bought by Google.
So that was the journey there.
There's a lot of lesson there about how to build infrastructure.
So this was do I understand that 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 the right move.
I'm starting to see how these things are coming together.
So now you're you're at the startup which almost took off, but not quite.
And then what was your next step?
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 nobody got the VP.
And then after about eight years, seven years there, and the dot com bust happened, right?
At right at 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 one thing on the dot-com bus, because you kind of swept over 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 dot-com bus?
Because the people I talked to, especially were new grads, it sounded very, very scary.
What did you feel like?
And what did people, professionals, uh, engineers all around you feel like?
The dot-com bus was was kind of scary when the correction happened, right?
But before that, there was this exuberance that everything is dot com, right?
Uh, pest.com, foobar.com, everything is a dot com.
When ban.
Yeah, all of that.
So I still have the webbing bin in my shed, actually.
And so, yeah, but then uh there was there was a checkout eventually, uh, 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-com wave, there were massive companies that emerged, right?
There was Google, there's Amazon, all of those companies.
There's also a bunch of other companies, uh, Webband and others, or whatever that would go under, because they didn't have like a strong value proposition that lasts the test of time, right?
So yeah, it's all about 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 that's just a me too, right?
Just put a dot com on something and it's hot.
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 code 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.
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 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 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 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/slash pragmatic to find out.
With this, let's get back on what Twan 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 your job could be in danger or you might have a harder time switching jobs, or did you not did was it a very short-lived?
It lasted a couple years.
Uh, I remember.
And during that time, it was definitely hard to get a job, uh, especially for new college grads.
That's always the first layer that gets hit, right?
When everything retrenchs, people want more experienced people, uh, people want to stretch existing folks rather than keep on you know hiring entry level stuff that you have to you know continue to invest in, right?
So it's just an economy of time.
It it comes and go in wave.
Um, yeah, so that was a certainly a very scary time.
Um, but of course, you know, in the longer range of history, things generally tend to recover, uh, but it did cause 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 with 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 peacetime, invest in that scale, never be complacent.
Constantly try to be better, and then in wartime or in rough time, uh, those things 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, but that's time.
Yeah.
So let's see, after I went uh from double click to that, uh, and then I jump into a four-person company.
Again, leaky roof and everything, classic startup.
That business did not succeed.
Uh, it took about three years or so, got to about 40, 50 people in size, and then kind of ran out of money and then got acquired by another entity that was built with a security appliance product, uh, which now 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 uh, but eventually it it uh it went away.
But even then, you know, 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.
Um, but your skills still get better.
So you you are getting better as a professional, even though that's right.
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 sides succeed.
But if the other one succeeds, 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 things that you learned so far and all the mistakes that you've made.
Oh, all you 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 things when that company was acquired, and then I went into VMware.
Again, when Eventwell was a pretty small, not very well known yet.
So it was a 40-person organization and sort of that build software to stitch together.
So VMware was still early.
VMware was still early.
Yeah.
There was two, there was three divisions.
And then there was the division that does the hypervisor, which is the OS underneath the OS.
And then there was my division that was building enterprise software that stitched together all of the hypervisor into like a cloud platform, a management platform.
Right.
So I was the response for that.
Those are 40 people.
And we kind of built the very first product suite for VMware.
We called virtual center that tied to ESX.
So that was um that was a really, really fun, right?
And and then and then VMware really took off.
So 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 what was was it a kind of hockey stick-ish 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 a 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 just the hypervisor.
But the the 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, with that capability, it unlocked the whole cloud thing, right?
Because you have a thousand machines, it can look like one.
It can look like a C machine.
And so application inside of your machine will just scale and it would 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 with it, right?
So that actually makes it very much like a cloud operating system.
And then at VMware, we also grew with the company, right?
So again, I it seems you have this history of you were a 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?
Yeah, yeah.
I have this weird thing where when I get when the thing gets large, um, and I start to feel too comfortable, I get nervous.
Really?
Yeah.
And so that's where when a double click when I got to VP and I managed hundreds of people, I was like, is this a fluke or is it real?
So I had to go back to a four-person company and try to see if it's real or not.
That didn't succeed really well, but the engine was healthy, it was good.
And then when a VMware, again, it's a smaller company and it goes big.
And when it gets really big again, when you get to a point where you're just running things rather than breaking ground and doing your thing, or you're how learning, then you gotta do something different, right?
So I keep on going back small, and when I get big, I might go back small again.
Yeah, so I'm 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.
It was Uber Cab was way before that.
Yeah.
Yeah, it was when after eight years of VMware, um, and sometimes people change, sometime company change.
Uh sometime both sides change.
And so um, yeah, for me, what changed personally for me was I have reached to the point where I didn't feel I could do much more there, right?
I'm running 800% engineering team, we're building this software, and and it's been like the third generation of that software already.
We're tweaking, we're adding more features to it.
I love my team and all that, but you know, it's just more of like keeps keep it steady, keep it growing and add more features.
And then the company has also changed along the way.
You know, the the original founder left, new crew came in, and there's uh fair amount of uh 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, larger or small.
What was your search process look like?
And and then how did you come across it again?
Because because Uber was still pretty obscure.
Yeah, uh, here's a really interesting thing.
People do ask me about what the search process looked like.
How did you stitch 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.
Uh, 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 minds.
And people always come and go throughout the industry.
But if you're good with them to them, whatever it they tend to remember that.
And then when you become available, then people come to you.
Yeah.
About this, how about this?
How about this?
How about this?
And then you actually look at all those things, and then you can dig in and you can decide.
And so uh that played out multiple times for me 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 saying, 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 came to me uh after he knew that I'm leaving VMware.
Hey, can you take a look at this one?
I'm investing it, it could be really interesting.
So I went up to his uh his uh office in uh uh Stan 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 was trying to recruit some people, it was like, why don't why are you joining a taxi company, right?
Yep, I remember everyone, everyone's asking once I joined.
Exactly.
And so, but I I knew that.
And of course, then we have to go through like uh pretty rigorous interview process with Travis.
Uh and uh yeah, but ultimately it's about the connection that leads 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 a series B, which was 30 million dollars, is what it was will value at 300 million dollars, which was sizable, but still not nearly the the gigantic company that later became.
And one fun fact that I I read about is you had this very rigorous interview, travel swift process, which was tens of hours 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 uh over 30 hours interviewing me one on one-on-one.
Wow, yeah.
It's like several days of like low.
Two weeks worth of interviewing every single day, a couple hours each day minimum.
Yeah, with passion, with intrigue.
And we end up after a while, I kind of forgot that I was being interviewed.
It was like two people kind of sharing ideas, like changing ideas, and sometimes disagree something and then kind of work it out.
And then you you showed me you took a photo of like some topics that you talked about.
Like can you like summarize 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 wanted to talk about with me.
That was a really long list.
There's a big long list of general topics about you know hiring and firing and communications and all of that stuff, org design, everything else.
And then there's a shorter list of very engineering specific stuff.
What about code quality?
What about QA?
What about design?
Um, all that.
And then there is also a list of shorter lists of the five things that he wants to see in an engineering team and the culture of the engine 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 lasts two, which is actually good because we got totally into it.
Time ran out.
And then uh as soon as I drove out of the office, I barely get to the exit.
I got a call from the the exact recruiter saying, Oh, 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 topics.
That's why I took a picture, a photo of that whiteboard, and he did the same thing as a as a list of topics to talk about.
And I still have it on my phone today.
It's so impressive to be that because we'll we'll share that list uh in this episode as as well, that screenshot.
But that the fact that the 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's viewed the business has two major engines that powers it.
One is the operation, you know, bits and out of, right?
You gotta have real physical thing moving around the world, and then there's technology, and technology is a key part of that, right?
No one side is superior to the other, but it's required 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 wanted in whoever it is.
And so I think this list and this this this series conversation was for him to to vet 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're inside, we're all working with each other all the time.
And can we disagree on something?
Can we work things out?
Do we have generally similar philosophy and principle?
And he did himself.
Yeah.
And so that would yeah, and and the level of passion and commitment he showed was just really impressive 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 picked up his phone, called 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 I guess it was another 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 rights a day when I pulled the data on 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 joined, I joined on Monday, um, was about 30,000 rights a day.
Uh and Uber was, I don't know, 20-something cities around the world at that point, uh, 20, 30.
And so that was very modest.
The that's certain things that were going for it already.
The the engineering team was very young, but uh pretty scrappy and uh pretty committed and talented, where whatever we need to get done by hook up by group, they'll cobble together, right?
And so, and as a result, though, the the service was beautiful.
Anybody who ride, we only had black car service at the time, but the XP was beautiful when for the other 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 grew 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 it, and um the system was built not to scale, right?
It would build for functionality.
It's actually very difficult.
Yeah, and it worked and 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.
At 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 was the next most critical thing that would break and how to get ahead of it.
And one of the things that Travis always tell me, even from the interview days, is you gotta see around corner.
So I try my very best to see around corner.
This does and one of the first things I I did when the first couple of weeks were beyond getting the getting to know the engineer and build relationships and build trust was to start examine what we currently have and what we need.
And this patch was the first thing.
Without this patch, there is nothing, right?
So that's what you matched the riders and and drivers.
Yeah, it's it's our magic service, right?
When it has the drivers, the writers and doesn't match.
Yeah, that's right.
And without that, there's no business, right?
Uh there's no written, there's nothing.
And so, yeah, and 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 it wasn't gonna scale.
Uh it was a JavaScript, it's not Node.js, and it was a single-threaded thing.
And the the engineer at the time where when the city got 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 things, but also to teach people along the way.
And so I would just asking leading questions to the team, and the team only has three people, three or four people at a time.
And uh, so I asked the engineer, um, okay, what would happen if the city gets larger and you have to support that?
Because every city is getting larger, the right volume is getting larger and larger.
Uh, then engine-based 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 the same city.
Do they talk to each other?
Do they share the same state?
Not really, right?
So it's it becomes very partitioned.
So pretty simple by asking those leading questions, the engineer now discovered a flaw that this thing would not scale, right?
And then and then I have to establish the limit of where is the brick wall.
And I basically sort of what's the biggest city uh that we currently have in terms of uh write volume, and uh they say New York City.
And I said, okay, when is New York City is gonna we can run our capacity even hand in New York City, even on the biggest box that we can get our hands on, it's about October, and this is 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 requirements that 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 feature necessary, just make sure that we can do that.
And then that allowed the business, the company, to just pour a whole bunch of hardware behind that.
And it will scale.
Technically, it will scale infinitely, right?
And so the engineer did that.
And because the requirement is very simple, uh, we have to do it really quickly before we run out of time, uh, run out of runway, not to survive.
And uh, so they did that, and we actually deployed that right around August, September, right before it's actually actually and then on to the next problem.
Database gonna be the next choke point, right?
And other than then the API monoliths gonna be the next choke point.
And we keep on identifying all these things.
Uh so there's all these threats coming at us, and we have to establish like how much runway we have until we like really get in serious trouble.
There's no way out, and then get ahead of it.
And so this was 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 still 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 that depends on how fast you're growing that dictate how you make and because the faster you grow, the shorter runway you have to even 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.
Oh, yeah.
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, Worker West.
If you're building any SaaS, especially an AI product, surprisingly, you reach the need to build enterprise features like SAML edge cases, directory sync, audit logs, and all the things enterprise customers expect quickly.
Building that infrastructure yourself takes months.
WorkOS gives you APIs to ship it in days, authentication, SSO, SCIM, RBAC, audit logs, and more, all designed to integrate directly into your product.
That's why companies like Entrophic, OpenAI, and Cursor already run on Work OS.
Skip the rebuild, keep shipping.
Visit workOise.com.
With this, let's get back to Twan's team providing the dispatch system and the short breeding space that this first rewrite gave them.
So that's what with this patch.
We knew we had to do it very quickly, maybe buy ourselves another 12 months.
And after we get through that point, then we have another 12 months to think about the next phase of survival for that team.
That's why the system needs to be rewritten uh several times.
But let's say if my requirement for the engineer was build a system that will scale infinitely to test the time, it might take a year.
We never get there.
We'll 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 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, 2028 14.
Uh, we were all hanging out in the the the big room in uh 4055.
And Travis made a declaration that okay, come the new year.
I'm gonna light it up and we're gonna go into China.
Okay.
And then he turned over to me.
It's like, I want the uh and one of the requirements at the time was that we have to run our services on China soil, right?
And data center physically there.
Physical data center needs to be there.
Until then we kind of dabble into the water by powering it from the US.
Okay.
And we have a limit of time um to do that, but he's gonna light it up.
I'm gonna do that.
And it's 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.
Shouldn't take more than two months.
And then I have to like explain that it's not that easy because when you do that, then it works on day one and then the two drift, and then how are you gonna maintain that, right?
We don't have twice the engineering team to actually manage two different systems that deviate.
So the right way to do that is you build re-architects, 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 they are anything that runs over there cannot presume to have any level of privacy or anything like that.
Uh, but over here we have to protect uh everything, right?
So we have to build that same system that has completed partition of data and controls and everything else, so that yeah, nothing bleeds across.
But it has to be every time you deploy code, you have to record everywhere, right?
So you have to re-alct that uh uh 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 the CPM technical programming, yeah.
And um, I think the best path for us was about six months.
And that was the fastest we can even imagine, right?
Um, 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 entire thing.
Uh, but you know, that was Uber.
So we just like we didn't think too much about it.
It was like, well, let's uh um let's do that.
And then drive it in like the the six months.
So we are kind of settled around four months, right?
So and so because it didn't like split the different, we didn't know anything, but you know, we just want to head down and start getting to it.
And so we look at all what needs to change given like this is the end uh uh goal and the requirement.
And then with everybody starts getting really busy, uh working a lot of hours to start making these changes.
And four months come and we are still a month or so short.
So we slip the window trappers.
And he's not too happy about that, but it's fine, right?
And then uh five months comes around and we are very close, but we're not there.
We're about to slip again.
And so uh it was not 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 means give us an ability to incrementally launch.
Instead of lighting all the city in China up level once, let's let us do it in phase, right?
Every single week we'll launch a number of cities, and then we're gonna do it in the process of like a few weeks, and then we're done with that.
And he said, okay, that's reasonable, but he won the the biggest city first, and that's Changdu.
So he he agrees to the incremental launch, but you need to serve the biggest city.
That's all Travis, no?
Yeah, exactly.
But it it is brilliant though.
Now that you think about it, uh I I thought a lot about that over time, and that was the most brilliant thing because by doing the hardest thing first, once you launch that, everything else is downhill from there.
The team has this swag, the team knows that would go into next set of cities with confidence.
Had we done the traditional way, let's start with the safest one, the smallest one first, the next one we step it up.
On the surface, it seemed like oh, it's a very good risk control measure, but every single week we'll be holding our breath until it's done, it's not done, right?
But this time we we did everything we can to do the hardest thing first, and after that, it's 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 tear the water.
I know some other entity 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 uh with a friend of Duper 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 gathered a 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 heads down and we just the 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.
Uh Uber started to compete head on head with the leading Chinese provider, Didi, and there 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.
Yeah, so that that was something incredible.
That was something incredible, and I think just the experience having gone through that and doing things that initially you didn't think was possible, just increases everyone's confidence and range.
And and that's what stretching is all about.
And I think that there's a saying that Travis liked to say that sometimes you have to be willing to red line 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 as we did?
The program and platform came first, yeah.
And the microservices came later.
Um, and the platform and and uh program and platform as an organizing structure came first out of necessity.
When I came in April of uh 2013, uh we had 40 engineers and three product managers.
Yeah.
By the end of that year, um, we had about a hundred 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.
Uh imagine those hundred engineers, there were about up to eight or ten mobile developers, uh a number of infrastructure engineers and a bunch of back end engineers, et cetera, et cetera, and um five, eight people also 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 became impossible to navigate trade-off because every feature you want to do, you have to go negotiate with so many teams, right?
And so then the team wanted to move fast and start to feel that friction and complain right away.
And that's a good thing, right?
You know, we raised the concern.
And so I remember uh Travis and Jeff Holden and I saw that and we got together for a couple of days actually.
And I remember we had uh sticky note, all the different colors.
Each color represents a different function, engineering product, designer, um, and uh we put one person's name to each of the sticky notes.
And then Travis gave a talk about what are the most important areas of the business that he thinks, right?
And at the time there were like 17 areas that he can think of of the world.
The world of Uber can cover 17 area.
It turned out to be a lot more than that, but that 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 just can remain empty until we hire more people and we fund it.
And so that was the the the thing.
But then as part of that process, we then put sticky note onto each of these areas have to be a cross-functional team because we can no longer afford to run it.
Uh no, uh yeah, cross-function rather than a functional team.
Yeah, but which means that there's like a back and the mobile and whatever else they need, like a design if they need to go, etc.
That the the concept is that team has to have all the skill set necessary to just 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 programs and some of them platform.
So programs are the team that build things that the end user actually use.
And the platform are the thing 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 uh 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 things quick enough to survive and so um we knew right away that the the the back end 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 decompose that that monolith that API monolith into a bunch of services yeah we used to call it API right that was a nice 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 three to six months but it took us two years to do that because as we peel out a piece of code the business keep on going forward right these hockey six are laying on top of each other now as we launch new city and happening fast enough city and the new product, Uber as 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 needs to be 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 do the best that it can.
And then we kind of keep chasing our own tail until eventually, you know, something gets completely pulled out.
And as it happened, it bulges up like this, the monolith, right?
Because you pull out one thing, the remaining stuff grew even fast than the stuff that you pull out.
So the code base gets larger and larger, eventually reach a certain point when it started to come down.
And that's why it took two years.
And meanwhile, everything that is new must be on because we don't keep on adding stuff, right?
To to the monolith.
And so that's how it came up to like you know thousands of microservices.
But that was out of necessity, so that we can just fan out and solve every problem all at once.
And then over time, after things stabilize and sort of 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're gonna look at this stuff and how do we clean it all up?
So we put like domain interfaces on top of 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 block post that Uber had about 5,000 microservices.
And I just saw about a few months ago, Uber published another one, and they have about 4500.
So in that 10 years, the number has gone down, right?
It should go down.
But even then we couldn't do that.
Now Uber has so much more complexity, right?
Yeah, it's it's so interesting.
The R process for 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, uh, new tool has to be invented by us.
Jaeger, the tracing tool, all of that stuff.
And so that'd be a really great tool that we open source to the let's let's talk about how how and why Uber built so much internal tools and also open source a bunch of them.
Yeah, as well was one of them, but internally we had schemaless, a trip data store, t channel, an RPC protocol, ring pop, Gel 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 did it not seem like a lot of waste for us to build this, or was it again a necessity?
It was mostly necessary.
I can't claim that every single one of those things were absolutely necessary, but all the important ones were absolutely necessary.
The thing is when when I started, Uber used pretty much all the open source stuff.
We use Redis, we use everything, right?
Because those the engineer there just focused on putting together a service that actually moved cars.
But then as we scale, uh, we keep on using uh pushing the boundaries of the capability of those um um open source style 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 well.
We did not have the kind of the big tech investment in open source back then.
So there was very little, and and most of the big teams like Google and Facebook, they were keeping their things inside.
Yeah, I remember, like, for example, a very painful example of that we had to face early on was we use Postgres.
All right.
And we get to certain scale that Postgres would randomly fail and that take our services down randomly with 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 Postgres to be our consultant to help us diagnose this problem.
And we spent several weeks and during that time, 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 open source.
There's no single person, no some single company.
I'd 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 motivators 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 MySQL 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 destiny.
And we only built the feature that we really need, right?
And so that was one of many examples.
And eventually we run into our brick wall of scaling.
I remember in 2015, right around the holiday, I was taking a holiday trip and go to the airport.
And I I took an Uber ride as usual.
The receipt didn't come for two 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 uh a deal breaker for maybe people because they just write and then receipts come later.
That's 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 ride happened, the rest of the stuff can be processed later.
But it's still not great.
Okay.
When I dug into it, like our data processing capability is at capacity, right?
So we have to rewrite a bunch of stuff.
And then our capability to monitor things is reaching a breaking point with the open source tool that we use.
So the M3 has to be invented, right?
And all of that stuff.
So we we a lot of we have to do things because we had the scale where we broke all the open source stuff that we used.
I do where 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 uh user experience was starting to degrade because it was really cluttered.
Travis got a bit fed up with it.
The designer team came up with a solution, which was a very nice and clean UI, which kind of the engineering team looked at it and it would have been a full rewrite.
And then we just did a full rewrite back then.
I remember we had a million or two million lines of code.
We had two or three hundred 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 uh from it didn't feel it felt existential threat from the inside, but it was not uh like uh like a Google Plus versus uh versus uh Facebook uh existential thing.
And how did we decide on that short deadline?
Yeah, uh it seemed like uh a recurrent theme that keeps on coming up with a tight deadline, right?
Everything we do had a tight deadline.
It's just it's yeah, it's just that's just how the culture rolls.
Um anything we want to do, we 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 as a lead designer at the time, they pair up and then all these storyboards and everything else.
And he has a vision where the current app back then was too limiting.
Yeah, it's really good.
Put 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 writing, uh, the new architecture a lot it was much more open, right?
To all those things.
Uh, and so that was the division behind that.
Uh 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 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 a certain amount, um, then the engineering team, the mobile team got 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 five seconds we would pull, yeah, and it was pretty painful to an actual push uh push channel.
Yeah, this path with that but by that time it's called real-time system now, right?
Yes, yeah.
It has to change, back end has to change, everything has to change to support the new flows and then all that stuff.
And so, yeah, it it took I don't know, six, seven hundred engineer all toll, seven, eight months to actually do it, then we put it off.
And it's still live today, it's still on that same architecture.
It was so far well thought out.
Oh, 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's 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 send 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 the young engineer want to have fun.
Yeah we we were having fun yeah and name things in a goofy way I think the trigger for that was a service name Mustafa.
I have no idea what it is right I look at that stuff and by that time we were already very complicated right and we have to onboard new engine all the time we want builders ram up quickly etc etc and I can imagine an engineer coming here and if all these weird names have no context to it by the time our tooling wasn't that great either right new blame didn't come into existence yet right and so there's no mapping so people discover what this really means and then then those weird naming schemes so I got to the point where I'm kind of fed up.
So I send that email out.
Of course, you know, those mass emails sometimes you'll regret after you send it out because it has some effect, but it didn't really solve it.
And I I think it was very quoted because you specifically wrote this is not a Mickey Mouse shop.
Exactly.
We're not really outside we did and and yeah it was uh again it was it was uh 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 gotta take ourselves seriously we gotta do things better faster and this is not helping.
Twan's been talking about improving things as the org scales such as moving to a more mature naming policy.
Introducing new and better approaches as the company matures leads us nicely to our presenting sponsor statSig.
Statsic built a unified platform that enables both experimentation and continuous shipping.
Built on experimentation means every rollout automatically becomes a learning opportunity with proper statistical analysis showing you exactly how features impact your metrics feature flags lets you ship continuously with confidence roll out to 10% of users cash issues early rollback instantly if needed and because it's all in one platform with the same product data teams across your organization can collaborate and make data driven decisions.
They have a generous free tier to get started and pro pricing for teams starts at 150 per month to learn more and get a 30 day enterprise trial go to statsig.com slash pragmatic with this let's get back to twan 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 two.
Can you talk us about why you did that?
And I where did you get the idea from?
I I did that.
I'm I'm not apologizing for it.
I think it was a good move at the 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 engineers, crossing from senior engineer, I mean uh engineer two, pass through the senior engineer to get staff, it could be a five-year journey.
Okay, it's a long time.
And so I just want to break it in two so that people get a sense of progress.
And then also not everybody can make it to staff, right?
But some people is good enough to make it to yeah, senior two.
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 it worked, we can say, right?
It worked for a while, right?
And then people were climatized to that, and then they start complaining.
It's like, oh, why there's two level, we need to get to 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.
Yes.
Uh, and later on after I left, I think it got really good.
They got pushed down, L5B is now staff, and everything got pushed down.
I didn't want to do the title 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 NGRs are unhappy because their managers do not support them.
And then what you wrote is like we are creating a very easy internal transfer process.
You can move teams.
How was that perceived?
And again, how did you decide that we need to do this?
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 if 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 processes when you have to ask your manager for permission to go to another team?
Yeah, why do we make it harder for ourselves, right?
When engine our own engineers go from team A to team B, have to ask for all these uh you know, permission where they don't have to ask for that if they interview outside.
Yeah, that just doesn't make any sense.
But 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, you know, put position the best people into the best assignment for them to grow, and then they're 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 pushback because it'll be radical at the time.
Yeah, but we just did it anyway.
And so that that would turn out to be the right thing to move.
And what 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 the manager.
Hey, look, I'm I'm I want to do this, and the manager should be generally supportive instead of saying, no, you belong to me, that kind of thing, which is the the wrong thing.
I have a saying that I share with you guys all the time, right?
It's not a jail, we can lock anybody down.
Everyone 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 and you should be able to shop within all the opposite they have inside the company and stay with the company.
And why make it so hard and then 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 I asked around a 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 the 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, uh 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 accountable 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 that's 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 said, look, you know, when you're in uh an important position, people treat you really well, but don't let that get to your head.
It's not you, it's a position you hold.
And I remember saying this, we were like, the moment I stop being CSR Uber, nobody's gonna care or know about me.
They're gonna talk about the next CTO, right?
And that's always happened, right?
The the world forget about uh 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 ends, and then I'll get to the movie stuff like life even end itself.
And so then I measure my myself, like what is my achievement that I would be most proud of.
And I say, well, when I'm gone, the thing I'm most proud of is how many people remember how I was good to them or helpful to them, and for some number of years, right?
And that is that because I can't take anything with me.
And so live in the moment, be as best as you can to everyone and be very as constructive as you can, and uh and and leave a good life piece behind you.
So that that that was the 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 happened, 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 show you another angle too, which I personally experienced over and over again.
It's not only that other people around the industry pull you into good stuff.
When you pull in and you don't have people to support you succeed, you would not 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 you did not know how quite build system at scale reliable all that stuff.
And the network that I have to really knew how to do that was on VMware where you're building system software we're being operating system right rigorous principal level engineer all the time experience, no, like the in their sleep they can do it, right.
Right.
So when I came in, and when I have to like um work with the team on dispatch, I pull in the first engineer from Uber to to lean land on that team.
Right?
His name is George.
And so he there and then he worked for everybody else or uplift everybody there.
Right?
That and then engineer from VMware.
Yeah, yeah, yeah, yeah.
And then when I build payment system, I had to pull in another a few more ones.
And then when we get to build schemaless, it was a Denmark team, right?
I pull the top four engineers from my VMware team.
And then I moved them down from one floor to the next in Denmark.
So they put seven office.
This is why we had a Denmark office, which was correct.
Which was one of the best infrastructure offices at Uber.
And they built schemaless.
They built schemaless.
They they built a lot of other and so now if I weren't a good person doing a good job for them, with them or whatever, why would they come back to the case?
Yeah, they would they they wouldn't answer the phone.
Yeah, they wouldn't answer the phone, right?
But every single one that I call because I really needed help, they all came.
Initially they all asked the same question, why a taxi company?
But when they understand that, they came, right?
But they came because they still enjoy working with you, right?
They are people who work with me for 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, is one thing is where you can hire, the other thing is where people 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, 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 use existing open source stuff, right?
And we build that.
And another thing that I, you know, uh discover along the way is great talents are everywhere, but you know, you have to bring opportunity to them.
Yeah.
They don't necessarily relocate from Denmark to San Francisco, right?
And so that's why we end up having nine engine offices around the world.
Because we have a lot of work needed to be done.
We didn't go to other places because of cost savings, anything like that.
We go there because we have needs and we have world-class talent and we just cherry pick the world-class talent, doesn't matter what size it is.
And Denmark team was small compared to team in India, et cetera.
But you know, there was really great talent and infrastructure, and we'd invest on that.
Uh, Lithuania, we had the amazing DevOps uh team.
And so we just go to where the talent uh is, and then we bring the great work to the great talent.
And and then we establish a structure uh to manage and give people first class ownership of the problem.
And then you know, everybody's kind of equal.
At Uber, you you talked about several times of your three chores of duty.
Which ones were these?
Yeah, again, it it come back down to purpose.
Uh so when I do something, I try to be intentional about why am I doing something, what's my purpose of doing that?
And so, of course, my purpose to come in to Uber was hey, let's build this business.
Uh just build a tech that supports the business.
And so the first couple years, 18 months, 24 months, we're fixing a lot of the broken stuff.
Things weren't reliable, become more reliable, et cetera, et cetera.
Uh, rebuild things, um, basically just get things to work and work well.
And then along the way, you know, these things don't end and beginning on a particular day, it's just phase in and out, right?
So the phase two, uh, that was called my second tour of duty was scale, worldwide scale.
That was China, that was massive scales everywhere in every dimension.
Uh and so, yeah.
So at each of those phase, when you're done with that phase, you ask yourself, am I still useful?
Do I want to read up right?
My commitment and energies and everything else.
And so the first two phases were no question, right?
We're there to do that.
And then as phase two were about to wrap up, right?
Uh, about 2017, we actually kind of stabilized, we're really big now.
I was actually asking myself that question do am I needed here anymore?
And I was actually about to wrap it up that summer.
Because, you know, at that point, we had also another STP that was higher, and I think he's really, really great technically, and I can like feel very, very at peace.
Kind of, you know, there's there's someone who really takes it on even better because the person has done even bigger thing at Google, right?
Yeah, and then but that didn't work out, and then Uber has a really rough year.
So then I have to like sign myself to the third tour of duty, which is and what is the purpose of that?
You know, help the company get through the turbulent years.
And I had no idea at the time when that phase would end.
I just kind of know the condition for that to end, which is whenever the next CEO arrived, right?
And then after that, whether that person liked me, I like that person, or whatever it is, that's to be decided.
But that third phase, I have to stick it through because you know we owe it to ourselves and we owe it to everyone along the way who have built Uber to that point, right?
To to get through that turbulent phase.
So we did that.
And then now when the new CEO came in, and you know, I stayed on until 2020.
And then in in so in 2017, I remember it was really turbulent.
Travis had to step down for a while.
A group of of I think 14 people uh who were Travis's director boards, they took over steering the company.
You you you were one of them.
So this is the point where you decided that if everything would have gone smooth, you might have actually just left, but you decided to stay on to help the company, help the team to help us get through.
Because we Uber was built by tens of thousands of people, right?
Past and present.
The fact that people built somewhere and then left already before them, that's so fine.
They that work was still in there in some way, right?
That led to that Uber that we have there.
And it was a really important thing that we all built.
That's it, many of our lives were.
And and then just to suck it up, we went public, which which which went good.
And then it it it went okay.
And then of course, COVID happened, which really hit uh Uber.
And a f a few months uh later, in in into COVID, uh, you did step down.
Why did you leave Uber?
And and why what why was the timing what it was, and what motivated you to say, okay, this is the time to to go?
Yeah, it it didn't have anything to do with COVID, really.
It you know, I was I'm lucky enough to arrive at a point in life where money doesn't matter, right?
And so then I asked myself, why am I doing anything?
If I wake up every day and spending X number of hours on doing something, why would I do that versus something else?
And so it come down to three things.
One is do I really love the mission and what I'm doing?
And the second one is do I feel like my being anywhere, right?
Is making a really big impact.
And the third one is am I enjoying the company of people I'm working with, right?
And if several of those dimensions are lacking, then at some point it's not enjoyable in totality anymore, right?
Then uh then it comes down to okay, when you wake up and you spend 50 hours a week doing something where money doesn't matter anymore.
Uh I live very modestly, so it doesn't change anything.
So uh then why would I do that versus doing some other thing?
And so I think that was that was the realization at that point where I'm more like, okay, I'm there doing a a big job, but more or less running things rather than you know being very uh much more effective and building the company like in the early days.
And so and at that point, I think it's actually much better for other people who take a crack at that job.
Again, it's you know, like everything ends, right?
And so it you have to decide yourself at the time.
And it did give opportunities to other people, right?
So, like, and and they did pick it up.
Now, after Uber, I I remember you did an interview uh with uh with the publication.
I think you said that you're thinking of retiring or you'll see.
But then you you were not done.
Oh no.
You you you did other stuff.
Uh you know, coupon, new bank, fair.
Can we talk about what what what what happened?
What was your thinking?
And you never even left for for a moment, honestly.
Well, I blame that on COVID.
So seriously, that one COVID had everything to do with it.
Uh so when I left, um, we had um a plan to travel the entire summer because my 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 plans.
Everything got shut down.
Everything got shut down.
All the flight that cancel, all the country clothes, 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 to and then like very sparse to kind of race through it, pick up what you need, and you get out with all the mass.
And yeah, and so uh we kind of bored though.
And so I I'm bored, so I sit at home and we all got on video uh Zoom call.
And uh lots of people want to kind of chat with me.
Uh to um not surprising.
And so I took a bunch of calls, and uh, one of them was the the founder of coupon.
And we had really great chat, and you know, it's like hard charging person, wanting to get a lot of things done.
And I 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, and I um yeah, I 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 coupon does it is to talk about five hours, six hours delivery.
Wow.
Yeah, you order before midnight, and the thing show up on your doorstep, five o'clock in the morning, five, six.
And I when I was there, I joined the delivery truck, putting package in front of the people's home like two, three o'clock in the morning.
And it's it's brilliant, right?
And all those things that you learn, and you you 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 was it is it an advisor or board member at Nubank?
Uh board member, yeah.
And Nubank is for for those that don't know and outside of the US or Europe, it is the most successful and highest valued non-US companies, the largest growing bank uh in Latin America.
It's it's it's extremely it's as it's engineering culture.
I hear amazing things about.
You're the first person I'm actually talking about.
So what what did you learn there?
And and you're still involved, right?
Yeah, yeah, I'm still involved, but as a in the as a board member capacity.
Uh and for a while, uh I also took on a more active responsibility to mentor the CE CTO, right?
A couple of them.
And so, yeah, and so I I again, it's all about being useful.
Um, 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 advise, help people move forward better, faster.
And and I find that very fulfilling.
And so, so that uh was that and the the culture there is very vibrant.
I mean, it reminded me of our early days, Uber, when everybody's gung-ho hard charging, the founders hard charging, everybody is.
Um when I visit there, uh usually during board meetings, uh, once a year we kind of go down to Brazil, uh, and we will have all hands with the entire company, and sometimes I also did all hands with the engineering team and uh do AMA style the way we all did it Uber.
And so it's just very energetic, right?
And and there are many factors to their phenomenal success.
One is like uh very much like Uber, they actually solve the right problem at the right time.
There's a whole bunch of unbanked population before new bank came along, and they deliver like leapfrog that of traditional banking just online on the app and the experience is beautiful, the NPS score is through the roof.
Uh and it it ultimately it had a lot of value to people, right?
Life, and that's why the adoption rate is crazy high, right?
And and and so, yeah, well executed, um, amazing product vision, phenomenal cultures and energy, and all those factors are very common and like great companies.
And we experienced one of those things at Uber too in the early days.
So it's really, really energizing being a part of that.
And and and they're doing great.
And now you're the CTO at FAIR.
What made you join FAIR?
I took a couple of years off when my daughter was finishing high school.
Because I figured that time would not ever come back when she's gone and she's gone now.
What was it the right choice?
Oh, absolutely.
I would not take that time back.
So that I'm yeah, good.
I'm so glad.
Yeah.
Now 10th, 11th grade and 12th grade.
I get to stay home, drop her off, pick her up, cook, you know, hang out together, help with college application, all of that stuff.
And so the bond we had was really cool.
And as I was thinking about her going to college, I was thinking, well, I'm gonna have a lot of time on my hand.
So what should I do?
Here we go again.
Yeah, 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, uh the CEO of Fair, and really liked him, very smart.
Again, all the same characteristics, very smart, uh, very hard charging, want to do all the right thing.
The business is empowered you know, local, you know, business businesses.
Can we talk a little bit about that?
Because from the outside, you know, when you Google Fair and you and I look at it, it doesn't tell you exactly too much.
Feels a little abstract from the outside.
Um it is uh B2B marketplace, right?
Between uh big brand wholesalers and retailers.
So people buy that and then uh stock their storefront.
And and so, yeah, and so all this traditional two-sided marketplace dynamic apply, and the mission is very similar to Amazon Ruby, even though we are 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 like grow grow their business.
May that be like just more inventory.
More successful demand, more demand, more supply, all of that stuff, right?
So yeah, it's like a really marketplace.
This is like really fun and very complex.
And so I really like that.
And I really when I dig in uh 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?
Have to go and present and everything else.
And so I re 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 how uh help out.
And can you give us a little context on fair in terms of the size of the company, the size of the engineering team, where the hubs are, what the what the work is like?
Is it in person?
Is is is it hybrid and so on?
Yeah, the company is about a thousand person.
The engineering team and including the data science team combined is about 300 people.
The work we are in the office three days a week.
Um, yeah, three days on the week.
The other two on um are working remotely online.
Uh yeah, and some people show up more if they live close to the office.
Um yeah.
Uh the engineering team, uh, there's a portion here in SF, um, just down the street from here.
And uh a large part is in uh Canada.
Uh that we have a big office in Waterloo, and we have a big office in uh Toronto.
So I 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, uh right now, clearly the most exciting thing is AI and how is AI changing everything so quickly.
So tell me how how what what are you seeing?
What's working, what's not at you know, like in on your teams.
In my team as far as in the company, you know, we're using AI to boost everyone, yeah, effectiveness and productivity is an output, right?
And so that's one within the engineering specifically, we use AI to make you know, search and recognition better, right?
Because the whole job is to help people discover things that would sell really well for their business and et cetera.
And imagine AI as a shopping consultant, right?
And all that stuff.
And then coding-wise, you know, AI is doing a lot more of uh of the coding now.
Um, but we also uh used uh different techniques to actually boost uh engineering productivity.
Um have you heard of like swarm coding?
So swarm coding as an agents?
Yeah, a whole bunch of agents, uh swarm of agents, right?
It's it's pretty new, so you're already using it.
So we are ready using it, and we we're building orchestrators to orchestrate the action of all this agent, and uh we measure the the first the early adopters, um the and then the the bulk of the engineer follow through after we build the the more robust tooling, and we see dramatic lift in engineering output among the early adopters, the one 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 programmers with single-threaded, right?
You have to think about all these other things, you have to prompt all the action, and then you have all this code get come back at you, and you have to review it, you have to sit together.
Yeah, and it required a different way of thinking and the cognitive load might be a little higher, but the output is dramatic.
We have seen our best engineer double their output.
I I know we're talking about that, but just to make clear, we're talking about not the code output, the actual business output, the impact of their work, right?
Yeah, the impact uh now it depends on the the evolution of AI, right?
So right now, the state uh of the art right now 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 uh productivity increase and output, building new features on top of a code base that are older, right?
It's not like oh, you and I can just go build something brand new, not entangled anything.
It's really fast.
The whole thing will generate for you, right?
Yeah, but we got millions of lines of code.
And how do you like deal with that and build feature on top with all those dependencies and all that stuff, right?
Can AI good enough now to help us untangle some of those things along the way, 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 or what skills we value?
Yeah, it's already changing.
I mean very rapidly fast as these changes are faster than anything I've ever seen, including the internet, right?
Back then I remember when we first learned how to um do programming we have to know a lot about the machine architecture.
We have to know about virtual memory have to do and then we have to learn how to like syntax and coding all of that stuff been abstracted away now right you say I want X, Y, and Z, blah, and it should be this way and whole thing get constructed, right?
So it elevated level of the playing field where people who don't even know how to program can now create good, you know, good decent code and app or whatever it is that look on the service really good.
So it is game changing, right?
It it um it elevates the playing field.
Now then in that level of of abstraction, how do you tell the great engineer from the good engineer?
Great question.
How do you?
Well, from what we see so far, the great engineer are still finding ways to leverage this and accelerate the output even more.
Then we see the difference between the great engineer and an and average engineer is still two or three X in terms of their capability.
They're more inquisitive, they're at the bleeding edge more, they're more innovative, right?
And then there are people who like, okay, well, here's the tool that you give me.
I'm gonna be two times more productive, right?
Because I'm using this tool, it's great.
But the great engine continues to break new boundaries.
And so I think that is still uh a very, you can still you can look at people and you can see who are the high performer versus who are average.
So do I hear correctly that the what the traits that you're seeing in your engineers is we didn't mention, but it's kind of a given the foundations plus curiosity, curiosity, innovation.
Fearlessness, willing to innovate, willing to stretch, willing to try new things and break new ground.
All of those traits are it still exists.
Interesting.
If I think back to like just the Uber days or your startup days, that those traits were kind of the traces of the standout.
That's right.
Those are things that make someone outstanding versus someone the average.
So I guess maybe an advice is like, well, I mean, try not like if if you were a great engineer before, just don't be complacent and keep using key.
That's right, approaching the same way, right?
Correct.
Yeah, complacency is death.
I mean, like every the world will move faster and faster, and the moment we stand still, we're falling behind.
It sounds like if you if if you worked at a fast fast-paced startup before, which is this is how it works, AI should be familiar.
Welcome to how it was before.
To me, it is a incredibly powerful tool, but in the end, it's still a tool.
And you you can wield the tool properly, you can do extraordinary things.
Versus you just merely use a tool in a mundane way, you're not gonna be a great stuff.
So we talked about standout engineers in this age.
I'd like to talk about something that I cannot talk with too many things: standout CTOs.
You have now been CTO at multiple companies.
I I lost for VP of engineering.
You've been at some of those higher highest engineering leadership, and at Uber at Fair, you've you've done an outstanding job as a CCO.
What is the most important job of 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 gotta do, put the org structure, put it, you know, uh develop the talent, prune, you know, uh 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 would just want to hire more A-level players, and yeah, they just intolerant of anybody who's not performing, right?
So you when you get to, but you gotta 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, it doesn't mean they work really well if you don't have like a the culture alignment, right?
So that organizational side of things I've always deeply believed in.
Like if you do that one well, then good outcome would just happen.
It doesn't matter what you want to do, right?
They will just uh be able to come out with great results because we have great talent and with great motivation.
The other side is you have to look in the future and see around that corner, right?
For example, I always think about two years out.
What does great need to look like?
Okay.
Do we have the key, you know, uh ingredient, if you will, talents and otherwise to actually get there, whether it's architects, leadership, whatever, right?
And what problem are we trying to solve?
What would the business look like?
So, you know, uh the famous Wayne Gretzky quote is gate to where the puck would be.
So you have to envision that future.
And I would I would share this with everyone at every management level.
That when you in a 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 right now is the most so many people, including me, see it's an unprecedented time with growth.
How do you look around the corner?
What do you see around your corner right now?
Like what will be coming, maybe not if in two years, but even in six months.
Well, i in six months, you know, we know what we need to do.
In fact, it's too short, right?
Like these are the things that about two years.
I I I I recently asked OpenAIs uh on what they see in two years, and they're like, oh, that's too long.
Let's talk six months.
But in context of everything, right?
For them, they're trying to reinvent that future.
And sometimes things are changing too fast there from that context.
Yes.
But from fair the business, yes, we know what business results we want to drive.
We know what project we need to execute, right?
To me, that's 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 uh problem, right?
And so for example, there are many areas that we need to clean up, right?
There's the e data ecosystem that's been old and you know, same problem we saw at Uber too.
You know, something changed upstream, breaks things downstream.
And how do you really clean it up with all this, you know, uh older, you know, code base?
Then, you know, what is the next generation of search and discovery that are AI driven, right?
You know, some of the consultants need to look like productivity, right?
How can we leverage AI to like double output on you know feature development?
Right.
So all of these things, what is that future need to look like?
And do we have the horsepower and and to get there, right?
In terms of expertise, uh management and the planning, all that stuff.
And so and and then if the answer is no, then it'd like the next question, how do we actually position ourselves there?
Who do we recruit?
And so that's the job of the CEO on the sort of the the non-management side.
And then finally, um, what advice you 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 entering the 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 uh new grad, but it's come through our uh intern co-op channel, right?
Uh, we're not in the world where we just hire massive number of new college grad like the old days anymore, right?
But if great people are still finding opportunity, right?
So we have uh a healthy cohort of you know co-op every single um four months that come through, right?
And the best of the best still get offered from us because if we don't hire those folks today, what senior engineer will we have for yeah 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 so that will always the opposite will always be there for great talent.
So invest in yourself.
When a student, you know, volunteer doing interest, solve hard problem early on.
The earlier and harder you work early on, the better you have in in the in the 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 uh I think career phases.
I would say the first five, 10 years or so, find opposite what you learn the most that push you the most.
Because those are the time that you you have the most energy to develop your skill and ramp up really fast.
And when you get to like senior engineer staff, engineer range, then you know enough to be very dangerous in terms of making a big impact.
Then seek opportunity where you can make a big impact.
Maybe a smaller company will allow you like a bigger stage to actually make a huge impact, right?
Just take some of that risk and do that.
And that phase should be about using what you know and make this big impact as you can, and you will learn along the way too.
And then when you get to the next phase where hopefully if you're really good, you're already at this, you know, principal engineer, senior staff, or on the management side, senior director, VP, whatever it is.
And then that point you learn to give back, right?
You learn to coach and there are a lot of people along the way.
You'll be leading and responsible for you know very big things.
Uh, you know, apply that knowledge to do a really great job, but also teach and bring other people along.
So different phases you should change the priority a little bit.
Twan, thank you so much.
This was a great conversation.
So I hope that everyone be um 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 microservice story is such a good one.
Nobody had 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 two years to do something that in isolation would have taken three to six months.
Uber had unusually violent business growth that resulted in unusually fast code growth, and microservices helped Uber tame its growth.
But unless you're going 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 Tuan's entire career was shaped by relationships he built by simply doing great work.
Bill Gurley reached out about Uber because he remembered Tuan from NetGravity, a company from a decade earlier that didn't even win this market.
The engineers Tuan 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, Tuan'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.
The 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.
Thanks and see you in the next one.