- [Reid] It is my great privilege that we have Eric Schmidt with us today. Actually, on the topic of blitzscaling, there is nobody higher in the world that I would like to talk to
about this subject than Eric. He has literally done it in
the most serious ways possible, He thinks about these things
in theoretical and deep ways, and actually teaches his own
class on entrepreneurship and everything else. So, it is with great pleasure,
why don't we welcome Eric. (applause) And then kick it off. I don't know if everyone
knows that you had a kind of a substantive
career before Google, since they all know about
your career at Google. First at Sun doing very
hardcore tech stuff, and then Novell. What did you learn from those two gigs that you took with you to Google, that was really helpful
and essential for Google? - First, thank you for having me. and obviously I support what you're trying to do with Stanford. in fact, all of your activities and there's nobody I work
with who's more clever and insightful on most of
these issues than Reid Hoffman. It's interesting that
yesterday I went to visit my old boss when I worked at Xerox Park, whose name is Bob Taylor. And to talk to somebody
who is the person who funded the ARPANET, and
ask him how did he do that, and the person who conceived
the personal computer and who did he work with,
gives you a reminder of both the extraordinary
and the awesome things that have happened in our industry, and also, frankly, how old I am. That's sort of my conclusion. My history is I'm a computer
scientist at PC from Berkeley, but I've been around
here for almost 40 years. After working at Xerox
Park, I went to Sun. And one of my sort of rules
as a first young manager is as a young manager,
you absorb everything. So, my manager at Xerox, Bob Taylor, had a particular management style which I now realize, 40 years
later, is kind of like mine in the way I approach things. My first impressions
of being a Sun manager and the way Sun worked I think colored the next 30 years of development. One of the things to remember is that the next five or
10 years of your careers is in fact crucial because that's when you learn
all this shit, right? And sort of where you
are and the people you, the sort of subtle things
that make leadership happen are learned during that period, which was a surprise to me. So at Sun, Sun was both very tumultuous, very political, and very complicated. There were many, many
good things that I learned and I also learned some real negatives. One of the things I learned negatively is that companies can
reorganize prematurely. Companies can become religious. Companies can not react to actual facts. The low point in my time at Sun was we had a meeting where we were looking at Sun computers versus PCs and we concluded we could not
get our manufacturing costs equal to that of PCs. Now, by the way, that's a
signal that you should quit, because I failed to answer
the question I advocate now which is, "What does the
next five years look like?" One of the sort of things we talk about in my other class in the MBA school is ask the five-year question. I learned that sort of
the hard way becuase for most of my life, the
answers were given to me or they were highly narrow. So now I ask, "What's gonna
happen the next five years?" and I learn down. So, after 14 years at Sun,
lots of politics and so forth, I did the Java maneuver
which we can talk about if you're interested, I went to Novell under the mistaken idea
that I wanted to be a CEO and I failed to do any due diligence. Had I done the due diligence,
I wouldn't have taken the job and therefore I would
not have gone to Google, so it's probably good I
didn't do the due diligence. At Novell, there was a
week which we remember, my colleague and I who had joined with me, was the worst week ever. Our basic goal was to
get out of this with our professional reputations
intact and not in jail. And that's, after you join
a company, you discover the books are cooked, and
the people are frauds, and the customers aren't
paying, and so forth and so on. In hindsight, what I
learned is that you can actually overcome that. The skills I developed at Novell, in fact, allowed us to do things at Google. So, what happened when
I showed up at Google, to make a long story short there, was that the company's very
interesting, very innovative, but because I'd had such
a tough time at Novell, I understood the role of cash. So we did everything we
could to run the company for revenue, and the rest is history. - Is there anything other
than maybe telling yourself to maybe one time not do due diligence, but other times do it,
for the obvious thing of getting to Google, if you go
back to your younger self, is there anything you
would have told yourself to do differently pre-Google? - I think all answers of
that category in our industry are to do things that you did sooner, and to make fewer mistakes. In hindsight, I would always have made the right decision faster and I would have made fewer mistakes. I wonder what is it that causes me to not make the decisions quickly, and, by the way, I continue
to have this problem. It may just be that some people are quicker decision-makers than others. It's not obvious that you have to make all the decisions
quickly, but in hindsight, you would judge them all that way. And every executive and
every business class and every management class
will say the same thing which is, "I should've fixed this earlier. I should've fired this person sooner. I should have cleaned that
up earlier," and so forth. And that's why businesses
are not like the government where none of that ever happens. (laughter) - Or very little.
- Yeah. - So let's go to Google. What was the employee size
when you joined Google? - About 150. I should tell you this story about Google. Larry and Sergey had to take in funding, $25 million, from two
venture capitalists who-- thank you very much, Peter. This, by the way,
delivering the Diet Coke is Peter Wendell, my co-professor,
thank you very much Peter, in my business school class
who's joining us for a minute, and we hope to steal all of your best ideas for our class,
Reid, so we're clear. That's why we're here, so we're clear. - [Reid] With pleasure and honor. - So what happened was,
the venture guys had said, "These two young men are
brilliant, crazy, and unreliable and they need a proper CEO." So the two young men agreed to hire a CEO as long as they could vet them. And so their vetting algorithm was they had to spend a weekend
with the two of them. So each candidate would do
something for the weekend. The took some of them
skiing, some of them boating, some of them go to the various farms. They went to New York once
with somebody, and so forth. This guaranteed no one
was gonna get hired. I was eventually called
by John Doerr and I said, "Well, I'm really not gonna do that," but in turns out we met and it
pretty obvious we agreed. I made a list of things they had to fix. They had to fix them
and the rest happened. What's interesting about
Larry and Sergey is that they had both been here and they had the same professor 18 years later, so we're far more similar
than we'd like to admit. Similar backgrounds. We have a question. - [Student 1] I was just
wondering if you could remember some of the things that were on the list. - I have the list,
because I save everything. Remember, this is Google. (laughter) You know, when you think
about a small company, almost all of them have the property that they're full of energy and no process. And they get to the
point where Google was at by just sheer force of energy, hard work, and figuring stuff out. So, my list was pretty straightforward: International expansion plans; sales plans; hiring plans; "Is the money real?" proper accounting; "Do you understand where
your inventory is?" in this case, Google didn't have any; development plans; 18-month product plans, none of which existed. The first meeting I was in at Google, it was like being in graduate
school at a university, full of very interesting conversations without deadlines or deliverables
was sort of the style. Much of the Google culture
was developed out of the graduate school of Stanford. In other words, the offices
have four people in it because that was the office
that Larry and Sergey had. It felt very much like that. It turns out that with
that kind of raw material, all you have to do is ask
questions, like "what's the plan?" They go, "Ohh," then an answer comes out. It's not that they haven't
though- well, it is. If you push them, they can develop a plan. It's just they didn't
think it was important. It was more interesting
to talk about this, and that's where the raw talent matters. - Just as an elaboration on that, what advice would you give- how does the partnership
between young, ambitious, highly-talented, super-smart founders and new people coming in? What were the key things to
make that work really well? - I was well aware of the
John Sculley/Steve Jobs story, and you all are too young
to have lived through it, but the fact of the matter is that Jobs needed someone to be the CEO. The board picked Sculley.
The two had a fight. Sculley went to the board. The
board had to support the CEO. Because if they don't, the CEO quits. And the rest happened.
Eventually, Steve left. Formed a company called
Next, and as you know, he very cleverly ultimately
got himself acquired, and then within a month or two, got the CEO who acquired him fired and replaced the entire board. By the way, that's a Steve Jobs moment. That's very hard to do,
certainly for you and I. That's like an amazing
achievement in and of itself. (laughter) And, you know, it produced the most valuable company in the world, so, you know, it's clearly
the right choice in hindsight. Well, I was very, very
aware of this issue of founders and the outsider, and I understood I was the outsider. So from the moment I started, I knew it was their company,
and I didn't get confused. It's their company. It's their
company. It's their company. So what does this mean?
I refuse to do any press. So, as young executives,
and all sorts of press, they really enjoyed it,
they had all these pictures, they were on the cover of
Time, and so forth and so on. And then, right before the IPO, they did an interview with Playboy. (laughter) No pictures,
just so we're clear. The interview with
Playboy was on, roughly, February 20 or April 20 of that year. It turns out that the
interview was at the wrong time in the cycle of being quiet period, and it put our IPO in jeopardy. So I still remember in August of that year sitting with them and saying- you know, these are my closest
friends, my colleagues. I really care deeply for them. They have those long
faces people get on them, and uncharacteristically they said, "Did we screw up?" and
the correct answer is, "Yes. You really screwed up," but the even more correct answer is, "No problem. Easy mistake to make. I would have made this mistake." And we papered it over
in a legally-correct way. From that moment on,
they've given no interviews. (laughter) - [Reid] Really? From that moment on? - From that moment on. Now that was 12 years ago. What's interesting
about that psychology is somehow, as young
executives, they wanted it, but once they didn't want it,
it was fine for me to do it. But intuitively, it is their
company. It's not my company. I am the professional that was
hired. They are the owners. They are the founders. It's their company. If you get confused on this
point, you're not gonna win. Nowadays, the founders
are much less likely to offer control the way, say, Pierre Omidyar offered it to Meg Whitman. There's an increasing sort
of view of their own ability. And that's fine, too. If you look at Facebook,
it's worked really quite well with Mark, who's brilliant and young. By bringing in someone who
is much more experienced in many, many things, Sheryl Sandberg, that partnership worked extremely well. So there's not one answer. - So, joined at 100. It's
now over 50,000 people. - 60-plus thousand. - 60-plus thousand, a classic
example of blitzscaling. Matter of fact, there was
one year - I think it was 2004 to 2005 - you over tripled the number of employees in that year. - I do have a saying about this. It's easy to double. It's very
hard to quadruple every year. (Reid chuckles) It's a bit of advice. You can double. You can kind of see it. You can kind of, "Okay, I can add in another person here. I can add another person,
and then, you know, I can expand into this country,"
and so forth and so on. But to quadruple is almost impossible. - So, what were the kind of- because you had to invent a
lot of these techniques, right? These hacks, I mean. Everything from the three
of you reading every resume to, you know, keeping innovation going 20-percent time, other kinds of things. What were the key hacks that worked and the key hacks that didn't work? - So, I want to offfer a cautionary tale. And again, having both read your book and also the notes that you
kindly sent me before this, if you don't understand the subtlety here, you would conclude that
the correct thing to do is to grow everything as fast
as you possibly can everywhere so let's just make as many
engineers, as many salespeople, as many products, and so forth and so on. That completely does not work. It doesn't work because
no product shall ship before it actually works, alright? The way you build great products is you have small teams
with strong leaders who obsess over trade-offs
and they push things off and they say "we've gotta get it done," and they put a lot of
pressure on the team, they work all night, and
they produce a product that just barely works. I'll use non-Google examples. The original iPod just barely worked. Look what it became. Try, people, to remember
the original iPhone. No apps, right? Everyone's forgotten that. Just barely worked, but was
just the right combination to create an enormous franchise that's now 70% of the revenue of the
world's most valuable company. I was talking to Travis Kalanick. We are major investors inside of Uber, so we have good relationships with Uber. And his description of Uber was that he understood scaling, but the product, the app, wasn't ready. So you have to sort of
have judgement about when the product is ready
to scale against it. We would debate this over and over again. Larry and Sergey would play tricks on me. A typical example would be: I would say, "We're not strong enough to take on Microsoft." They wanted to do an operating system and a browser, and I said, "There's no scenario where we'll ever do an operating system and a browser, because Microsoft will kill us, and I don't want to get killed. We're a small company, and yes, yes, you're very smart, and yes, yes, we're full of smart people, and yes, yes, we have lots of revenue. These guys can kill us, because I've been previously killed at previous jobs." So, they hired somebody to improve the performance of Firefox. Six months later, I'm
called down to one office, and the person who was supposed to improve the performance of Firefox has managed to invent Chrome. (laughter) Shocking. And I'd say, "Well, how long
have you been doing this?" "Well, I've been doing it on the side." "No, you haven't. You've
done it full-time." "Well, yeah, you know, I
had three other people." "Okay. Well, how many
more people do you have?" "Oh, 10 more people." "Okay, did Larry and
Sergey know about this?" "Larry and Sergey encouraged it." I said, "Screw those assholes." I knew it. I knew they
were going around me. (laughter) So, and then I said, "We
can't do an operating system." So, they bought this
company called Android and they said, "it's just for smartphones. It's software for smartphones.
Don't worry, Eric." (laughter) Today, Android is 1.4 billion-plus
operating systems used. Largest number of operating
systems in the world. Chrome is the largest and
most successful browser. Maybe the lesson to learn in management is "I'm just wrong all the time." But the secret was you
have to have judgement as to when these things can scale. I can give you plenty
of negative examples. An obvious one is Wave. It was a complicated email
product that we launched to great fanfare, and we
watched its adoption rate. Marissa had this rule, which
is a good rule, at Google: you cannot tell how
successful a product is until the first six months,
because what happens is you get this adoption cycle,
and everyone loves the product because everyone tests it, and
then you watch what happens. And the great products,
they're bumpy, but they go up. Well, this is what it
looked like. Like this. So, it took Eric, your
friendly CEO, 18 months of going down, before that
project was cancelled. So, again, lack of due diligence lasts. The reason I'm answering your question, the blitzgrowth argument, by saying you've got to have
the products you can scale. If you have the products that can scale, the thing that's new is
you can scale very quickly. The Uber example. Once you have an app and a business model that more or less works, there's no reason why you
shouldn't go global and wide. When I started at Google, my first concern with Google is I thought the whole thing was a sham. The company was using
Quickbooks for its accounting and I was convinced
that there were errors, so I asked to be shown the
actual cash balance in the bank. There was, in fact, cash in the bank, which was shocking to me. So then the sales guy, his name was Omid, who's now just gone off to Twitter. I said, "Okay, well, where's
this money coming from?" He said, "We have sales
for us. We sell these ads." "Who clicks on these ads?" "Well, nobody." "Well, okay, whatever." It
must be some fake thing. So, we investigated and we decide people really were clicking on these ads, so I said, "How many clicks do you get outside of America?" and
he said, "Well, none." I said, "Well, you have
lots of traffic," so I said, "Leave and go to Europe,
and don't come back until you have sales operations in Britain, the UK, and France," which is a strange thing
to say to somebody. This is a month after
I started, so he left, and he came back in three weeks having set up those operations. Today, the operations he set up contribute 60% of the profits of a 60
billion-dollar corporation. So, in hindsight, I should
have done it a month earlier. Think about the compound
value of that decision. There's a point where you keep it small, and there's a point where you expand. When you expand, you
grow very, very quickly. And it has to be replicable. So, let's just use Uber as an example. Always the favorite example, because everybody
understands Uber, as I said. Do you believe that the Uber model scales well outside of the United States? Well, ask the French, okay? The French love it, but
the government hates it. So they meet two problems: They need a scalable app and they need a scalable
negotiation strategy with the governments, right? So, now you can guess how far they'll be. Google had the same problem
with China, and we lost. - So, any heuristics for when the product is right for scaling? - Well, I have another opinion about this. If you think about the greatest products, they've almost always been designed for the benefit of the people who are actually building them. So, the Uber story: they
built this to share apps. In fact, the original Uber
was a private sharing group. Larry and Sergey built Google for Stanford and in particular, for themselves. The server was in Larry's dorm room, and they needed a second server. They didn't have enough power, so they ran the cord over the room into the gentleman next door's dorm room. They opened up the server
for the entire campus here, and the usage was phenomenal. Andy Bechtolsheim heard about
it through David Cheriton. He wrote a $100,000 check. They didn't have a name for the company. He wrote the check, he gave it to Sergey, Sergey put it in his
wallet without a name on it for $100,000 and left it
in his wallet for a month until they had the name Google invented. (chuckles) They moved into Sergey's
girlfriend's sister at the time - then wife, ex-wife; long
history of life there - house, which we now own, where they set up the servers in the garage. And they slowly took over
each of the bedrooms, and this poor woman, who I
think was pregnant at the time, kept saying, "The baby's
coming. The baby's coming." They put "Google World
Headquarters" in the baby's room. (chuckles) So, the rest happened. - But then is the heuristic,
you already see such impressive demand, you know
you have to keep up with it, or is sometimes, your heuristic simpler, or different than that? - It's easier that I give you a latch. It is tempting to believe that you have a product that works before it works. The error that's made, especially
by non-technical people, is they believe what
the engineers tell them, and then they pre-scale for a product that doesn't work very well. So, think of it in a different way. Think of it as, "I'm going
to raise money from you," because, of course, you're a
very famous venture capitalist. I'm going to take your
money, and I'm going to do everything I can to build a great product, and you're going to be all over me. "Where is your international strategy? Where is your sales strategy?" and I'm going to say, "Reid, just stop. The product doesn't work
yet. I'm saving your money." Because I know, in today's market, the moment I have that
product, I know I can hire a sales and marketing and
evangelism team in a week. And I can do it globally.
That's the difference. Think of it not as the
measure I described here, but rather as a funnel
which is very tight, then there's a global expansion period. I think that's the essence of what you're trying to say in your book, which is there's a point
where the sum of all of this, it's like this huge push, right? But you have to time it right. Now how do you know? One is people use the product itself. Let me give you- lots
of failures in my case. Let's use Wave. Nobody
at Google used Wave. Okay? Other people did. By the way, they were really
nice and really energetic. They're not using it anymore. They were just, like,
caught up in the hype. How many people do you see walking around Stanford using Google Glass? Anyone here wearing Google Glass? I don't see it. Okay. Let's keep going through the list, right? Again, maybe it's just we're at Version 1 and we need Version 1.1. Maybe we need just a small
change, and then boom. Those are two examples. You can pick hundreds
of examples at Google, and thank goodness we've
all forgotten them. (chuckles) - So once you have the product/market fit that works sufficiently, part of the thing that I think
we do here in the valley, China does, but it's
actually relatively rare, is figure how to really build fast into that global opportunity. And some of those techniques were things that you guys invented, so what was some stuff in order for you guys to be able to-- - Well, I want to talk a
little bit about hiring. Before your excellent book,
Jonathan and I wrote a book called "How Google Works." A third of the book is on recruiting. I want to give Sheryl Sandberg credit, because when she was with us, she set up a lot of this. There is a way to systematically hire better people than anybody else. What Bob Taylor, who I
interviewed yesterday for a new book I'm working
on, "The Future of Everything" which looks at the past
of everything, said was, "Sell the dream." Here's how he funded the ARPANET: He called up people, and he
described what he wanted. And they either got it and
got incredibly excited, or they didn't. If they didn't, he just
went to the next person. How hard is that? Well, if your idea's pretty good- if the person is sufficiently
dull that they don't get it, then are they gonna get
it after some persuasion? Probably not. You want somebody who's quick. One of the things you say
is, "hire generalists." So, we, in the form of Larry
and Sergey, to start with, had very strict rules. Here's a typical example. I would go in and I would say, "Hmm, we need some
experience in this layer, in this area, and we need some people who can program in Java and SQL and various other sort of XML protocols, which I was very familiar
with in my previous jobs, and they would say,
"That's the stupidest thing we've ever heard. No one
would ever want to use Java or any of those kinds of things." They did this partly just to annoy me. And I said, "Well, who
do you want to hire?" They said, "We want to hire
incredibly intelligent people." Well, so do I, okay. You're implying that people working on the stuff I care about
are not very intelligent. And they would say, "No, no no. We want to hire incredibly
intelligent people. Incredibly intelligent
people would figure out that the stuff you're
talking about is stupid, and therefore, you should
work on the right thing." (laughter) So we would have these debates, and it's all in great fun, of course. By the way, today we have
thousands and thousands of Java programmers just in
case you're worried about it. They were actually
making a different point. They were making a point
that you hire people who can get the job done, that the industry over-values experience and under-values strategic
and intellectual flexibility, which is the point you make in your book. And I feel very strongly about that. There's an easy way to understand this. I'll tell you, in all the
issues we had at Google, I realized that I had no idea what to do. I am, after all, the CEO. I'm
supposed to know what to do. I had no idea what to do, but I knew I had by far the best team ever assembled to address them. Examples would be dealing with the then-competitors at the time, the shift that we did in our business from one way of selling to now what is called the Vickrey auction or
second-price auction. I'll give you an example. There's this fellow named Saul, who's a biology undergraduate here who looked, to me, to be about 21. He's actually older than that,
but he looked very young. So one day, he announces we're switching our entire revenue system
from an as-sold model by the sales force, to
an auction-based system. And I was convinced, remember, that these things were being oversold, that they weren't worth very much, and our sales guys were so incredibly good that they were maximizing the values to the point where the price was too high. I said, "I'm not sure." "But we won't get there with salespeople. We have to have an auction," and I said, "Okay. Whatever." Larry and Sergey were on his side, anyway. I got so worried about
this, I put in place a program in the first year which I called the Cash Restriction Program. You can imagine the acronym. We would only spend
money at 10am on Fridays, because that way, I figured I could control the amount of money. I was worried we were gonna go bankrupt while this very, very young
man implemented this auction. We turned on the auction, I'm terrified, and the revenue triples in day one. Of course, we completely
forget the whole program. And I'm saying, "You're telling me that our incredibly talented sales force is under-pricing our product
by a factor of three?" So then I immediately call
the sales guys and say, "What are you doing?" I don't know whether that's luck or scale, but it showed you in Saul,
of course, a brilliant man and a person who really is
responsible for the architecture that drove the $60 billion, you need ideas like
that, that scale so fast. And let me put in a pitch
for my current best idea, which is machine learning. In the careers that you all will have and the companies you'll
found and so forth, machine learning will be the way in which you get that multiplier. For the non-programmers in the room, the way to understand this is that programmers like me were taught how to write algorithms that precisely specify the methodology, and we got really good at it, and we're very proud of it, and we're very arrogant. A new set of programmers understand how to have a computer learn something, and then the learning model
is applied to this problem and that's a very scaleable model. And that's gonna produce
immensely larger companies than the kind of companies we're talking. And the speed will be immense because once you learn something, the scaling can occur
globally in a matter of hours. - [Reid] Or even necessarily quicker. Hiring? Is there stuff you want to go into how you did hiring particularly well? - Well, we had a whole bunch of reasons. One of the rules is we didn't
want to hire your friends, which always was upsetting. We also didn't want to hire anybody from what were considered to
be lesser universities. (laughter) We also wanted to hire people
who had very high GPAs. The constant problem was that somebody was a good employee, had
someone they had worked with who was very loyal,
very hard-working, who was not from a great
university and did not have a very good GPA, we wouldn't hire them. That was controversial. We've relaxed that a little bit now, but the fact of the matter is it got us to where we are today because it produced
these high-IQ generalists from prestigious universities. That's the best way to understand this. The second thing is one
day, we were looking- when I was at Novell, I
had learned that there were people who I call "glue people." The glue people are incredibly nice people who sit at interstitial
boundaries between groups, and they assist in activity. The are glue, and they
are very, very loyal, and people love them, and
you don't need them at all. At Novell, I kept trying to
get rid of these glue people, because they were getting in the way because they slowed everything down. Every time I get rid of them in one group, they'd show up in another group, and they'd transfer, and
get rehired and all that. I was telling Larry and Sergey
this one day, and Larry said, "I don't understand what your problem is. Why don't we just review all the hiring." And I said, "What?" And Larry said, "Let's just
review all the hiring." I said, "Really?" He said, "Yes." So, guess what? From that moment on, we
reviewed every offer packet. Literally, every one. And anyone who smelled or
looked like a glue person, plus the people that
Larry and Sergey thought had backgrounds that I
liked that they didn't, would all be fired. So anybody who sort of
met the original profile, they'd go right through. We'd have this huge argument. Every once in a while, we'd have arguments that
were sort of speechless. I remember this one
argument about a fellow who one of the founders
did not like his last name because it was too humerous. By the way, we hired him. You can imagine you can
have some fun with it. The fact of the matter is, because we never fire anybody, the hiring decision is crucial. The people you hire define the culture whether you like it or not. Larry and Sergey, when
they started the company, said, "We need to have
really smart people," so they hired a rocket scientist. And they hired a medical doctor. And they hired a Stanford graduate who had been a professional
football player. Because they figured
they wanted normal people who had done something exceptional. In my case, I was a pilot
and I had done other things. They said, "Okay. You're good enough." The CEO has to have
something besides being a CEO that makes them interesting. And everyone had something, and I would go around and I'd say, "Well, what's special about you?" like Sesame Street. What's special about you, and what's special about you? But there was always an interesting story. So another lesson I learned was that you don't hire generic people, you hire people who have had some kind of stress or achievement or whatever. The best people to hire, by the way, are CFOs who've gone bankrupt, because, boy, have they
been through the war. On the CFO side and the finance side, you want somebody who's
not gonna happen again. And you only go bankrupt once, by the way. - Exactly. Now, the interview process, as I recall, from early Google was fairly involved. - Oh yes. Yes. So the interviews. Well,
anyway. Finish that. - I mean, it's precisely
that. Was that a good thing? Bad thing? Mixed thing? Because it was definitely
a deliberate thing. - Once we decided we were going
to review all the packets, then we had to figure out
how to score everybody. So we put in a scoring system
and asked people to score. And they were scored between one and five. Sergey said, "The problem here is that these scores were biased." So we put in a statistical measure where we would look at the average weight of the scorers and then correlate that with the future performance
of their scoring. So a year later, we would look back and see how we had graded that employee versus the way you had rated them. And oh my god. Guess what? We discovered that if it's a woman, the female is scored
with inverse correlation to her performance. It's the most extreme
evidence of male bias against female candidates was
sitting right in front of us. How could this be? I mean, this is as liberal a
company as we can full of guys. It's called "unconscious bias" now. We didn't have the term. - [Reid] Hidden bias. - Hidden bias. Excuse me. So we, in fact, changed the entire way in which we run the recruiting
for female candidates and so forth and managed to correct that. So there's an example
where something that, even as liberal and analytical
a company as we had, we didn't really realize we were doing. And this is now a decade ago, so the good news is, we corrected it. But it's an interesting story that even the best-meaning people can have these kinds of biases. So, we would do this scoring and then we had the problem
of people being interviewed. So, I still remember this packet. This gentleman who we
interviewed 16 times. The person who was running this process had come in and said, "Look, you have gotta make a decision." And the recommendation
was to not hire him. And I said, "Look, you just can't do this anymore to people." I said you can't interview
people more than eight times. They have since revised
the statistical metaphor that for engineers, they
have five interviews, and for non-engineers, they have four, and that turns out to be
statistically significant. So very interesting. You
can systematize even that. - As I actually recall,
the way you did that is you actually looked at when was the score dropoff no longer predicted. You were taking all that and then said, "Okay, at this interview,"
yeah, and that was-- - But those are simple techniques that wouldn't have occurred
to the normal company. Because we'd hired all these smart generalist types
with obnoxious degrees from famous universities
that were obnoxious, you know, whatever stereotype you want, they applied an analytical bias. We did the same thing. We did analytical bias to facilities and to cash management
and so forth and so on. So, during this heyday, me made very sure that our
marketing was disorder. I used to call this "the lava lamp pitch." What we would do is we
would show you around all these incredible things we were doing. We would show you all the lava lamp, say it's complete chaos; people
can do whatever they want, which, of course, is completely not true. And so if it was somebody important, like a shareholder, I would say, "By the way, there's
another half of the company that's run incredibly
rigorously with goals and so forth and so on
that produces the results." So you want to distinguish between the marketing and the reality
of how you manage them. - Speaking of management, growing an organization this fast is a nightmare to figure out how to manage who you promote into management, how do you run it. What were the things that worked and what were the things that didn't work? - I had had negative experience at Sun in divisionalization
and operating companies and things like this. My position was pretty simple. Larry and Sergey are running things. It's chaos anyway. We're just gonna run it as a group and run it as fast as we can. We would have a meeting on Monday which was called "60 minutes," which always took two hours. It was called "60 minutes" because you had to be offline and off
your computer for 60 minutes, and if you were found, at the time, typing on your Blackberry,
there was a 25-cent fine. We used to call this the prayer-- - 25 cents? (chuckles) - Well, it's a cheap place. People would be on their Blackberries underneath us and we would
do Blackberry detection. This strategy eventually
failed, by the way. It turns out that it was
impossible to get people off of their computers
for one hour per week. Another example of a strategy
that didn't work for me. On Tuesdays we had something called the "Google Product Strategy Meeting," where we would review- we
would use that as a checkpoint. With so much going on that- we realized we were
launching all these products that no one knew that they were launching, so we put in a launch review process. You could not announce something without going through a launch
review a week before, and that was sort of the way in which we caught the problems. Inevitably, the problem was the engineers were doing something that they hadn't told the support people or the lawyers about. My best example here was
the fellow who walked in - and he was very young,
probably early 20s - had taken one of our products
and added the ability to geolocate where your friends are and predict where they were going to be and you were going to be. He puts this demo up
and my face goes ashen. The lawyers are going, "Oh my god." The marketing people
are going, "Oh my god." Larry and Sergey loved it. They went, and I still
remember, this went on- and we had a schedule, and
of course, it was blown. We're in there for two hours, and they're just screaming
about how incredibly brilliant this product idea is and
how wonderful this is and what was wrong with
me and so forth and so on. I put it out there that
there's this minor problem that such predictive behavior
is almost certainly illegal. In any case, even if it weren't, I don't want to deal with
all the real-time subpoenas that are gonna come in because now we know not only where you were, but where your friends are and we have it all on one database. I said, "Look, we can't even afford the lawyers to deal with
the current subpoenas." The great thing about Google
is, after you have one of these and by the way, just so we're clear, Larry and Sergey were
doing this for effect. They were just trying to be
disruptive and have a good time. This is part of the culture
is to draw this out; to be provocative in a good way. It's healthy. I'm saying this in a good way and I think it was a very healthy process. So guess what the solution was? This particular product, you could actually pin it
and lie as to your location, which makes the legal records unreliable. We launched it. (chuckles) You see? - [Reid] Uh huh. - Another example that we had-- - [Reid] Latitude. - Yeah. I remember Latitude. And then, another example
is that we were having- after it was discovered
we were doing Chrome, and we launched Chrome and it was beginning to be successful, we had a debate over HTML5 and the exclusivity of browsers and the rate at which we put stuff into the browsers and so forth. And at the time, Chrome
was not the number one. It was well behind Safari
and Internet Explorer. And so, we have 20 people in the room, and we're having this argument. All of a sudden, it's pretty clear that Sergey's not gonna give up, right? He is absolutely convinced, and I disagree with him, and Larry disagrees with him and me. We had a rule, the three of us, that we would not have
huge arguments in public, which, of course, we did anyway. I realized, at that point, I kicked everyone else out of the room, and the three of us had it out. We clearly didn't agree, and I said, "Look, you guys go back you your office." They shared an office. "You guys argue it through, and if you haven't
decided by noon tomorrow, I'll make the decision," which was clearly the worst decision of the three from their perspective. (laughter) - [Reid] A forcing function. - A forcing function. So that afternoon, I go back
over to visit their office. "Hi guys. How are you?" You
know, just chatting around. "Did you come up with a solution?" They'd come up with a
completely better solution that was far better than
any of the previous ideas. So sometimes the cauldron of ideas works. I'll give you another example. We had an engineer who
had invented a free wi-fi. They had launched this
thing in San Francisco. Nikash, who has since left
the company had just come from Deutsche Telekom, and
knew a lot about this. We knew nothing about free
wi-fi, telecoms, and whatever. So he starts asking this guy very reasonable business questions, none of which he could answer. The review is going south, and it's getting worse
and worse and worse. At some point, it was pretty clear that this was like torture, and we had to stop. I said, "Look, let's stop." At that point, you have a choice. You can say to the person, "You're an idiot for having
brought such a terrible idea. You've clearly embarrassed yourself and the company," and so forth. That would be the wrong thing at Google. The right thing at Google, in a
situation like that, is to say, which is what I did, is I said, "I think this is the most
incredible idea I ever heard. You need to come up
with a better approach. The objective of free wi-fi is incredibly strategic to the company." So all of a sudden, you can see this guy. "Oh," and he runs out the room. Six months later, we re-introduced it, and got huge benefit from it. So we ran with this
product strategy thing, and then we would do deals on Wednesdays. That was the structure. Thursdays, we had a no-meeting day, which meant that we
were always in meetings. It was organized so that
the salespeople could travel Wednesday and Thursday
and come back Friday. And the cycle would begin again. - But in terms of- I mean,
Google had a bunch of different things where like sometimes- like there was a day where
everyone worked for Larry, it was like we're gonna
be completely flat. - I have to tell you about the disorg. One day, again, we're in the first year. I'm a normal engineering manager. We have normal engineering
plans, and I think they're fine. We have five engineering directors. Wayne Rosing was the
engineering vice president. Wayne came in and said,
"You gotta come talk to me." I said, "What?" "Larry and Sergey are on the rampage." I said, "Over what?" We had something called Snippets, and the engineers were
supposed to write down what they did per week. So Larry has been reading the snippets, and he's been correlating it with what the managers had been saying. Not good. Larry's very precise
and a very analytical person. So, he said, "Look, we've got a problem. I mean, I can't deny it." "Larry, what are you gonna do?" He said, "We're gonna get
rid of all the managers." I said, "You can't do that, Larry." Nevertheless, that was, of course, an even greater challenge. They took the five managers and made them individual contributors. All of them are still in the company, I might add, ten years later. We have 120 people working for one engineering vice president directly. We reasoned that this would guarantee he couldn't interfere with their work. So we ran that way for two years. His name was Bill Cohen. He's now a very successful
venture capitalist. He jokes about what it was like, but you can, in these situations,
do extraordinary things. - That's probably a good tip, too. In this kind of blitzscaling circumstance, what's the role of the CEO? - I can tell you my role
was to manage the chaos. You have different kinds of CEOs and there's no single answer. In any successful company, you've got to have somebody who can run very fast and has
very good product sense and has sort of the intellectual
emotional leadership of the key stakeholders. In that sense, it's like a faculty. The key engineering talent, they sort of put up with the management. They know what they're doing. They're incredibly professional. They're very, very driven. They know what great products look like. That's what success looks like. My job was to sort of organize
the world around them. Ultimately, if you ask Larry and Sergey, when they hired me, Larry said to me, "We don't need you now, but
we'll need you in the future." I think that was roughly right. As a small company, they were doing fine, but in order to scale, you needed
someone who understood replication, and who could basically
put the systems in place. So I set out to hire the
non-essential executives, which was everyone else. All the other functions that you need and deal with all the
other kinds of things while Larry and Sergey, as
founders, were working on the technical side of things. There are other models where you have a very tactical founder
who won't give up control who cedes partial business
control to a business associate. I think Mark is a good example of that, where Mark's not gonna give
up control over Facebook, and, by the way, Larry
and Sergey didn't, either, it doesn't matter whether
they're called CEO or not, but Mark allows the key stakeholders, in his case, the CFO and Sheryl, to run large parts of the company, and, of course, they do a great job. - One of our theses in
blitzscaling is that part of what you do is that
you also make decisions on what not to do in order to move fast. Were there any kind of key decisions about what not to do in order to be
able to move fast at Google? - Surprisingly, no. Because the ambition was so broad, the only lever I had was
to slow some things down and emphasize other things. I don't agree that you
should narrow your focus. What I believe is that
you get the best outcome when you make the broadest
appeal in terms of leadership and excitement and so forth. And we worked very hard
to make that happen. There were other things. For example, we would refuse to
doing exclusive deals with people, but I would explain to people, "We
don't really do exclusive deals, but we only have the
capacity to work with one, and it's going to be you." So there are other ways to
achieve those kind of things. I'd be careful to conclude that
you should do a small thing. All success starts with doing
one thing really, really well, but you'll recruit better
with a broader vision that's credible and
that you can articulate. But go back to that 'selling the dream.' What you do is selling a dream. If you can't sell a dream, then
you're not gonna be successful. - What were the key
things that kept Google innovating intelligently as it scaled? 20 percent time was something
that was publicized. - We talk a lot about that. 20% time was a rule - again,
when I started there - there were two actually interesting. One was 'don't be evil' and
the second was 20% time. 'Don't be evil,' I thought was a joke. Because I mean, nobody here is evil. I don't wanna be evil.
You don't wanna be evil. I was sitting in the
original conference room in the small building when we started, and there's this conversation
about ad targeting and a particular ad click. One of the engineers, his name is Ron, pounds the table and said,
"That would be evil." And I'm like, "Oh, okay.
What just happened?" (laughter) The whole mood of the room changes and there's this huge debate
over whether that's evil or not, and ultimately, they didn't do the change. So I thought, "What's the analogy there?" and the analogy was
it's the kanban system. In Japan, the notion that any
employee can stop the line if they see a poor-quality thing. It works because of shared value. Strong shared values, a strong
buy-in to principles, takes you far. I think that helped us. It may or may not be true today
that the company has that feeling, but there's certainly- its
history is clearly that. The second one was 20% time
and the idea was that we could ask you as an employee to do
everything you can in 80% of your time, and the other 20% time, you
could do whatever you wanted. Don't be too worried
here. These are engineers. They're not exactly gonna run
off and do something wild. But if they're passionate about
something, they could do a 20% project. Many of the features we offer
today began as 20% explorations. Part of the management job was to
listen for those 20% time things and then sort of aggregate them. And Marissa - again, I'm
just mentioning people who you all would know - now
running Yahoo, of course, and a superb executive,
would watch for these things. So Marissa maintained a top-100
list which had 300 things on it, and she was constantly,
constantly culling that list and trying to identify these little ideas and trying to get them
to talk to each other. - Marissa's a good example.
Her, the APM program, etc. How did you end up growing managers? - I would argue,
immodestly, that the program that's called the APM
program is the largest source of entrepreneurs in the Bay Area today. So Marissa had this idea. Marissa, I think was an undergraduate
or a TA here or something. - [Reid] Undergraduate
in symbolic systems. - Oh, yeah. Incredible talent. Very, very technical, and
she became a product manager. When I started there, she was one of the three product managers. The company now has thousands. She had the idea that we should grow these Associate Product Managers, as she called them, and the idea
was that you would hire people who were right out of college
with a technical degree, particularly Computer Science, who did not themselves
want to become programmers. They wanted to work with programmers. She would identify
them, and they were all, again, very young, right out of college, and then she would train them. They would, for example,
go on these trips for weeks and sleep four to a hotel room, just like in college or high school, and it forged these incredibly
tight bonds of people who were highly technical
and could specify products. Then she would run them through this sort of training program. Sundar was an example of this. Slightly older version of the same thing. All of the executives running
the key parts of Google came in through that
program, it turns out. The program, although she was
too young to understand it, was originally invented by Microsoft. Microsoft had these people
called Technical Leaders, who were non-programming
liaisons who then, and they were incredibly technical, and they were the ones
who did product specs. I think we give Microsoft the credit, and we give Marissa the idea for inventing the model at Google, and that model is scaleable today. - And is that the kind of key way that you populated a bunch of the
key strategic leaders? - Yes. One other thing that we did: one day, we'd hired a woman named Shona Brown who had been at McKinsey. She had been a partner, and
I guess she'd gotten tired of being a partner and she wanted to work in a proper company, so she came over and we made her chief operating pubaa something or other and put her in charge of all the things that nobody knew what to do with. So she comes in and says, "I think we should have our
own McKinsey operation." I said, "No no. We're
not gonna pay McKinsey." She said, "No no. We're just gonna hire the people from McKinsey." I said, "What?" and she goes, "No, we're
going to hire the following: we're gonna get the people
who would be associates," that is non-tenured, non partnered people, "and we're gonna have them come in and do the McKinsey function." She didn't mean hiring from McKinsey, she meant replicating
that function and they'll be in this group for one to two years, and they'll go with the
business that they studied and that will be their career path. I said, "We'll give that a try." An example is that one of
my students here at Stanford went into that program
for a year and a half, again, very good Stanford
MBA analytical skills. He's a pilot and just a great
leader in all known ways. He runs half of YouTube today. Now how did he get from, 10 years ago, that to running half of YouTube? He earned it. He went
from project to project. I'll give you another example. Dennis Woodside, who's now the Chief Operating Officer of Dropbox, came in through a similar program. He studied salesforce effectiveness, and we put him in charge
of the emerging world. He was doing so well, we eventually put him in charge of all of Europe. And then we eventually put him
in charge of all of Motorola, and then he left to become
number two at Dropbox, which is a good move for him. So these people who have these sort of business analytical skills
are incredibly useful. Whenever we had problems
involving business units and how the businesses interact, we'd take one of these people, and inevitably they'd go
with the problem and fix it. Again, think of that as an
eternal stable of talent. Another story about the APMs. Marissa worked for Jonathan,
and Jonathan was very colorful. Jonathan said, "We need a chain gang." And I said, "What is a chain gang?" He said, "A chain gang is
a whole bunch of people who are waiting for work, and what we're gonna do is come up with projects which are good
for the chain gang." So we wrote down a list of questions that we had about the business and the products and so
forth that were sort of identifiable products and they
had to be doable in a month. All of a sudden, we had answers to every question we had about competitors, positioning, evolution, costs and so forth through the chain gang. By the way, these are 23-year-olds, as part of their development learning. So you can use the talent, and those models I described
are very scaleable. Yes, sir? - [Student 2] What are the
most counter-intuitive signs of talent and potential
at a very young age? - I would describe Nome. Nome went to Berkeley in the Math department at 19, got bored. He applied to Google and didn't
meet any of our criteria. Somebody knew him and said,
"You should talk to him." - [Reid] Berkeley wasn't elite enough? - Berkeley was not good enough. (laughter) He applied to Google and was
rejected for obvious reasons. Somebody knew him and said,
"You should talk to this guy." So he shows up and he's very unusual. He had figured out a way
to do spelling correction. Somebody said we should just hire him to do spelling corrections. "Okay, whatever." In other words, it's kind of loose. So, he invents the spelling corrector, which is the first time
this had ever been done, which is a huge achievement. Somebody said, "We should've hired him." I said, "Well, he didn't
meet any of our criteria." So we have another rule, which is that if the person is super
smart, hire them anyway. But they've got to be able to do like invent a new spelling corrector. Armed with that information,
six months later, I'm in the cafeteria and it's six
o'clock at night on a Friday night. I'm getting my dinner,
and Nome is next to me. Nome says, "I gotta talk to you." I said, "What?" He said, "I need 10,000 machines now." 10,000 machines at that time was a lot. It wouldn't be today. I have a lot of credibility with Nome. I said, "What are you going to do?" "I'm gonna solve general
knowledge by the weekend." (laughter) "Okay? Okay, good. Okay." I said okay. I put my tray down. I went over to the valet in
charge of machines and I said, "Get him as many machines as he does." So he turns on the software. We're chunking away and
the algorithm stops. They can't figure it out. They don't need more
than a couple thousand machines for the weekend, and I'm saved. Today, Nome is still
trying to solve general AI, but if there's anybody I
can think of in the world who's likely to do it, it's gonna be him. What do you learn? Talk to the person and figure out what is it that they're going to do. If they've got a path, give them a shot. But they've got to be able
to answer it that way. That's how you handle these
sorts of strange cases. There are always odd cases. I can give you lots of examples of hiring. We try to hire people who can coexist with other human beings because we tend to work in teams, but there are cases where we've said, "Okay, keep them over there." (laughter) - Usually, the measure on that
is they have to be so valuable, that you're willing to put all
the infrastructure around-- - And one of the things
that Jonathan and I say in our book is that
you should hire the divas. By the way, if you read any
management text that says "Don't hire the divas, because they're
nothing but a pain in the ass," by the way, they are, but the people
who are the divas who believe, are the ones that will drive
the culture of excellence and they'll drive you to that excellence. Steve Jobs was a diva. Bill Joy was my colleague for many years. He's an example of a diva. I mean this in the most flattering way. They expect a lot, they drive people hard, they're controversial, and
they care passionately. If you find those people,
you're probably gonna work for one, so be nice to them. Pay attention, or be that passionate. - Back to innovation. How
important is it to have separable groups to
accomplish something big within an existing company? You know, the Android group, Google X-- - This problem has never been solved. It's just a mess. The correct answer is two people with a graduate student and a
faculty member at Stanford and they go off and change the world. Every project I've been associated with in the 40 years I've been doing this has started with two people, and roughly the equivalent
of a graduate student, and roughly with an assistant professor who's working for tenure. So for example, Windows. The platform, you know,
was started by one person who I happen to know. Unix was two people. Java was one person. I'd go on and on and on. Gmail was one person with his colleague, and that's Paul Buchheit. Now today, how many people work on Gmail? Many, many, many, many hundreds. Android: a very small team. Linux: done by Linus Torvalds.
That's why it's called Linux. I can, again, go on and on and on. So one day- I'll give you an example. One day, I thought, "I love
this Google Docs product. They've got a spreadsheet, and a word processor, and so forth. I want to meet the team." And there was a conference room near. I said, "Just bring them into the team." They said they won't fit. I said, "How many people
work on Google Docs?" And they said 150. I said, "150? What do they do?" So, we'd then get
everybody in a larger room, and I went, "What do you do?" Well, the answer is, the projects today require a lot more research. That's because of internationalization, integration, and so forth. The point here I'm trying
to make is actually slightly different. One of the complaints I
have is that teams that are doing the work of products you see are far larger than they should be. And that's a failure of architecture. In other words, when you have
that many programmers programming, that means they don't have the
right libraries to depend on. They've not generalized the phenomena. It is my hope that the
machine learning revolution will fix that problem. - [Reid] And is there anything
you think is important about the separability
so you don't have to interface with a cross-coordination with all the rest of the company? - Computer scientists understand
the concept of interface and API. Well-done platform APIs
are the key to everything. One of the problems we have internally is that our system is incredibly powerful, but now so co-mingled with itself, because of its co-dependence. It's very difficult to partition, and I think that's a
fairly normal end-state for these large software projects. So, again, within the company, there's a major initiative to
put services into Google Compute, which is the externalization
of this, which requires APIs. Sorry for the technical jargon, but
I'll tell you what I tell people. I never want to do a
platform product without an appropriate end-user
app that goes with it, and I want to look at the interface, and I want a well-designed
interface between the two. If you can maintain that discipline, you can build great things. An example would be
today, the vast majority, if you guys go to any
startup here in the Valley, and most around the world, you're
likely to use Amazon Web Services, AWS and its associated interfaces. What's unique about that
web service's interfaces is that they're programmable
by mere mortals. They're relatively straightforward. They're relatively intuitive. They did a pretty good job of it. There are limitations to what it can do, but it represents good design. The original Mac Toolkit
is another example of something where you can
get a lot of work done. It's in a single book. I worked on something called
the Alto, which dates me. Done before you guys were born. The Alto had a single book
which showed all the APIs. You know when you have that kind of
proper interface, that's where you are. So the question was about Alphabet. I was giving a technical
answer to interfaces. There is a size at which companies
begin to be- to fall in on themselves. I think Google has done
particularly well because the two founders are so
strong-minded and so technical and, obviously, so brilliant. And I would argue that Apple
had done the same thing. If you look at the industry today, it's Apple, Amazon, Facebook, and
Google driving sort of the first four. Then there's plenty of
others right behind. Each of those companies has either a
strong founder or a strong culture, a very strong product focus, and so forth. Steve told us, of course, I was on
the board of Apple for many years. Steve told us that the
problem with Google was that we had too many things going on. That his vision, which, of
course, I think has been realized by the success of the company, is a very small number of
incredibly well-done products. We can debate that, but
the fact of the matter is the success speaks for itself. In our case, I think we've hit
some kind of mission scale problem. We spent two years arguing about this. The argument was "Should
we change the logo?" which I don't really care,
but everybody else cared. They said the mission was
all the world's information that we could index and use. How do you match that with
cars and biology and so forth? Larry reviewed this at some length. We had visited with Warren Buffet on the 14th floor of a building in Omaha. It was the three of us and Warren
Buffet, if you can imagine that. He held forth. He's a facinating
and impressive man in every regard. It had a big impression, I think. You can understand Alphabet
as an attempt to build a holding company that looks
like Berkshire Hathaway out of an existing large company. This has never happened in the
history of American business. It's a big bet, not a little one. It's typical of Google,
more important to know, that we announced this without actually even knowing what the companies were. One of the fun things I do with employees
is I'll say- let's do a show of hands. How many Alphabet companies
do we have, and what are they? Of course, there isn't a good answer
because we haven't announced it. No rational company would ever do that. They would have had
months spent of their time figuring out this market and so forth. Our attitude was, "Just get
started and work it out." Today, there is one, which is
the Google life sciences stuff, which looks like it's
gonna be hugely successful. We've also said publicly that
Calico, which is an aging company. We've also said publicly that
Access, which is above Google Fiber and a few others are coming. Characteristically, we're
not doing this halfway. So, having spent all week on this, I can tell you the
instantaneous situation is that we're trying to push
the Alphabet companies not to be divisions, but
really separate companies. That means severing the ties and
really operating autonomously. That's inspired by Warren Buffett's
rule that he loves to hire people who would do it whether
he hired them or not. He never has to worry about them. He knows that they're going
to wake up in the morning and show up at work and work very hard. That's just the nature
of the people they are. Ultimately, the recognition
of our scale was we needed to have an
organizational structure that would attract those leaders. We just hired this guy John,
who's gonna run the car stuff. I talked to him yesterday,
and he's fantastic. He came here to do this.
It's what he wants to do. He's gonna work 24 hours a day.
He's from the car industry. He wants some exciting driving tasks. He has all sorts of issues
and all sorts of partnerships. I can't think of a better
leader to take it forward. Normally, companies would have given him a little bit of leeway. He's gonna be the CEO. He's
gonna have his own operation, and he's gonna bear the
risks as well as the upside, and that's very attractive to him. - If you're giving advice
to entrepreneurs who are thinking about building
game-changing companies, what do you think the key things were that made Google win? - First, you have to
have the right founders. You understand this. You are a founder and
obviously, the right founder. You have to have the right
founders for the problem. And the founders have to be good, and by good I mean they
have to be impressive, they have to be smart,
they have to be passionate, they have to be committed, you know, this has to be their life's work, which, again, was true of
you, and it's true of ours. That's point one. Point two is you need to have some luck. And in our case, a search
and the ads that we developed turned out to be a goldmine of revenue. So once I figured out
that it wasn't a sham and once I figured out
that people really were clicking on these ads, we set out to maximize
the amount of revenue we could get from that business. If you look, it just went like this. You maximize that by making
the ads more relevant, making them more useful,
all the things you've heard. The fact that we wound up in a very high-gross margin business very early, gave us the ability to take these risks. When I talk to people I always say, "How much gross margin do you have? How much flexibility do you have?" I've been so lucky, and I give
this credit to luck first, I forget that there are
other businesses that are relatively low-margin businesses like almost every other business, by comparison. So you want to be careful to understand how much flexibility you really have. The ideal business is
the Microsoft business, a monopoly software business with hardware competitors
who are competing for good treatment by you in a growing and global industry. Again, let's use Uber as and example. Notice that Uber spends
an awful lot of time talking about how the
drivers don't work for them and that they don't own the cars. There's a reason. It's not the
legal and liability reasons. It's because if you think of them as a software infrastructure comany, in other words, they help
and assemble this thing, then they have very different economics than if you think of
them as needing to open and own all those things. In that sense, it's a modern
version of the franchisee. Why do people own McDonald's franchises rather than McDonald's? Because McDonald's
couldn't get the capital to own them all themselves. Franchisees have to risk their business under a franchise model. Why do hotels like Four Seasons doesn't actually own the buildings? Like how could the Four Seasons hotel not own its own building? It's actually better to be the operator with a fixed revenue share
in all the ways that you know and let somebody else ride
the real estate up and down which is vicious if you
haven't spent some time in it. - So I have a bunch of questions.
I'm gonna ask one more. Then we're gonna open up, and if you guys don't have questions, I've got a stack of more and more. Way too many for the amount of time. - You and I are together
tomorrow afternoon, too. We're doing something
together in San Francisco. - Exactly, and it'll actually
be on radio at some point. - Oh, really?
- Yes. (laughter) - What do we do about the middle class? It's an important problem. - I'm in favor of them.
They click on ads a lot. (laughter) So it's clear what my position is, I'm in favor of more human beings, because more human beings
means more customers. And more customers means more growth and revenue for the
corporation that I represent. If you are confused on
that, do the math around employment and people. We want more people. We
want more immigration. We want more customers.
We want more internet. We want more revenue.
That's called capitalism. - [Reid] Exactly. We want
more empowered people too. Google, obviously making
massive amounts of progress in a lot of different areas. Everything from self-driving cars, genetics, global connectivity of internet, search, mobile phone systems,
the list just goes on. Were there any kind of particular Valley of the Shadow
moments where you were like, "Oh gosh. Is this gonna work?" - Well, a lot. The one that drove me crazy was the conversion in the auction. Six months later we had a- for various reasons, we had to merge our databases together and I thought, "Well this
is a pretty big deal." I talked to the engineers, and we had three different databases
to a single ad system, and I said, "Maybe I
should spend the weekend in the data center watching it." An engineer said, "What
planet are you from? You never visited the data center." I said, "Okay." I figured I'd take the weekend
off, they would do the merger and I would go into
work on Monday morning. For various reasons, I had
to be in New York that day. I flew to New York on Sunday into Monday, and I wait and see what
happened after the merger. So we're now merging to a
single auction-based system which, based on the data,
would produce a lot of revenue. At 5:00, I'm sitting
next to a young woman, I have my little cube next
to me, and the phone rings. You can hear on the voice. It's a man and he is
screaming at this woman. "How could you do this to
me ? This is a disaster." And this goes on for 25 minutes. I'm listening and writing down. I figured this is real feedback. They say in the book you're supposed to actually listen to the customers. I was happy to have her listen and I wrote down what this
poor woman had to put up with. She hangs up eventually, she's
as polite as she could be, and I said, "Well, what happened?" She said, "First place,
he calls me every day." I said, "He treats you that way?" "Yup. Absolutely every day at 5:00." I said, "Why doesn't he drop you?" "Because everything in his
business is dependent on us." I said, "Well, what was that all about?" "He said he couldn't get
his report to show his boss that day of how much
product they had sold." So sometimes, you get
the wrong impression, if you build something
that's that crucial. What happened was I thought, "Oh my god." So I go to the airport,
I fly back, and I say, "We've got a disaster, and
we're gonna have meetings every day until we resolve this." So, by Thursday, it still wasn't resolved. So I said, "Okay, we're gonna
have meetings twice a day at 10 in the morning and
four in the afternoon." That started Friday, and I said, "By the way, if next
week this isn't resolved, we're gonna meet every hour for seven days a week." And we fixed it, and that
database is the benefit. I think sometimes knowing
where the problem is, and this poor woman and
the abuse she suffered at the hands of this
unknown customer drove that, and I thought, "Well,
okay, that's both a lesson, but also a crisis." - [Student 4] At our company, we use a lot of Google products. We use Google Adwords, Atlas, Gmail, Google Docs, Android
phones, the list goes on. One of the things we noticed was that our experience with Google as a company and their products was
different with each product. Support was different.
Quality was different. So first of all, is that
intentional, or kind of a result of all of those things that
you were talking about? And secondly, how is that
gonna change with Alphabet? - The products you're describing are all in the Google part, in the G of Alphabet, so there's no change from
an Alphabet perspective. We had various of these kinds of problems and I think a lot of them
have to do with scale. It's just a level of how
well you can integrate all your support, the products are at different levels of maturity, there are interconnection
issues and so forth. Without knowing the specifics, I can't give you a better answer. Initially, we didn't
have any support at all. That was sort of a non-starter. One of the things that
Valley companies do is they try to minimise the human
support that they provide, because the model
requires them not to have you know, the old telcom support model.
"Hire people that can get the job done. The industry overvalues experience, and undervalues strategic and intellectual flexibility" (26:00)
@48.26 - its called an Andon. Andon (Japanese: アンドン or あんどん or 行灯) is a manufacturing term referring to a system to notify management, maintenance, and other workers of a quality or process problem.
"Because we never fire anybody, the hiring decision is crucial ... (Larry and Sergey) wanted to hire normal people who had done something exceptional ...you don't hire generic people, you hire people that have had some sort of stress or achievement" (31:10)
https://www.researchgate.net/scientific-contributions/2059717778_Noam_Shazeer
@48:26 -- its called an Andon. Andon (Japanese: アンドン or あんどん or 行灯) is a manufacturing term referring to a system to notify management, maintenance, and other workers of a quality or process problem. (48:20)
Stanford professor Eric Schmidt , gives talk to Stanford students, about Google and the future
https://www.youtube.com/watch?v=Bh804pcy5sc&t=2s
https://www.youtube.com/watch?v=Bh804pcy5sc&t=2s