Speed: The Most Critical Competitive Advantage with Reid Hoffman | Greymatter

This episode of Graymatter is in partnership with sfelc, a curated community of engineering leaders working to evolve the way leadership is implemented in the tech industry. At the annual SF ELC Summit, Greylock's Reid Hoffman and Sarah Gore discuss the techniques and opportunities associated with blitzscaling.

I'm excited to be here tonight. Let us talk about Blitzscaling so you guys can read the book with more context. Let's start at the very beginning, help us understand what it is.

So actually, I'll start a little bit with the story of why I wrote the book, which is I was on the stage in London with a couple of other Silicon Valley folks, and we were being asked what the secret of Silicon Valley is, because you end up with this kind of weird thing where there's Roundup, 4 million people in San Francisco Bay Area. That's not the tech industry, as you know. That's a tiny part of that half of the nasdaq. Why is that? And so you end up with this kind of like, okay, there's something interesting going on. And the story that they were telling was kind of the 1990s story, which is we have this culture that welcomes immigrants and people to come here. We have tech universities, tech companies, venture capital. We have a culture that allows some experimentation and willingness to take risks and doesn't penalize those risks, and actually, in fact, rewards learning and taking these kinds of efforts. And then we have enough shots on goal that great things happen. And the thing that's true now and has been for years, is that, by the way, that culture exists in at least 100 places outside of Silicon Valley. I'm not even including China, where it's all throughout China, but 100 other places in the world at least, and maybe a lot more. And so why is it that things continue to play interestingly here? And so I kind of said, well, I didn't have the term then, but I said, well, actually, in fact, it's the way the network brings together talents and ideas and capital and accelerates them. And you play for global scale as fast as you can and you're looking for the angles to do that. And as I thought about it, I realized that that wasn't the meme that had been going around like people's reflex was still to tell the old startup meme versus the fast scale up meme. And so it was like, well, maybe we should do a book. And then what I did is I said, well, let's do the easiest possible book we can, which is what we'll do. Is we'll host a course at Stanford. This is online. You can find it through the Greylock website and other places. I think it's on YouTube and blah, blah. And we'll get all these great leaders ranging from like Marissa Meyer and Brian Chesky and Reed Hastings and all these folks to say what they did in order to do this, and they'll drop all these gold nuggets on the floor and we'll just write a book and it'll be done. And as it turned out, it ended up being a lot more work than that. I don't know if there's many Blackadder fans in the audience, but it was a cunning plan. Clearly not very many. I recommend Blackadder to you. And so then we had to do a lot of the hard work to figure out what the frameworks were, how to think about this systematically across a bunch of different things. And so it was a multi year effort to write the book.

Okay, so you have this insight that there is this special thing happening in Silicon Valley that was not quite the original startup story about our unique culture and talent and all that. And I think that's actually probably obvious to a lot of people in this room with people's global teams and everything. And then you have this class, then you're drawing on your own experience. And so, like, where did the framework start?

So the precise definition for blitzscaling is prioritizing. So speed over efficiency. In an environment of uncertainty and because of competition, because of the need to get to a scale effect, a network effect, and that kind of density, it's super important to get there fast. And then the question is, what do you do in order to do that? How do you have differential speed? How is your OODA loop faster?

Reid, define OODA loop.

So observe, orient, decide, act. It's fighter pilot terminology. And the faster OODA loop in fighter pilot wins, the other one dies. And so you think about what your speed of an OODA loop for you yourself is and what your organization is in terms of how you're processing information decisions and what you're going forward on? And what you do is you say, well, what are the things? Like classic and kind of blitzscaling stuff is, well, what are the things that we can do such that we get to scale faster? We expand into the market very early in the first Internet boom. Things like, well, we'll only do email customer service. You want me to tell the PayPal customer service story? This is probably my first direct personal experience with this. And beginning to think about these kind of trends. So PayPal was compounding at 2% to 5% per day in both users and transactions. This audience, everyone here I know is math capable, so you understand what those kind of exponential curves look like.

And how big was the team when this was happening?

