> You mentioned 5 product "concerns" that Uber must contend with to make a point. No doubt if we brainstormed more we could come up with perhaps 10 or 20 more such "concerns".
> Now let's be very generous and assign 10 engineers to each concern.
> I still come up with a maximum of 200 engineers for Uber.
But Uber has 2000 engineers
There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.
Uber might be overstaffed, but I suspect the answer is mostly that you are drastically underestimating and don't see the complexities of running a large-scale service in multiple countries, dealing with regulations, worldwide scalability, time and cost estimates, surge pricing, tracking and mapping, payroll, billing, payments, apps, internal IT, etc., etc., etc. There aren't 10-20 "concerns". There are hundreds.
I bet they have at a hundred engineers just working on billing and they're all overworked.
> I don't see any creative ideating that would justify that many engineers
Because most of Uber's engineers aren't there to build "creative" solutions. They're there to enable the business.
I agree with your two interpretations. But to clarify that is my position: I believe Uber is overstaffed by an order of magnitude.
It seems after reading through this thread that I am definitely in the minority on that opinion, but I'm not sure if I understand the position there.
How many engineers would Uber need to have before one would say "okay, that's too many". 3000? 5000?
Uber can afford 2000 engineers. That doesn't mean they are anywhere near good at utilizing them, which seems to be the implicit assumption in many comments on this thread.
Google has in the tens of thousands of engineers, which they can afford to have because of Search. I highly doubt they are anywhere near reasonably utilizing those engineers to top line or bottom line product value.
> How many engineers would Uber need to have before one would say "okay, that's too many". 3000? 5000?
However many it takes before the cost of an engineer is higher than the value added. I have no idea where that line is for Uber. Maybe it's 10K. Maybe it was back when they hit 50.
> Uber can afford 2000 engineers. That doesn't mean they are anywhere near good at utilizing them, which seems to be the implicit assumption in many comments on this thread.
This might be true but it doesn't support your point. If Uber is bad at utilizing engineers, that doesn't mean they should employ fewer. In all likelihood, they'd be about as bad at utilizing their workforce if they cut it in half.
Netflix is another example. A couple of thousand programmers and tens of thousands of VMs to build a top drawer e-commerce site. I built a drawer-below-top e-commerce site with twelve people in a year, and a third of them were muppets.
I interviewed at another well-capitalised streaming video place, and they also seemed overstaffed. They had a permission service that worked out what people could watch, based on purchases, subscriptions, and bundles. Something that's basically one SQL query. They had something like six people working on it full time.
Is it not a problem to people that this many people would be required just for billing? I don't want to grossly oversimplify but at some point people need to start getting judgemental and saying, "no, we have created something too complex. We have to simplify."
You clearly have never worked anywhere close to payments :)
Kidding aside, the regulations around anything that handles money are quite complex, and the liability issues mean that you'll spend a lot of time on getting it right, too.
In theory, payment is super-easy. In practice, any payments solution that is not just a toy eats engineers for breakfast. Stripe is probably one of the leanest ones - and they have 400+ engineers, lean on existing infrastructure, and cover only 25 countries.
>> I still come up with a maximum of 200 engineers for Uber. But Uber has 2000 engineers
> There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.
The third interpretation is that we have no idea what else Uber is working on besides the operations that are visible to us as consumers.
Uber can afford to pay 100s of engineers to build out a few technical concepts/prototypes that will never see the light of day.
They basically need to do this, because their unicorn valuation isn't based on chasing the vanishing margins of the taxi industry, its based on owning an entire market that won't exist until they create it.
Exactly, Uber needs to scale along axes in a way most traditional web companies do not.
The axes have been pointed out are heterogeneous city/state/nation regulations, labor law, naviagation/connectivity issues, etc. And onto each of these diverse cases, there needs to be a way to analyze results consistently and deploy business objectives from a centralized corporate strategy.
As you point out: to justify its unicorn status, Uber needs to prove that it can succeed not just in competing with taxis in the major markets where it already exists, but that it's technology platform can be deployed to the edge cases, and the areas where it hasn't.
So what the extra engineers are doing finding a way to acheive user reliability under the reality of accelerating changes to requirements and sharding of policies for separate operational units that will result from forced-growth into non-optimal markets.
> Now let's be very generous and assign 10 engineers to each concern.
> I still come up with a maximum of 200 engineers for Uber. But Uber has 2000 engineers
There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.
Uber might be overstaffed, but I suspect the answer is mostly that you are drastically underestimating and don't see the complexities of running a large-scale service in multiple countries, dealing with regulations, worldwide scalability, time and cost estimates, surge pricing, tracking and mapping, payroll, billing, payments, apps, internal IT, etc., etc., etc. There aren't 10-20 "concerns". There are hundreds.
I bet they have at a hundred engineers just working on billing and they're all overworked.
> I don't see any creative ideating that would justify that many engineers
Because most of Uber's engineers aren't there to build "creative" solutions. They're there to enable the business.