• Choose a category
• All
• Classic-Fiction

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

"When you have a list that's longer than you can deal with, you have to prioritize," Urs instructed us. "If you give a project a quick improvement that gets you eighty percent of the way to solving the problem, you haven't solved it, but it drops below the line versus one you haven't worked on at all." And then he put his finger on the crux of my conflicts with engineering. "Once a problem falls below the line you should work on something else, even though it's not finished."

How the hell could I stop working on something when it wasn't finished? The whole world would see scratches in our metal-flake paint and dings in the door panels of our corporate identity. The shame!

"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