The team was probably about 35 people, which included two customer service persons and an office manager who would pinch hit on customer service. So given that we quickly were ramping to thousands of emails of customers who were angry with us with, well, my money didn't get here or the transaction didn't work or whatever. The system was good, but there's always some error rate. Things didn't quite work out as you expected. And we weren't responding to those emails because two customer service people, one office manager who was now working full time in customer service, trying to help stem the tsunami what was descending on our heads. And so enough people figured out that we had a phone number listed in the Palo Alto business directory. Get that phone number by calling the Palo Alto business directory. Dial extensions at random such that 7 days a week, 24 hours a day, you could pick up any desk phone and talk to an angry customer. And so like part of what blitzscaling is because, you know, kind of normal business wisdom. Another way of thinking about the set of lessons within the book is these are the things that Silicon Valley learns and does that aren't taught in MBA schools. Right. In terms of how to do this, so classic would, oh no, you have to work on your customer mps and so forth. And which you do, your future customer, your scale customer.

But make them all happy before you keep going, right?

Yes, make them all happy before you keep going. And instead, of course, what we did is we turned off all our desk phones. We would occasionally when we were talking to a candidate who didn't believe us, we would literally do the magic trick of going over and pulling up the desk phone which is not ringing because we turned off the ringer and say, here, talk to an angry customer. And it worked all the time because.

It was still at that period as a recruiting tactic.

Well, as a, this is what you need to help us with, right? This is why we are moving really, really fast. And we were scaling and this is the representative of it. But by the way, it's a battlefield situation. And then a set of ways which we went out and built, we said, we can't build a customer service center in Silicon Valley, we have to build somewhere else. Well, one person happened to know Omaha had a bunch of good customer service thing across different companies that Was there plus the network connectivity and the right accents and hours in the middle of the country and all the rest for kind of a US focus and not enough languages that you could do global, at least in a lightweight. And so we hashed a plan and did a set of things such that we had a. I think it was 250 reps live in six weeks. But part of the way we did that is we flew out a third of the company every weekend and interviewed people in groups of 20 in order to set that up. So that was my first real taste of this is changing the rule set to play to scale fast.

And what were you trying to get to? Like, when did that ever slow down? Was there an end in sight?

Well, so like one question I've gotten is, do you ever stop blitzscaling? And the answer is, of course you do. Efficiency is a good thing, right? Eventually you want to be efficient. You want to understand what your business model is, what your revenue vs. Cost of customer acquisition and a bunch of other things that you might be saying, we'll figure those out later when we're blitzscaling, even though we're deploying tons of capital, hiring lots of people, doubling our organization every three months, six months, 12 months. So you eventually want to tune to a very good business, you want to get back to efficient and you want to be efficiently onboarding people. You want to be working in a way that you understand how your capital investment is getting specific rewards for your business when you make that decision has a lot to do with competition. Whether or not the competition catch you with blitzscaling where you are in the establishment, frequently network effects or scale effects, these kinds of things in the business. And so you have to turn that corner in terms of how you're doing it. But you're spending usually at least a couple years in chaos. There's counterintuitive rules in the book. Embrace chaos. Hire Ms. Right now versus Ms. Right. Tolerate bad management, which by the way is not tolerate criminal management. We also wrote a couple of articles on that. Anyway, great.

If we just scroll back to prioritizing speed over efficiency in the face of uncertainty. I don't know about you guys, but I feel like anything in one of my companies is always uncertain. Right. So what is the kind of uncertainty that makes scaling relevant?

Well, the uncertainty is the macro arc of these companies is trying to like for example, you get product market fit, you understand your unit economics, you understand how much it costs customers and acquire customers in various ways, what your long term value is of the different set of analytic customers, how it all plays into a scaling system and you understand.

And what your competition is doing.

Well, I know what your competition is, but it's that very long arc. That's the kind of system you're building with a company. Frequently in blitzscaling, you're saying, well, I actually don't really know what my customer acquisition cost is. I may not even really know what my business model is. I may have a couple ideas. I say, oh yeah, it'll work out. It'll be advertising, we'll do something. That kind of thing might be part of what you're doing. You might say, look, we really just need to be in every market. We need to actually have market share and everything else we'll figure out as we go. Those are the kinds of things and the uncertainties are all the things that actually in fact lead you to what is a very valuable business. Like, you have a high margin structure, you have a lot of revenue, you have a lot of loyal customers that are repeat engaging, all that kind of stuff. You say, yeah, I got a theory about how I'm going to get there. But my theory may be very light or vague.

It sounds like a very risky strategy, right?

Yes, it's a choice, by the way.

This is a soft answer.

