I’m Feeling Lucky: The Confessions of Google Employee Number 59 by Douglas Edwards

Hooray!  I can now sync the highlights that I make in books from my Kindle Fire.

I just finished “I’m Feeling Lucky: The Confessions of Google Employee Number 59″ by Douglas Edwards.  Prior to reading this book I didn’t really know much about the history or culture of google.  I enjoyed the narrative.  I noticed some reviewers didn’t feel like it gave a balanced view of Google.  I’m sure it doesn’t.  But it does give a detailed personal account from one close insider.  Here are the things I highlighted.  Mostly I was curious about the engineering culture, and recruiting strategy.  

The technical staff were all tucked into that space because the engineers were literally the core of the company. Great things would come from packing them tightly together so that ideas bounced into one another, colliding and recombining in new, more potent ways.   (location 382)

Urs’s most significant accomplishment, however, was building the team that built Google. “Your greatest impact as an engineer comes through hiring someone who is as exhorted everyone who would listen, “because over the next year, they double your productivity. There’s nothing else you can do to double your productivity. Even if you’re a genius, that’s extremely unlikely to happen.”   (location 776)

Two such hires were Jeff Dean and Sanjay Ghemawat. If Urs was Google’s architect, Jeff and Sanjay were the master carpenters who raised the roof beams and pounded the nails that held together the load-bearing walls. Wherever problems needed to be solved, “JeffnSanjay” were there*—from devising the Google file system to developing advertising technology, from accelerating machine translation to building breakthrough tools like MapReduce.   (location 782)

… placing recruiting ads on Google that appeared whenever someone searched for obscure coding-related keywords like “TLB shootdown” or “lock free synchronization.” (After engineer Paul Haahr joined Google, he told Jeff, “Any company that advertises on ‘lock free synchronization’ is good enough for me.”)   (location 798)

Had NewsHound been a disruptive technology that changed its industry, Larry and Sergey would have wanted not just the code but the Google-caliber engineers behind it. That way, Google would own their future breakthrough ideas as well as the ones they’d already developed. Larry and Sergey didn’t like renting intelligence when they could buy it. There are only so many really smart people in the world. Why not collect them all?    (location 870)

…there might be a role for a product-management group if, and only if, it didn’t usurp the divinely ordained primacy of engineering. God forbid that Google become a marketing-driven company. In marketing-driven companies, researchers identified customer needs and then product managers (PMs)* directed engineers to create products to fill those gaps. I had been taught that was a good thing to do.    (location 1052)

Doerr’s corporate growth regimen comprised a system for setting goals and measuring progress that he called Objectives and Key Results or OKRs.  “Objectives,” Doerr instructed Larry and Sergey, “should be significant and communicate action. They state what you want to accomplish, while key results detail how you will accomplish those goals.” Key results, therefore, should be aggressive, measurable, and time-specific. Doerr warned the founders not to overdo it: five objectives with four key results each should be sufficient.    (location 1077)

In a company filled with overachievers, I assumed everyone would accomplish all their OKRs. No. It turned out that that would indicate failure. The ideal success rate was seventy percent, which showed we were stretching ourselves. Larry and Sergey assured us that missing OKRs wouldn’t factor into performance reviews, because if they did we would take too few risks.    (location 1087)

“When Urs put me in charge of UI,” she reminded us, “he said we didn’t need opinions. We need facts and research to base good UI decisions on.”    (location 1141)

At Google, quick mockups ruled, data persuaded, and decisions were made in hours.    (location 1311)

Insecurity was a game all Googlers could play, especially about intellectual inferiority. Everyone but a handful felt they were bringing down the curve. I began to realize how closely self-doubt was linked to ambition and how adeptly Google leveraged the latter to inflate the former—urging us to pull ever harder to advance not just ourselves but the company as a whole.     (location 1501)

“Google hires really bright, insecure people and then applies sufficient pressure that no matter how hard they work, they’re never able to consider themselves successful. Look at all the kids in my group who work absurd hours and still feel they’re not keeping up with everyone else.”     (location 1505)

I had to agree that fear of inadequacy was a useful lever for prying the last erg of productivity out of dedicated employees. Everyone wanted to prove they belonged among the elite club of Google contributors. The manager who articulated that theory, though, considered himself too secure to play that game. Which may be why he lasted less than a year at Google.    (location 1507)

