Blitzscaling 08: Eric Schmidt on Structuring Teams and Scaling Google

• During the early days, most startups are full of energy with no process. They use their sheer force and energy to figure stuff out.
• 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 interesting part 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.

When Eric Schmidt joined Google, they were at 150 employees. In some periods (2004–2005), he had tripled their employees; this is classic Blitzscaling.

The approach: 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.

No product scales before it works.

An example of when not to scale was Google Wave. It was launched 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 a 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.

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.

• 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.

There is a way to systematically hire people better than anyone else. Bob Taylor (founder of ARPANET) said to “sell the dream.”

Here is his approach:

• 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.

• Stay away from "friends of friends". 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, and did not have a high GPA.
• Stay away from "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.

I don’t agree that you should narrow your focus, you get the best outcome when you get the broadest appeal. (...) I’d be careful to conclude to just do a small thing. All success stems from doing one thing very well — then moving broader.

The idea is you could ask your employees to work on the company for 80% of their time, and the other 20% of the time they could work on whatever they want.

If they are passionate about something, they could work on it as their 20% project. At Google, many of the features started as projects turned into core features. Part of the management job was to listen for those 20% project ideas and then aggregate them.

One major complaint 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 programming, it means they don’t have the right libraries, aka the problem hasn’t been generalized enough.

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.

• The right founders. The founders have to be smart and good but more importantly the project they are working on needs to be their life's work.
• You need to have some luck.
• Be careful about 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.