Yeah, it's a choice of. But usually it's a choice of which risk is bigger. Is going blitzscaling bigger or is not blitzscaling bigger? And so, for example, most often when you look at the field, if your competitor is blitzscaling and you're not, you're losing. They may lose too, but you are losing more, certainly.

Or if you're PayPal and you've captured lightning in a bottle and you've got this one chance to get to adoption.

We have to get to scale. Right. EBay owned a competitive product that it wanted to be all on ebay and to kind of drive us off, and you had to establish your network position before they could figure out how to do that.

So I gotta ask you, Reid, as an investor at Greylock in Silicon Valley, where we like mostly invest in Silicon Valley based companies, why, if you want to go discover the secret to what makes these companies great and huge, why go share it with the rest of the world? In your book, we could just. In this room.

Well, a couple reasons. So one is that I think we're actually.

I want my fighter pilots to win.

Yes, well, yes. But by the way, part of the secret and the thing that's great about Silicon Valley is events like this because while we Compete intensely. We also collaborate intensely. We say, well, you know, how did you get, like, I remember from early LinkedIn days, I went to go talk to Max Levchin, you know, co founder of PayPal, good friend of mine, and I was like, I was so proud of myself. We were releasing every week to production. Now this room is like, yeah, that was so 2003. Yeah, right, right. But we were really proud of ourselves. And Max was like, oh, that's good. Yeah, you're doing good. I'm like, okay. He's like, oh, yeah. We're releasing every hour. Like, how do you do that? What's the way you're running engineering? What does the test environment look like? How does this play to make that happen? And that's the kind of way that we actually, in fact, get better here. Because, yes, company X is intensely competing with companies Y and Z, but we're actually outside of that. We're all trying to learn how to move faster, how to do this better and that kind of thing. I think that's part of what makes Silicon Valley special, is this ability to do that. Now. I think it's also better for the world and ultimately better for us. In the same way, the more strong places like Silicon Valley we have, both within the US and over through the world. And so this is trying to help that evolution of entrepreneurial knowledge. Like, it's just generally better to spread entrepreneurial knowledge. That's one of the reasons why I ended up doing the podcast.

So you, obviously, you began to have this instinct around, like, how to get a company to importance in these environments at PayPal and LinkedIn. What about in your portfolio? What have you learned from them?

So, as I mentioned, my first thing was PayPal, but the book actually opens with an Airbnb example because it was one of the places where it was long before I started writing the book, long before I started doing the podcast. But we got the kind of classic call to arms that happens with a. Oh, gosh. The only real way to respond to this is Blitzscaling. It shows part of the lesson that it's not just Silicon Valley that does Blitzscaling. Because what happened is there was this outfit called Rocket Internet, whose model was to look at mostly Silicon Valley, about companies that were here, and then try to build the Europe version very fast, very strong, and operate with all the same kind of rules that we have learned in Blitzscaling. And to do that in terms of how they're building, it was a company called Windu, which had this kind of nice. It was not Designed this way, but this nice poetic arc that Wimdo kind of shut down around the launch of the book Blitzscaling, which was this arc about how Airbnb went, oh, my gosh, they just funded this competitor in Europe, which is our primary market, where all of our revenue comes from. Not all, but 80%, lots. And they're going to try to copy our playbook, they're going to try to scrape all of our hosts, they're going to try to do all this stuff, and they've raised more money than we've ever raised, and they're coming to us and saying, it's fine, you can buy us for 25% of your company and that'll be working. We're like, yeah, but what about the company culture, which is really important to grow and stay solid? You just raised the $50 million. You're just getting off the starting grid. You're threatening to do all these things. You're having actually really made progress doing it. And the decision was, no, actually, in fact, we should move to a Blitzscaling pace. And that's part of the joy of working at these interesting companies that we work at here, is that it's like, how do you then figure out how to do that? Each journey to scale has its own unique elements. One of the things for the founders and executive teams and everyone in the company is to, say, have a learning curve, explicitly learning what's new here. And that was part of the pitch.

So if we think about Airbnb, which has progressed a lot since then, Blitzscaling from them fighting Windu is very different than many would argue. They're still Blitzscaling today. Right. And so in your book, you talk about how this applies at different scales of company and how you need to change your management. How should Airbnb or anybody at that scale think about it?

