In this 2008 video, Jonathan Rosenberg, VP, Google, talks candidly about product management, innovation, their hiring process, bozos and specialists, product selection, managing dispersed teams, the "20% time" and acquisitions. Although a bit dated, the interview is still revealing  Particularly in how the company has instrumented itself for innovation.

An annotated log of the video, with links, is included in the post, too.

In 2008, Bill Campbell, Intuit's Chairman, interviewed Jonathan Rosenberg, Google's VP Product Management, at the annual Think Tomorrow ~ Today event.

The subject of innovation came up three times during this 42-minute interview. A little past the 10 minute mark, Bill asked Jonathan how "innovation, how is it different in a technology company."  Later, after Jonathan had talked at length about how Google hires great people, Bill again asked "let's assume that we can attract these great people and these great people, in fact, inspire innovation–how? how does innovation occur?"   Towards the end of the interview, the well-known "20% time" came up, and this, too, very much linked back to the topic of how innovation happens at Google.

Besides inspiration and perspiration, effective innovation needs a way of getting out the door repeatedly, not by accident. Jonathan describes how this "machinery" works at Google.

Who? The Engineers!

First, he touches on who should be in charge of driving the dynamics of future products. To Jonathan, and Google, the answer clearly is the engineers. Because they are, he claims, the people most likely to understand at a gut level the implication of up and coming technologies and trends. The can visualize, in its entirety, what capabilities can be expected to be available in future and, therefore, what products should look like to take advantage of these new technologies. (Hopefully, in a disruptive way.)

Hire Smarter

Of course, Google tries very hard (and sometimes in strange ways) to make sure that they "hire smarter."  Jonathan explains that if everybody follows the rule of hiring people smarter than oneself, then it creates a "network effect," a virtuous cycle of good engineers attracting great engineers, attracting even greater engineers.

That is pretty much the same rule that we had at Sun Microsystems in the early years. And it worked for a while, but as a friend of mine (who now works at Google) liked to say, "if you hire everybody in the world, you'll end up hiring the average."

The difference I see is that Google has a explicit process for making sure that they hire really good candidates (even if not always the best). Their system is fact-based, rather than it being dominated by the loudest person in the room (or, at least, it strives to be so).

Process: The Approval Meeting

As Jonathan explains it, at an Approval Meeting,

1. Everybody gets a packet for each candidate.
2. Each packet includes the original CV.
3. Each packet also includes feedback from every interviewer.
4. The feedback consists of facts, not opinions: what questions did you ask? what answers did you get? and, what revelation you got from those answers?
5. Then, everybody reads the packet, in silence. Once everybody's read the packet, the arguments… er… I mean, the discussion begins.
6. You can only argue based on information included in the packet. If you had extra info and you didn't include it in the packet, it's not fair to bring up at the meeting.
7. At the end, the team comes to "some kind of consensus."

It may not be perfect, but it is, as much as possible, fact-based and consistent. Every candidate goes through the same process, regardless of role. We didn't have that at Sun. It was only later in the life of the company that we introduced Behavioral Interviewing and other techniques, but they weren't used consistently throughout.

At this point Bill jumped to the edge of his chair and asked Jonathan, "but, is it scalable?"  Johnathan spread his arms and said "YES!" Nevertheless, Bill could not help but retorting with "It has, till now."

How? With Social Rewards!

In explaining how Google encourages people to innovate, he quickly mentioned "y'know, the cafeterias, and you walk the dogs and all that sort of stuff."  He also mentioned that "you have to get the important people, who are going to have the brilliant ideas, who are generally the engineers and create a culture where they understand how important innovation is."  But he really spent time talking about The Ideas Meeting, a social reward process that works by creating visibility and giving ideas, and the people behind it, a stage and a forum.

Process: The Ideas Meeting

Here's how Jonathan explained The Ideas Meeting process,

1. Show up.
2. Talk about an idea.
3. When people got bored, you were booted off the stage.
4. Else, you get more time.

Before Bill could ask, Jonathan acknowledged that this process worked "when we were small," but it did not scale as is. They extended it with an Ideas Distribution List, where ideas get voted on via email. This voting in essence creates a funnel of ideas and the ones that get the most votes, get to present at The Ideas Meeting.

"That actually scaled" and, in fact, they're practicing it in all their remote offices.

Note that this is a social reward process. There are no bonuses or other monetary rewards for generating ideas.

The act of presenting at The Ideas Meeting gives engineers "a badge of prestige … the pride of showing off to your peers with your ideas."  The process has worked and has generated disruptive, monetizable results.

Process: To Demoware and Beyond

Now, here's the interesting part,

1. If people like an idea and it looks like a good one, "feed the winner…"
2. The engineer can quit what he's doing and work on the new idea full time.
3. In fact, they then put together a small team and crowd them together in a space the size of a small garage.
4. Make sure to "include two or three really smart engineers" in the team.
5. Then "leave them alone for a while and come back later."

