Earlier quoted context omitted.
I love the "small team of focused engineers" trope for apps like uber. It's so easy to blow past that number. Website? That's a team. iPhone app? That's a team. Android? Another team. Data collection and A/B testing platform for all the front ends? Another team. Backend? A team. Infrastructure? Another team. AI solutions for problems like delivery time estimation? Another very expensive team. BI for the executives? Y…
Fairly recently I moved from a company of about 8,000 to a company of 54 or so. At first I wondered how the tiny company got anything done, but they've been around for 30 years so I figured they must have some skill. Now I wonder what the hell all those 8,000 people actually did. Each team you just named is 1-2 people at the current gig.
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.