Well, so everyone was much smaller when they thought about it. But when you move into it, what you're doing is you're saying, we know that there's a bunch of things that are a standard part of building companies, of understanding the numbers of the system, of tuning it, of learning it, how you put a dollar in, you get $2 out, that kind of thing that we are now going to do. Stuff like with Airbnb, it was like, okay, well, as opposed to tuning what is our exact customer acquisition model, we're actually just going to move to critical mass and presence in as many cities as possible. We're going to try to up the level of engagement and kind of transaction. And we know that there's fundamental other things that we're going to need to learn alongside about. Like, well, how should the experience actually fully work? How should the margins and the model work? And that kind of.

Whereas some companies might think like, okay, I'm going to grow until I hit this sort of CAC level or something. Something.

Yes, exactly. Or what I'm really going to do is just keep going at a modest marketing spend until I figure out what is the efficient way of doing cac. Understand which categories of users you pay for in which ways, you know, that kind of thing. No, we just go for it. Like we're going to go open an office in Europe and start doing a bunch of stuff in Europe. And yes, we're opening an office in Europe. Why? Well, because we should, like, we should be present, we should be doing stuff.

There and we just want to get to winning your.

Yes.

Okay, so you've got us convinced we're all going to go and in our day jobs try to apply the blitzscaling framework. Where does it go bad?

So risk, real risk, always leads you to failure. And you know, for example, in the Internet boom, there's lots of examples of it. My personal favorite was a company which maybe some people here remember all Advantage, which basically would pay a dollar to give out 90 cents. And so then you scale it and that's a perfect thing to lose 10 cents on everything as a scaling thing, you make it up in volume. And they may have had a theory about how that model would change with scale, but it was never apparent to me or the outside in a webvan like this capital intensive model where said, oh, we're going to completely. And by the way, of course the ideas have led to different ways of reinventing delivery and all the rest and we benefited from it. But they're like, we're just going to essentially build all the infrastructure for all of this super cheap delivery. And you're like, well actually the infrastructure is super expensive. And so while you're in the boom and capital is free and you can spend capital for free, it's not clear you get there now one that turned the corner and won. It's not clear that you could have taken the path that Amazon took to get where it was unless it had a massive period of free capital. But it did that got the infrastructure. Now the infrastructure is a huge advantage and then kept going. So you have webvan on one side, Amazon on the other.

Right. They maybe had to build up to a point where they actually could blitzscale, right? Well, maybe for this audience, let's turn to blitzscaling. For people who are technical leaders, what specifically applies about blitzscaling here? I mean, in my personal experience, one of the reasons we bring great engineering leaders into organizations at different scales is because we need management process, accountability, predictability and the idea of just going for it. So is that opposed?

Well, it's always challenging from an engineering context on at least two levels. One is you're trying to build systems that don't break, that don't fail, whether it's from scale or aero conditions or other kinds of things. And usually the we put it all together as fast as possible is not usually the recipe for that. And so part of, I think what happens is people learn. How do you do tooling to try to make it more effective? How do you rebuild systems quickly and deal with that? How do you identify which things are really critical that you really try to make sure you don't, and which ones are like, oops, okay, that one didn't work out so well. Classic dialogue between kind of business management and engineering is look, make it simpler, make it thinner, make it apply to the business model, do less with this in order to have scale characteristics. And then one of the other challenges, obviously building engineering teams because some areas of function in the organization, probably most notably sales, are expected to churn people every year, like, who are your top performers, bottom performers, production out as the way you're working it, engineering, generally speaking, you'd actually prefer all these people who have this deep specific knowledge and built the system stay as long as possible, that you don't want to have error rate in, in hiring technical talent. Technical talent, but you still have to do that when you're kind of scaling and you figure out like, okay, among many reasons, kind of modularize systems, do agile development, other kinds of things. Those are also partially like, ok, well how do we do iterative speed in these parameters? That is kind of a controllable development process as opposed to the classic decades old waterfall method and so forth. Those are, I think some of the adaptations to make it work. Because sometimes you just have to move at speed. And you know, all right, I understand that I'm going to have to rebuild this and I know roughly what parameters where I'll have to start rebuilding. And that's part of the reason why you have this kind of constant dialogue between the company and the engineering function about like, well, how much tech debt should we get into, right? And then when should we start paying off the tech debt and how do we do that in this quest Tour, establishing the company, the product, the service. Right.

And we've talked about the evolution of Facebook's attitude to this.

