One of those who looked at it was Schwim, the ops guy who liked to edit my copy. "I'm flabbergasted this got so close to launching," he told me. While casually browsing through the catalogs, he had found ample adult content. A broad group, including engineers, also felt the product wasn't ready for prime time. I let Cindy know that the launch, scheduled for that week, might have hit a snag.
Cindy had been unaware of the filtering issue, but immediately recognized it as a potential PR liability and informed the product team that the risk was unacceptable. Marissa explained again why full filtering couldn't be done, but Cindy remained adamant. Her opinion carried considerable weight, so rather than debate filtering options ad infinitum, the team removed the adult catalogs altogether. That led to deep philosophical discussions about what constituted an "adult" catalog—and to a heightened awareness among all staff about the existence of "anal toys."
Finally, the product launched and all was copacetic. For about a week. Then CNET ran an article that said we would "sell retailers the names and addresses of Google users who request a specific catalog in the mail," and that we had "suggested selling links to product pages on retailers' Web sites."*
Gerald Aigner, our chief frugality officer, was outraged, and complained to the founders that the article implied that we would sell user data and that we put revenue ahead of user interests. "This is a true marketing fiasco," he said. "We basically screwed totally up."
I was just as unhappy about it as Gerald, even though the article was quoting me. Larry had given me specific instructions to add information on our web page directed toward catalog publishers. The copy I wrote said in part, "What are the keywords users enter to find your catalog? How many pages do they typically examine? Google can provide you with information about how your customers use your catalog in ways no other research tool can, all while adhering to the strictest standards of individual user privacy." There were references to ad programs Google was developing and to Google's ability to help generate leads, including "the names and addresses of our users who have specifically requested that your catalog be mailed to them."
We had never telegraphed our product-development plans before, nor given any hint that we might sell user data, even if our users said it was okay to do so. So why do it this time? It was all part of Larry's master plan. If we were explicit about the potential of catalog search for marketers, they might call off their own legal departments when they noticed we hadn't asked permission to include their copyrighted materials.
Larry always thought strategically and never hesitated to make short-term sacrifices to win a more important battle down the road. Trying to pry that strategy out of him was like squeezing water out of a rock, but when he did baptize us with drops of his wisdom or give us insight into his stream of consciousness, I couldn't help marveling at the depth of his thinking and the breadth of his understanding. His pragmatism around user privacy gave me pause, however. I believed absolutely that we would never provide any user's personal data to an outside party, but Larry's willingness to play around the edges of perception made me—dare I say it?—concerned.
Let's Do Launch
Bay Chang was a quiet, good-humored member of our UI team with a floppy mop of jet-black hair that reminded me of the cartoon character George Shrinks. Among the many innovations he introduced at Google was Sparrow, a collaboration tool he had created while still working as a researcher at Xerox PARC. With Sparrow, anyone could edit a web page without knowing HTML. One member of a team could set up a web page and others could make changes to it online, using just their web browsers and a menu on the page. Googlers quickly adopted it to manage all sorts of team projects.
Marissa chose Sparrow as the basis for an online launch calendar in November 2001: our first intranet-based accounting of every project that would ultimately be visible to users. Each project page had toggle switches that needed to be changed from "No" to "OK" before a product was officially ready to launch. I owned the switch labeled "copy." No product was supposed to launch if I hadn't flipped my switch approving all the text appearing within it. I didn't abuse my power to stop the production line, in part because I wasn't convinced anything would actually happen if I pushed my big red button. Once everyone had given approval, a note went out to a Googler mailing list named "Visible Changes." That ensured, in theory at least, that half-baked products would not slip out the door and Googlers would not awaken to find their world radically changed without warning.
Each week Marissa led a meeting to review launch-calendar projects about to become public or stuck in limbo awaiting approval. The meetings were an extremely effective way to generate buy-in or to force naysayers to articulate their objections face-to-face with product managers. For all the emphasis on electronic communications at Internet companies, regular meetings in which people had to explain themselves to their peers were swords that cut the Gordian knots of bureaucratic red tape.
If a PM showed up at a meeting without having procured all the "flipped bits" needed for a launch, Marissa would ask why those approvals were being withheld and what had been done to address outstanding concerns. People scurried frantically immediately prior to the meetings, but things got done. Skipping the meeting was not an option if your approval was the gating factor for a launch or if your product didn't have all the sign-offs you needed. The minutes were published, so no one needed to point fingers. It would be obvious who had held up progress.
Launch calendar grew to include dozens of engineers and PMs, and Marissa kept the meetings clipping along. I enjoyed going, though (or perhaps because) meetings were occasionally contentious. On rare occasions a product launched without everyone's okay, but for the most part you had to win over approvers or expect delays. The people in the room knew their stuff and, when challenged, fired back with live data and true passion. There was intellectual satisfaction in finding flaws in well-constructed logic or uncovering unseen and potentially problematic aspects of new products. If the engineers and PMs were blacksmiths beating code into new plowshares, I was the anvil against which they hammered. I wanted to ensure that each new product tempered our brand rather than introducing a weak link into a chain of successes. I always amped up with a double espresso before taking my seat.
I knew I was playing the role of roadblock, raising red flags left and right, but my colleagues were driven by youth, enthusiasm, and energy to just do things and damn the consequences. I think we struck a healthy balance, even as we struck sparks along the way. Marissa made sure my concerns were given serious consideration, and once they were answered, I gladly flipped my bit to OK.
Ego eruptions were rare in the meetings, but intensity visibly increased if debate threatened to become delay. When copy was the gating factor, I made sure that it was done on time or that the reason it wasn't lay with lack of final specifications from engineering or product management. Marketing would not hold up a launch. No one at the table with any sense of self-preservation wanted to violate Larry and Sergey's most sacrosanct commandment: Get it done on time.
Chapter 18
Mail Enhancement and Speaking in Tongues
USER SUPPORT STARTED the year 2001 with eight thousand unanswered emails. Even after the Deja News furor passed, the number again crept up to ten thousand, in part because of an orchestrated campaign to add Catalan to Google's list of interface languages.
Larry and Sergey strongly hinted we should look for an alternative to our customer-relationship management company, Miasma, which continued to hinder rather than enhance productivity. "I don't want to start looking for a new CRM vendor," I warned them, "if we're just going to pick the cheapest one at the end of the road. That's how we got in this situation to begin with. It's better to stay with the devil we know than to start over with a new set of problems."
Miasma had just released a software update. I let their sales rep know that we would order a copy, but that Larry and Sergey wouldn't pay the five-thousand-dollar cost of flying their techs out to install it.
>
The sales rep was taken aback. "You don't want us to install it? You know, this is a completely new version, not a service pack. It's very complex. We'd strongly recommend against a self-install."
"We have a building full of engineers," I rejoined. "They're confident they can do it themselves. Just send us the disks and the documentation."
"Well, frankly, only one other customer asked to do it themselves and they gave up halfway through. We'll have to pull some documentation together for you."
I wasn't nearly as worried by that as I should have been. I had developed unquestioning faith that there was no task beyond the capabilities of Google engineers. The disks arrived in the mail. The installation did not go as planned.
"We are rapidly approaching a major email meltdown," I advised our executive staff ten days later. The wheels had come off and we were grinding along on sparking rims toward the edge of a very deep canyon. The program kept crashing and the database of incoming emails was leaking bits and bytes at an alarming rate. Miasma's corporate headquarters was not taking our calls, and my sales rep's phone message said she had left the company. It was the email apocalypse.
Two days later, our Miasma server stopped accepting inbound mail.
I accelerated plans to find another email solution, though I had no budget or parameters for the search.
Composing a list of new CRM vendors didn't take long. Fewer than half a dozen major players offered stable, well-tested systems. Google's tech evaluation team would ensure we weren't sold a bill of goods (though they hadn't kept us from choosing Miasma), and Larry had a college friend who would advise us on desirable features. The friend, David Jeske, counseled us on what to ask for, then added that, by the way, he and a buddy were building a CRM product called Trakken—if we were interested. It wasn't really finished yet, but Larry's other Stanford pals at Wunderground.com were using it.
Interested? Interested in an untested CRM product still in development with one tiny client? Created by a company of two people? Sure, that's just what I was looking for—another risky technology with no support and no track record behind it. I thanked David for his help and, because he was a friend of Larry's, assured him we'd be happy to send him our request for proposal.
Meanwhile, our real search was well under way. One vendor couldn't provide any support for non-English email. Another had a terrible UI because it was a first-generation product. A third seemed overpriced and their salesman's aggressive stance made us wary of doing business with them. Only one company offered a reasonable solution, and we began negotiating with them in earnest. With our leading contender scheduled to make a presentation to our finance, operations, and sales departments, I felt confident I could convince Larry and Sergey to loosen the purse strings and do it right this time: spend money for a high-quality, stable system from a respected vendor.
I hoped Larry's friend had taken the hint and forgotten about us. It would be a frosty day in Hades before we'd make the mistake of buying a bargain-basement CRM solution again. No such luck. Jeske came back ready to present his proposal. He emailed us his slides and let us know we should print copies for the attendees and that we would need to set up a projector for his demo. I had to laugh at his chutzpah. I didn't really have the time for what I knew would be a dead end, but a friend of Larry's is a friend of Larry's, so I agreed to give him a half hour. What he showed us was surprisingly well thought out, but still not ready for beta testing. Many of the essential features we required were missing, and the interface lacked the polish of the others we'd seen.
I broke the news to David. "It's a good start, but I'm afraid we need something more developed."
"Not to worry," he said, taking notes on the features we wanted. "I can get these done. How about I come back next week with a new demo?"
It was more like two weeks before we met again. In that time, David and his partner, Brandon Long, had implemented more than thirty feature improvements from our list. It was impressive, but I was far from convinced. I was more worried that David seemed to think he had a shot at winning the contract—I didn't want him complaining to Larry when his hopes were dashed. I decided to head him off at the pass by talking to Larry myself.
"Actually," Larry recommended when I described the situation, "you should hire these guys. They're really smart. They'll work hard to build the product for us, and we can invest in their company."
"Larry," I explained slowly and carefully, "we just went through hell with an undeveloped product. I can't burden my team with another flaky piece of software that will just slow us down. We're close with a real CRM company and should have a proposal in a couple of days. I'll let David down gently."
"No. Really," Larry repeated. "You should hire these guys. Look, they're a small company and they'll be very responsive. We can give them space in the office and they'll live here and build their product to our specs. We'll be their most important client, and we'll benefit from their growth based on our product design ideas. Have Biz Dev negotiate the contract and make sure we get some equity."
I could say I was stunned, outraged, incredulous, but that would be an understatement. I couldn't believe Larry was going cheap again instead of buying reliability. When I informed the other vendors, they thought I was either corrupt or an idiot. One salesman sent blistering emails demanding to talk directly to Eric and our board of directors. "This decision lacks wisdom and foresight," he asserted. "If you are under the impression that you can build an email tool resembling ours in thirty days, you are mistaken. It has taken us four years and twelve hundred customers to get to where we are. To not include us in your plans does not make sense."
That guy was kind of a jerk anyway, so telling him no didn't bother me, but I'd still be cursing Larry's decision today if not for one small thing: Larry was absolutely right. Though we wasted weeks negotiating our investment in Jeske's nascent company NeoTonic (we squeezed just an extra one-tenth of one percent in equity out of them), by the end of October 2001 we had the new Trakken CRM system running in parallel with Miasma. David and Brandon lived in our office and Denise Griffin, our user-support manager, gave them a daily list of desired features and bug fixes. Unlike the big "reliable" company I had wanted to hire, NeoTonic didn't have hundreds of customers using the same product. They didn't release upgrades only twice a year. They fixed things as they came up, in priority order. Within a couple of months we had the CRM system we wanted, built to our specs, fully stable and intuitive to use. We cut our ties with Miasma and never looked back. A year and a half later, we bought the rest of NeoTonic, making its two founders full-time Googlers.
So what did I learn from all this? I learned that obvious solutions are not the only ones and "safe" choices aren't always good choices. I had thought that due diligence meant finding the product most people relied on, then putting pressure on the vendor to cut the price. It never occurred to me to talk to a startup, even though I worked at one. It never occurred to Larry not to do that. We had different tolerances for risk and different ideas about what two smart people working alone could accomplish in a complex technical area—and that is why I spent seven years working in mainstream media while Larry found a partner and founded his own company. Two smart guys working on complex technical problems, it turns out, can accomplish a hell of a lot.
Lost in Translation
The "translation console" was an idea, like building our own ad system and hiring the Trakken guys, that originated with Wunderground, the weather site founded by Larry's college friends. It was a tool for translating our site into all the languages scattered over the face of the earth. Marissa was the chief proponent of implementing it at Google, and Ron Garrett was the lead engineer.
The translation console split all the text on Google's pages into single sentences, phrases, or even words to make it easy for volunteers to translate our interface one bit at a time. When users posted multiple correct translations, they earned editorial power to overwrite awkward or incorrect submissions made by others. If it
worked, the system would make our site available in hundreds of different languages—a long and arduous task for us to manage alone.
Insofar as we had a clear strategy, a big part of it seemed to be getting other people to do our work for free. Nowadays that's known as "crowd-sourcing." We just called it "cutting costs." Self-service AdWords, porn cookies, affiliate programs, viral marketing—all were based on many hands lightening the load and the unbeatable value of unpaid labor. Google parsed all its tough problems into manageable pieces and parceled them out.
Our engineering staff worked in teams of three instead of in large groups assigned to a single massive project. Our hardware employed thousands of small computers working in parallel instead of large mainframes. Our desktops ran on Linux, an open-source operating system cobbled together by volunteers. We sharded databases into smaller segments to make searching them faster. When we finally built a trade show booth, Larry and Sergey made us do it as a design contest for college students. Why settle for one "professional" designer when you can have a hundred students applying their creativity?
This divide-and-conquer approach even informed the basic algorithms running Google search. Rather than basing search results solely on a single source—the content of individual web pages—Google looked at links created by millions of people to determine a site's importance. Sergey called it "the democracy of the web," because each link was a vote cast in favor of a site's credibility. That approach made Google scale better than the competition, because the more the web expanded, the more links Google harvested for its ranking algorithm.
The translation console would be another break—it-into—tiny-pieces solution for the big, bloated mess of multiple languages. Marissa and Ron set up some fun languages Googlers could use to test the system before it went live, including Pig Latin, Klingon, and Elmer Fudd ("I'm Feewing Wucky"). Marissa translated our entire interface into Bork, Bork, Bork, the language of the Swedish Chef from the Muppet Show. The first real new interfaces to launch were Afrikaans, Bulgarian, and Catalan, and we formally announced the console to the world on March 27, 2001. Within five months, volunteers had translated Google into sixty—four languages.
I'm Feeling Lucky: The Confessions of Google Employee Number 59 Page 30