Urs insisted on adopting the best practices he had seen in more industrial settings to things like source control and compiler warnings. “We’d make sure the compiler actually failed if it had a warning, so you couldn’t ignore it,” he told me. He formalized the most important elements into a style guide, which became a mandate enforced by Craig Silverstein.   (location 1517)

“You get to pick one good engineering practice to be your cultural touchstone,” Craig said, “and for us it was code reviews.” To initiate a review, a coder would send out a pointer to an online design document. Anyone could respond with comments, but an official reviewer had to sign off on the actual code.  (location 1533)

“A good team is ultimately what makes or breaks the problem,” Urs explained years later. “If the team isn’t the right one, they make little mistakes that erode the solution and in the end, you don’t know what mistake you made, but it doesn’t work. You need the control every day, every week. A new person will make little tiny judgment calls and not realize the cumulative effect. So after a few months you have actually destroyed the idea while you made no recognizable mistake. It was a sequence of small things.” (location 1562)

Much has been written about Google’s free meal plan (one estimate put the cost at seventy-two million dollars per year),* but the basics of the program were simple: lunch and dinner were free, and we could eat as much as we liked from our first day with the company until our last. Like most Googlers, I spent less than half an hour at lunch and, if on deadline, would just retreat with a plate to my desk. Without the café, I would have lost twenty minutes getting to a restaurant, half an hour eating, and another twenty minutes getting back. I would have stopped thinking about Google as soon as I cleared the front door so I could focus on consuming fatty, salt-saturated foods on my way to increased sick days and a premature death. Looked at that way, the policy made sense to me.  (location 1699)

And when Larry was done, he was done. “I don’t want to talk about this anymore. It’s not worth discussing. Just do it.”  (location 1774)

“Larry and Sergey had an expectation that things would be watered down along the way,” he explained. “Starting with something that’s more ambitious will get you something that’s reasonable. But if you don’t put the goal post way out there, people are already taking fewer risks and are less ambitious about how big the idea should be.” (location 1950)

I rarely heard profanity in the halls of the Googleplex, where raised voices raised eyebrows. People could be infuriating, but the approved response was to bludgeon them with facts until they succumbed to superior logic. Not that Larry and Sergey couldn’t be caustic, even to each other. David Krane, who traveled extensively with the founders, sums up their relationship this way: “Those guys had a communications channel that was very direct, very open. When there was tension, it was when they were fighting over data. They would be downright rude to each other, confidently dismissing ideas as stupid or naive or calling each other bastards. But no one would pout.” (location 1998)

Think big. Stay flexible. Embrace data. Be efficient and economical in the extreme. I was mapping Google’s unique terrain and starting to feel less like a toddler lost in the wilderness and more like an intrepid explorer boldly exploring terra incognita. (location 2106)

All that effort without any inkling of what our overall company priorities or strategy might be. I began to suspect that my new employer’s expectations were always going to exceed my capacity by at least thirty percent. (location 2211)

So I needed to stop saying “Here’s my concern,” and start saying “Here’s what you need to do to make that happen.”  (location 2276)

“Good enough is good enough” was the standard Urs set for engineering. In those five words he encapsulated a philosophy for solving problems, cutting through complexity, and embracing failure. It should be stitched into the fabric of every cubicle at Google. It drove Google’s software development, the heart and soul of the company’s technology.  (location 2356)

“Hire ability over experience.”* Brilliant generalists could reprogram themselves like stem cells within the corporate body: they would solve a problem, then morph and move on to attack the next challenge.  (location 2379)

“The key thing,” Urs said, “was that they be able to independently make progress, because there wasn’t much room for babysitting. They had to have good judgment about whether to coordinate or not.”  (location 2381)

I was to identify key issues, then solve them or learn how to solve them. Saying “I can’t do that, because I don’t know how” revealed a deficiency of initiative, flexibility, and perhaps even IQ. It was a shock to my sense of the way an office operated.  (location 2388)

Matt Cutts, who carved out a niche attacking the porn and spam that degraded search results, summed up our staffing philosophy this way: “It works pretty well if you hire really smart people who are flexible and can get things done. Then just throw them into the deep end of the pool.”  (location 2393)

