Authors: Douglas Edwards
"Even if something starts big, it decays in importance as you work on it because you fix some parts of it," Urs informed me. "At some point all the problems above the line that are really important are being worked on. That is my definition of success: if you do a good job hiring, you get the luxury of actually doing it right and the luxury of going far beyond what you 'need to do.'"
*
I touched on the importance of hiring back in the Introduction, and I'll touch on it again in the pages that follow. Urs made it clear that adding talented staff cured everything but male-pattern baldness. Larry and Sergey agreed—as long as the new staffers' talents lay in the technical realm. I was able to hire a marketing coordinator, but for a long time the only bodies added to Cindy's group worked on public relations. That meant I had plenty to do updating the content of our website while overseeing our ad partnerships, affiliate program, and user-support service.
Larry and Sergey wanted to keep Google's ratio of engineers to non-engineers at fifty-fifty, but in the dot-com feeding frenzy the pickings were slim. And hiring was the one area in which Urs would accept nothing less than perfection. "In April 2000," he told me, we didn't make a single offer. Our plan was to hire three to four people per month. We asked, 'Did we make a mistake? Maybe we're too tough? We can't succeed if we don't get people in.' We looked at all of them and said, 'No, actually, this was the right decision.'"
Fortunately (for almost no one but Google), the dot-com bubble burst the following month. Coders suddenly warmed up to cold calls from recruiters, and Urs began collecting résumés that matched the profile of a good Google engineer.
"Nobody had experience with search engines," Urs recalls. "What was most important was what else they had done, how good they were technically, and how quickly they could learn." He dictated a mantra to Google's HR staff: "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.
"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."
Google generalists needed a firm grasp, not just of coding, but of the hardware and performance issues essential to scaling the search engine. Most recent computer science grads didn't have that breadth of knowledge, but Urs and the founders remained adamant that offers be extended only to those who could retool quickly. "It was too hard to predict where the next fire would be," Urs explained. "If you only know how to do
A
and it turns out the company moves in a way that
A
isn't important anymore, you have an intrinsic reaction to argue that we
must
do
A.
If you're a generalist, you're much less threatened by that. Instead, it's, 'Fine. Great. Here's something else to do that's exciting!'"
That expectation applied to everyone at Google. 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. I'd worked mainly in union shops, where grievances were filed if you tried to do a task that "belonged" to someone else. I once flicked the wall switch in an empty TV studio and was scolded because studio lights could only be turned on by a member of NABET. When I worked at ad agencies, media buyers didn't write copy, copywriters didn't talk to clients, account people didn't buy TV time. It would have violated the natural order.
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."
What you had studied in school wasn't relevant. What you had been doing at your previous job didn't matter. Once you waded into Google's sea of needs, someone tossed you a project and you were expected to grab it. Either you learned how to swim with it or it sank you.
Even though Urs had an unhealthy fixation on hiring, he seemed like an upright guy who thought beyond the black and white of "Can we do it?" to the murkier question "Should we do it, just because we can?" I was impressed with the stand he took on RealNames, but I didn't realize that his fundamentalist views on absolute honesty had a dark side, one that seeped into the company culture and cast a shadow over working collaboratively.
"Urs was rather sparse with his praise," as systems guy Ben Smith diplomatically put it. Smith
*
wasn't much of a talker himself. Not aggressively reticent, just coolly laconic. A world-class Ultimate Frisbee player, Smith had the intensity of athletic confidence wrapped around an intellect capable of solving Google's most intransigent grit-in-the-gears software problems. Steve McQueen with a PhD, maybe.
"I had written up detailed instructions," Smith told me about a piece of notoriously unreliable software he had been up all night trying to fix. "I explained to Urs before I left, 'Here's what we've done. Here's how it's running. Here are the things to look at. Here's what's going to go wrong if it goes wrong, and here are ten steps you need to do to turn it off.' I was driving home, listening to
Morning Edition,
and I get a call from Urs. 'It broke like you said it would,' he says. 'I fixed it. Good work.' It was like, 'Your directions worked. Thank you for not completely screwing us over.'"
"Urs was people-challenged in just the funniest way," engineer Ron Dolin confirmed. "He didn't give compliments. If you were doing a good job, that's enough said. But some of us—especially the ones who were not the supermen of the company—could have used a little encouragement here or there."
So why was Urs so parsimonious with his accolades? Is it just that engineers are tight-lipped? "I don't think there's an engineering aversion to praise," Urs replied when I asked about our compliment-free culture. "It's one of my biggest management problems. Myself, I don't need effusive praise. I didn't grow up like that and it doesn't come naturally."
The language barrier contributed to Urs's reticence to laud his team. "'Good' in German really means 'good,'" he explained. "Here it means 'not really that good, but not bad yet.' In German, you wouldn't say 'excellent' almost ever. You'd say 'very good,' because the highest mark at school was 'very good.' That's the best there is. 'Excellent' maybe means Olympic caliber. Not what normal people would achieve. That was always a little bit of a challenge."
Urs not only had trouble giving compliments, he had a hard time accepting them as well. "My advisor at Stanford would tell me that things were 'great,'" he once confided with a grimace, "and I knew it wasn't all great and I had trouble understanding. In Switzerland, you'd say, 'This is bad, and this is bad, and this is bad. And why did you do this? This is not going to work.' And here it's like, 'Do you think that ... maybe you could... ?'"
Urs acknowledged to me that his attitude created problems. "I'm not really proud of that," he said, "because we had really excellent people. It's easy to forget, because there are problems everywhere, and obviously you focus on problems, because that's what needs to be fixed, right? But that can come across as 'everything's bad,' right? When in fact things are great." And then, because, after all, he was Urs, he added, "Except there still are problems."
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.
For my own ego nourishment, I deciphered different types of feedback I received and developed an interpretative scale of success. Ordered from "Can I double-check your SAT scores?" to "I don't think that would have occurred to me," it went like this:
It's a waste of time.
It's not worth talking about.
It doesn't offend me.
It will do until we can fix it.
It seems reasonable.
It seems sensible.
It's kind of interesting.
I also developed a personal theory about why encouragement to improve productivity came easily but effusive praise proved elusive. It wasn't that people didn't expect and appreciate exceptional performance, or that coworkers and managers were too envious to note a job well done. Just the opposite. If you assumed all your colleagues were at Google because of their skill and intelligence, calling attention to their success might be insulting—as if you were surprised that they had done what was expected.
I took some comfort from that notion, specious though it may have been, because I didn't want to dwell on the alternative possibility—that I was hearing so little praise because no one thought I actually deserved it.
The fear of falling behind churned my stomach and tattered my sleep. Not so for Urs. Despite the massive load Larry and Sergey had placed on his shoulders, at the end of a full day he could let things be. "I've always had the ability to accept that there's stuff that I can't deal with right now," he said. "And I don't feel bad about it because I know I made the best use of my time. People are going to laugh when they hear this, but it's actually easier for me to accept failure or imperfection than for other people—if it's there for a good reason."
I always questioned my allocation of time and how I set priorities. Looking over my shoulder, Cindy did too. A bike-to-work-day flyer got the same attention as a vital piece of a product launch. Once I latched onto a project, I forced myself to stay with it until every preposition was assigned an object and every participle properly tucked in. I sometimes struggled with a single word choice for an hour and then spent days defending it. Intense focus. Willful execution. Methodical progress. Long periods lost wandering in the trees.
Urs would take a step back, squint to obscure the details, and take in the larger picture. He understood the minutiae, but he was self-disciplined enough not to obsess on them, which freed him to paint in large sweeping strokes. As he put it, "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."
What did that look like in practice?
"Screw quality," Urs instructed one development team, urging them on to an earlier launch date. "Screw anything you can screw." Adopting that mindset might have reduced my intake of antacids.
I concluded that Larry and Sergey trusted Urs because they shared his preference for quick fixes over long-term solutions. They, too, gladly sacrificed perfection on the altar of expediency.
"Larry and I would differ on how important it was to fix problems so they never recurred," Craig Silverstein recalls. "Larry was usually in favor of patching things up and dealing with them later, and I was always in favor of fixing them right. His take was, put out the fires faster and then you can spend time on the other things."
When duplicate results began showing up in searches, for example, Craig wanted to completely restructure the software to eliminate the problem. "No," Larry overruled him. "We can just make it work better in this system."
"Then it will be really fragile, and I guarantee the time will come when it breaks and will be harder to fix," Craig warned. But, of course, Larry won and Craig patched the system instead of replacing it. "I was wrong," Craig said later. "It never ended up being a problem again, and as far as I know, we're still using that same technique to deal with it."
Urs did his best to institutionalize his prioritization strategy among Google's engineers. He set up formal project reviews every couple of weeks, to force people to pay attention to the most urgent issues and to identify obstacles that might impede progress. "Sometimes people try to solve the problem," he explained, "instead of immediately escalating it and saying, 'Please help me get rid of this problem.'"
"It was pretty obvious what to do," Sanjay Ghemawat told me about his first few months on the job. "I could see the problems in the infrastructure around me. So a lot of it was finding the biggest pain point and working on that." Once the agony had been reduced to a dull throbbing, it was time to move on to the next source of irritation.
A potential drawback with Urs's notion of "self-correcting" engineers was that too many people might unwittingly work separately on the same problem. That didn't happen at first.
"There were maybe two or three people per project," recalls Jeff Dean, "so there were only like twenty pockets, and at that point you say, 'I know what those twenty are doing.'"
As Google grew, though, the company instituted an automated weekly update system. Engineers used it to file brief online "snippets" describing the areas in which they were working. The system compiled all the snippets into a single list, which it emailed out to everyone who cared. Though many engineers didn't make the filing deadline each week or ignored the process, Larry and Sergey rolled it out to other departments, including marketing. That was pretty typical. Engineering would create some new technology and try it out, then share it with everyone else to get the whole company aligned around the same set of productivity tools.