I have an issue with number 4, promoting the most prolific engineers. Lets take two new engineers.<p>One just cranks out code and it looks like he is the most productive employee. Even if he does a lot of cutting and pasting.<p>The other engineer takes his time but when he releases something there are never any bugs. Plus his UI's are a thing of absolute beauty. The other programmers are always asking him for help which slows his production further.<p>Management rarely considers the true cost of bugs, not just the cost of fixing them but higher customer churn. Funny how the first engineer gets the promotion and now he also becomes a sub-par leader.<p>Suddenly the startup starts losing programmers as well because they don't respect their bosses decisions. Now the guy hires more coders just like him. The startup stalls and management is befuddled because so many lines of code are being written.
I'm not sure the author should be quite so proud of the results of his hard work (i.e., the Facebook user experience). And indeed, my own startup experience has shown that the "move fast, break things, ask forgiveness not permission" method results in burning through $millions of investor cash and frequently building products that aren't really that useful or successful?
I think it's important to consider the context for this advice, which is introduced in the opening: dwindling funding and competition out to kill your company.<p>Presumably, the advice that follows is a direct result of those <i>constraints.</i> However, if you don't have those constraints, I don't think you need to grind yourself to the bone.<p>Yes, there will always be competition looking to eat your lunch. Is getting to market first and fastest the most important thing? Depends on the product. All-encompassing social media platform? Yes. High quality saas tool? Perhaps not. In most markets, there's always room for competitors, and even if you become an underdog, producing stable, affordable, high quality software can make you a serious competitor to a company 10x the size who is constantly breaking things and pissing off their users.
I think it’s generally true that product shipping speed is very important for startups. You’ll always have competition, having the best product is crucial to “winning”, that means you have to be faster than your competitors.<p>However, speed has to be balanced against things like:<p>- Doing customer research/building the right things<p>- Stability (high uptime, few bugs)<p>- “Workflow regressions” (not explicit bugs, implementing a change correctly, but not realizing it breaks a key workflow for key customers)<p>For a B2C social network, speed dominates those factors. Ship a lot, keep the successful features and prune others, customers tolerate the rapid change and a moderate level of
bugs and outages.<p>However, for a B2B Enterprise startup, where your software is absolutely mission critical for your customers, and you MUST have a great reputation to do more sales, it’s distant. Those other items are really important too, and you do have to sacrifice some speed for them.<p>Even for mission critical Enterprise startups, I think you still have to emphasize speed a lot to “win”, but it can’t dominate things like stability, customer research and workflow regressions. You have to sacrifice a moderate amount of speed for those things.
I worked at FB in 2016-17. The bootcamp _was_ amazing, but we didn't go live on day #2. (Maybe this was true earlier.) I think I got something live on week #2. Day #2 was not realistic, you need to set up the macbook, accounts, receive the bootcamp tasks, get some context in a multi MLoC codebase, test locally, commit, get it reviewed, then it went live for staff.<p>Still, the spirit of the post is definitely true. Bootcamp was awesome, it indoctrinated us to Move Fast and Break Things, and Just Ship It. FB was an amazing company, best company I ever worked for.<p>What others point out, that this doesn't work for all domains; it's true. But it's probably true for 90% of the startups here on HN. Also, if you're a startupper, esp. one doing the other 10%, you better be able to apply critical thinking to advice on the Internet..
A worm on its own is faster than a horse in the mill stone .
It's bad mindset to think that all software companies are the same , there are some companies which ship things other than CRUD apps on the web(shocker !!) .<p>My main gripe is the statement of ask for forgiveness than permission, that mindset does not work on projects like the 737max . Anything of value is built by teams and as such hero worship should be avoided whenever possible. Good work should be rewarded but don't skew the social dynamic to the point of "hero said it so it must be true".
As mentioned in multiple other comments: context matters. Some commenters have presented more extreme contrasts of context (737 Max, B2B etc etc) but I also think the context matters even for products that might be quite close.<p>While the specific strategies employed at Facebook (or Google or wherever else) may have had a direct influence on the current position there are many other factors to consider when contemplating the fate of some of the most extreme outliers.<p>An obvious example of this is all the companies who started using (or frequently misusing) OKRs <i>because Google uses OKRs</i>. Using OKRs won't make your company the next Google.<p>I can get behind the sentiment of "A Bias For Action" or "Speed Matters" but these principles need to be applied appropriately too. I've been in startups where "Speed is the most important factor" has been used to hire faster. The costs of hiring poorly are very high. You can't just revert the breaking change and go back to BAU.
"Key startup lessons ... if your goal is to make a lot of money, work like crazy and get lots of people talking about you"<p>By contrast, you might want a nice job in a little niche with lots of work/life balance, a reasonable income and being left alone except by your valued customers. In which case, almost none of these lessons are for you.
I feel like one success story doesn't necessarily make it good advice for everyone else.<p>Maybe in the world where your customer base is flexible (students), and where your product "doesn't really matter", then hey, why not break it from time to time. The penalty for failure, is well, zero.<p>In a different context though small errors can result in very large penalties, even extinction. In which case this strategy will (and certainly has many times) failed.<p>Advice without context is dangerous. Before adopting any advice (especially "how we did it" stories from survivors) it's worth really understanding the external factors that aided in that success.
The advice is very much in alignment with the "Zero to One" book. They are explaining how they made their startup "successful". But that doesn't mean if you follow their foot steps your startup will be successful as well.<p>This line of thinking is not far from the type that leads to cargo cult or any other superstitious belief.<p>So, not necessarily good or bad advice, do whatever works best for you, but it's important to measure often to know if things are actually working.
This seems like good advice for startups with high burn in competitive markets. However, that may have more to do with the "high burn" and the "competitive market" part than the "startup" part...
There are obvious tradeoffs with stability that are being noted. These concerns are well expressed here: <a href="https://xkcd.com/1428/" rel="nofollow">https://xkcd.com/1428/</a><p>But I think the more insidious downside of this mentality in practice is that it tends to absolve the product management of their responsibility to form a strong opinionated vision of what needs to be built over the course many months.<p>Tactical engineering speed is important, but I would much rather work for a company that obsesses over building the right thing and knows how to communicate a view of what 'great' looks like.
LOL reading this...<p>There are many mistakes that I can make at my job that will result in a death. So... I will definitely ask for permission, go ahead, ask for forgiveness after you killed a person or pet. Let's see how that goes.<p>I feel like these "dude, its obvious if you do X it'll totes work out". No. It worked at your company.
Setting up dev env. in one day is normal, it normally shouldn’t take more than couple of hours at worst but how did they managed to publish a commit next day?<p>What type of a code base was that, because normally an engineer should spend at least couple of days trying to understand the full code base.
Mandatory for people to commit code on Day 2 that goes to all users?<p>Just because you've seen it somewhere, and it worked for them/you doesn't mean it's a good practice. In fact, this particular one sounds pretty stupid.
One thing I don't see mentioned is that a lot of this is great advice for a social media startup (fine for ad-tech, etc) but maybe not a higher-risk space, like medical devices