Scaling Google with Eric Schmidt— Class 8 Notes of Stanford University’s CS183C

Here is an essay version of my class notes from Class 8 of Stanford University’s CS183C — Technology-enabled Blitzscaling — taught by Reid Hoffman, John Lilly, Chris Yeh, and Allen Blue. Errors and omissions are my own. Credit for good stuff is Reid, John, Chris Yeh, and Allen’s entirely.

This class was an interview by Reid Hoffman, of Eric Schmidt — the CEO of Google (now Alphabet) — on lessons learned from scaling Google.

Eric Schmidt shared many personal stories. While these stories are interesting, they are hard to capture in note form (the video will be posted soon), but I will try to summarize the lessons and key points as best I can*

Video of the class, notes are below:

Reid Hoffman: Before Google you held exec roles at Sun Microsystems and Novell — what did you learn through these experiences which you took with you to Google?

Eric Schmidt: The other day I was talking to Bob Taylor who founded ARPANET and helped conceive the modern PC. I was reminded of the extraordinary things we as an industry had accomplished, and that I have been around for 40 years working in tech.

As a first time manager I had to absorb everything. The first few years is your career is crucial, it’s the time period where you learn and develop your own management style. I learned much of my style through Bob Taylor who I worked under at Xerox PARC.

During my time at Sun I learned a few negative lessons — the dangers of reorganizing prematurely, reacting without facts, not being able to innovate. One meeting I was in, the team talked about how they couldn’t get the manufacturing costs of Sun systems down to the cost of PC’s.

I learned the hard lesson of “what does the next 5 years look like.” As an employee I had the answer of “what does the next 5 years look like” given to me, but now I am able to answer that question myself. I continually ask this question now.

For Novell, I wanted to be the CEO — my mistake was I didn’t do any due diligence. The first week was one of the worst weeks ever in my career — the books were cooked, customers weren’t paying, and I just wanted to fix things and get out with my reputation intact. In hindsight I was able to overcome all of these issues and this is what led me to join Google.

I had such a tough time at Novell that when I joined Google — I had a deep understanding of cash, revenue, accounting, etc and worked hard to put into practice all of the systems a business needs.

Reid Hoffman: Looking back on it, would you have told your younger self to do anything different pre-Google?

Eric Schmidt: These sorts of questions (“What would you have done differently”) all have the same answer — do things sooner with fewer mistakes.

In hindsight everyone including me: should have fixed this early, should have fired this person sooner, etc. What’s more interesting is what causes me not to make those decisions quicker? Maybe some people are quicker than others at making decisions.

II. Google Days

Reid Hoffman: What was the size and scope of Google when you joined?

Eric Schmidt: When I joined we had 150 people. Larry and Sergei had just raised $25M in venture capital and their VC’s said these guys are brilliant, crazy, and unreliable, so they need a CEO.

Larry and Sergei agreed but their one demand was they would only hire a CEO if they could personally vet them by spending a full weekend with the two of them.

Larry and Sergei took potential candidates skiing, boating, stayed on a farm, went to New York, etc. These trips guaranteed no one would get hired — however when I met them we got along quite well. During our first session I gave them a list of things they needed to fix, and they did it.

Question from the audience: What was on the list?

Eric Schmidt: I actually have the list — I save everything, remember we are Google :)

During the startup phase most startups are full of energy with no process. They use their sheer force and energy to figure stuff out. On my list was a set of things to think about to instill some initial process:

International expansion plan, sales plan, proper accounting, inventory, product development plan, etc. None of these existed at the time.

Being at Google in the early days was like being in graduate school. There were so many interesting projects going on, but no deadlines or plans. The culture felt very much like graduate school at Stanford.

The interesting part however was all of the raw material was there in the room. The trick is all you need to do is to ask the right questions and the answers would come out. For example: If you asked for a product plan, they could create a great product plan — they just didn’t think it was important at the time.

Reid Hoffman: What are the key considerations for mixing together the initial founding team with an outside executive?

Eric Schmidt: Everyone had seen the case where this didn’t work out: John Sculley and Steve Jobs.

