Move fast or die: Key startup lessons
blog.southparkcommons.com
blog.southparkcommons.com
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.
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).
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.
Come on Asana, let me change task dates and sort correctly. What kind of TODO app doesn't reliably save dates...
No.
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.
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'm sorry to go in a tangeant here, but, what? That's an incredibly strange statement to make.
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.
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.
- 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.
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..
It revealed a lot about how much FB’ers respect their colleagues’ time! Pretty gross if you ask me.
[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.
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".
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.
Toxic bullshit.
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.
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 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’.
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.
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.
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...
Typically we empower governments with restraints to prevent them from allowing those tactics, and for good reason. (Even if in reality it is imperfect).
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.
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?
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.
Not just fine... better off.
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.
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.
Few people who call themselves (non-software) engineers today are running locomotives. Words can evolve over time.
That sounds pretty dubious to me.
https://en.wikipedia.org/wiki/Smeatonian_Society_of_Civil_En...
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.
https://en.wiktionary.org/wiki/engin#Old_French
Edit: Might have heard of the term "Siege engine" as well?
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.
Heh, reminds me of this tweet: https://nitter.net/apenwarr/status/1440656518701932554 / https://twitter.com/apenwarr/status/1440656518701932554
The startups advantage is to simply be faster. A slow startup is worse off than a division in a big company.
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.
> 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.
Paul Graham said recently: https://twitter.com/paulg/status/1561566435012251648
> 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.
> 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 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.
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.
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.
That's a disgusting and idiotic assertion.
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.
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.
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.