Yes, I obviously like all of the Masters of scale episodes, but one of the things that was particularly delight, kind of like, oh, right. When I went in to interview the one on one with Zuckerberg, which is out, I had been told, well, even Facebook had to get mature because they had to move from move fast and break things to move fast with scalable infrastructure. And that's when they learned. And I was like, oh, okay, that's interesting. And so I asked the question that way of Zuck when I was interviewing him, and he was like, no, no, it's the same thing. I was like, what? He was like, yeah, yeah, same thing. The whole idea is emphasizing speed. Now, when you're young and you're early, move fast and break things is the way to have the heuristic of emphasizing speed, because you're really not moving fast enough unless you're breaking some things. But as you get big and have a bunch of systems and have a bunch of customers, if you break things, that slows you down more. So you need to have a scalable infrastructure. So you're still moving fast, you're still experimenting. You still have this entire kind of set of tooling and test harness. So you can run lots of experiments, see which of them work and don't work, but you're doing it within not breaking the scalable infrastructure, because if you break that infrastructure, you're actually going to be net moving slower. So it's the same principle. I was like, of course I knew that the whole culture was in this kind of blitzscaling, moving fast. And I was like, no, no. This is the same articulation. It's just a different heuristic for applying the principle for emphasizing speed, especially at a crazy scale. Yes.

So if you're making these iterative decisions and you don't have full data to make any of them, and you work with an opinionated team who you value, for example, engineers.

How do you make engineers never have opinions?

How do you make these decisions quickly? Because your book is actually in huge part a management book. Right.

There's different ways that you can try to speed up your OODA loop, you can speed up your decisioning. PayPal was my first experience with it. And so one of the ways I do it personally, and I do this relatively regularly, but especially when I know that I'm working in, in a kind of quick step, which is when I'm confronted with any decision including difficult ones like, oh, should we hire this person or should we try this business model? Or which of these three products we have bandwidth for doing one of them? Which of these three products should we experiment with in order to make this work? While I'm sitting there, I actually make a provisional decision. I go, if I had to make the decision, you held the gun in my head right now and said decide, then this would be the decision. That's always by the way, emotionally and psychologically makes you, well, almost always makes you uncomfortable because you're like, oh, but wait, this is really hasty. I don't know. There's unknown questions, but you could move.

Forward if you had to.

But you move forward, you have to. But then the next part of this is you then say, okay, what specifically would I want to know? Who specifically would I want to talk to? What are the macro things that would cause me to change this decision within my current knowledge set? Now there's always the unknown unknowns, but the current knowledge set that would do that. And then what would it cost to go do that? What would that cost in time? What would that cost in decisiveness for the team or a need to quick step? I also will do this. And what's the cost of being wrong? Is this reversible as kind of, as a factor of how much should I push for that time and what's the impact of that? And then you bring, you mean because.

You could actually have the wrong answer, figure that out and then go to the right answer faster than you can go get really confident it's the right answer. Exactly.

And so you do all that and sometimes you go, oh, I have time for this and that and I should make time for that because it'll be expensive otherwise. And then go figure it out. And by the way, sometimes you still make decisions. You go, well, if we're wrong about this, it's going to be painful and it happens.

Okay, I know we're running a little bit out of time here. In your book you have a bunch of rules that are non obvious, right? And so like rapid fire. For somebody who is an engineering leader, a cto, a product leader, like what are three of those rules that they should understand?

Well, I'll start with one of my favorites. Just because it's slight of hand deceptive, but it's ignore your customer and of course everyone, you're ignoring your customer. Are you out of your mind? And the answer is ignore your current customer for your scale customer. It doesn't mean don't get as much data. Try to figure out your scale customer as much as you can. Your current customer may be the right lens into your scale customer, but like the PayPal example, you're not actually, in fact, trying to make sure that absolutely everybody who uses your product or service right now gives you the perfect NPS score. That'd be a great thing to have if you can have it. It's awesome. You know, people loving it. By the way, a side corollary to that is having some people really love your product versus more people kind of think your product's kind of okay. That's a better trade to have a more passionate group that's less of the blitzscaling thing. Just a comment on that specific one. Second one is to tolerate bad management. What that means is have an understanding that. And bad management is not criminal management. It's not the legitimate critique within the MeToo movement of saying, we should not allow any of this shit to go on and you should immediately end it. It's things like, well, look, should you have regular one on ones every week, every two weeks and make sure, like, hey, how's your career going? And what are you doing? Those are good management practice. You should get to that at some point. In a blitzscaling circumstance, you might go, well, we'll do that in six months. Like, we'll get to it. Right now all we're doing is solving problems. And that's what I mean by tolerate bad management. And then there's kind of a corollary to that because this is again, a little bit of your earlier question about write the book is the first one we put in there was embrace chaos. And that was like. Part of the idea for the book was, if you guys, any of you, and all of you or whatever are in a circumstance, you're going, wow, this is really chaotic. We really have to do this. Part of it is the company goes, oh, right. Some chaos in communication, some chaos in decision making, some chaos in a certainty of what we're doing. We expect that they're going to have some of that and that we're going to have to, like, sometimes drive over landmine, recorrect and everything else. And it's that understanding of that's the game we're in. And so it's when the culture has tolerance of that. That was one of the things that really helped PayPal is that people went, got it. We understand that we're in that game and we're keeping rowing forward in one direction really, really hard, even though we're kind of like, oh, yeah, we know we need to solve that problem at some point.