Job’s investors thought he needed a CEO, they brought in John, John and Steve didn’t agree and got into a fight, the board supported the CEO, Steve left, started NeXT, sold it back to Apple, replaced the entire board, and took over as CEO again.

This is an amazing achievement in and of itself — something only Steve Jobs could have done. Everyone had seen the dangers of bringing in an external executive into a startup.

I was very aware of this issue from the beginning. The approach I took was: I knew it was their company, I didn’t get this confused. For example I didn’t do any press — Larry and Sergei were on covers of the magazine.

One time before the IPO they did an interview with Playboy. There were no nude pictures but this was during the quiet period time before the IPO and this article put the whole IPO in jeopardy.

Larry and Sergei both looked at me with these long faces, clearly they were sad and distressed and asked if they screwed up? The correct answer was yes they screwed up our entire IPO but the better answer I told them was “Yes it was a mistake, but we could fix it.” From that moment forward Larry and Sergei never did another interview again.

If the founders wanted to do something, I didn’t get in their way. Once they didn’t want to do it anymore, I could do it myself. From this moment forward I started talking to the press myself. If you get confused on this, the relationship will never work.

Since Apple there have been a few partnerships that worked well — Facebook with Sheryl Sandberg, eBay with Meg Whitman, etc. There isn’t one answer or one way to do things.

III. Scaling Google

Reid Hoffman: When you joined Google they were at 150 employees, now Google is well over 60,000 people. In some periods (2004–2005) you had tripled your employees, this is classic Blitzscaling.

Eric Schmidt: I had a saying:

It’s easy to double every year — you can imagine adding a person to each team, adding a country, adding a product line, etc.

It’s hard to quadruple. It’s difficult to even imagine what quadrupling looks like within an organization.

Reid Hoffman: You guys had to invent many of the techniques Google is now famous for — reading every resume, 20% time — what are some of the key scaling techniques which worked and didn’t?

Eric Schmidt: Before any specific examples I want to lay out the cautionary tale — if you don’t understand the subtlety of the lesson, then you will think you need to grow as fast as possible in all areas. This doesn’t work. No product scales before it works.

I have seen the same cycle again and again — great products are created through small teams, with great leaders, who eliminate all non-critical features, while working under extreme pressure, and produce a product that just barely works.

Look at the original iPod and see what it has become. Many people don’t remember that the original iPhone didn’t have any apps, there was no app store. The first version barely worked but it had the right combination to be interesting.

Travis Kalanick of Uber (who Eric Schmidt has a good relationship with through their investment in Uber) understand scaling very well. The first version of Uber was interesting but wasn’t ready to scale yet, you have to have good judgement on when something is ready to scale.

We debated this all of the time at Google and Larry & Sergei would play tricks on me. Once they said they wanted to build an OS in the browser — but I said that we weren’t ready to take on Microsoft. Instead they hired someone to “improve Firefox”. On nights and weekends a small team created what would become Chrome. When I saw the first version, I was shocked. I asked the team if Larry & Sergei knew about the project, and he said they encouraged it. Larry & Sergei basically went around me.

Larry & Sergei said they wouldn’t do an operating system, then we bought Android. I was told Android wasn’t an OS, and look at Android now. Maybe the lesson is I am always wrong but it takes precise judgement to know when these things are ready to scale.

An example of when not to scale was Google Wave. We launched this product to great fanfare and a base of passionate users. The difficult part is you can’t tell if something is successful until 6 months after the initial wave of excitement. Great products have this big fanfare, big drop off, then small bump back upwards, and steady usage upwards. Google Wave on the other hand had a wave of excitement and then a steady drop off downwards.
Once you have an app and business model that works — you can scale and go global fast.

When I first joined Google, I thought the whole thing was a sham. They were using Quickbooks for their accounting and I found many inconsistencies. Instead I looked at the cash balance in the bank, and saw we were in fact making revenue. I asked where our revenue was coming from — advertising, and investigated further. I noticed much of our traffic was coming from overseas but we were only monetizing the U.S., so one of the first things I did was to send the advertising lead to all of the continents to set up our international ad operations in those areas. These have since become some of our largest contributors of revenue.