The result of this effort is usually a good demo. If that's promising, then it is the management teams' job to remove whatever obstacles stand between the innovation and production (or eternal Beta as it's often the case with Google products).

It's Not Just about Good Ideas

What this illustrates is that successful innovations don't make it to market by accident. The whole lifecycle, from idea generation to production through every stage in between, progresses from one stepping stone to the next (i.e., the "Process" steps above). If a stone is missing ("great idea, why don't you work on it on the side"), the process breaks down and potential innovations will die in their infancy.

Putting policies and practices in place, like the "20% Time" policy, helps the company generate a bunch of experiments to feed the innovation pipeline. It also a way for Google to "guard against, y'know, imperial, dictator types of management."

Time Log

Here's the log of all questions Bill asked throughout the interview:

05:43 Product Management

• How product management is different at Google, because it has to be.
• With the technology base changing so dramatically, so quickly, new products must take advantage of future conditions.

08:36 Feed the Winners, Starve the Losers

• Jonathan gives a couple of examples of how Google practices its own form of "creative destruction" internally.

As Tim Kastelle, Dennis Baron and others have written, "every innovation has to fight to find space for itself in the world."

11:10 How Is Innovation Different in a Technology Company (Ι)

• You have to build for where the technology is going to be. "Those dynamics change everything."

13:53 People/Hiring

• "It's the network effect" (and may the best network win).
• Don't hire specialists.
• Hire people who are smarter than you are.
• Go back to the technology base because, again, everything's changing.
• New hires do not (cannot) have experience with future technologies. Find people who know how to learn.

17:18 Bozos and Specialists

• As an example of a potential "bozo" Jonathan mentioned a "Trainer." According to Jonathan, Larry Page thinks that a trainer "is like a High School Principal, it is somebody who gets in your way, not somebody who's great at teaching."

This "example" struck me as offensive and arrogant. It was a jarring turn on an otherwise delightful interview.

19:19 Recruiting Process

• We don't want the people who are applying, we want the best people in the world.

21:46 The Recruiting Dynamics and the Selection Process

• See "Approval Meeting," above.

24:13 How to Get Great People to Innovate

• Eliminate things that get in the way of innovation.
• Put engineers are at the center of it (people who are going to have the brilliant ideas).
• Create a culture where they understand how important innovation is.
• Then create visibility (see The Ideas Meeting, above).

28:05 Remote Offices

• Find talent everywhere in the world.
• Do remote offices contribute or stifle innovation?
• Created "focus areas."
• Each office works on two or three focus areas.
• Rosing & Rosenberg first thought to make teams equal (in size). That didn't work. They drift apart and split into two separate teams.
• Video conference sucks/counterproductive.
• Instead, make the team aberrantly different in size.
• One team is dominant; the other team has to work hard to be noticed/included.

You'll be he judge of it, but it didn't sound to me like the Jury is yet out on this experiment, but one aspect of it resonates with me. In my experience, teams that are farther than two time zones apart, naturally drift apart into separate teams. In fact, at Nearsoft we limit our clientele to within 0-1 time zones to avoid that very situation.

One of the things I did at Sun Micro was to manage the Graphics and Multimedia group. We started with "aberrantly asymmetric" teams and that didn't work worth a damn (note: the locations were three time zones apart). We reorganized so that each office was responsible for a technology and all its associated deliverables (e.g., 3D Graphics in California and Video in North Carolina) and that worked a lot better.

31:30 The Number of Projects Going On in Parallel

• Prioritization, how to focus on "the right thing."
• Feed the winner, …
• That's management's judgment call
• Project that looks promising AT THE DEMO STAGE.
• Give them what they need to allow them to show them to you.
• Then get obstacles out of the way.
• Judgment based on demos.
• Else, put it in Labs or somewhere else to show "eric" that he is wrong

33:49 Larry and Sergey and Eric and Product Prioritization

• Larry is more focused on "product… guardian of the end user."
• Eric focused on big arch/strategic decisions.
• Sergey is the "cool" spotter; also, what's the impact on the world.

35:14 The 20% Time

• Prevent total domination of management.
• Get something over a hurdle to show it, make it a demo, get people excited.
• Then apply distribution and engr talent to move it to product quickly.
• Can be apportioned however: daily/weekly/monthly/yearly.

37:09 Acquisitions

• Keyhole/Google Earth.
• How will you monetize? i don't know.
• As it played out… it got them more distribution than they expected.
• Google Earth > Google Maps > Google Local
• Again, measure future opportunity in the future context.
• YouTube, Jonathan managed it.
• Eric's advice: work with Chad and Steve as Eric worked Larry and Sergey.
• Treat them as founders.
• They understand the community better than anybody.