Okay, then I gotta ask you one last question on that, which is like, okay, let's say we are making these decisions as leaders and we're moving in that direction and we're moving fast and we've got that goal of the breakout scale or penetration in an area or whatever it is. This sounds very uncomfortable for everyone's teams, right? Like, how do you communicate about it? How do you get them comfortable with it?

Well, so, I mean, that's the reason I was saying the embrace chaos is part of it is to make sure that people understand that this is what the experience is like.

Okay, Right, Yeah.

And I literally don't know of any blitzscaling experience that doesn't have the. When I did my first startup, SocialNet, a friend of mine from my eWorld days wrote me a note which I put up for all SocialNet. Welcome to where 15 minutes is the difference between exaltation and terror, which is roughly like, we're going to win. This is going to be awesome. Oh, shit, we're going to die with 15 minute gap. And that has that kind of uncertainty and anxiety part of it. But that's part of the game. And so adjust to it, understand it's there and play forward intelligently. Take intelligent risks. Like, don't try to avoid risks. Take the risks that are smart. And smart doesn't mean there's zero chance of failure. Smart means it's a worthwhile risk to take that if it works, you've changed the game.

I have a founder that calls me about once a week and the conversation goes something like, everything is breaking. And I'm like, okay, good. Are you growing? Yes, but everything is breaking. Are you still moving in the direction of feeling better about it breaking? Yes, but everything is breaking. I'm like, ok. And you're good with that now? Yes, but I just wanted to tell you, I'm like, yeah, this is very healthy conversation. So you're saying get personally comfortable with that and then figure out how to communicate it in terms of everything is breaking. But we've got a goal.

Yes.

Great. I think we should do questions from the audience. So I just pick off this list now. Great. So this is a good one. How do you think about product development when scaling so fast and how to validate feature ideas, finding fit.

A lot of this here is pretty common within the kind of methodologies we've all built. And so I feel like in this audience I may be saying stuff that's like repetitive to you, but It's a high bias towards experimentalism. It's not all experiments because you have to have coherent ideas, a theory of how you're going to win. Sometimes, by the way, that is a multi turn polestar. Like how much investment do I have to make in order to kind of test that idea? Like one of the things that larger companies don't do enough of, that small startups do, as an example, is simply doing the equivalent of paper testing, which is build a little website saying hey, this is the thing we're offering. And then essentially doing advertising on Facebook, LinkedIn, Google, whichever, to see what the click through rate and acceptance would be. And then people say oh yeah, I'd like it and say, oh great, we're working on it. And that kind of thing is a way to kind of figure out how to validate ideas. I don't see enough. I see it happen in startups, in the larger companies. I don't see product groups doing that as much as they should. So that would be the thing that I would say for at least some product groups.

That's probably a useful tip of cheaper experimentation.

Let's figure out, how would you get an experiment that would give you evidence, not proof, but evidence about is this a good idea, is this not a good idea, what's the way that we play out? And maybe even some of the sub questions depending.

So here's a question that is, is this a good idea, is this not a good idea? How does the concept of blitzscaling account for changing cultural perceptions of Silicon Valley and perceived obsession with speed over accountability?