There is a point when you keep it small, then once you hit the point where it's working, you grow as fast as possible.

Reid Hoffman: Do you have any heuristic when the product is right for scaling?

Eric Schmidt: I have also noticed the greatest products are typically designed for the benefit of the people who are building them.

In Uber’s case, the original product was a private car sharing for a small set of people. Google was built for Stanford but mainly for Larry and Sergei themselves. The first Google server was in their bedroom. Once they outgrew this, they put several servers in their home, the garage, then took over the whole house, etc.

Reid Hoffman: So is the heuristic — just seeing such an impressive demand?

Eric Schmidt: It is tempting to believe you have a product that works before it works.

This is an error especially made by non-technical people. They listen to the technical people who say it works and start to scale the organization before the product is working.

It’s best to think of this process as a very long and tight funnel. It takes a long time to get the product right, then once you get it right you scale up the team as quickly as possible, then go off to a global expansion strategy.

Another way you know a product is ready is when you and your team can’t stop using it. With Wave, no one at Google used Wave, only outside people did. They were nice, but they didn’t continue to use the product, they were just bought into the hype. Google Glass, who in this class wears Google Glass? (no one raised their hand..)

Maybe we need to go from version 1.0 to 1.1? Will a small change really get people to use it? We have 100’s of examples of failed products within Google, but we forget all of them and only remember the successful ones.

Reid Hoffman: Once you have product market fit — what were some of the things which worked and didn’t work with scaling the organization?

Eric Schmidt: We wrote a book called “How Google Works” and 1/3 of the book is about recruiting. Sheryl Sandberg built up much of this at Google.

There is a way to systematically hire people better than anyone else. Bob Taylor who we talked about earlier (taught Eric many of the lessons he uses today) said to “sell the dream.”

Here is how Bob Taylor funded the ARPANET:

• He called people
• Described what he wanted
• They either got it and got incredibly excited or they didn’t
• If they didn’t, he went to the next person

How hard is that? If people don’t get it initially, are they really going to get it after some persuasion? Probably not. You want someone who gets it.

One of the thing Reid Hoffman talks about is to hire generalists. We had very strict rules about this at Google.

I would say we need someone experienced in this layer, someone who can program in Java, who understands SQL, etc. And Larry and Sergei would say that’s the stupidest thing we ever heard. (They did this to partially annoy him). So Eric would ask, who do you want to hire? Their response was we wanted to hire “incredibly intelligent people.” Eric would say "so do I?!"

Larry and Sergei insisted there was a difference though. They wanted to hire “smart people” who would figure out exactly what they needed to do and what tools they needed to use — these people would probably do what you want to do but in a better way than how you want to do it.

You hire people who can get the job done. The industry overvalues experience and undervalues strategic and intellectual flexibility.

For example, even with myself at Google, I didn’t know what to do much of the time, but I knew I had the best team in the world to address all of our challenges. Examples include: our competitors at the time, the shift from direct selling to auction pricing of our ads. The latter is a good example to dive into.

Salar Kamangar who was a biology undergraduate and looked to be about 21 at the time (he was older than that). One day, he announces we are switching our entire revenue system from an “as-sold” model drive by the salesforce to an “auction based” system. If you remember, I was convinced that these ads were being oversold, but our sales people were so good they were maximizing the value of these ads. However Larry and Sergei were on Salar’s side on this one.

I got so worried about this I put in a place a program called the “cash restriction program” (you can imagine the acronym) and we would only spend money on 10am on Fridays. That way I could control the money because I was so worried we were going to go bankrupt trying this experiment.

We turned on this auction and the revenue triples, in day one. I said you are telling me our incredible sales force is underpricing our product by a factor of 3!? I don't know whether this is luck or we were just at the right scale but the lesson is you need ideas like this which have the potential to scale quickly.

My pitch today is to learn machine learning. For people like me we had to write programs that specified exactly what we wanted the program to do. The new set of programmers understand how to have a computer learn something and then the learning model is applied to this problem. This is a much more scalable model, and has the potential to get a much bigger multiplier than anything we had seen before.

IV. Hiring at Google

