Uber is in fair running as the best product of the decade. It has enabled millions of people across the world to make money, give up owning a car, and has literally changed city traffic patterns. Uber's level of impact, naturally, goes hand in hand with some of the fastest growth growth in startup history. So how has Uber managed it's astronomically rapid growth?
Most companies would have been crushed under the weight of rapidly accumulated technical debt, the chaos of expanding roadmaps, and the ossifying effects of politics - not unlike Zenefits. Instead, Uber has remained remarkably nimble throughout its growth, setting records for execution speed, while keeping internal politics to a minimum.
Here's what I've learned about scale from working at the world's fastest growing company.
Operations over Technology
The first insight is that Uber is, at its core, not a tech company. Uber is first an operations company, and a tech company second. This isn't a knock against the company; instead, it's one of Uber's strategic advantages, and what has allowed it to scale with such speed.
Take, for example, one of Uber's most respected roles: not the software engineer, but the city launcher. Throughout its growth, Uber's city launchers hustle 24/7 to recruit driver partners, make a splash with the launch, and organize marketing campaigns. This hustle is exemplified by Uber’s Head of Expansion, Austin Geidt, who has been profiled in numerous publications - "I live and breathe Uber," she says. Uber has an office in every geographic region and nearly every city that it is live in, and this level of operations has given the company ears and feet on the ground, all of which powers its growth.
Their primary domestic competitor, Lyft, tried to build centralized operations, with workers in San Francisco managing their entire US operations. However, they have not been able to launch new cities at anywhere approaching the same pace as Uber. Their mistake? Lyft tried to automate too soon, instead of doubling down on operations - and hustle.
The problem is that cities have different usage patterns and different types of people using the platform. One city's learning simply don't translate well from one place to the other. Having teams in every city allowed Uber to be highly adaptive, molding itself to the local ecosystem in order to maximize growth. Moreover, in many cities drivers visit Uber offices to sign-up in person, where a representative can answer any questions or troubleshoot issues. That level of support isn’t cheap, but also gives Uber ears on the ground, so that problems in any particular city are discovered quickly. It's a human experience first.
All this isn't to say technology isn't important at Uber - in fact, it is critical to the company’s success. Instead, almost like a good entrepreneur who fakes a product to sell it first, and only builds it with market validation, Uber has built only things that were absolutely, unequivocally, on the path of optimal growth. Anything else is done manually by humans. Only as a market matures does that charter expand and there is more breathing room to build & automate many of the auxiliary functions that are nonetheless critical to the operation of a city.
Programs & Platforms
Uber also developed a corporate structure to make each team self-sufficient and remove all barriers to execution. It inherited a company structure used at Amazon called Programs & Platforms. Programs & Platforms works by grouping people into cross-functional groups, so that every team is able to operate independently and every barrier to execution is removed.
Think of a platform as a technical “home” - maybe it's a backend, a mobile feature, a web deployment, or even design or product. If a person is doing structural or architectural work, they will work day-to-day with that team. Most people however, sit day-to-day with their Program team. A Program team combines employees from every domain - designers, PMs, backend, mobile, and more - so that all the expertise to execute on the team’s mission is assembled on one team. There’s never a notion of being blocked on the roadmap of another team, because someone with the proper expertise is sitting right next to you.
As the company scales, removing all barriers has gotten harder with the complexity and number of backend services. However, the structure still serves the company well, and manages to keep barriers to a minimum if not eliminating them outright. The same structure also reduces the amount of politics at a company. With each team enabled to execute autonomously, there is no need for a team to game another team’s roadmap to ensure their work gets done.
Built from Scratch
Lastly, almost to a fault, Uber encourages home-grown solutions over using existing technology. For all the extensive benefits of open source, it’s often faster to build a new system from scratch than adapting existing software. While this decision causes numerous growing pains (implementation mistakes and difficulty onboarding new engineers, to name two), the reality is Uber’s meteoric growth means the system will have to be rebuilt in a year or two to deal with new levels of scale.
Any company, in every element of its structure, makes tradeoffs. Uber, from everything to its culture and technical choices, even its funding, has optimized for a single thing - execution speed. That choice has served the company incredibly well. As anyone builds a company, it’s worthwhile to pay attention to the question. So what are you optimizing for?