• Choose a category
• All
• Classic-Fiction

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.

That we used the same systems as engineering, however, did not mean we were equal partners in the product-development process. "Never, ever, ever delay the launch of a product just for a marketing issue," Cindy warned us. It was the third rail of company politics. We could not fall behind or fail to deliver. If my piece of a project wasn't completely up to my standards and the launch date was at hand, I would have to dump all the loose screws into the box, solder it shut, and hand it off to the engineers impatiently waiting for it. And then move on.

A day would come-or at least a moment—when it would be appropriate to stop and drink the decaf, reflect on what we had accomplished, and contemplate what lay ahead. This was not that moment. "There's plenty of time," Cindy reminded us on numerous occasions, "to rest when we die."

Chapter 10

Rugged Individualists with a Taste for Porn

THE MARKETING