An accomplished entrepreneur, executive, and investor, Reid Hoffman has played an integral role in building many of today’s leading consumer technology businesses. In 2003 he co-founded LinkedIn, the world’s largest professional networking service. In 2009 he joined Greylock Partners.
Part of the secret and the thing that’s great about Silicon Valley is that, while we compete intensely, we also collaborate intensely.
- Reid Hoffman
He currently serves on the boards of Airbnb, Apollo Fusion, Aurora, Coda, Convoy, Entrepreneur First, Gixo, Microsoft, Nauto, Xapo, and a few early-stage companies still in stealth. Also, he serves on many not-for-profit boards, including Kiva, Endeavor, CZI Biohub, and Do Something. He is the host of Masters of Scale, an original podcast series and the first American media program to commit to a 50-50 gender balance for featured guests.
He is the co-author of two New York Times best-selling books: The Start-Up of You and The Alliance. His new book is Blitzscaling, based on his Stanford course of the same name. He is an Aspen Institute Crown Fellow, a Marshall Scholar at Oxford, and a graduate of Stanford University.
Sarah joined Greylock Partners as an investor in 2013 and spends a lot of her time thinking about opportunities in B2B applications and infrastructure, cybersecurity, artificial intelligence, augmented reality and healthcare. She is on the board of Obsidian and also works closely with Awake, Crew, Rhumbix, and Skyhigh.
Before joining Greylock, Sarah was at Goldman Sachs, where she invested in growth-stage technology startups such as Dropbox and advised pre-IPO technology companies such as Workday (as well as public clients including Zynga, Netflix, and Nvidia). Previously, Sarah worked with Casa Systems, a venture-funded technology company that develops a software-centric networking platform for cable and mobile service providers
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.
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. We were being asked what the secret of Silicon Valley is. Because you end up with this kind of weird thing where there are around four million people in the San Francisco Bay area. That's not the tech industry at you know. That's a tiny part of that, half of the NASDAQ. Why is that?
So you end up with this okay, there's something interesting going on. And the story they were telling was kind of the 1990s story which is we have this culture that welcomes immigrants and people that come here. We have tech universities, tech companies, venture capital. We have a culture that allows some experimentation and a willingness to take risks and doesn't penalize those risks. And actually, in fact, rewards learning and taking these kinds of efforts. Then we have enough shots on goal that great things happen.
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 and we're not even including China where it's all throughout China. But 100 other places in the world at least, and maybe a lot more. So why is it that things continue to play interestingly here? I kind of said well I didn't have a term then, I said well actually 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. You're looking for the angles to do that.
As I thought about it I realized that that wasn't the meme that has been going around, but people's reflex was still to tell the old startup meme, versus the fast-scale meme. So I was like well maybe we should do a book. Then I said well let's do the easiest possible book, 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 Marissa Meyer and Brian Chesky, and Reed Hastings... All these folks to say what they did. And we'll do this and they'll drop all these gold nuggets on the floor and we'll write a book and it'll be done.
As it turned out, it ended up being a lot more work than that. I don't know if there are many Blackadder fans in the audience, but it was a cunning plan. Clearly not very many. I recommend Blackadder, too. So Rowan Atkinson in his younger years.
Then we had to do a lot of the hard work to figure out what the frameworks were, how to think about this systematically, a bunch of different things. So it was a multiyear effort to write the book.
You had this insight that there was this special thing happening in Silicon Valley that was not quite the original start-up story about our unique culture and talent, and all that. I think that's actually probably obvious to a lot of people in this room with people's global teams and everything. Then you had this class, then you're drawing on your own experience. So where did the framework start?
So the precise definition for blitzscaling is prioritizing speed over efficiency in an environment of uncertainty. And what that means is you've got to look because of competition and 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.
Observe, Orient, Decide, Act. It's fighter pilot terminology. The faster OODA loop with a fighter pilot wins, the other one dies. 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. What you do is you say well, what are the things 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 e-mail customer service.
Do 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 kinds of trends. Paypal was compounding at two to five percent per day in both users and transactions. This audience, everyone here I know is math capable so I know you understand what those kinds of exponential curves look like.
And how big was the team when this was happening?
Our team was probably about 35 people which included two customer service persons and an office manager who would pinch-hit on customer service. 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 work out as you expected, and we weren't responding to those emails because two customer service people, one office manager was now working full-time in customer service trying to stem the tsunami that was descending on our heads.
So enough people figured out that we had a phone number listed in the Palo Alto Business Directory, got that phone by calling the Palo Alto Business Directory, dial extensions at random such that seven days a week, 24-hours a day you could pick up any desk phone and talk to an angry customer. So part of what blitzscaling is 'cause 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 in terms of how to do this. So oh no, you have to work on your customer MBS and so forth and what you do, your future customer, your scale customer.
Make them all happy before you keep going, right?
Yes, make them all happy before you keep going… (of course, we did). We turned off all our desk phones. We would occasionally when we were talking with Ken and he 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 in that period.
As a recruiting tactic.
Well as a ‘this is what you need to help us with’ tactic. This is why we are moving really, really fast and we are scaling and this is the representative of that. But by the way, it's a battlefield situation. And then we went from…
“We can't build a customer service center in Silicon Valley.” to “We have to build somewhere else...”
Well, one person happened to know Omaha had a bunch of good customer service things across different companies that were there. Plus the network connectivity and the right accents and hours, and in the middle of the country, and all the rest for kind of a U.S. focused and enough languages that you could do global at least in a lightweight way. So we hashed a plan and did a set of things such that we had I think 250 reps live in six weeks. That’s part of the way we did that was we flew out a third of the company every weekend and interviewed people in groups of 20 in order to set that up. That was my first real taste of “this is changing the ruleset to play to scale fast.”
And what were you trying to get to? Did that ever slow down, was there an end in sight?
So ultimately, one question I've gotten is do you ever stop blitzscaling? And the answer is of course you do. But efficiency is a good thing, right? Eventually, you want to be efficient. You want to understand what your business model is, what your revenue versus cost to 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 efficiency. 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 awards for your business.
When you make that decision has a lot to do with competition, whether or not the competition catches what blitzscaling, where you are in the establishment, frequently network effects, the scale effects. These kinds of things in the business. So ultimately you have to turn that corner in terms of how you're doing it. But you're spending usually at least a couple of years in chaos.
That's one of those counterintuitive rules in the book, embrace chaos. Hire hire Ms. Right Now versus Ms. Right. Tolerate bad management, which by the way is not tolerating criminal management. But I also wrote a couple of articles on that, anyway.
Great, so 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 blitzscaling relevant?
Well the uncertainty is the macro arc of these companies is trying to make product-market fit. You understand your unit economics. You understand how much it costs to 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 what your competition is, too.
Well and what your competition is. But it's the 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 know what my customer acquisition cost is. I may not even really know what my business model is. I may have a couple of ideas. Oh yeah, it will work out, it will be advertised and 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 then certainties are all the things that actually, in fact, lead you to what is a very valuable business. You have a high margin structure, you have a lot of revenue, you have a lot of loyal customers that are repeat engaging. You say yeah, I have a theory about how I'm going to get there, but my theory might be very light or vague.
This sounds like a very risky strategy, right?
Yes, it's a choice by the way.
It's a soft answer.
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? 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. eBay owned a competitive product that it wanted to be all on eBay and kind of drive us off. And you had to establish a network position before they could figure out how to do that.
I gotta ask you, Reid, as an investor at Greylock in Silicon Valley, where we mostly invest in Silicon Valley-based companies, if you want to 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 of reasons. One is--
I want my fighter pilots to win.
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 how did you get... I remember from early LinkedIn days I went to go talk to Max Levchin, co-founder of Paypal, a good friend of mine. And I was so proud of myself. We were releasing every week to production.
Now, this room is like yeah, that was so 2003. 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 said oh yeah, we're releasing every hour. I'm 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 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.
So 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 U.S. and over the world. This is trying to help that evolution of entrepreneurial knowledge.
It is just generally better to spread entrepreneurial knowledge. It's one of the reasons why I ended up doing the podcast. And anyway I think that's your answer.
You obviously began to have this instinct around 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?
As I mentioned, my first thing was Paypal, but the book actually opens with an AirBnB example because it was one of the places 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 an “Oh Gosh.”
The only real way to respond to this is blitzscaling. It also shows part of the lesson that it's not just Silicon Valley that does blitzscaling. Because what had happened was, 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 do that in terms of how they're building.
There was a company called Windu which has this kind of nice, it was not designed this way but it had this nice poetic arc that Windu 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 gonna try to copy our playbook, they're gonna try to scrape all of our hosts, they're gonna try to do all of this stuff, and they've raised more money than we've ever raised. They're coming to us and saying it's fine, you can buy us for 25% of your company and that… Yeah, but what about the company culture which is really important to grow and stay solid? You just raised \$50 million and are just getting off the starting grid. You're threatening to do all of these things, you haven't actually really made progress doing it.”
And the decision was no, actually, in fact, we should move to a blitzscaling pace. That's part of the joy of working at these interesting companies that we work at here is that 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 have a learning curve explicitly learning what's new here. And that was part.
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? 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?
Smaller when they thought about it, but when you moved into it what you're doing is you're saying that “we know there is 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 two dollars out. That kind of thing that we are now going to do stuff.”
With Airbnb, it was like well I was supposed to tune in what was our exact customer acquisition model? We're actually just going to move to a critical mass and get presence in as many cities as possible. We're gonna try to up the level of engagement and kind of transaction and we know that there are fundamental other things that we're gonna need to learn along the side. Like well, how should the experience actually fully work? How should the margins, the model work?
Whereas some companies might think okay, I'm gonna grow until I hit this kind of CAC level or something, right?
Yes, correct, or what I'm really going to do is just keep going at modest marketing spend until I figure out what is the efficient way of doing CAC. Understand which categories of users you pay for and which ways. Just go for it. We're gonna go open an office in Europe and start doing a bunch of stuff in Europe and yes, we're opening an office here, why? Because we should be present, we should be doing stuff there.
And we just want to get to winning here. So you've got us convinced, we're all gonna go to our day jobs try to apply the blitzscaling framework. Where does it go bad?
Real risk always leads you to failure. For example, in the internet boom, there were 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. 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. So they may have had a theory about how that model would change with scale, but it was never apparent to me or the outside.
Web Van, like it's a capital-intensive model where it said oh, we're gonna recruit completely and… by the way, the idea has led to different ways of reinventing delivery and all the rest….
We have benefited from it but they're like we're just gonna essentially build all the infrastructure for all of this super cheap delivery. And you're like well actually the infrastructure is super expensive. So while you're in the boom and capital is free and you can spend capital for free, it's not clear how you get there. One that turned the corner and won, it's not clear that you could have taken the path 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's a huge advantage, and keep going. So you have Web Van on one side, Amazon on the other.
Right, and they maybe had to build up to a point where they actually could blitzscale. Well maybe for this audience let's turn to blitzscaling for people who are technical leaders. What specifically applies to blitzscaling here? I mean in my personal experience one of the reasons we bring great engineering leaders into our organizations at different scales is because we need management, process, accountability, predictability and the idea of just going for it. 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 doesn't fail, whether from scale or aero conditions or those kinds of things. Usually the hasty, we put it all together as fast as possible is not the recipe for that. 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? Which ones are like oops okay, that one didn't work out so well? Classic dialogue between business management and engineering is to make it simpler, make it thinner, make it apply to the business model. Do less with this in order to have scaled characteristics. Then one of the other challenges is obviously building engineering teams because some areas of function in the organization, probably most notably sales, are expected to churn people every year. Who are your top performers, bottom performers, product performers, you turn out has a way of 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. You don't want to have an error rate in hiring.
Technical talent.
Technical talent, but you still have to do that when you're kind of scaling a need. Figure out okay, that's part among many reasons marginalized systems, do agile development. Other kinds of things. Those are also partially, well how do we do iterative speed like in these parameters that's kind of like a controllable all-in process as opposed to the classic decades-old waterfall method and so forth?
Those are I think some of the adaptations may work because sometimes you just have to move at speed. And you know, all right, I understand that I'm gonna have to rebuild this and I know roughly what parameters where I'll have to start rebuilding. That's part of the reason why you have this constant dialogue because the company and the engineering function, about well how much tech debt should we get into? And then when should we start paying off the tech debt and how do we do that in this quest for establishing the company, the product, the service?
Right, and we've talked about the evolution of Facebook's attitude to this.
One of the things I obviously like all of the Master of Scale episodes. But one of the things that was particularly kind of like a delight like oh right was when I went in to interview the one-on-on with Zuckerberg which is out, I had been told well even Facebook had to get mature because they had to move. Move fast and break things to move fast to scalable infrastructure. And that's when they learned. I was like oh, okay that's interesting.
So I asked the question that way of Zuck when I was interviewing him. He was like no, no it's the same thing. I was like what? He's like yeah, yeah same thing. Like 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 the whole culture was in this kind of blitzscaling, moving fast. I was like no, no this is the same articulation. It's just a different heuristic from applying the principle for emphasizing speed.
Especially 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 these decisions quickly? Because your book is actually in huge part a management book, right?
There are different ways that you can try to speed up your OODA loop. You can speed up your decision making. Paypal was my first experience with it. So one of the ways I do it personally is I, and I do this relatively regularly. But especially when I know that I'm working in a 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 do we make? We have bandwidths 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 a gun to my head right now to 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 well wait, this is really hasty, I don't know. There are unknown questions.
But you could move forward if you had to.
You move forward if you have to. But then the next part of this is you then say okay what specifically is what I want to know? Who's specifically who I want to talk to? What are the things that are the macro things that would cause me to change this decision within my current knowledge set? 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 it cost in decisiveness for the team, our need to quickstep? I also will do this, and what's the cost of being wrong? Is this reversible as a factor of how much should I push for that time and what's the impact of that?
You could actually have the wrong answer, figure that out, and then go to the right answer faster than you could go get confidence in the right answer.
So you do all that and then you go okay, sometimes… I have time for this and that, and I should make time for that because it will be expensive otherwise. And then go figure it out. By the way, sometimes you still make decisions, you go well if I'm wrong about this it's gonna be painful. And you know, it happens.
I know we're running a little bit out of time here. And in your book, you have a bunch of rules that are not obvious, right? So rapid-fire for somebody who is an engineering leader, a CTO, or product leader, what are three of those rules that they should understand?
Well I'll start with probably one of my favorites just because it's a little sleight of hand, but it's ignore your customer. And of course, everyone goes you're ignoring your customer, are you out of your mind?!
And the answer is to 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 than 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 would be a great thing to have. If you can have it it's awesome. People love it.
But a side corollary to that is having some people really love your product versus more people really think your product is 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.
The second one is to tolerate bad management. What that means is to have an understanding that... and bad management is not criminal management. It's not the legitimate critique within the Me Too movement of saying we should not allow any of this shit to go on and you should immediately end it...
It's things like 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 practices. You should get to that at some point. In a blitzscaling circumstance, you might go well we'll do that in six months. 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 as kind of a corollary to that because this is again a little bit of the earlier question about why I wrote the book is the first one we put in there is “embrace chaos.”
That was part of the idea for the book was if any of you guys, all of you, any of you ever are in a circumstance you go wow, this is 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 uncertainty in what we're doing. We expect that they're going to have some of that and that we're going to have to drag over a landmine, re correct and everything else. And it's that understanding of that's the game we're in.
So when the culture has a tolerance of that that was one of the things that really helped Paypal is that he went got it, we understand 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've got to 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 the 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. It sounds very uncomfortable for everyone's teams, right? How do you communicate about it? How do you get them comfortable with it?
That's the reason I was saying the embrace is because part of it is to make sure people understand that this is what the experience is like, right? I literally don't know of any blitzscaling experience that doesn't have.
Like when I did my first startup social net, a friend of mine from my e-world days wrote me a note that was which I put up, welcome to our 15 minutes is the difference between exaltation and terror. Which is roughly like we're gonna win, this is gonna be awesome, oh shit we're gonna die! Within a 15 minute gap.
And it has that kind of uncertainty and kind of anxiety, part of it. But that's part of the game. So adjust to it, understand it's there, and play forward intelligently. Take intelligent risks like don't try to avoid risks. Take the smart risks. 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 “okay, and you're good with that now?”
“Yes, but I just wanted to tell you.”
I'm like yeah, this is a 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. Great, okay 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 methodology we've all built. I feel like in this audience I may be saying stuff that's 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 the game of how you're gonna win. Sometimes, by the way, that is a multi-turn pull of star. Like how much investment do I have to make to kind of test that idea?
One of the things that larger companies don't do enough of that small start-ups do as an example is simply doing the equivalent of paper testing which is build a little kind of website of saying hey, this is the thing we're offering. Then essentially doing advertising on Facebook, LinkedIn, Google, whichever just to see what the click-through rate and acceptance would be. Then when people say I like it, you say oh great we're working on it.
That kind of thing is a way to kind of figure out how valid an idea is. I don't see enough, I see it happen in start-ups. And 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 useful.
A cheaper experimentation.
Yeah, 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 would play out? Maybe you'll win some of the sub-questions.
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 in 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 is you move from kind of being a start-up and a scale-up to social infrastructure. It could be social infrastructure in communications, social infrastructure in logistics, social infrastructure in any of these number of different areas. 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 it's also in your communications plan.
So early you said well we do that absolute thinnest thing, so we just do it. We're not worried about we're having a communication-less society. I think part of it is being more proactive. So for example, usually this one is most directed at Facebook these days. Part of I think is important is to say look, yes there are legitimate challenges, filter bubbles, advertising loops that may, or engagement loops that may get to more emotional outrage, and we should do something 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 with each other. That's a good thing, and to make sure that you're doing that as well. Now there are all kinds of things that lead to why we're in the tech-lash, and it's uncomfortable. I don't think it's going to be solved any time 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.
I think this one you'll definitely have a point of view on. We're invested at Greylock in a number of companies talking some, I'd say pretty hard, long-term problems. Does this apply, does blitzscaling apply to self-driving cars or some of these other just really 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 blitzscaling. Or it can be, sometimes that's the right answer, but that's not always the right answer for blitzscaling.
I actually think of Ermson as running up a very long mountain.
Yes, exactly, Chris Ermson. So what you do is you say that we know that we need to get to a place where we're doing this accelerated, 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.
So then you say well how is it we do all of the hard systematic work such that we 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. Sometimes the plan is not oh my God we're doing all this stuff and we're all acting. We're systematically getting ready in the infrastructure and the tools, and the baseline for them being able to get it for them. And by the way, for example in the responsible blitzscaling, one of the things is so we called out oh the blood-testing company.
Theranos.
Yes, Theranos, it's funny I've now forgotten the name. Theranos, for specifically one of the risks which is, well look if you're gonna have kind of call it life impact on people, don't take those kinds of risks. Be more certain.
So, for example, you say well, are you gonna blitzscale with kind of like all right, oh well we don't really know if we're gonna reduce the number of road fatalities by 90% or not. No no no, be more certain on that. Now the mistake is going to zero. If you have a 90% reduction that's huge. We have to deal with that and legal liabilities in society and all the rest.
Let's end with a personal one then. Who are the people, I mean a lot of people look up to you, Reid. What people have been influential in your own career and how'd you meet them?
My style and my recommendation is always to think about the people that you learn from that you want multi-decade relationships with. Like people say who's your mentor? And I say well actually I have lots of mentors. Neil Bushry 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. He helped me figure out LinkedIn is both this consumer network or post-consumer network together with an enterprise business. It's like here's how to think about the enterprise. 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 Himowee, who is 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 how the engineering teams operate at scale. I was like wow, how did you do that? And learning things about that. So it's kind of you go through all of the different things.
I had Jeff Weiner at LinkedIn who was like okay here's how scaled management looks. This is the kind of thing you're doing. For example, one of the things that's uncomfortable as you get into scale management is, this is something I learned from Jeff, was by the time when you're saying something to try to get the whole company kind of 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. And I was like okay, to your team in terms of how you're doing as a measure.
It's almost like the discomfort of blitzscaling is like that's how, 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 scaled team.