Not so sure about that. The company was notorious for having teams constantly rollout competing internal libraries/tools and rewrite them over and over, obviously not having enough bottom-line work to keep everyone busy. A smaller workforce may be able to focus on the work that matters, it doesn't have to imply a lower productivity.

I have never witnessed a company at least the size of Uber where this wasn't the case. This isn't exclusively a culture thing, it's a bandwidth thing. There is limited human IO available to coordinate, and available bandwidth diminishes in proportion to org size. The org can either choose to slow down to match available IO, or run at closer to natural pace and accept duplicate work. I guess the latter must be the obvious choice, or the automatic tendency

I imagine the same problem is why so many large orgs inevitably turn into hyperstructures of insane management layer cake.. coordination overhead will eventually send everyone begging for the ability to shed work or delegate

Even if a tool should not have been written, the ability to troubleshoot it is still critical to its consumers. And making hundreds of dependent teams spend a month migrating is easily more expensive than 3 headcount to maintain it.

It could be worse. You could have a large company notorious for rolling out competing external products, like messaging and video chat apps....

IMHO Unicorns are built with the assumption that almost every developer is replaceable. At that scale the critical knowledge is not with the developers.

That's what business leaders think.

Then you get to the critical component where you fire the lead architect/programmer and then it keeps working fine for few weeks, but you find more bugs and you need to upgrade/fix it. Only to find out the documentation if they exist don't help at all and the first 2 tries builds fine so you put it in production only to see everything destroyed. And after 1 year of back and forth you hire 10 other developer to maintain this thing and then 50 others to write a new one.

I bet the number of developers that are working on the business critical stuff is very low. Years ago I talked a lot to people at Oracle and Apple and it was always amazing how small the core development teams for the big products were.

Oracle 12 lists 66 developers https://docs.oracle.com/database/121/REFRN/title.htm

An architect that doesn't leave documentation and share knowledge isn't doing their job and management needs to get ahead of this. What if this "key person" decides to find another job?

Of course there's documentation, and also knowledge sharing, doesn't help he/she and 50% of his/her teammates are let go and without a solid way of knowledge transfer or the desire to do so under this context.

This is especially bad for software that are written under tight deadline - no matter how much document you write about it. And sadly, there's more software that are written like that than otherwise.

An architect that doesn't leave documentation and share knowledge might also be thinking about protecting his own job. Being irreplaceable is good job security.

I’ve always wondered, does this actually happen? People not getting fired because they are irreplaceable partly because of their own failure to document stuff?

Nobody except newcomers to the codebase look at documents on code structure, and of course no one is fired for not producing it/producing a crappy version of it.

When the newcomer can't get anything out of that doc, if it exist, he/she just need to ask the creator, who will explain very nicely how everything is done, and that newcomer become a code guru in that codebase, and the cycle continues.

Until you layoff 50% of the team and now suddenly nobody knows how 50% of the stuff work.

Very frequently in corporate environments, at least in investment banks I have known and heard of many people earning four figures a day pretty much purely because they've been allowed to carve their own niche that becomes indispensable.

Ironically, the worse they are (think 5000 lines of Perl with two functions) then the less viable it is to replace them.

> IMHO Unicorns are built with the assumption that almost every developer is replaceable. At that scale the critical knowledge is not with the developers.

Critical knowledge is with the developers unless:

1. The system is stable and feature-complete.

2. You've employed about 10 FTEs documenting every aspect of the thing.

If those two criteria aren't met, they system becomes tech debt, a larger risk, and will likely decay until replaced.

I've seen engineering orgs cut in half and become a lot stronger as a result. Fat is trimmed across the stack. Processes are automated. Runbooks and documentation is written. Applications are 'operationalized' to be easily maintained. You'd be surprised how constraining resources makes it really clear what is important and what is not.

what kind of unique expertise is required to run a taxi app?