Reid Hoffman: Is there anything in hiring you want to share or go deeper into?

Eric Schmidt: A few of the rules we had were: we didn’t want to hire your friends, we didn’t want to hire people from “lesser universities,” we only wanted to hire people with very high GPA’s.

The constant problem was somebody was a good employee, had someone they had worked with, who was very loyal, but not from a great university, did not have a high GPA. We would not hire these people. It was controversial.

We relaxed it a bit now, but the fact of the matter is it got us to the point of where we are today. They got us these intelligent generalists from top Universities.

Second thing — when I was at Novell I noticed there were all of these “glue people.” These glue people are nice people that sit between different groups who assist in activities. They are very loyal and people love them, but the reality is you don't need them — they just slow things down.

At Novell I kept trying to get rid of these glue people because they were getting in the way, and every time I got rid of them in one group, they would show up in a different group. I told Larry and Sergei this and they responded, I don’t get what your problem is — why don’t we just review all of the hiring. He was being serious about this.

From that moment on we reviewed every single offer packet — everyone that looked like glue people, weren’t hired. The fact that we never fired anybody, the hiring decision was critically important. The people you hire define the culture, whether you like it or not.

Larry and Sergei wanted to hire smart people so they hired a rocket scientist, a medical doctor, a professional football player, etc. They wanted to find people who were exceptional. For me I was a pilot and had done a few other things so Larry and Sergei thought I was good enough. The CEO had to have something besides being a CEO which made them interesting.

Everyone had something. I would go around and ask “what’s special about you,” everyone always had an interesting story. The important lesson is you don’t hire generic people — you hire people who have had some sort of stress, or achievement, or something. The best people to hire are CFO’s who have gone bankrupt — these people have been through the war.

Reid Hoffman: Early on, the hiring process at Google was known as being very involved — was this a good thing or a bad thing?

Eric Schmidt: I’m not sure if it was good or bad, but it was definitely a deliberate thing.

Once we decided we were going to review every single offer packet — we then figured out how to score everyone. We put everyone on a scoring system on a 1–5 scale.

Sergei said the problem here is the scores would be biased. So we put in a statistical measure where we would look at the average weight of the scores then correlate that with their future performance. A year back we can look at how we graded that employee and how they actually performed.

What we found out that is if the employee was a woman, the score was inversely correlated with performance. It was the most extreme evidence of bias against female candidates. We thought how could this be? We were the most liberal company we were trying to be. Now there is a term for this — it’s called hidden bias.

So we changed the entire way in which we recruit for female candidates and managed to correct this. Here is an example of even for as liberal and analytical of a company as ours — we didn’t realize what we were doing. This is 10+ years now so the good news is we corrected it.

Next we had the problem of people being interviewed. I still remember the packet of this individual we interviewed 16 times. The hiring manager came over and said look you have to make a decision — and the recommendation was to not hire him. I said look — we can’t do this to people anymore So we made a policy that you can’t interview a person more than 8 times.

Over time they have since measured this statistically — for engineers they have 5 interviews and for non-engineers they have 4 interviews. This turns out to be statistically significant. You can systematize things even like this.

Reid Hoffman: Let’s talk about management. Growing an organization this fast must have been a nightmare, how did you manage it? What worked and didn’t work?

Eric Schmidt: My position was simple — Larry and Sergei are running things, it’s chaos anyway, we are just going to run it as a group and run it as fast as we can.

One strategy which didn’t work — we would have a meeting on Monday which we called 60 minutes (but would normally take 2 hours). It was called 60 minutes because you had to be offline, off your computer, off your phone — for 60 minutes. If you were found violating this, there was a fine.

This strategy failed, we found it was impossible to get people off their computers for 1 hour per week.

Another strategy that didn’t work — on Tuesdays we would have a Google Product Strategy meeting. We used this as a checkpoint because there was so much going on, we were launching so many products, people in the company didn’t even know what we're launching.

We put in a launch review process. You couldn’t announce something unless you had gone through the launch review process. We used this as a way to catch the problems early on. For example the engineers worked on things they didn’t tell the support team or lawyers about.

