1. With more customers, you find your code is much buggier than you thought. Most code has a long-tail of weirds bugs that may be a non-issue at current scale but absolutely crippling by just increasing the number of users by 1-2 orders of magnitude.
2. As you increase the number of business functions within the company, cohesion breaks down. People start losing more and more context and you start needing full time jobs just to keep everyone pushing in the same direction without stepping on each others toes. I don't know you in particular, but most engineers seem oblivious to how many business functions a company trying to operate internationally often needs.
3. As engineers, there's often a wall between us and huge amount of effort that goes into sales, marketing, and customer service (even if the last is only provided to enterprises). One way to keep headcount down is keep this to a minimum, but you're usually leaving most of your profits on the table.
My previous role in the big company was actually post-sales customer support so I'm actually pretty familiar with those functions and somewhat aware of all the coordination and power politics that come with increasing numbers of people - there's a reason I'm trying something pretty different these days. And so far, I have to say I'm happier with the surroundings.
> If we increased our users by an order of magnitude or two, I doubt we'd need to increase headcount by anything near that much
Two orders of magnitude would land you with a few hundred thousand users.
Uber has ~93 million users in 80 countries.
Just supporting payments in all those countries is a full-time job for a dedicated team.
Uber's 93 million in 80 countries means that (very roughly) in each country they have three orders of magnitude more users than you: 93 mln/80 countries = 1+ mln in each country = 1000 times more than you = 3 orders of magnitude.
As I said, just dealing with payments in each country is often a full-time job for a dedicated tema even if you process payments through a third party like Adyen.
Are Uber operating at 100% efficiency? Hell no. Will you have several orders of magnitudes fewer people than Uber when you grow to Uber's size? I very highly doubt it.
Of course, there are exceptions like WhatsApp, but WhatsApp in itself is a very simple product (that is very hard to scale), and was (and still is) very slow in rolling out features.
What makes it particularly hard to scale?
Netflix has over 1000 engineers, maybe close to 1500? Uber has ~3,000.
If we assume these companies are handling similar amount of work, Netflix has only managed to do 2-3x better in terms of headcount to work ratio. (talking to friends at these companies, I think this paints a rosier picture of Netflix than is reasonable).
As another commenter pointed out, there's also a real step change when you go global. The requirements in terms of governmental compliance and engineering effort to outcompete local software shoots up headcount significantly. With a global audience you generally need to be providing an excellent experience in more ways as local values and tastes can vary more significantly than you expect.
One guy/girl was doing stuff, might be quite a bit, so it's decided it is really needing 2.something people, so they send two more, because you can't have part of a person.
Then they need a manager, and a doc controller and maybe an admin. Then the service people need a manager, and you need a manager of the managers, and they needs an assistant and who knows who else, maybe a HR and next thing know what one person was doing is all of a sudden a ten person team.
And instead of going to just talk to someone in another team, it's no "my manager will confirm with your manager" etc etc
I worked in one place where to send a document to the guy in the next office from me for official review had to go through a document control office in a another country. That was not unusual, apart from being unusually frustrating and time wasting.
At big organizations, it’s often 90% or more of all work the entire organization is doing (depending on how you calculate kt).
Unicorn tech companies generally don't realize this, which is why they all redesign their apps over and over and add poorly-thought-out features all the time. They're still paying for a build-an-entire-iPhone-app-from-scratch-sized team, and all those engineers are desperately looking for stuff to do!
You still need a non-zero number of people who know how the iOS app works, but the number you need is smaller.
However, The moment that you discover that your AWS bill exceeds your engineering budget, you will have a different view of maintenance. People will now start calling it resilience, scale, optimization, etc. And then one day, the db will need to be partitioned (almost always, if the product is successful) and then the people who created the mess [almost always using a nosql database as it was available ]will run for the exits. You (or the poor unthanked ‘maintenance’ engineer ) will start learning about why distributed systems are hard to maintain.
Most line engineers often realize it too pretty quickly, which is why we end up with so many new frameworks every time there is a huge boom cycle.
And many of the largest ones use the same app. Because they aren’t in that business, they are in the taxi business. If there is a margin to be found in scheduling or pricing, then their app supplier should provide it.
This is perhaps what Uber should be doing: making the white label apps for local companies doing ride services.
Not sure how many taxi markets are that unregulated that they allow it.