3 ms·
There is an important distinction between MFABT and these other examples. In all of the other examples, the consequences of breaking accrue to the person making
by apinstein 7y ago
There is an important distinction between MFABT and these other examples. In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. People make better decisions about the risks to take when they have to deal with the consequences. With MFABT the party doing the breaking isn’t often the one suffering from the breakage and that drastically changes the system dynamics of such a policy. It has a huge tragedy of the commons dynamic to it. I have seen so many companies and products end up getting stuck treading water due to these dynamics. It only even begins to be workable if you a) have almost no users so breaking is of little consequence or b) you have so much money coming in due to moving fast that you can pay for the cleanup. Always be aware of the primary and secondary effects of the system you implement.
- jasode 7y ago>In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. If a fishing ship goes out to sea and fails to catch enough fish or is wrecked because of a storm, it affects the families of the crew and everyone else who depended on them. If Michael Jordan fails and misses the game-winning shot, it affects his whole team. If it's losing a playoff elimination game, it affects the workers at the sports arena because they don't the get the income from extra games. > With MFABT the party doing the breaking isn’t often the one suffering from the breakage I don't know about every company that's (misusing) MFABT but with Facebook, it was their mantra before 2012 when they were not making any profits and trying to survive while competing against the bigger website, Myspace. Their software engineers could have conceivably broken their website so badly that FB goes out of business. That's what happened with Knight Capital when they misconfigured a server and lost $450 million. MZ's aphorism is just a twist on a common observation about making progress. He expanded on it in an interview: >We've optimized so much of our culture around just making it so that people can come and build things quickly. Whether it's everything from having the right tools in the right development environment to build things quickly, to nightly code pushes, hiring the best people who have a bias toward just pushing things very quickly, very entrepreneurial. The whole culture is tuned around that. And I think there's probably something in that for other entrepreneurs to learn which is that making mistakes is okay. At the end of the day, the goal of building something is to build something, not to not make mistakes. [1] He actually does not want a broken Facebook system. But he also knows that if there are no mistakes, it means the team is not bold enough with adding features. Yes, they could die from a broken code deployment to production servers. But they'll also die if Myspace or Google+ is more aggressive in adding social networking features. Being ultra-conservative just to "avoid breaking things" will mean the business can go bankrupt and thus, there's no website to even worry about breaking. [1] excerpt from: https://theweek.com/articles/462863/stories-behind-3-great-business-mantras https://theweek.com/articles/462863/stories-behind-3-great-b...
- jdmichal 7y agoI can confirm that I saw the phrase on posters visiting the Palo Alto site in 2011.