The best example is we had one engineer who built a product to be able to geolocate where your friends were and predict where you were going to be. He demo’s this product and my face goes white, the lawyers say omg, the marketers said omg, and Larry & Sergei loved it.

Larry and Sergei argued that this was a great product, what was wrong with everyone else at the meeting. There was just one minor problem, this was probably illegal. Even if it was legal I wouldn’t want to deal with all of the real time subpoenas because not only do we know where you are but where your friends were — didn’t want to have that information in our database.

Larry and Sergei wanted to do it anyway so the solution to this problem was they added a feature where you could lie about your location which made the legal records unreliable and they launched the product which became Latitude.

A final example is after I discovered we were working on Chrome we had a debate on HTML5, the exclusivity of browsers, and the rate at which we put things into the browser. At the time, Chrome was well behind all of the existing browsers out there. We were having this argument and it was pretty clear that Sergei was not going to give up.

We had this rule that we wouldn’t have huge arguments in public so we kicked everyone out of the room and the three of us had it out. The solution was Larry and Sergei needed to agree on a solution, if they didn’t, I would decide for them. That afternoon they came up with a solution better than anything else we had came up with previously. I used my decision as a forcing function to get them to decide.

V. Team Structure at Google
Reid Hoffman: There are stories that one day everyone worked for Larry, then one day the whole organization was flat, how did you organize people?

Eric Schmidt: I have to tell you about the dis-org. One day in the first year — we were reviewing our engineering plans. At the time we had 5 engineering directors and one VP of engineering.

At the same time we had these things called Snippets in which engineers are supposed to write down what they did per week. Larry was reading the engineering snippets and what the engineers were doing wasn't correlating with what the managers were saying — it wasn’t good.

Larry called everyone in and said "look we have a problem." I asked Larry, "what are we going to do?" Larry said, "we should get rid of all of the managers." I said "we can do that." Larry said, "yes we can."

What we did is we took the 5 managers and made them individual contributors. For all of the 120 engineers, we put them to work under 1 engineering VP. Larry tried to guarantee that this one manager couldn’t interfere with your work. We ran this way for 2 years, the one manager — Bill Coughran — is now a successful VC and jokes about what it was like. The lesson here is you can do extraordinary things, even to the organizational structure itself.

Reid Hoffman: In this blitzscaling phase— what is the role of the CEO?

Eric Schmidt: My role was to manage the chaos. There is different kinds of CEO’s and there is more than one answer.

In any successful company, you have someone who can run very fast, has good product sense, and has emotional leadership of the key stakeholders. In that sense it's like a faculty — the key engineers put up with the management. My job was to organize the world around them.

If you ask Larry and Sergei what they thought when they hired me was “we don’t need you now, but we know we’ll need you in the future.” They were roughly correct. As a small company they were doing fine, but in order to scale you need someone who understands replication and systems.

I set out to hire all of the non-essential executives — which was everyone else besides engineering.
There are other models where you have a technical founder who cedes partial business control — Mark Zuckerberg and Sheryl Sandberg. Mark allows the CFO and Sheryl to run large parts of the company on their own.

Reid Hoffman: Another thesis of Blizscaling is what can you not do for the sake of moving fast? Were there any key decisions on what not to do at Google?

Eric Schmidt: Surprisingly no. Because the ambition was so broad, the only lever I had was to be able to slow certain things down.

I don’t agree that you should narrow your focus, you get the best outcome when you get the broadest appeal.

There were other things, for example, we refused to do exclusive deals with people. The way we said this though was “we don’t do exclusive deals but we have the capacity to work with one partner, and that’s going to be you.”

I’d be careful to conclude to just do a small thing. All success stems from doing one thing very well — then moving broader.

Reid Hoffman: What were the key things that helped Google keep innovating as you scale?

Eric Schmidt: Two which have been publicized are: "Don’t be evil" and "20% time."

"Don’t be evil "— I thought this was a joke in the beginning. I don’t think of anyone as evil. I was sitting in the original conference room and there was a discussion of ad targeting in a particular click — one of the engineers pounds the table and says “that would be evil." I was thinking to myself …ok what just happened. The whole mood of the room changes and there was this huge debate over whether this feature was evil or not. They decided not to make the change.

