3 ms·
Assuming the premise of this article: efficiency is the only way to survive death(literal or metaphorical). Say what you will about MAANG, but has anyone who is
by ghm2180 2y ago
Assuming the premise of this article: efficiency is the only way to survive death(literal or metaphorical). Say what you will about MAANG, but has anyone who is a meta/google etc engineer also been a SEAL?
I bet after both the experiences, they will be like: "The only thing we could say with certainty is that how to make effective teams one way or another. 97% you fail or flail. 3% you succeed and succeed big."
If you see the graveyard of MAANG Products you can see a pattern. The sheer volume and size of products that have come and gone IS how they survived[1].
Can any one say, for example, Meta is where it is today by doing any of this Slow is Smooth and that is fast culture?
Sure, there were acquisitions(those too were fast) and there are bad initiatives and orgs (alexa, google+social, facebook phone), but then there are also many amazing things like LLMs and MooCs.
[1] https://killedby.tech/ https://killedby.tech/
- borski 2y agoThere’s definitely plenty of survivorship bias in that argument - you’re making the argument that Meta could not have built successful products without also building a ton of unsuccessful ones, which they did by virtue of executing fast rather than slow/smooth. (I’m paraphrasing to try and ensure I’m understanding the argument correctly, just to be clear) The issue is that if you look at Meta’s successful products… 1. Facebook - would have won whether it moved fast or slow. This was network effects, not “features” 2. Messenger - has not won, and only exists because of Facebook’s aforementioned network effects. 3. Instagram - acquired. 4. Quest - acquired. 5. A bunch of other random shit nobody cares about and will never make Meta money. I can pretty much guarantee both FB and Messenger would be just as big as they are now if Facebook had “broken less crap.” Moving fast and breaking shit made working at Meta fun, not necessarily more productive, even if at times it felt more productive to the engineer, since they could push code faster.