By Patrick Hall

To achieve ‘blitzscaling,’ you have to go against common sense

When it comes to startups, there’s growth, and then there’s ultra-rapid growth—what I like to call “blitzscaling.” Blitzscaling a company isn’t easy; if it were, everyone would do it. Like most things of value in this world, blitzscaling is contrarian. To succeed, you’ll have to violate many of the management “rules” that are designed for efficiency and risk minimization. In fact, to achieve your aggressive growth goals in the face of uncertainty and change, you need to follow a new set of rules that fly in the face of what is taught in business schools and are completely counterintuitive to accepted “best practices” of either early stage startups or classic corporate management.

Rule #1: Embrace Chaos

Annual plans. Revenue guidance. Traditional business strives for order and regularity in management, operations, and financial results. This desire for order and regularity makes sense, because it allows companies to fine-tune their approach to be as efficient as possible and gives shareholders a pleasing sense of stability. But when you’re blitzscaling, you’re explicitly choosing to sacrifice efficiency for speed, which means the traditional focus on order and regularity needs to be replaced with a unique willingness to embrace a level of chaos that would horrify most Harvard MBAs and their professors.

Yet simply throwing up your hands is unlikely to bring success; passively succumbing to chaos is not a winning strategy. Embracing chaos, on the other hand, means accepting that uncertainty exists and, therefore, taking steps to manage it. If you know you’ll make mistakes, the answer isn’t to sit back and wait for answers to find you, nor is it to charge ahead without preparation or forethought. You can still make smart decisions based on your estimate of the probabilities, even without certainty. And, perhaps most important, you can make sure that you have the ability to correct your mistakes.

Rule #2: Hire Ms. Right Now, Not Ms. Right

For most of Silicon Valley’s history, the conventional wisdom on hiring executives into a startup was to quickly bring in an executive who could scale. This meant hiring someone who had experience with much bigger organizations, the idea being that their experience would come in handy at a later stage.

Hiring someone who has been managing 1,000 people to run a 10-person company is actually counterproductive.

In today’s startup world, this rule no longer applies. The Darwinian competition is so fierce that your organization needs to be all-in on the current stage of scaling. You need managers and executives who are “just right” for the current phase of growth; after all, you won’t have to worry about that next phase if your team can’t actually get you there. Hiring someone who has been managing 1,000 people to run a 10-person company is actually counterproductive, because the skills needed to succeed during those two phases are very different.

Part of hiring Ms. Right Now also means knowing when to let someone go when the moment passes. For example, a great designer might excel at running a one-woman show but is less effective working as part of a larger design team.

Rule #3: Tolerate “Bad” Management

When blitzscaling, speed is more important than having a “well-run” organization. Under normal circumstances, you should strive for organizational coherence and stability. Chaotic, unstable organizations make employees nervous and hurt morale. But when you’re scaling up at lightning speed, you may need to reorganize the company three times in a single year or repeatedly churn through members of your management team. When your organization is growing 300 percent per year, you might have to promote people before they’re ready and then swap them out if they sink rather than swim. You don’t have time to be patient and wait for things to work out; you have to act quickly and decisively. There’s always a lot of change, and much of it isn’t voluntary. You’re simultaneously building teams and the company. In the interest of speed, you might even surprise or blindside your people to reduce the time required to make and implement important decisions.

Consider the example of PayPal. While PayPal was a great success, the company was badly managed — and I write that statement as one of its senior managers. We did a few good things, such as making sure that every employee had a clear primary job and staying focused when working on certain important projects, but for the most part, PayPal’s management was a lack of management. There were no one-on-one career development conversations with employees. There was no work done to form teams beyond simply picking who was going to belong to them.

But PayPal’s “bad” management provided a number of counterintuitive strengths while we were blitzscaling. During the critical times when PayPal was developing its business model innovations and scaling up, we found ourselves needing to navigate a series of make-or-break challenges, or as I like to call them, “Oh shit!” moments.

Oh shit, we have a fraud problem and we’re losing millions of dollars we don’t have. Oh shit, Visa says we have to change the product or they’ll shut us down. Oh shit, eBay, our most important business partner, just started its own venture to directly compete with us.

