Do Things That Don't Scale

Launched in 2015/16 in Toronto, Uber Eats was the “newest” food delivery company on the market. We needed to move quick to catch up with the competition. As a result, our engineering tech stack was always a work in progress.

We initially only enabled basic levers for our Operations team to manage their city’s marketplace. Uber leaned heavily into Operators. They were the actual humans living in the cities we supported. And ensured the product and marketplace was running well and in a healthy state.

For Uber Eats, that included things like managing online restaurants, adjusting the delivery radii, positioning drivers, optimizing pricing, etc.

And yet in 2019, just a few years later, Uber Eats managed to grow into one of the largest food delivery platform across the globe. How did we do that?

The answer lies in the hustle and ingenuity of those early Operators. They turned to spreadsheets and scripts, creating makeshift solutions that filled the gaps left by the initial tech stack. This gritty approach allowed the marketplace to not only function but thrive.

It not only bought valuable time for our engineering teams (like mine) to build auto-optimizations of these critical levers into the platform, but also informed us on what other levers we needed.

Doing things that don’t scale is an important rallying cry in the earliest days of a venture. Paul Graham’s famous essay reminds early employees how essential it is create the ways for your startup to take off:

Startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually it takes some sort of push to get them going.

Paul Graham, Do Things That Don’t Scale

This is a powerful reminder that sometimes, to build something scalable, we must first be willing to do the things that aren’t.

What exactly was running on that laptop?

This famous picture of “Uber Eats Canada running on a macbook” has gone viral a few times on social media. Was it really running the Canada business?

Well yes and no.

Uber and Uber Eats aren’t global, national, or even city-wide products. They really are hyperlocal. You don’t care about the many restaurants or drivers on the other side of town, you only care about what’s nearby you.

So while we built general-purpose systems that handled things like consumer app experience, user identity, payments, dispatch, and trip history, a lot of aspects of how successful a particular market was relied on tuning many local parameters.

And that’s why our operators are such an essential part of our business, especially for a newer product like Uber Eats. Many of those local parameters would eventually be auto-tuned and optimized as our tech stack and market matured. But until then, we needed operators to help do things that didn’t scale.

In this case, this laptop was running a macro for our Canada market that regularly adjusted the delivery radius of each restaurant. This was important to balance supply and demand across restaurants and orders.

For example, Uber Eats demand would always pick up over the weekends, with dinners on Friday and Saturday often representing our peaks of the week.

And our tech platform didn’t yet have any automatic levers to control that demand. So this laptop and those macros it was running helped manually set the delivery radius of a given restaurant. When you shrink the radius, less eaters could order from it and vice versa. You didn’t want a restaurant to be overwhelmed with too many orders or not enough couriers to deliver from that restaurant. We needed to smooth demand curves.

And that helped Uber Eats Canada stay online with a balanced supply and demand. And helped us scale.