As an entrepreneur, starting up is just the beginning, but scaling up is how you change the world. This Greymatter episode is a fireside chat that took place at Greyscale, an event for tech founders hosted by Greylock Partners. Chris Yeh, the co-author of The Alliance, sits down with Reid Hoffman and John Lilly to discuss how companies go from startup to scale-up. Reid, John, and Chris taught a course at Stanford centered on the theme of hypergrowth called Technology Enabled Blitz Scaling. Here they discussed some of the key themes from that class. For more podcasts, please visit news.greylock.com.
Thank you so much for being here for this panel on Blitz Scaling. I'm Chris Yeh, the co-author of The Alliance along with Reid Hoffman and Ben Casnocha. As you heard from Jerry earlier, one of the key elements of growing your enterprise companies is this notion of hypergrowth. The thing about hypergrowth is, is it just growing faster, or is there more to it? As Jerry mentioned, we taught a class at Stanford last fall called Blitz Scaling. The good news for all of you is that the materials from that class are all available online. If you go to the Greylock YouTube channel or to Medium, you can find the notes, essays, and videos from the class. But just in case you don't have 30 or 40 spare hours right now as you run your company, we're going to take about half an hour to tease out some of the major themes and things you need to think about as you're growing the company. So the first question really is, and I love the fact that we hearken back to the dot-com era, how is Blitz Scaling different from just 'get big fast,' which was something people talked a lot about during that time? By the way, one entertainment I have personally is that enterprise is also evolving because I thought, 'I'm coming to enterprise, I'm going to wear a jacket.' I look out in the audience, and I think Chris and I may be the only two blazers. But no, no, no, wait. Thank you so much anyway.
The key thing to think about is that Blitz Scaling is essentially a relative speed measure. What you decide to do is, in order to either fully realize an opportunity, react to market, or react to competitive pressure, you decide that you need to move much faster than your competitors. Essentially, you deploy capital and techniques in order to scale faster. Usually, that means people tell themselves, 'Oh, it's because I have operational excellence,' but usually it means you run somewhat inefficiently. You either hire very fast, build and reorg very fast, deal with cultural issues as you're scaling your organization. Because usually, in order to get large-scale customers or large-scale revenue at a fast clip, you also have to scale your organization at a fast clip. The sort of things we do in Silicon Valley, which is one of the reasons we build such industry-transforming companies, is to realize that opportunity, whether offensively or defensively. You essentially deploy capital and expertise in a network around you in order to scale much faster than your competitors and realize the market niche. That's essentially what Blitz Scaling is, and there's a set of different techniques around it. We won't be able to capture all the ones we had talking to people like Eric Schmidt, Reed Hastings, and others in the class, but you essentially go, 'All right, because getting first mover is actually first to scale. First out the gate doesn't really matter; it's the first scale that matters.' It particularly matters when you're either locking in key areas like a network effect in your business, key customers, or a key market position such that winning continues to accrue to the leader. One of the things that's really important in Blitz Scaling is to make a decision about whether it's time or not, because it's a lot of capital and you can misfire. You have to make a decision if it's necessary offensively or defensively. To hearken back to some of the things Jerry was saying, if you have a big wave, that's a good time to think about whether this is the right time to do it. The analogy really came from the idea of blitzkrieg in the Second World War, where Germany overran a country. Critically, what happened is that they pushed their offense way beyond their supply lines. That meant that if things had gone wrong, it would have been disastrously bad. So the thing to understand is that this is not without risks. You have to be intentional and specific about the option, but it does mean you're going to do some things that leave you very vulnerable in other ways—team, technology, or something. So it's considered. To elaborate specifically, the innovation on blitzkrieg was to carry only enough munitions for one battle. Previously, you advanced only to your supply chain. This was: you go, you get to the space, you win that battle, and that helps you win the battlefield. If you lose, you lose big. That's part of the choice. The part of the technique in the blitzkrieg was, somewhat different for companies but for the army, at the halfway point you decide whether to keep going or not, because you're all in once you keep going. A friend of mine, Bryce Roberts from OATV, tweeted one Sunday morning, 'Blitz Scaling is sometimes indistinguishable from blitz failing.' What he meant is that when you're out in the battle, people who look like they're winning may or may not be winning, so it's very hard to tell from the outside whether you're doing it in a sensible way or not.
One of the interesting things that's happened, I think Jerry highlighted in the data, is that the funding climate changed dramatically from the time we taught the course to today. So what are some of the ways that this kind of funding climate affects the concept of Blitz Scaling?
At a high level, you do need to have substantial capital in order to make the game play work. So what it does is change the landscape of which companies are going to have the option, but also whether your competitors are going to have the option. It may also mean that the actual ultimate sizes of capital you're deploying and the way you're doing it in terms of relative speed—because again, Blitz Scaling is a relative measure relative to what's happening with the opportunity and relative to what's happening in your competitive landscape—that you may be much more cautious about the choice to do it now. That doesn't mean you can raise a big pile of money and not Blitz Scale yet. In fact, that can sometimes be an intelligent way of buying optionality, buying time, and seeing it. It's the question of when you hit the gas. Ideally, you would have gotten product-market fit, identified the wave, and you're taking much more substantive risk if you don't. But sometimes you do that anyway. Sometimes in these companies, you go, 'Okay, I'm going to hit the accelerator even though I don't know that this is going to work, because I need to do it from a competitive position.'
We had a meeting with an enterprise company selling some health stuff to enterprises last night. They've spent about maybe 10 or 12 million so far, and they want to go raise 20 or 25 now. You ask them why, because they still have a fair amount of money in the bank. They said two things: we think we've figured out how to acquire customers efficiently on advertising spend through particular channels, but also we spent the last 90 days getting our first BD person in and building our pipeline. Here's what the pipeline looks like; time to close is collapsing. There are a whole bunch of triggers for them that suggest it's time to scale more quickly.
When you have capital markets available, you can actually take a much higher amount of risk. For example, when we were pouring on the juice at PayPal in the early days, which is one of a number of canonical Blitz Scaling cases, we were giving out $10 bonuses—$10 for me, $10 for John—free credit card processing, and we had no business model. Our cost line was exploding with no revenue, and yet we were hitting the gas. That's a choice, because what we felt was we had to win the eBay market beforehand. There was an incumbent owned by eBay called Billpoint, which probably no one in this room knows, but we thought we had to win that market. One of the interesting questions about Blitz Scaling boils down to people. I think it was very appropriate that Jerry talked about the number of people involved in the different stages he laid out. I'm curious: for the audience members, how many people here are at a company with 1 to 100 people? Raise your hands. How about 100 to 1,000? And over 1,000? Okay, so that gives you some sense of where we are. Yes, you may raise your hand as well. That's an interesting question, because I do think those are some critical phases along the way. How many of those people who are in the 1 to 100 phase feel like they've achieved product-market fit? Don't worry, you're not being held to this. That's very illustrative as well. The fact is that is the job of the early stages of Blitz Scaling: figuring out that product-market fit.
When it comes to the product side, which is obviously very much on the minds of the founders, how should they think about their product strategy evolving as they try to Blitz Scale? How do they think about it changing as they grow their organizations and as they achieve that product-market fit?
Everybody here is going to be going through it right now, so I think probably everybody here can answer the question in just as good a way as we can. In the early days, you're just trying to figure out what product to build that anybody cares about, and getting really strong signal that they care is a big deal. When we talk to founders, we care more about how much time they're spending with customers, how much time customers are pulling on them to get it out, and how willing customers are to deploy even when the thing is not ready yet. That's a lot of what we look at. So where's the hair on fire for our problem for customers? I think one of the things to do is to list what you think are the best hypotheses you have about what would demonstrate product-market fit and test those as aggressively as possible. Part of the test, obviously, is with customers and with actual adoption, but part of that test goes around asking people to say, 'Well, what do you think of this idea?' Because if you go to smart people and they give you a piece of feedback, sometimes one piece of feedback can be erroneous, but if you talk to 10 different smart people and they all give you a similar kind of pattern, that's a form of almost like paper testing product-market fit amongst people who are smart and thinking about markets, how customers act, and how entrepreneurs build companies. That can actually give you a faster cycle. One of the things I find is a corollary to Blitz Scaling: Silicon Valley is the only place that uses the OODA loop as part of its business decision-making. It comes from fighter pilots: observe, orient, decide, act. The faster OODA loop in a fighter pilot wins the combat. That's very similar to how Silicon Valley works. The faster you find product-market fit, the faster you identify that pattern and have compounding learnings, which essentially leads into Blitz Scaling. So you want to be focused on how your OODA loop is. When people talk about failing fast, some people idiotically generalize to 'failing is great.' No, no one's trying to fail. What they're trying to do is test these hypotheses in order to get to success faster, and that's through a faster OODA loop. One of the things you have as startups as 1 to 100 person organizations that most big companies do not have is that faster OODA loop, and you have to deploy it as your advantage. It's worth saying that this gets harder and harder as your organization gets bigger and more complex. Even adding a couple of people slows you down because you're trying to go as fast as you can as a founder or product person, and you add one or two more people, you have to explain what's in your head and what's in the customer's head, and it slows everything down. So you're trying not to Blitz Scale until you're ready to Blitz Scale, but until you're there, you want to keep the team as small as you possibly can, even though it feels like you're going agonizingly slow.
One of the interesting things that happens as companies scale is that the role of the founders changes. In many cases, founders have to be the product people at the outset, but they may not necessarily remain the product people throughout the lifetime of the company. Can you talk a little bit about that?
I think the best companies have the founder stay the product person, or at least the linkage between the product teams and the customers.
I think they stay very close to the product and have to be deeply oriented in how product connects the decisions. If you're handing off the product and saying, 'Oh, now I have a product person, now I'm doing other stuff,' that's most often a failure point. However, you do have to hire product people, that's true.
Mostly the jobs of the founder are storytelling, product definition, and then recruiting and financing. That's about it. I think it really doesn't change very much.
I think it evolves in terms of what additional competencies you need that are really key. Storytelling is part of what you mean—recruiting, fundraising, customer—it's all the same stuff. So I do think it evolves somewhat based on what your particular fits are. For example, I like product strategy and business strategy, but I don't like organization running. So my role very specifically did evolve in good ways.
I'd love to follow up on the evolution of the founder role as well, but before we leave the topic of product, I think one important through line from the class was that often as companies grow and Blitz Scale, they need to eventually make a shift from being a single-product company to a multi-product company. They have to go from a single thread to multiple threads. Can you talk a little bit about that? I think this is something the founders in this room are going to end up experiencing if they're successful.
First, given the number of people in the room that are 1 to 100, you don't move to multi-threaded until you actually have a product-market fit that's working. If you're moving to multi-threaded before that, that's usually a very high predictor of death. Think about that carefully. Now, what happens is there are a couple of reasons you might move to multi-threaded. Your first thread is working but taps out; it scales, and in order to get to the real size, you have to do a second thing, which is really difficult because it's like both running the thing that's working and getting the next thing. Most companies at that point opt to sell as opposed to keep going. But you can. Lyft and Uber both did it, moving to the UberX/Lyft model. Lyft and Uber are different; Lyft came out of the Zimride stuff, and that is actually the pure move. Uber is more of the classic set of multi-threading, where we continue to run each of them, but there's an alignment between them. The black car business was not very big until UberX changed it a lot, and it was Lyft that prompted them. It's competitive, but it's the same customer, same app, different kind of supply chain, different configuration. When you move to multi-threaded, as John's pointing out, it can either be an offensive reason for expanding customer base or share of wallet, or it can be absolutely necessary competitively. In Uber's case, it was both. There was a funny moment: Ann Miura-Ko from Floodgate was one of our speakers, and she said that some of her founders come and ask her how you know when you have product-market fit. Her answer is, 'If you have to ask, you don't have it.' Because when you have product-market fit, it's very obvious—everyone in the world is yelling at you to release, release, release.
Let's shift gears back to the role of the founder, because I think we started to touch on issues of people, culture, and hiring. One of the things we heard from the class and our guests is that so much of Blitz Scaling boils down to people issues, which in many cases founders aren't as familiar with when they go in. When you're scaling an organization fast, you have all kinds of management and cultural challenges, and you have to anticipate that you'll continue to have those. You have to try to lightly set them up in advance. Some of this comes to: when you're in a 15-person organization, most people think that as the organization grows, their role is going to grow, some other roles are going to grow, and some roles aren't. How are you going to navigate that? How do you preserve and deserve the majority of the key talent being bought in? What is the conversation you have with them? For example, when I was interviewing Sheryl Sandberg last week, one of the things I asked her about Blitz Scaling was, 'What did you learn when you were doing it?' This was at Google, because she was in charge of growing the AdWords ops and sales teams. She said, 'Well, we started and I wanted to make everyone feel special, so we celebrated when they had their birthday. Then we got to a place where we were having birthdays every day of the month, and that was too distracting for the company. So we started doing birthdays by the month, then by the quarter.' Part of what that meant was that everyone had this tangible thing of, 'Oh, this place isn't like it used to be; it used to be special.' If she were to phone her younger self, she said, 'Start at doing birthdays by the month or by the quarter,' because still being engaging but anticipating that you're going to get to that scale, so people say, 'Oh yeah, it's still the place I know and love.' That's the kind of thing when you're thinking about how you maintain your culture and grow it. I think the Netflix culture deck, and we talked to Reed Hastings a bunch about this in the course, is also a canonical thing. One of the things I've come to realize is that I think it's useful for companies that are Blitz Scaling to actually define a culture deck, because part of what that creates is horizontal accountability, not just top-down accountability. That's really key for how you're scaling an organization. Those are the kinds of things you have to look at and anticipate when you're trying to scale a company.
I think you're trying to go as fast as you can, and you're trying to pay attention to where massive communication breakdowns happen. I got to Mila when it was about 12 people, and it was going fine. But when we got to about 40 people, it was clear that we needed to have a management team meeting every week. I was not the CEO then, but we started spending a couple or three hours together on Mondays. There were times when we said, 'Do we really need this meeting?' because we weren't filling up two or three hours. Then you try to skip it a few times, and the communications would start to break down again. So just being together in a group every week was a really big help. Then we got to 70 or 80 people, and you could see we started to layer a little bit. You started to have communication issues, so we said, 'Let's have every week on Thursdays a management plus the next layer down meeting.' That was a big jolt to the system because everybody had been used to everything being basically open meetings, and this was a closed meeting. But we just needed to be able to model behavior between me and vice presidents to other people and vice versa. So I think you're looking for where catastrophic communication failures are and trying to deal with those in time, but you're trying not to over-architect the system as you go, because you realize that anything you architect now, if you're growing doubling or tripling in a year, will break in eight or 12 months anyway.