We are definitely in the tech lash part of the thing that I broadly think, and by the way, part of writing the book is we also have a chapter on responsible blitzscaling which risks you should actually start trying to invest in and understand earlier how the framework of thinking about that. But I think also what happens as you move from kind of being a startup and a scale up to social infrastructure? It could be social infrastructure and communications, social infrastructure and logistics, social infrastructure and any of these number of different areas. And so I think the ultimate thing is you start needing to think of society as a customer too. And once you begin to move that that needs to be something that is in your product plan, but is also in your communications plan. So like early you say, well, we do the absolute thinnest thing, so we just do it. We're not worried about, we're having a communication with society. I think part of it is being more proactive. So for example, usually this one is most directed at Facebook these days. And part of I think is important is to say, look, yes, there are these legitimate challenges, filter bubbles, advertising loops or engagement loops that may get to more emotional outrage. And we should do some stuff about that. We understand it, we're working on it, but also we're trying to make the world more open and connected. We're trying to make people easily able to share emotional experiences, communicate with each other. That's a good thing. And to make sure that you're doing that as well. Now, there's all kinds of things that lead to why we're in the tech clash and it's uncomfortable and I don't think it's going to be solved anytime soon. From a succeed as a company point of view, if you slow down and your competitor doesn't, well, that's difficult for you.

So I think this one you'll definitely have a point of view on. We're invested at Greylock in a number of companies tackling some pretty hard long term problems. So does blitzscaling apply to self driving cars or some of these other just very ambitious, deeply technical problems?

It does. But one of the key things to think about this is that it's not like you just start all running crazy, yelling, waving your swords down the hill. That's not blitzkaling, or can be. Sometimes that's the right answer, but that's not always the right answer for blitzscaling.

I actually think of Urmson as running up a very long mountain.

Exactly. Christian Urmson, Aurora and so what you do is you say, we know that we need to get to this place where we're doing this accelerating compounding curve. We know we need to get into that compounding curve substantially earlier than the competitive threats. But that sometimes isn't next month, sometimes that's two years from now. And so then say, well, how is it we do all of the hard systematic work such that we can get into that, we get into that and we win that when it goes into that J curve and we can do the blitzscaling then. And sometimes the plan is not, oh yeah, oh my God, we're doing all this stuff and we're like systematically getting ready in the infrastructure and the tools and the baseline for then being able to get in there. And by the way, like for example, in the responsible blitzscaling, we called out the blood testing company Theranos. Yeah, Theranos. It's funny, I've now forgotten the name the Theranos for specifically one of the risks, which is, well, look, if you're going to have kind of call it life impact on people. Don't take those kinds of risks. Be more certain. So like for example, you say, well, are you going to blitzscale with. All right, well, you know, we don't really know if we're going to reduce the number of road fatalities by 90% or not. No, no, no, no. Be more certain on that. Now the mistake is going to zero. If you have a 90% reduction, that's huge right now. We have to deal with that in legal liabilities, in society and all the rest.

Let's end with a personal one then. A lot of people look up to you, Reid. What people have been influential in your own career and how did you meet them?

So my style and my recommendation is always to think about the people that you learn from that you want multi decade relationships with. And so people say, who's your mentor? And I say, well, I actually have lots of mentors. Anil Busri, when it comes to enterprise software and how to think about how enterprise is different than consumer, was hugely helpful and he helped me. Yes, exactly. And he helped me figure out LinkedIn is both this consumer network or prosumer network together with an enterprise business. Here's how to think about the enterprise side of that. I'm like, oh, that's interesting. Take notes. Kevin Scott, who's the CTO of Microsoft, literally when we hired him, which is very far along the LinkedIn journey, I got this email from Omar Hammoui, whoever liked, who's a partner at Sequoia, who said, you don't know how lucky you are. And he taught me how you can actually substantially upgrade the culture, the quality, not just the code, but of how the engineering teams operate at scale. And I was like, wow, how did you do that? And learning things about that. So, so it's kind of you go through all of the different things. I had Jeff Weiner at LinkedIn who was like, okay, here is how scale management looks. This is the kind of thing you're doing. For example, one of the things that's uncomfortable as you're getting to scale management, this was something I learned from Jeff was by the time when you're saying something to try to get the whole company oriented in that direction, that you're so sick of it that you literally cannot hear yourself say it again. Maybe you've said it enough, right? And it was like, okay to your team in terms of how you're doing. And so as like a measure, it's almost like the discomfort in blitzscaling. It's like you can't say it once and presume it all sticks. You have to say it, maybe in different ways. You have to keep yourself fresh about it, but you have to keep on that message. And that's how you lead. In fact, when you're doing a scale team.