Because of our “bad” management, we didn’t have any preconceived notions of “this is what the company must look like in three years.” The chaotic nature of our management actually kept us nimble in the face of these serious, unexpected land mines. When everyone in the organization has roles that are undefined and in flux, it’s easier to say, “I know this is what you’ve been working on for the past four days, but now we’re doing something different.” The internal chaos had the effect of normalizing radical change for our people, which meant they were better able to adjust to the radical changes the outside world was throwing at us.

Rule #4: Launch a Product That Embarrasses You

It’s not that you should strive to produce a bad product. Rather, if you need to choose between getting to market quickly with an imperfect product or getting to market slowly with a “perfect” product, choose the imperfect product nearly every time. Getting to market fast allows you to start getting the feedback you need to improve it. Any product that you’ve carefully refined based on your instincts rather than real user reactions and data is likely to miss the mark and will require significant iteration anyway. Speed really matters, and launching early lets you climb the learning curve to a great product faster.

I learned this lesson the hard way when I was running my first startup, SocialNet. I didn’t want to be embarrassed by our first release, so the approach we took was to complete the entire product before we pulled back the curtain and let people sign up. This approach delayed SocialNet’s launch by a year, and when we finally did launch, we quickly realized that half the features we’d painstakingly implemented weren’t important, and half the important things that our service would be useless without were missing because we hadn’t thought of them. While there were other reasons why SocialNet failed, not launching early and iterating based on market feedback was probably the main cause of death.

After my experiences at PayPal and the success we found through rapid launches and product iteration, I was determined to launch LinkedIn as soon as possible. Our team defined a list of features that we thought were the minimum required to enter the market. Years later, Steve Blank and Eric Rieswould dub this a “minimum viable product” (MVP). For LinkedIn, the MVP included a user’s professional profile, the ability to connect to other users, a search function to find other users, and a mechanism for sending messages to friends.

Shortly before launch, we started worrying about whether LinkedIn would be useful without a critical mass of profiles. If a user logged in to LinkedIn, how could we make it useful even if none of that user’s friends had signed up yet? We decided that what was missing was a Contact Finder, a version of search that would let a LinkedIn user find potential vendors. Our engineering team estimated that it would take us a month to build this feature. We were presented with a difficult choice — delay the launch by a month, or launch without a feature that we thought might be essential to our success. Operating on the embarrassment principle, we launched without Contact Finder. And quickly we discovered a far bigger problem: Unlike users of personal social networks like Friendster, which were growing explosively as new users invited their friends to join, LinkedIn users weren’t sending any invites. Our user growth was stalled. Our baseline product was embarrassing because no one was using it! If we had delayed the launch a month to build Contact Finder, there still wouldn’t have been enough people hanging around to use it, meaning we would have lost a month building a feature that didn’t address the core problem. We estimated that we would need at least 1 million users before search (and Contact Finder) would be useful, and solving that problem was the top priority.

Based on the launch data, we focused on trying to increase virality, which is how we became the first social network to allow you to upload your address book. This feature helped LinkedIn get to a critical mass of more than 1 million user profiles, and the rest is history.

Keep in mind that you should be embarrassed by your initial release — not ashamed or indicted! The desire for speed is not an excuse to cut dangerous corners. If you trigger lawsuits or burn through your money without learning, it means you did launch too soon.

Rule #5: Let Fires Burn

At every stage of blitzscaling, there are always far more problems and issues clamoring for your attention than you have the resources to address. You might feel like a firefighter, except instead of trying to extinguish a blaze in one contained spot, you can see separate fires all around you — and you don’t have time to put out all of them. One of the ways blitzscaling entrepreneurs can stay alive is by deciding to let certain fires burn so they can focus on the fires that, if allowed to rage unchecked, really will destroy the company. My Greylock colleague Joseph Ansanelli says, “What you say no to is more important than what you say yes to.”

You can’t ignore those fires forever — they are actually dangerous and will eventually require attention, but they aren’t relevant at most points during blitzscaling, because extinguishing them doesn’t move the needle on the expected outcome.

