Move Fast or Die: Key Startup Lessons

The most common question I get from CEOs at early-stage companies is how to move and ship products faster. They ask me how Facebook famously created a culture that moved fast (and broke things). When you are racing against the clock of dwindling funding and competition out to kill your company, nothing will serve you better than a rapid product cycle. Here’s how we did it at Facebook.

1. We would indoctrinate a cult of speed in the first 3-4 weeks for every employee. All new hires at Facebook were required to get their dev environment setup on Day 1 and have a commit released to all users on Day 2. This is insanely fast compared to most companies, which don't have you commit any code for 2-3 weeks. The takeaway for new hires was clear: 'Holy smokes, this company moves Fast'.
2. We would celebrate the first time someone broke something. This was a public right-of-passage, like sending out a congratulatory email to all of engineering. It was important to remove any shame associated with breakage. Speed necessarily entails mistakes—the only unforgivable mistake was delay.
3. We embraced asking for forgiveness, never for permission. Let anyone touch any part of the codebase and get in there to fix a bug or build a feature. Yes, this can cause bugs. Yes, that is an acceptable tradeoff. We had a shared mythology about the times that the site went down and we all rallied together to quickly bring it back up. There were never any recriminations about who introduced the bug—just how heroic they were as part of the fixing team. (This point is a critical part of a Total Ownership mindset, which I expand on in the next section.)
4. We would celebrate and promote our most prolific engineers—not the ones who solved the hardest or most interesting problems. The organization pays a lot of attention to who you choose to recognize publicly. The relative values of quantity (aka speed) and quality are different for startups. You can shift what a team prioritizes with what you reward.
5. We invested a lot in our ability to recover quickly from failures. This took the form of testing (Chaos Monkey!), process (Incident Response Review), NOC centers (for constant monitoring) and tooling in general. Without revealing too much publicly, our TechOps team was top-notch from day one. If you accept that mistakes are going to be made, then it is vital that you are able to recover as quickly as possible.

This is by no means an exhaustive list of what Facebook did to embrace speed. The fundamental takeaway is that we were deliberate and methodical about moving fast. It was a key part of our identity as an engineering team.

These practices were all part of what I call a Total Ownership culture. Everyone must feel empowered to fix anything while safeguarding the system from descent into chaos. Easy to say. Hard to do.

Maintaining this culture amounts to three basic practices, the first of which I mentioned above but is so important it’s worth repeating:

Propagate a 'Don't ask for permission. Ask for forgiveness' mindset.

Make sure everyone knows that if they see something broken or have an idea to go ahead and make the change. Don't wait for permission. Waiting is toxic.

Don't be afraid of stepping on toes or of 'doing the exact right thing'. Don't try to figure out WHO to ask for approval. This fear of pissing someone off is the single biggest reason why companies become SLOW. Embrace your inner Nike. Just do it. Make the change.

Like all great cultural values, this is an explicit choice and does not come free. You will empower a tremendous amount of creativity. But you will also incur a number of inconsistencies, errors and potential downstream bugs. You can and should create systems for rectifying those issues quickly, but they will never be zero.

However, as a STARTUP, you should absolutely be OK with this trade-off, because you win if you move fast and die if you move slow.

Have an open method for soliciting input and ideas into product direction.

Make it a point to include bottoms-up ideas into any 'official' roadmap. Without doing so, people will quickly stop volunteering good ideas and will slip into seeking permission for action.

This is also a tradeoff. As a founder and CEO, you will have to relinquish some control over what is being worked on in order to find hidden treasures. If you can't handle losing that control, then this strategy will likely not work for you. Don't try to force it. The tradeoff isn’t worth it for everyone.

Create a culture of 'disagree and commit'.

Just because you can make changes doesn't mean that your change is always the right one. You need to be OK having your change rolled back or switched up. NO HARD FEELINGS.

This aspect is critical—people in the company should feel zero entitlement in terms of having things always go their way. There is still a chain of command. There are still product managers. There are still CEOs.

If you get this part wrong, you will have an entitled culture, which can become even worse than moving slowly. Don't be afraid to flex the chain of command. People will respect it if decisions are made quickly and communicated well.

If you get this stuff right, you will have an amazing culture that propagates ownership, is nimble and doesn't take things personally. And most importantly, you will sustainably operate a cult of speed.

Once you have committed to the cult of speed and made sure everyone has a Total Ownership mindset, a new question arises: How can you tell if your startup is moving fast enough?

This is hard enough to measure for more mature companies, but at the early-stage it can feel impossible given the lack of instrumentation, metrics, analytics, etc.. I tend to break down this question into two parts:

1. Is the team working smartly/efficiently?
2. Is the team working hard?

Is the team working smartly/efficiently?

One of the best ways to analyze this is to simply ask your team about what is holding back efficiency. High powered people LIKE to be maximally effective. They are going to have a catalog of things that they feel are holding them back. Even asking them to rate their own productivity is a huge unlock. If you have hired well, people are not going to pad the answers. At smaller startups, everyone understands that they win if the company wins. There is no career ladder to optimize for.

Here are some sample questions you can ask your team members to suss out slowdowns:

• How much time do you spend blocked on others?
• How much time do you spend trying to figure out what to work on?
• How much time do you send on low ROI activities?

There is a treasure trove of potentiality in these simple questions.

The other part of efficiency that is more on the founders to debug is systemic or team-wide issues. Examples include:

• Are people working on projects that play to their strengths? While the point of a startup is to learn new skills and pick up things as needed, it still means that you should try to play to people's strengths where possible.
• Is the team red-lining to its global detriment? A small amount of buffer/slack in the system can have a non-linear impact on productivity. Think about the difference in a day when you are completely back-to-back vs. when you have 1-2 hours free. The difference can be huge.
• Would a smaller scope of product surface area produce non-linear positive execution? Same idea as above. Often reducing a small amount of context switching can have big returns.
• Are there hidden misalignments? This is the root cause of so much lost productivity. Get people to disagree and commit! Have some forum for airing misalignments but move on after that. So important.

Is the team working hard enough?

This question doesn’t require timecards. You can intuitively tell if your team is busting or not.

My approach is to work as hard as I can and THEN to expect the same of everyone. I learned this from the best in the business (Mark, Dustin, Schrep, Drew, Arash). I will never ask the team to work harder than I do.

As a founder, you cannot be afraid of demanding a certain amount of commitment and output. If you feel bad about demanding commitment and excellence, that is a deeper issue.

One other note on commitment—it is poisonous to have even one person who isn't giving their all. The rest of the team immediately notices and it brings down morale and productivity. You can get away with it at larger companies but in a startup there is nowhere to hide.

Move fast or die slowly. Create a culture of Total Ownership. Ask for forgiveness, not permission. Figure out if your team is working smart and hard.

I learned these lessons from the most effective founders and engineering teams out there. And I work with founders everyday now to help them embrace these tenets. If you're a founder or leader at an early-stage company, embrace them or...you know.

Taking some time to figure out what to do next? Consider applying to SPC.