The analogy here is this is the Kanban system. Any employee can stop the line at anytime. This works because of the strong shared values and shared mission.

20% time — The idea was we could ask our employees to work on the company for 80% of their time, and the other 20% of the time they could work on whatever they wanted. We weren’t too worried because these were engineers and they weren’t going to run off and do something wild.

If they are passionate about something, they could work on it as their 20% project and many of the features which started as projects turned into core features. Part of the management job was the listen for those 20% project ideas and then aggregate them. Marissa Mayer was the key person who would watch for these things. She had a running top 100 idea list and she was constantly curating the list and identifying little ideas that could become big.

Reid Hoffman: How did you guys grow managers within Google?

Eric Schmidt: One program we had which worked very well is our Google APM Program. I would go so far to say this program is one of the largest sources of entrepreneurs in the bay area.

The idea for the program came from Marissa Mayer. She joined Google after undergraduate and became a product manager, she was 1/3 product managers out of the whole company (now Google has 1,000’s of PM’s). She had the idea that we should grow our own product managers and create a new role called an “associate product manager” — we would hire students right out of college with technical degrees who didn’t want to program but work with programmers.

The APM program set out to create training programs for becoming product managers and more importantly they went on trips, did activities together, etc just like in college which helped forge incredibly tight bonds between each APM group. Over time almost all of our execs running key parts of google have came in through this program.

Marissa didn’t know this at the time but Microsoft also had a similar program “technical leaders” who were technical people who didn’t program but wrote all of the product specs for Microsoft.

Reid Hoffman: Was this a key way you populated Google with key strategic leaders?

Eric Schmidt: Yes the APM program was key to this. Another example is we hired this woman named Shona Brown who was a partner at McKinsey but wanted to work a smaller faster growing startup.

We originally gave her the title of “chief business operations” and put her in charge of all the things people didn’t know what to do with. A short while later she comes in and says “I think we should have our own McKinsey operation”. The plan was to just hire the people from McKinsey — specifically the people who would be the associates — and have them do the McKinsey function within Google.

They would come in and study a particular group within Google for 1–2 years, and then afterwards go and join the group they were studying. We decided to give it a try.

One of the early members of this group studied YouTube and has since joined to run half of YouTube today. Another example is Dennis Woodside who went through a similar program, and is now the COO of Dropbox.

These people who have business analytic skills — are very useful. Whenever we had problems with business units or how business units interacted with one another — we would take one of these people to help solve the problem. We thought of it as an internal stable of talent, similar to how the APM program worked.

Question from the audience: What are the most counterintuitive signs of talent, especially at a young age?

Eric Schmidt: I will share the story of Noam (I think it’s Noam Shazeer?).

Noam went to UC Berkeley, was in the math department, and at age 19 got bored and dropped out. He applied to Google and got rejected but someone who knew him at Google said — you should talk to him.

He shows up and he is very unusual but had developed this way to do spelling correction — so they hired him to work on that. He comes to Google and invents the “spelling correction”, which is a huge achievement. We have another rule now: “If the person doesn’t meet our criteria, but is super smart — hire them anyway”.

6 months later Noam see me getting dinner on a Friday night. He rushes over and says I need 10K machines now (at the time this was a lot). I asked him “what are you going to do with 10K machines” and Noam responses: “I will solve general knowledge by the weekend”. So I went over to the guy in charge of machines and I said give Noam as many machines as he needs.

Noam turns on the software, and the program stops. Today Noam is still trying to solve general artificial intelligence, and if there is anyone I can think of who can do it, it would be him.

The lesson is talk the person and figure out what they want to do — if they have a path give them a shot at doing it. There are always odd cases and this is the best way to handle them.

Reid Hoffman: How important is it to have separable groups? Andorid group? Google X? etc?

Eric Schmidt: This problem hasn’t been solved, it’s just a mess.

The correct answer is 2 people can go off and change the world. Every successful project I have worked on within Google over the past 40 years has started off with 2 people working on an idea together.

