> The title also makes it sound like 500 engineers would make it easier to scale up WhatsApp, which does not make too much sense either.
It's something I think we have all seen a lot of times - that by the time a company is serving 1 billion users it has quickly expanded out it's engineering team hugely, and because of that additional abstraction is required and the complexity/LOC skyrockets.
"this team of 7 engineers is responsible for formatting the text content of a chat, including alignment and sizes of emojis and gifs"
"this team of 4 engineers is responsible for formatting the date of a message"
"this team of 7 engineers is responsible for the overall formatting of a chat"
"this team of 5 engineers is responsible for the formatting of the non-chat pars of the application, settings, profile page"
"this team of 4 ux persons is responsible for aligning the non-technical parts of formatting and the user experience over all parts of the application"
"this crossfunctional team of 5 is responsible for creating a framework to let the configuration of formatting be disconnected from the actual implementation of the formatting"
"this team of 7 QA engineers will aid in manual verification of changes and bugfixes but will also automate test cases for formatting in the entire application"
"this supporting team of 4 will develop automation tools and enable the formatting teams to collaborate in a high speed agile context"
> it has quickly expanded out it's engineering team hugely
But makes little sense (as a developer/engineer myself) to think that growth in users, requires a ton of new developers/engineers. We are not tattoo artists, our job can scale indefinitely if set up properly, i.e. all you should need to scale further (to 1BN or 7BN) should be enough money to buy more hardware; which WhatsApp/Facebook clearly has.
You're assuming that their use case & technology stack & application scale cleanly horizontally and they're not spending all their time fighting fires.
True in this instance, but far from a universal truth.
I think that makes sense if the application doesn’t need to also grow much functionally during the expansion, but I believe the more common pattern is more users = more functionality to manage those users, support teams, global legal compliance and accommodate more niche phone systems = more engineers.
It's something I think we have all seen a lot of times - that by the time a company is serving 1 billion users it has quickly expanded out it's engineering team hugely, and because of that additional abstraction is required and the complexity/LOC skyrockets.