The tone set by Urs in engineering was the tone for all of Google. The company stacked its payroll with high achievers unaccustomed to going unacknowledged, and despite the stock options and the free food, they often felt underappreciated. At the same time, many felt unsure of their own contributions or where they stood in relation to their peers.  (location 2427)

“You have to say both emotionally and intellectually, ‘I can only work so many hours. The best I can do is make good use of these hours and prioritize the right way so I spend my time on the things that are most important.’ Then if I see something below the line that is broken and I can fix it, it’s important not to try to fix it. Because you’re going to hurt yourself. Either personally—because you add another hour and that’s not sustainable—or you’re going to hurt something that’s above the line that’s not getting the hours that it should.”  (location 2448)

“Screw quality,” Urs instructed one development team, urging them on to an earlier launch date. “Screw anything you can screw.”  (location 2452)

In Google’s culture, when you ran into a wall, you built a ladder. If there was a moat beyond the wall, you made a boat. If there was a crocodile in the moat, you fed it one of your arms and used the other to paddle across. The takeaway was “Take responsibility. Do something.”  (location 2489)

Neither Larry nor Sergey had been to business school or run a large corporation, but Larry had studied more than two hundred business books to prepare for his role running Google as a competitive entity. He trusted his own synthesis of what he had read as much as anything he might have picked up in a classroom.  (location 2573)

…buy-in wasn’t a requirement. If there were holdouts, Urs would call a meeting and announce, “Okay, fine, we’ve argued for a week. There are no new insights being produced. Let’s do the pros and cons and make a decision and move on. Because it’s time to move on.” (location 2672)

Of all the elements of “big-company thinking” I had to unlearn, that was one of the hardest. I constantly sought reassurance that I was empowered to move to the next step, only to be asked, “Why haven’t you finished that already?” The upside of this philosophy is that Google did things quickly, most of which turned out to be positive. The downside is that individual Googlers sometimes misinterpreted exactly how much power they possessed and when it was okay to use it.  (location 2773)

“This wasn’t the burning problem of the day,” Urs told me. “The site wasn’t down because of it; it was just a productivity problem. If you stayed in the old, messy world too long, your effectiveness would continue to go down.” He gave the green light in the fall of 1999 to create a new codebase called Google Two. New systems would run on Google Two, and the original codebase would be phased out. Jeff and Craig started working on it, but writing new infrastructure took time—and time refused to stand still, even for the engineers at Google.  (location 2983)

The day after the deal went live, John Bauer added code that boldfaced the keyword a user had searched for when it appeared in an ad, making it obvious that the ad was relevant. That single improvement increased clickthrough rates by four hundred percent. One engineer. One change. Four hundred percent.  (location 5296)

Paul liked to hack things together. One night, he and Sanjeev went through his inbox one email at a time and tried to manually match each message to an ad already in the system. It wasn’t that hard. Paul decided to put together a simple prototype that would do the matching automatically. He rummaged around his code files and came up with a classifier tool: software that could identify things that were related and group them. He had written it as part of Matt Cutts’s porn filter project. Perfect for what he had in mind now. He reconfigured the porn classifier to match ads to the content of emails, flipped it on for all the users of Caribou at three a.m., and went home.  (location 5606)

For Paul, the experience confirmed the power of prototyping to give definitive answers far more quickly than theoretical discussions. “Experiencing something is much more powerful than just talking about it,” he reflected. “I didn’t think content-targeted ads would work, really, but I thought it would be fun. I spent a few hours working on it. It wasn’t that I believed in it that strongly, it’s just that it was really easy.” Once people saw the prototype in action they realized, whether they liked Paul’s implementation or not, that content targeting could be done.  (location 5637)

“I feel like the concept of twenty-percent time came out of that,” Paul told me. “I don’t think it was ever specifically stated, but it was more officially endorsed after that.”  (location 5646)

We stretched in the skin of our new headquarters and settled in to a new level of hyper-productivity. Everything needed to be done right now and everything was very important. New people were climbing onboard every week and taking control of projects in motion. (location 6265)

About brendansterne

Sr Director, Indeed.com Product Incubator
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s