Perhaps the next question is, what do 4000 engineers do? Not aimed as a troll-y question: an informed idea of what the breakdown of that many engineers do would be enlightening. For example, there were about 200 iOS engineers the last I heard. Assuming similar levels for Android, that leaves 3,500-3,600 engineers.
+1 Appreciate you avoiding the usual "it's just a little smartphone app"
I'm not going to try and give an exhaustive list, but as a rough explanation: things get really, really hard when you're operating at Uber scale (hundreds of thousands of riders on trip at any one time, each demanding low latency and reliability):
- Product: native clients for each side of the marketplace in each vertical (rides, eats, freight, atg, et al), maps, localization for every country with a presence (not just language, but tax, legal, hundreds of region-specific modes e.g.: tuk tuks)
- Infrastructure: hardware teams to build on-prem DCs (cloud can get very expensive at scale), software networking to deal with said low-latency traffic, storage to optimize for reliability/latency/cost, observability (metrics, logging, alerting, tracing), security, et al
- Data: insights, operational support, routing, et al
Uber doesn't just make apps for phones.
They also have an entire self-driving car division (computer vision, etc), car routing, maps folks, payments, the separate driver apps, etc. A company that size and complexity has plenty of work for engineers.
I still feel like this is a ridiculous amount of workers when one takes into account that the product they're offering is essentially a smartphone app with a backend service that pairs drivers and customers, which regular cab markets do without almost a single person.
To me Uber feels like some sort of soviet-era experiment of replacing a market with someone micromanaging cars
But of course, when you just oversimplify what the app actually does it sounds like it should be so darn easy to make and maintain.
It's like saying Microsoft Office is "just an app that writes documents" or that GMail is "just an email client."
Uber and Lyft do a whole lot more than what you described on the scale of millions of concurrent users in dozens of countries.
Your comparison to a taxi isn't really a great one because you see taxis sitting around on curbs and driving around empty looking for a passengers all the time. A lot of the cost of a taxi is you paying for idle time.
>Uber and Lyft do a whole lot more than what you described on the scale of millions of concurrent users in dozens of countries.
which is my point. There's no use in engineering and coordinating something that organises itself. The utility of a centrally managed service needs to be balanced against the resources it costs to run the operation.
Taxis actually don't spent as much time sitting around as you think, traffic organises quite spontaneously, drivers know where to wait and downtime is usually quite low. Which is why it is so difficult for Uber to make a profit, the efficiency gains compared to the engineering effort that goes into them are miniscule, which is the disease of all centrally managed systems. The Soviet planning buro managed millions of factories which sounds impressive, it doesn't mean that they were any good at it.
If Uber would realise such huge efficiency gains in organising rides the result would either be higher wages than taxi companies or lower prices, which would make them instantly profitable, no billions of subsidies required.
I work for a company that does kinda similar software stuff for vehicles - Uber has about two orders of magnitude more drivers than my company, but about three orders of magnitude more engineers - it's almost like they've got diseconomies of scale.
Two orders of magnitude are a lot of orders of magnitude. It could be the difference between using really easy off-the-shelf solutions to having to architect your own technology to solve scaling issues like Google has.
Uber operates in many more countries than us. Enough to necessitate ten times more engineers per driver? I can't really say without more insight into what they're doing.
One thing I've learned time and time again in software is if something seems super simple on the surface, it almost always means there was a hell of a lot of engineering and attention to detail to make it seem that simple.