Blitzscaling: The Lightning-Fast Path to Building Massively Valuable Companies

by Reid Hoffman

You see a surprising number of really well-run start-ups that have all aspects of operations completely buttoned down, HR policies in place, great sales model, thoroughly thought-through marketing plan, great interview processes, outstanding catered food, 30″ monitors for all the programmers, top tier VCs on the board—heading straight off a cliff due to not ever finding product/market fit.

Despite—or perhaps because of—the growing dominance of bits, the power of software has also made it easier to scale up atom-based businesses as well. Amazon’s retail business is heavily based in atoms—just think of all those Amazon shipping boxes piled up in your recycling bin!

While it is difficult to create a successful marketplace from a cold start, the first marketplace that does manage to achieve liquidity—the ability for buyers and sellers to quickly and efficiently find a counterparty to conduct a transaction—becomes very attractive to both sides of the market.

The best entrepreneurs don’t just follow Moore’s Law; they anticipate it. Consider Reed Hastings, the cofounder and CEO of Netflix. When he started Netflix, his long-term vision was to provide television on demand, delivered via the Internet. But back in 1997, the technology simply wasn’t ready for his vision—remember, this was during the era of dial-up Internet access.

It’s hard to find an engineering expert who would recommend fracturing your product and engineering group to work on two largely separate products, but that’s precisely what we did, despite the inefficiency and messiness.

One metaphor I use to explain this shift is to take yet another analogy from military history: the marines take the beach, the army takes the country, and the police govern the country. Marines are start-up people who are used to dealing with chaos and improvising solutions on the spot. Army soldiers are scale-up people, who know how to rapidly seize and secure territory once your forces make it off the beach. And police officers are stability people, whose job is to sustain rather than disrupt. The marines and the army can usually work together, and the army and the police can usually work together, but the marines and the police rarely work well together. As you blitzscale, you may need to find new beaches for your marines to take rather than ask them to help patrol the existing ones.

Transition from small to large teams.

Be clear that employees will get opportunities to grow and advance their careers, but this doesn’t necessarily mean that if they’re running engineering now, they’ll be VP of engineering when the company has ten thousand employees and is planning its IPO. Focus on responsibility instead of the specific title. An employee who runs the engineering “department” at the Family stage might consider it a demotion to be one of several directors of engineering at the City or Nation stage, but you can point out that at the Family stage she was managing a team of three engineers and now she oversees a team of one hundred.

Another piece that resonated well

Genius-driven design may be the only way to build a revolutionary product, but it usually needs to be supplemented with data-driven refinement.

Yes!

“The Ambidextrous Organization,” Charles A. O’Reilly III and Michael L. Tushman draw the distinction between “exploiting” and “exploring.” Mature business lines focus on incremental innovations that help them exploit a well-known market, whereas new threads focus on more radical innovations and exploring a new market opportunity.

Engineers hate doing throwaway work. Not only is it wasteful, it 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 of 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.

The classic. An effective engineering team can navigate this conflict well. At this point in time there are enough institutional knowledge and tools are available in the engineering community to achieve this. Trick is to build a vision that can evolve