I have an issue with number 4, promoting the most prolific engineers. Lets take two new engineers.
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.
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.
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.
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.
"The other engineer takes his time but when he releases something there are never any bugs."
Ah yes that guy. The person super worried about quality at a startup doing "uber for cats". Avoiding bugs at all costs, meetings, deep unit testing, always rolling their eyes at "bad code".
"Funny how the first engineer gets the promotion and now he also becomes a sub-par leader."
Not really at a startup. You are testing if an idea even "works" - why in god would you start worrying about quality. Bring the product to life, get feed back fast. Your quality slow churning code could be in the wrong direction. People that write deep quality code generally protect it, shine it, rub it. Good luck explaining to this guy this isn't 'what we want'. What is worse than bad code? Good code never used.
I think the point doesn't stand up to close scrutiny, but taking into consideration that the actual implementation of this action-reward feedback loop is probably more nuanced, it makes a bit more sense[^1]. Obviously, you don't want someone pumping out nothing but garbage commits and forcing it onto the production branch, but at the same time you really can't afford perfectionists who spend all their time stressing about a fractal infinity of possibilities containing other possibilities. Furthermore, in a startup environment a dev moving slowly because they're busy helping other devs can lead to the obfuscation of management issues. If a dev looks more 2X capable than they actually are because they're using up half the time of a 10X dev, then you really should be assigning the less capable dev a lighter workload where they're less likely to block things.
Bugs obviously can spiral into more time and time spent early can avoid timesinks and various issues down the line. I completely agree that spending a day to prevent an issue causing weeks to months of headaches is completely worth it (and to add to your point, I lost all respect for management when perfectly foreseeable issues weren't addressed, especially when I requested resources to address the issue). This is probably where the nuance is lost, where you need to have checks and balances in place to ensure that critical decisions are being made by the right people, and that guardrails exist so that devs can move quickly without stepping on anyone's toes.
[^1]: While Dan Luu's statement that nuance doesn't scale isn't entirely applicable, there's a similar effect here where nuance is sacrificed for a punchy, memorable aphorism. I personally don't agree with sacrificing nuance for more base appeal, but we can maybe also take for granted that readers have some capacity for critical thought (and the ones that blindly accept this advice won't hurt too many people when they inevitably fail spectacularly).
> The other engineer takes his time but when he releases something there are never any bugs.
In fairness a good portion of startups do not benefit from this in the beginning. Releasing the right albeit buggy thing is far more important than vice versa.
Later on or if operating in a less forgiving industry this becomes a different story obviously.
The forgotten Fibonacci law of hiring: only 1st class people hire 1st class people (but also some 2nd class people), 2nd class people only hire 3rd class people, etc.
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'm not sure the author should be quite so proud of the results of his hard work
Well, that's a problem for every for-profit company, right?
If TikTok goes from attracting 5 minutes of attention a day from its users to 10 minutes, then that's great for TikTok. If it gets to 12 hours a day, then that's a civilization-ending disaster. If a coal mining company extracts and burns every cubic meter of coal in the Earth's crust then we all die. Etc etc.
Companies want to grow and compete, and that's good, since it's resulted in literally all human progress, and is why we're no longer living in dirt huts and dying at 30 from cholera. But taken to the extreme...
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.
Presumably, the advice that follows is a direct result of those constraints. However, if you don't have those constraints, I don't think you need to grind yourself to the bone.
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.
However, speed has to be balanced against things like:
- Doing customer research/building the right things
- Stability (high uptime, few bugs)
- “Workflow regressions” (not explicit bugs, implementing a change correctly, but not realizing it breaks a key workflow for key customers)
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.
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.
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.
However, speed has to be balanced against things like:
- Doing customer research/building the right things
It's usually much faster to build something and let the users tell you why it's wrong than to research the crap out of something and hope to get it right first time. Usually you'll just have users tell you why it's wrong anyway (even if that directly contradicts what they said in the research phase), so skip the research stage and just get to the build-and-get-feedback bit as fast as you can.
Also, in a startup where you're a founder very often your instincts for a solution will be pretty good. Research shouldn't really be giving you any huge insights early on.
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.
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.
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..
I was in London. As far as I remember, speakers showed up and were very professional. I distinctly remember, FB feeled like a hedge fund [1] and a startup [2] had a baby.
[1] Lots of people in shirts, lots of people making a lot of money, company making a lot of money, free electronics from vending machines, lots of perks, etc.
[2] Move Fast and Break Things, The Quick Shall Inherit the Earth, etc.
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 !!) .
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".
No, you're right. A 737max can only affect a few hundred people's lives.
This is why 'build at all costs' has cost us so much. Look at the negative effects this dog eat dog build fast, break things (including people), culture has on society.
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.
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.
An obvious example of this is all the companies who started using (or frequently misusing) OKRs because Google uses OKRs. Using OKRs won't make your company the next Google.
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"
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 am not sure the word startup applies to that kind of boutique or lifestyle company and this is specifically talking about startups in the way we have now accepted them; funded, high growth, make it or bust type of companies.
I agree with you though and I would not want to work for such a company or take this advice and I do run my own companies, but I no longer call them startups because everyone always asks where are the VCs and why do I have time to socialise so much instead of killing myself ‘breaking things’.
I feel like one success story doesn't necessarily make it good advice for everyone else.
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.
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.
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.
> In a different context though small errors can result in very large penalties, even extinction.
But in practice, for startups it's almost never the case, and having this belief is actually harmful.
Backing up for a second, have you started a startup yourself, or know (have had a 1 hour, 1:1 convo with) anyone who started a startup for which that happened? If so I would like to hear the story.
Personally, I've started 4+ startups, 2 successful, and directly know dozens of startup founders. So I know many failed startups. None of them was due to a small error that resulted in large penalties. Most of them was due to lack of determination, or speed, or being too conservative if anything.
The above belief you have is so harmful for a startup not because it's wrong, but because it's so intuitive and drives startups in diametric opposite direction of success. By slowing down at each stage to do a "small errors" analysis you move a lot slower and fail by default. The fear of making a small error has killed more startups than just a small error.
The intuition is correct historically. Back when humans were in small tribes, if we lost our reputation, we would be outcast and lose our lives. For the startup world (and e.g. modern dating world), that intuition doesn't apply.
I have indeed started a company, but it was different then - we didn't have VC money to spend, so we built it from literally nothing. Our product has to calculate numbers, in a specific time frame. Failure to produce results on time, or excessive numbers of errors, (or excessive errors) can lead to significant issues for customers resulting is serious financial implications. That is my context.
I feel like the main thread of replies to my comment focused on the speed. Whereas perhaps I was commenting more on the "break things" aspect. We did, and still do, move quickly at times, and slower at others, but we work quite hard not to break things.
Our customers need our software to be reliable. It impacts them, and also (in a big way) their customers. They need it to work, not be broken.
That's my context. In my context breaking things is not OK. Your context may be different. My path is not necessarily good for you, your path is not necessarily good for me.
So I say it again - all advice can be useful, or harmful. Context matters. Make sure you understand your own context, and the context of the advice giver in deciding if the advice is worth anything.
Indeed, if my context is not your context, then my experience is of no value to you. So I agree with your first question;
>> have you started a startup yourself,
Discovering my context helps you understand my advice. That is a good instinct to have.
> Personally, I've started 4+ startups, 2 successful, and directly know dozens of startup founders. So I know many failed startups. None of them was due to a small error that resulted in large penalties.
> Most of them was due to lack of determination, or speed, or being too conservative if anything.
You simply don't get it, but most people don't, including founders. Lack of determination, speed, or being conservative, are the symptoms of those errors. They are second-order effects that cause third-order effects, and so on, in a vicious cycle. Maybe those founders learned those habits from a previous company, but at the root of it was a decision that wasn't given enough care.
They can be related to morale issues, resulting from small details or flaws adding up. Also from hiring decisions, stemming from again small details or flaws in that process.
> If you think people have scar tissue, you should see organizations. Each time there's a disaster, they create a process to prevent future disasters of that type. Eventually they accrete a thick layer of these processes that prevents them from moving. Then they die.
So you're saying entrenched companies become too conservative due to their over reactive policies and get slowed down to the point where they die? I'm really struggling to understand how you think this somehow contradicts what the person you're replying to said.
Alright, this is the part of the message in question, in case it wasn't clear:
> But in practice, for startups it's almost never the case, and having this belief is actually harmful.
Maybe they were thinking of startups in the earliest stages (before having any real number of employees, Pre-series A), but the failures in those situations are less nuanced, at least in this context - do they really need discussion? The article is clearly talking about companies that were not in the earliest stage at the time of the actions being discussed.
I wholeheartedly agree with your comment. The “move fast and break things” mentality works for the banal and unimportant, but not for the significant or important.
Who cares if a social media site is offline for a day? Society will be fine. Users will be fine. Is anyone really going to miss a random social media post lost due to misbehaving code? Probably not on balance.
But if you’re attempting to build a quality, say, EMR/EHR, or some kind of industrial control software, or a password manager, you have certain duties that are completely incompatible with that mentality.
None of the SpaceX ideas where actually that new, rockets lanfed already decades earlier. That ULA got complacent is a differwnt story, ULA is far from being the only competitor of SpaceX outside of US government launches.
Not tgat SpaceX isn't imoressive, it is. They did move woth less beauraucracy, not with more risk. Kind of like the Covid vaccines, less red tapes speeds things up. Otherwise, SpaceX seems to be rather conservative ubder Shotwell's leadership as far as safety is concerned.
Dpace flight is, funny enough, less regulated that commercial aviation and tue aero part of aerospace.
Every time peoples life, health and well-being depend on your action advocating for "move fast and break things" should be reason for immediate termination. The severance package can be negotiated later.
While I agree with you generally, one could make the argument that if your aim is to drastically disrupt some domain, you may wish to adopt a riskier but faster path even if you're working in a safety-critical field, because the "slow and safe" route means more lives lost / negatively impacted while you slowly perfect your solution.
If you'd humor my extreme utilitarian view for a minute, I would argue both autonomous self driving and some medical endeavors could save many more lives if we, as a society, said "you get a budget of 10k. 10k lives you can severely negatively impact to deliver impact greater than that number" - basically giving you an investment/debt you repay to society via your future impact.
Currently, traffic fatalities are at ~38k/year in the US (with over 2M/year injured), and the numbers for leading medical causes are staggering (heart disease ~700k/year, cancer ~600k/year, etc.).
I would argue our current processes for breakthroughs in areas where health or safety are involved simply lean too far towards the "safe" end of the spectrum.
One anecdote I can share is a friend who worked for over a decade on a system where patients could buy a medical test at a pharmacy, take a urine sample at home, and get lab quality results using their phone's camera. The tech was ready in their first year of running. They built a suite of validations and tested things across hundreds of phone models, they really did their part well because they truly care.
Getting things FDA approved and in patients' hands took much longer, because the processes are extremally slow and designed to reduce risk by almost all means necessary. While that's a good idea in theory, it didn't stop a scam like Theranos (because when you're intentionally dishonest rules don't always help), and it did make it so my friend's company took a lot longer before being able to get fast, accurate, test results for many different metrics to rural and poor communities where lab testing can be an issue...
Theranos isbthe exception proofing the FDA right, the 737 Max is the exception proofing the FAA right. And no, there is no such thing as a "budget" of lost lives to further innovation. That approach is just deeply cynic, and should ve in itself ground to not work in any of those industries. The 737 Max and Theranos do show so that there already to many people with that exact mindset out and about. And while Theranos didn't cause any death (at least not that I am aware of), the MAX indeed did. All for profit, all for moving fast. For me, that is simply not acceptable.
>> And while Theranos didn't cause any death (at least not that I am aware of), the MAX indeed did
The Max killed 346.
Theranos is directly related to 1 (Ian gibbons) but it is probable that the indirect number is much much higher. Between suicides for false positives, and lack of treatment for false negatives, there are significant outcomes.
Given that they delivered at least 150 000 incorrect results, I'm going to wildly speculate here that they are more deadly than Boeing.
Context matters. Good strategies for a social media company does not necessarily make it good advice for companies in another context. Turns out "breaking things" is not terribly good advice to airplanes or medicine.
I agree with you fully. However, the way I read int0x2e’s comment was as a theoretical example of the logic they were putting forth. Not as advocacy for actually taking that tact.
Typically we empower governments with restraints to prevent them from allowing those tactics, and for good reason. (Even if in reality it is imperfect).
> as a society, said "you get a budget of 10k. 10k lives you can severely negatively impact to deliver impact greater than that number"
10k negative impacts multiplied by every startup, most of which will never get to the stage where they’re able to deliver their “benefit”, and even then, how do we quantify whether it was worth the cost?
While what you're saying is generally true, one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes.
Github Actions went down yesterday, disrupting the service for thousands of companies. They also went down today.
And yet, if they didn't have the "move fast" mindset, they probably wouldn't have Actions as a product in the first place.
> one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes.
Perhaps that's true of software engineers but I don't think it's true for Professional Engineers. That's one of the reasons I wouldn't consider most people who call themselves software engineers to be an engineer at all.
Words do evolve. That’s why I said Profession Engineer rather than just engineer. It's a relatively new title (from early 1900's) and in lots of jurisdictions it implies the person is licensed and if something they stamp fails, they can be sued for malpractice and even lose their license to practice.
What does operating locomotives have to do with making sure the thing you're building follows all the rules and has appropriate safety factors and such?
Operating trains is literally the origin of "engineer". It was a job that required significant application of accepted rules and methods to calculate acceptable speeds for cornering, hill climbing, and hill descent, especially when they were all combined. Getting outside the acceptable speed ranges could be catastrophic in every single one of those cases, and acceptable speeds could vary significantly depending on weather, train length, and train weight. The job was all about understanding how to correctly apply all the rules and control the vehicle to stay within safety factors.
There were probably earlier usages of the term too. As the article says the Civil bit came about to distinguish themselves from the older profession of Military Engineers.
> one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes
I've found the opposite to be true, especially with engineers moving from pure software to founding companies in regulated industries such as aerospace or medical devices.
Good point, though I'd say the major factor is dealing with hardware, not necessarily being regulated. You can't just push a hotfix to a million of on-premise devices with one click.
The challenge here is that many startups will ultimately fail to produce anything at the early stages. A big company/startup can spend months or even years debating the feature in question with minimal consequence.
The startups advantage is to simply be faster. A slow startup is worse off than a division in a big company.
There are plenty of details in the OP that will be missed. Those who will fail will gloss over those details, will think that some of the advice doesn't apply to them, or is "only for bigger companies". I work with people like this. I have felt the pain. To them, the idea of speed means to sacrifice quality and to skip code reviews. Moving fast is not the software engineering equivalent of using a microwave oven to cook. Speed and quality are intertwined. They won't listen, and they won't learn except through failure.
The worst is when they tell you what you want to hear during the job interview process because you are a strong candidate, then the reality is the opposite. "We invest heavily in tooling to maximize productivity per engineer", for example. You need to press them for details, don't settle for a sound bite.
I think the article has sufficient advice, that if followed, will lead to big enough improvements to be worth it.
> "I feel like one success story doesn't necessarily make it good advice for everyone else."
I don't think the problem is with the advice giver, rather the receiver.
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.
This line of thinking is not far from the type that leads to cargo cult or any other superstitious belief.
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: https://xkcd.com/1428/
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.
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.
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.
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?
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?
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
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.
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.
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.
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.