Blitzscaling 08: Eric Schmidt on Structuring Teams and Scaling Google

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.

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

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.

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