Rule #6: Do Things That Don’t Scale (Throwaway Work)

Paul Graham, co-founder of Y Combinator, wrote a famous essay in which he advised entrepreneurs to do things that don’t scale. This advice is spot-on for young startups, but it’s even more important for blitzscaling startups.

A hack that takes a tenth of the time may be more useful than an elegantly engineered solution.

Engineers hate doing throwaway work. Not only is it wasteful, but it also offends their sense of efficiency. They are firm believers in the conventional wisdom that says it’s better to build your product right the first time so you only have to build it once. But when you’re blitzscaling, inefficiency is the rule, not the exception. To prioritize speed, you might invest less in security, write code that isn’t scalable, and wait for things to start breaking before you build QA tools and processes. It’s true that all these decisions will lead to problems later on, but you might not have a later on if you take too long to build the product. A hack that takes a tenth of the time may be more useful than an elegantly engineered solution, even if it has to be thrown away later.

Much the same logic applies to nearly every aspect of your business. You’ll often have to do things that don’t scale when it comes to sales (for example, founder Marc Benioff brought in Salesforce.com’s first customer, Blue Martini Software, by calling in a favor from its CEO, Monte Zweben), operations (Paul English listed his personal cellphone number as the original customer service line for Kayak), and so on.

Nor is the world neatly divided into “things that don’t scale” and “things that scale,” with the former smoothly — and permanently — giving way to the latter. The code or process that scales during one stage of blitzscaling may break down at the very next stage, and whatever you replace it with might not scale at first, either. Consider how the founders of Airbnb solved the problem of hosts posting poor-quality photos of their rental properties on Airbnb.com: They became the photographers. As Brian Chesky told me, “We would borrow cameras from our RISD [Rhode Island School of Design] friends in Brooklyn, then literally knock on the doors of all our hosts.”

Together, Brian and co-founder Joe Gebbia could photograph about 10 homes per day. (Co-founder Nathan Blecharczyk had to stay at the apartment that doubled as their office to make sure the site didn’t crash.) Talk about doing things that don’t scale!

As Airbnb took off, the photography function had to scale up considerably. So the founders hired photographers from Craigslist, hit up their RISD friends, and even recruited Airbnb hosts who listed photography as a hobby. By tapping these sources, the company was able to build a stable of five to 10 photographers who were paid $50 per home and tracked them using the sophisticated management tool of a spreadsheet listing photographers and their assignments.

Pretty soon, this system was overwhelmed. So they hired Ellie Thiele from Syracuse University as a summer intern and made managing photographers her full-time job. By focusing solely on managing the photography, Ellie was able to increase the number of active photographers to about 50. It was only at this point that Airbnb went to a truly scalable solution: software. Nathan wrote some code, adding two buttons to the site: one for hosts to request a photographer and the other for Ellie to trigger a payment when a photographer finished an assignment. Eventually, the founders hired Joe Zadeh as an entry-level engineer and asked him to work with Ellie to fully automate the photography process.

Airbnb worked its way through three different ways of handling photography before building any code and has rewritten the photography system multiple times since then. It wouldn’t have made sense for Airbnb to start by building a scalable automated photography system; at the point when the company began this journey, the site was receiving a mere 10 visitors per day, and the only engineering resource was Nathan Blecharczyk. Any work he did on this problem would have delayed all the other engineering work Airbnb needed to get done to grow its business. By doing things that didn’t scale, the company was able to grow despite the resource constraints and the “wasted” work of building spreadsheets that would have to be thrown away later.

Rule #7: Ignore Your Customers

The fundamental rule of customer service has long been “the customer is always right.” But for many blitzscaling companies, the key rule is “provide whatever customer service you can as long as it doesn’t slow you down—and that may mean no service!” Many blitzscaling startups will offer email support only, or no support at all, relying on users to find and help one another on discussion forums.

On an absolute scale, ignoring your customers is rarely going to be a positive. Customers like to feel heard, and ignoring them will eventually deplete your company’s supply of goodwill. But for blitzscaling companies, letting customers feel ignored is often one of the fires that’s easier for you to let burn until you have finished fighting the bigger, more deadly fires.