Examples: Windows was started by one person, UNIX was 2 people, Java was started by 1 person, Gmail was started by 2 people, Android small team, Linux was started by 1 person, and I could go on and on.

One day someone asked to meet with the Google Docs team and realized there was 150 people working on this product line. The question is what do all of these people do? The answer is the projects today require many more resources: internationalization, integrations, etc.

The point here I am making is — one of the complaints I have is the teams who are doing the work with the products you see — are far larger than they should be. This is a failure of architecture — when you have this many programmers programing, it means they don’t have the right libraries, aka the problem hasn’t been generalized enough. It is my hope we can fix this problem.

Reid Hoffman: How do you think about separability, so you don't have to deal with cross coordination between teams?

Eric Schmidt: Computer scientists understand this issue well — it's called interface and API’s. One of our problems is the system we built is incredibly powerful but it is so co-mingled with itself.

Within Google there is a huge initiative to put services within Google Compute which is the externalization of this which requires API’s. I never want to do a platform product without an appropriate user app that goes along with it with a well designed interface. If you can maintain this discipline, you can do great things.

For example if you are a startup you are likely using AWS. What’s unique with these interfaces is anyone can pick them up and use them. They are intuitive and straightforward, it has limitations but represents good design.

John Lilly: To scale this all the way up, if you do this by the organization design — is this Alphabet?

Eric Schmidt: There is a size at which companies fall in on themselves

Google has done well because the 2 founders are so technical, so brilliant, and so opinionated about all the products they do. I would argue that Apple, Amazon, Facebook, etc have all done the same things. Each of these companies has a strong founder, a strong culture, and strong product focus.

Steve Jobs told us that the problem with Google is we had too many things going on. His vision was a small number of incredibly well done products. We could debate this but Apple’s success speaks for itself.

In our case we have hit a mission scale problem. We spent 2 years arguing about this — our argument was — should we change the logo? The mission was “all of the world’s information” — how do you match that up with cars, biology, etc.

Larry and Sergei were thinking about this and we all visited Warren Buffet, just the four of us together. This meeting made a really big impression on them. 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 before in the history of America business — it’s a big bet.

It’s typical of Google but we announced this without even knowing what the initial Alphabet companies would be. We would ask people how many Alphabet companies are there, and what are they? — Of course there wasn’t an answer at the time. No rational company would have ever done this, our approach was just get started and work out the rest as you go along.

We’ve said publicly Calico, Access, and a few others are coming. Also characteristically of Google we aren’t doing this half-way — we trying to push the Alphabet companies to be true separate companies — this is inspired by Warren Buffet. He loves to hire people who do the jobs whether he hired the or not — he knows they are going to work hard. We needed to have an organization structure that which attract these kinds of leaders.

The leaders who come on to run Alphabet companies are the CEO of that company — they bear the risk, the downside, and the upside of their company.

Reid Hoffman: If you are giving advice to entrepreneurs —what are the key things that made google win?

Eric Schmidt: First it’s the right founders. The founders have to be smart and good but more importantly the project they are working on — it needs to be their lifes work.

Secondly is you need to have some luck. In our case, search and ads we developed turned out to be a goldmine of revenue. Once we figured out people were in fact clicking our ads — we worked to maximize revenue from this business — it just went up and to the right from there.You maximize it by making the ads more relevant, making them more useful, etc.

The fact that we fell into a very high gross margin business very early — gave us the ability to take risk. So when I talk to founders I ask — how much gross margin do you have? how much flexibility do you have? I’ve been so lucky I forget there are other businesses with low margins out there.

So you want to be careful on how much margin you have. The ideal business is to have a business like Microsoft — a monopoly software business with hardware competitors — who are competing for good treatment by you — in a growing industry.

Another example is Uber — they spend a lot of time talking about how the drivers don’t work for them. There is a reason for this — it’s not the legal reason. It’s because if you think of them as a software infrastructure company, they have very different economics than a cab company. In that sense it's a modern version of the franchisee.

Why do hotels (like the Four Seasons) not own the buildings? It's better to be an operator with a fixed revenue share — and let other people ride the real estate up and downs.

Took me awhile to write these notes, lots of great stuff in here. Looking forward to the next class.