# How Google Works ## Metadata * Author: [Eric Schmidt and Jonathan Rosenberg](https://www.amazon.comundefined) * ASIN: B00HUU13Y0 * ISBN: 1444792490 * Reference: https://www.amazon.com/dp/B00HUU13Y0 * [Kindle link](kindle://book?action=open&asin=B00HUU13Y0) ## Highlights For years, Google’s primary tool for managing the company’s resources was a spreadsheet with a ranked list of the company’s top 100 projects, which was available for anyone to see and debated in semi-quarterly meetings. These meetings were part status update, part resource allocation, and part brainstorming. The system was not very scientific: Most projects were prioritized on a scale of 1 to 5, but there was also room on the list for projects categorized as “new / far out” and “skunkworks.” (Today we can’t recall the distinction between the two, but at the time it all made perfect sense… sort of.) — location: [532](kindle://book?action=open&asin=B00HUU13Y0&location=532) ^ref-46039 --- He wanted to build the traditional, doomed-for-obsolescence-before-the-ink-dries type of business plan to which he was accustomed, but his team of deputies—Marissa Mayer, Salar Kamangar, and Susan Wojcicki—stopped him.61 The company didn’t need to document its plan (or even have one), they argued, but in order to hire new people and keep everyone moving in the same direction, it did need to document the foundation for that plan. Give Googlers those foundational elements, Salar, Marissa, and Susan said, and they would figure out the rest. The result was a presentation entitled “Google Strategy: Past, Present, and Future.” We delivered it to the board in October 2002 (setting the stage for Mike Moritz’s request for a more comprehensive plan the following summer), and components of it continued to be used to describe Google’s approach for years thereafter. The principles that it describes were quite different from those of the normal late-’90s dot-com, and today they stand as a foundational blueprint for how to create an Internet Century success story: Bet on technical insights that help solve a big problem in a novel way, optimize for scale, not for revenue, and let great products grow the market for everyone. — location: [1331](kindle://book?action=open&asin=B00HUU13Y0&location=1331) ^ref-57364 --- In the summer of 2004, a Google engineer named Kevin Gibbs came up with an idea. He described it as a system to “perform real-time completion against all URLs in our repository and all historical Google search queries, with results sorted by their overall popularity.” In English, this means that Google would try to anticipate what your query was and suggest ways to complete it. Working in his spare time, Kevin developed a prototype and sent a description of his incipient project to an email list for people who wanted to share new ideas.183 The note included a link to his prototype, where people could enter queries into Google search and watch the system perform the real-time completion. The prototype drew the interest of several other engineers, who joined Kevin’s project. (Derek Sivers would call these engineers Kevin’s first followers.) This feature, now called Google Suggest, is why, when you type “we”, Google suggests that you are looking for the weather forecast and provides you with a drop-down menu to click on the full query without needing to type the whole thing out yourself. Google Suggest shaves seconds off search times and helps users get exactly what they need even more quickly. One guy, from idea to launch to global availability to “how did we ever live without it?” for billions of people, in just a few years. — location: [3415](kindle://book?action=open&asin=B00HUU13Y0&location=3415) ^ref-42841 --- This is the power of 20 percent time,184 the Google program whereby engineers can spend 20 percent of their time working on whatever they choose. Twenty percent time has spawned a host of great products—Google Now, Google News, transit information on Google Maps, and many more—but it is generally misunderstood. It’s not about time, it’s about freedom.185 The program doesn’t mean that the campus turns into summer camp every Friday, with all the engineers goofing off in (hopefully) creative ways. In fact, 20 percent time is more like 120 percent time, since it often occurs on nights and weekends. But it can also be stored up and used all at once—Jonathan had one product manager take a summer to work on a 20 percent project. Regardless of when you take your 20 percent time, assuming it doesn’t get in the way of doing your regular job, no one can stop you from doing it. Twenty percent time is a check and balance on imperial managers, a way to give people permission to work on stuff they aren’t supposed to work on. It helps bring to life the Steve Jobs maxim that “you have to be run by ideas, not hierarchy.”186 And we have found that when you trust people with freedom, they generally do not waste it on extravagant pies in the sky. You don’t get software engineers writing operas—they write code.187 The Street View trike, which lets us capture ground-level photos along streets and paths too narrow for cars, got its start when Street View cars engineer Dan Ratner went on a trip to Spain. When Dan had to walk the last stretch to his Barcelona hotel through narrow alleyways where his cab couldn’t drive, he realized there was a lot of great stuff that the Street View cars couldn’t access. When he returned home, he initiated a 20 percent project building a tricycle that could navigate these places, and the Street View trike was born. It has since been adapted to snowmobiles (to chronicle the ski runs at the Vancouver Olympics, for example) and pushcarts (to walk the halls of some of the world’s great museums). — location: [3425](kindle://book?action=open&asin=B00HUU13Y0&location=3425) ^ref-5564 --- When Paul Buchheit decided that email could be a lot better, he started a 20 percent project he called Caribou. At some point, he decided that his… — location: [3444](kindle://book?action=open&asin=B00HUU13Y0&location=3444) ^ref-36095 --- To innovate, you must learn to fail well. Learn from your mistakes: Any failed project should yield valuable technical, user, and market insights that can help inform the next effort. Morph ideas, don’t kill them: Most of the world’s great innovations started out with entirely different applications, so when you end a project, look carefully at its components to see how they might be reapplied elsewhere. As Larry says, if you are thinking big enough it is very hard to fail completely. There is usually something very valuable left over. And don’t stigmatize the team that failed: Make sure they land good internal jobs. The next innovators will be watching to see if the failed team is punished. Their failure shouldn’t be celebrated, but it is a badge of honor of sorts. At least they tried. — location: [3591](kindle://book?action=open&asin=B00HUU13Y0&location=3591) ^ref-404 ---