Thuan Pham, Uber’s first CTO (2013–2020), recounts his journey from fleeing Vietnam as a child refugee to leading one of the most complex engineering organizations ever built, and how Uber’s breakneck growth forced a series of desperate rewrites, organizational experiments, and internal tooling decisions that shaped modern large-scale engineering practice.
Early life and path into technology
Born in South Vietnam, Pham fled with his family in 1975 after the fall of Saigon, surviving a dangerous ocean crossing as part of the “boat people” exodus, spending time in a refugee camp in Indonesia, and eventually resettling in the US through a church sponsorship with no money and no English.
Discovered programming in high school through a friend’s IBM PC, found he thought algorithmically and disliked doing things twice, making coding a natural fit.
Automated financial accounting at a government agency using Lotus and DBA3, reducing a three-week quarterly reconciliation to three hours, earning a recommendation letter that helped him get into MIT.
After MIT, joined HP Labs through a co-op program, working on cutting-edge medical informatics (distributed patient records, drug interaction databases), but left because research papers were never productionized.
Worked at Silicon Graphics on an interactive TV trial (video on demand, online shopping, set-top boxes) that was technically successful but commercially unfeasible due to $45,000 hardware costs, teaching him that timing and economics matter as much as technology.
Co-founded NetGravity, an early internet ad-serving company that put the first dynamically targeted ad on Yahoo; the company went public but lost to a competitor that prioritized growth over profitability, a lesson Pham later saw repeated at Uber.
Spent eight years at DoubleClick rising to VP of Engineering, then joined a small security startup that failed, before joining VMware at ~40 people and growing to VP of Engineering overseeing 800 engineers building virtualization management software.
Joining Uber and the Travis Kalanick interview
Left VMware after eight years when he felt he’d plateaued and the company culture had shifted under new leadership.
Bill Gurley of Benchmark Capital (who knew Pham from NetGravity a decade earlier) brought Uber’s board deck to him; Pham recognized the model was not a taxi company but a technology platform.
Interviewed with Travis Kalanick for over 30 hours across two weeks: the first session was supposed to be one hour and ran two, followed by daily two-hour Skype sessions covering a whiteboard list of topics spanning hiring, firing, code quality, QA, engineering culture, and the five things Travis wanted in an engineering team.
Pham realized the process was a simulation of what it would be like to work together day-to-day, testing whether they could disagree and work through problems with aligned philosophy.
Joined in April 2013 when Uber had ~40 engineers, ~30,000 rides per day, and was in 20–30 cities.
Scaling chaos: rewriting dispatch and the monolith
The system was built for functionality, not scale, and crashed multiple times per week; the engineering team was talented but very young (all in their 20s).
Pham’s first major task was the dispatch system (matching riders and drivers), a single-threaded NodeJS process that scaled only by moving to bigger machines.
By asking leading questions, he helped the three-person dispatch team discover the architecture’s flaw themselves, then gave two constraints: a city must be powered by multiple boxes, and a box must power multiple cities (N×M scaling).
The team rewrote and deployed it by August–September 2013, just before New York City volume would have hit the brick wall.
This pattern repeated continuously: database choke points, API monolith limits, each rewrite buying ~12 months of runway before the next crisis.
Pham’s philosophy: don’t over-engineer for infinite scale when you might die before getting there; just survive long enough to fight another day.
Program and platform organizational split
By end of 2013, Uber had ~100 engineers and a dozen product managers; the functional structure (mobile team, backend team, dispatch team) ground development to a halt because every feature required negotiating across all teams.
Pham, Travis, and Jeff Holden reorganized into cross-functional teams using a sticky-note exercise: each color represented a function, each note a person, and they grouped people into business areas that could execute independently.
These were split into programs (teams building end-user-facing features) and platforms (teams building tools and layers that program teams consume).
They funded seven areas fully, four partially, and left the rest unfilled until they could hire more people.
Microservices: an accidental architecture
The backend API monolith became the next bottleneck for velocity; Pham declared all new services must be built outside it as microservices.
A dedicated team (Project Darwin) was tasked with decomposing the monolith, but the business kept growing (new cities, UberX launch), so teams kept adding features to the monolith faster than Darwin could pull them out.
What would have taken 3–6 months in isolation took two years; the monolith actually grew during the process before eventually shrinking.
This resulted in thousands of microservices, not by design but out of necessity to let teams move fast without blocking each other.
Later, Project ARC cleaned up the sprawl by putting domain interfaces on top of related microservices; by 2026 Uber had ~4,500 microservices, down from ~5,000 in 2016.
Building internal tools out of necessity
Uber started with standard open-source tools (PostgreSQL, Redis) but kept hitting scaling limits that the open-source community couldn’t help with.
A critical PostgreSQL failure at scale had no vendor to call; Pham spent weeks on LinkedIn begging for kernel expertise, which motivated building their own data layers.
Internal tools built out of necessity included: Schemaless (trip data store), TChannel (RPC protocol), Ringpop (consistent hashing), M3 (monitoring), Jaeger (distributed tracing, later open-sourced), and many others.
Pham acknowledges not every tool was strictly necessary, but all the important ones were, because existing solutions couldn’t handle Uber’s scale at the time (2013–2016).
Launching in China: five months to do the impossible
In late 2014, Travis declared Uber would launch in China in two months; Pham explained that simply copying software to Chinese data centers would cause the two systems to drift, so they needed one system that could be partitioned with complete data isolation (for security reasons) while deploying everywhere simultaneously.
TPMs scoped it at six months (industry friends said 18 months minimum); Travis pushed back, they settled on four, then slipped to five.
Pham negotiated an incremental city-by-city launch starting with the hardest city first (Chengdu), which turned out to be brilliant because once the hardest case was done, everything else was downhill and the team gained confidence.
The IT team had two weeks to physically set up servers; every engineer had an impossible task, and somehow it all came together.
The launch was a massive success, leading to intense competition with Didi.
Helix: rewriting the entire mobile app
By 2015–2016, the Uber app had become cluttered and limiting; Travis and lead designer Yuki envisioned a more open architecture that could support messaging and other in-ride services.
The engineering team determined the new design required a full rewrite; ~600–700 engineers (mobile and backend) worked on it for 7–8 months.
The rewrite changed the communication model from a 5-second polling heartbeat to a real-time push channel, requiring backend changes as well.
The resulting architecture is still in use today and was considered future-proof.
Pham sent a famous frustrated email about engineers giving services goofy names (e.g., “Mustafa”), writing “this is not a Mickey Mouse shop,” arguing that at scale, mature naming conventions were necessary for onboarding and discoverability.
Organizational innovations: L5A/L5B and internal transfers
Pham split the senior engineer level (L5) into L5A and L5B to give engineers a sense of progress on what could be a five-year journey to staff engineer, and to create a level for strong contributors who might not reach staff.
After he left, the levels were pushed down (L5B became staff), which Pham saw as title inflation he disagreed with.
In 2016, after hearing engineers were unhappy because managers wouldn’t support their growth, Pham created an easy internal transfer process: engineers could move teams without manager permission, and an internal job board published all openings.
The rationale: it was easier to interview externally than transfer internally, which made no sense; managers should be incentivized to develop people and retain them, not block moves.
Pham’s philosophy: “It’s not a jail”; if people want to work somewhere else, they should be able to, and creating internal opportunity is better than losing them.
Work philosophy and legacy
Pham frequently gave talks about work from the perspective of death: when you’re gone, the only achievement that matters is how many people remember you were good to them; positions and titles are forgotten quickly.
He believes in being genuinely helpful and constructive altruistically, not as a networking strategy; his entire career was shaped by relationships built through doing good work (Bill Gurley calling about Uber, VMware engineers following him to Uber).
He pulled key infrastructure engineers from VMware to Uber’s Copenhagen office, which became one of Uber’s best infrastructure teams (built Schemaless and other core systems); people came because they enjoyed working with him, not because of the company name.
Pham believes great talent is everywhere and companies should go where the talent is (Uber had nine engineering offices worldwide), giving people first-class ownership regardless of location.
Three tours of duty at Uber
First tour (~18–24 months): Fix broken systems, make things reliable, rewrite dispatch and other critical components.
Second tour: Scale worldwide, including the China launch and massive growth in every dimension.
Third tour (2017–2020): Help the company through turbulent years after Travis stepped down, a leadership committee of 14 took over, Uber went public, and COVID hit. Pham had been planning to leave in 2017 but stayed because the company needed stability. He left in 2020 when the new CEO (Dara Khosrowshahi) was established and he felt he was running things rather than building.
After Uber: Coupang, Nubank, and Faire
Planned to travel the summer of 2020 after his daughter entered high school, but COVID canceled everything; took calls from recruiters out of boredom.
Joined Coupang (Amazon-style logistics, 5–6 hour delivery) in an active role, learning about delivery operations firsthand (rode delivery trucks at 2–3 AM).
Joined Nubank (Latin America’s largest digital bank, serving unbanked populations with beautiful UX and industry-leading NPS) as a board member and CTO mentor; was re-energized by the culture reminiscent of early Uber.
Spent two years off (daughter’s 10th–12th grade) to be present for her high school years, calling it an easy choice he’d never regret.
Joined Faire (B2B marketplace connecting wholesalers with retailers, mission: empower local businesses) as CTO because of founder Max Rhodes’ energy and intelligence, the company’s fast-moving culture, and the complex two-sided marketplace challenges.
Faire is ~1,000 people, ~300 engineers, hybrid (3 days in office), with hubs in SF, Kitchener-Waterloo, and Toronto.
AI’s impact on engineering at Faire
Faire uses AI for search and recommendation (helping retailers discover products that will sell well), envisioning AI as a shopping consultant.
Engineering productivity: early adopters using AI coding tools (including swarm coding with multiple agents orchestrated together) have doubled their output; the best engineers are 2–3× more productive than average even with the same tools.
Current frontier: making large-scale changes and cleaning up old codebases is easy with AI; building new features on top of millions of lines of legacy code with complex dependencies is the next challenge.
Pham believes AI elevates the playing field (non-programmers can now create decent apps) but the traits that distinguish great engineers—curiosity, fearlessness, willingness to innovate, pushing boundaries—remain the same.
His advice: complacency is death; the tools changed, what makes people exceptional hasn’t.
The role of the CTO
Two primary jobs: (1) build a high-performance team through talent density, culture, organizational structure, and trust; (2) see around the corner, envision what the company needs in 18–24 months, and ensure the right expertise and leadership are in place.
Quotes Wayne Gretzky: “Skate to where the puck will be”; every leader should see further out than their team, who are focused on near-term execution.
For young engineers: invest in yourself early, seek learning-heavy opportunities in your first 5–10 years, seek high-impact opportunities as a senior/staff engineer (smaller companies can offer bigger stages), and in later phases focus on coaching and developing others.
Great talent will always find opportunity; companies should still invest in co-op and intern pipelines because today’s new grads are tomorrow’s senior engineers.
