The 20% Doctrine

Ryan Tate

• Éditeur: Harper Business
• Année: 2012
• ISBN:
  9780062096692
• Sujet: Betriebswirtschaft
• Sous-sujet: Leadership

Gawker tech-blogger and journalist Ryan Tate reveals how businesses can inspire greater creativity and productivity by giving employees the freedom to experiment and explore their passions.

We're at a crossroads. Many iconic American companies have been bailed out or gone bankrupt, while others are fighting to survive ever-increasing digitization and globalization.

In The 20% Doctrine, Tate examines how companies large and small can incubate valuable innovative advances by making small, specific changes to how work time is approached within their corporate cultures. The concept of "20% Time" originated at Google, but Tate takes examples from powerful businesses like Yahoo!, National Public Radio, Flickr, and the Huffington Post to demonstrate how flexibility and experimentation can revolutionize any business model.

By pursuing their passion projects, employees can fuel innovation and foster new ideas.Only through a new devotion to the unhinged and the ad hoc can American businesses resume a steady pace of development and profitability.

1

Scratching Your Own Itch

Paul Buchheit’s Dark Struggle to Launch Gmail

At 3 A.M. one day in Mountain View, California, a software engineer named Paul Buchheit made a promise to his manager, Google vice president Marissa Mayer, with whom he had been working late at company headquarters. He pledged not to press forward with his idea for “creepy and weird” text ads based on the contents of one’s e-mail in-box. “I remember leaving,” Mayer later said, “and when I walked out the door I stopped for a minute, and I remember I leaned back and I said, ‘So, Paul, we agreed we’re not exploring the whole ad thing right now, right?’ And he was like, ‘Yup, right.’ ”

Buchheit broke his word almost immediately. Over the next few hours, he hacked together a prototype of “the ad thing,” a system that would read your e-mail and automatically find a related ad to display next to it. The advertising system would fund Gmail, an advanced new e-mail system he had invented. When, the next morning, his coworkers saw what he had created, they called it blasphemy. Mayer thought about ordering Buchheit, asleep at home, to drag himself out of bed and pull the plug on his creation.

Luckily, she didn’t. “This story is a lot of egg on my face,” Mayer later said in a Stanford University podcast. Buchheit’s system, called AdSense, makes Google around $10 billion in revenue each year. You’ve probably seen AdSense’s trademark blue-and-white ads in page margins all over the Web.

Through his long struggle to launch AdSense and its companion product, Gmail, which boasts hundreds of millions of users, Buchheit transformed Google from a company narrowly focused on search to one with a bigger vision of itself, a company expanding quickly into new markets by following the passions of its employees. The mild-mannered engineer proved to Google high command the value of letting frontline programmers push the company into new markets.

“I think I may have something to do with 20 percent projects,” Buchheit told start-up adviser Jessica Livingston, “because I’ve created a few things on the side. . . . Inevitably . . . something catches my eye and I go off and work on it for a little bit.” In other words, before Google proved the value of 20 percent time to the world, Paul Buchheit proved it to Google.

He did so by embracing an idea that should be at the core of any 20 percent–style project: Before you can create a product that solves problems for other people, you must be able to create a product that solves problems for you. Gmail and AdSense addressed issues that, first and foremost, bothered Paul Buchheit. Slowly but surely they grew to address the needs of Buchheit’s immediate coworkers. Then Buchheit set a goal of making one hundred Googlers happy with his creations. Only later were they released to the public. By putting himself at the center of his development process, Buchheit created products beloved by millions of users, to say nothing of Google’s shareholders.

If you’re trying to launch your own side project, the takeaway from Gmail and AdSense is that before you can sell the project to your boss you first to need to make something you yourself would buy into. Scratching your own itch provides the motivation to work on something above and beyond your regular duties. Everything Buchheit did was possible because he built first and foremost for himself. The emotional payoff to what he was doing helped Buchheit push past many obstacles.

The process of turning your personal wants into products that help others is remakably visceral.

“Just notice problems that are around you,” Buchheit told a gathering of aspiring entrepreneurs in 2008. “Kind of stop and pay attention to what’s going on inside your own body, your own mind. . . . Start to notice every time you have to wait for something or every time you get slightly confused or aggravated with the product, every small annoyance . . . most of the things we put into Gmail were just, like, I was annoyed with something, and we would try to think of a solution for it.”

The process of turning annoyances into products is also deeply satisfying. “The more you feel that you can control your environment, and that the things you do are actually working, the happier you are,” software guru Joel Spolsky has written, citing research into “learned helplessness” by the renowned psychologist Martin Seligman. “When you find yourself frustrated, angry, and upset, it’s probably because of something that happened that you could not control: even something small. The space bar on your keyboard is not working well. . . . The key to your front door doesn’t work very well. . . . These things add up.”

The story of Gmail and AdSense began in August 2001, when Buchheit finished work on Google Groups, an archive of online conversations from an old part of the Internet known as “Usenet.” Buchheit’s job was to make the archive searchable. He did a very good job: Buchheit’s system let users find posts within particular message boards, called “newsgroups”; messages written by particular people; and messages within a certain range of dates. It was eventually recognized with a “product excellence” award from the well-regarded programming magazine Dr. Dobb’s Journal. Internally, Google Groups just earned Buchheit more work: a mandate to build some sort of search personalization product. Google’s mission was to organize and make useful all of the world’s information, but much of that knowledge was locked away within people’s private troves. The particulars of solving that problem were left up to Buchheit.

“I was given a kind of vague direction to work on some kind of e-mail or related project,” Buchheit told me.

The engineer knew what he wanted to do. Ever since he was a student at Case Western Reserve University in the 1990s, Buchheit had wanted to put e-mail on the Web. Back then, checking e-mail meant firing up crude specialized software. Buchheit, ever the tinkerer, began building a website that could bring up his e-mail from any Web browser anywhere. He eventually abandoned the project, busy with other things.

E-mail was still bugging Buchheit after he got to Google, which had the most advanced e-mail software available. The engineer was swamped with five hundred messages per day, many from Googlers talking past one another in the same conversation, their in-boxes so cluttered they missed one another’s messages. People came up with awkward coping strategies, like religiously sorting their conversations into folders, or ruthlessly deleting old messages, losing valuable history in the process. Buchheit himself found it nearly impossible to navigate his in-box. “It was all really confusing for me,” he later said.

It took just a few hours for Buchheit to create a prototype of what he dubbed “Gmail,” thanks to an ingenious shortcut: Buchheit simply took the code he had written to search Google Groups and set it loose on his personal e-mail archive. It helped that e-mail messages are nearly identical to Usenet messages. Both have fields like “To:,” “From:,” “Date:,” and “Subject:,” and follow the same formatting rules (a historic document called RFC 822). As we’ll see later, this type of reuse is a common pattern among successful 20 percent projects.

The first Gmail was pretty darn basic. Buchheit had not had time to code support for more than one account. Yet the programmer didn’t let the rudimentary state of Gmail keep him from showing it off to colleagues, to whom he e-mailed a link to the service. “They said that it was somewhat useful,” he later deadpanned on his blog, “but it would be better if it searched over their e-mail instead of mine.”

As requested, Gmail 2.0 let people search their own mail. By version three, users could even reply to messages, a feature requested by Google cofounders Larry Page and Sergey Brin, two of Gmail’s first users. Buchheit later added “conversation view,” which displayed all replies to an e-mail message as a unified thread on a single Web page, hiding copies of prior e-mails appended to the bottom of subsequent messages. At last, Buchheit had come up with a way to keep his coworkers from talking past one another. They’d have to read all prior replies to an e-mail before they could send one of their own.

Like Gmail’s search feature, conversation view was built quickly using code Buchheit adapted from Google Groups. Buchheit kept launching new prototypes, one after another in rapid succession, all internal to Google. He was practicing an increasingly popular software development technique: Release early and iterate often, with a slew of new versions. The churn of the early Gmail code base was intense, so intense that the front end was rewritten about six times and the back end three times before the product was ever shown to the public.

As he refined Gmail, Buchheit was methodically eliminating his own workday annoyances and those of his colleagues at Google. “Every time we would get irritated by some little problem,” he told Livingston, “or one of the [internal Google] users would, we’d just spend time thinking about it, looking at what the underlying problems are and how we can come up with solutions.”

Buchheit said that this sort of rapid improvement was the key to the success of Gmail. Iteration is how Buchheit took a website designed by and for himself and turned it into something that was useful to other people. It allowed Buchheit to show people he was incorporating their ideas, to get feedback on flaws not apparent to him, and to generate discussion on how to grow the product. Brin and Page became crucial early champions of Gmail, thanks to their participation in this feedback loop.

Buchheit later called Gmail’s development process “the humble approach to product design.”

“What’s the right attitude? Humility,” he wrote on his blog. “It doesn’t matter how smart and successful and qualified you are, you simply don’t know what you’re doing. The good news is that nobody else does, either, though some are foolish enough to think that they do (and that’s why you can beat them). . . .

“Pay attention. Notice which things are working and which aren’t. Experiment and iterate. Question your assumptions. Remember that you are wrong about a lot of things. Watch for the signals. Lose your technical and design snobbery. Whatever works, works . . . you should consider spending less time talking, and more time prototyping.”

Anyone embarking on a 20 percent time project can benefit from the sort of iterative feedback loop Buchheit established when developing Gmail. The trick is to find a way to make a small initial prototype and then to take small steps forward. If you’re too ambitious and the steps are too large, the iterations take longer and your feedback loop loses energy—fewer coworkers talking about your project or sending in suggestions, fewer new versions to try, and less internal mindshare for your experiment. The best way to keep your steps small is to keep your very first prototype small. In the world of tech start-ups, this minification is referred to as creating the “Minimum Viable Product.” While your ego, fears, and superiors tend to push you toward a bigger, more impressive first release, the religion of Minimum Viable Product preaches the virtues of starting small. The sooner you release, the sooner you get information from your users about where the product should go. It might feel embarrassing to release something as crude as Gmail 1.0. But embarrassing yourself in front of your first customers is better than never interacting with them in the first place.

It can be hard to know when you’re done iterating—when a 20 percent time project has gestated long enough and can be considered both conceptually proven and sufficiently developed. Buchheit, on the advice of then-CEO Eric Schmidt, decided “we should get 100 happy users inside of Google before launching.” This proved tricky. “I was like, ‘Oh, that’s easy, Google has like thousands of employees,’ ” he said at the 2008 gathering of aspiring entrepreneurs. “But it turns out happiness is a really high bar, and to get people to say that they’re happy was actually sort of challenging.”

“We literally did it one user at a time. We would go to people and be like, ‘Okay, what’s it going to take to make you happy?’ And in some cases, they would ask for something really hard, and we’d be like, ‘Okay, well, you’re not going to be happy with Gmail, quite possibly ever.’ But with other people it turned out there would be something really small we could do and then they’d be happy. And so we’d do the really easy things until we finally got 100 people who were happy. And 100 doesn’t sound like a lot but it turns out people are pretty similar to each other, so if you can make 100 people happy, usually you can make more [happy].”

Buchheit and the team he later assembled used iteration to steadily overcome opposition within Google. After all, the surest way to shatter a preconception is with direct evidence to the contrary, and each new version of Gmail did a better job than the last, proving Google could do something awesome and transformative for e-mail. Each one of Buchheit’s improvements converted more skeptics into allies.

And there were plenty of skeptics. Former Googler Chris Wetherell, who helped create Google Reader, remembers being amazed at the team’s ability to pull through.

“Can you imagine working on it for two years?” he asked me. “No daylight. Very little feedback. Many [interface] iterations, many. Some so bad that people thought, ‘This will never launch, this is the worst thing ever.’ I remember being in a meeting, and a founding member [of Google], I don’t want to say which one, said, ‘This is brand destroying. This will destroy our brand. This will crush our company.’ ” (Buchheit has said Gmail development was tough, but didn’t remember sentiment being so extreme when I asked him about this quote.)

It’s hard to imagine today, when Gmail has hundreds of millions of users, and when Google makes everything from a smartphone operating system to office software to a blog platform, but for years many Googlers opposed on principle the idea of venturing beyond search, believing the company should add only niche products like news search, shopping search, Usenet search like Google Groups, and so on. Gmail took the company way beyond that. “People weren’t sure we should even be doing this,” Buchheit told Livingston. “So the general attitude would swing, and when it would swing against us, that was very hard to deal with.”

He later wrote, “For a long time, almost everyone disliked it. . . . Quite a few people thought that we should kill the project.”

Buchheit overcame the objections by showing how much better an e-mail system could be when it had strong search capabilities. It’s no accident that search was Gmail’s first feature; other e-mail programs just sucked at it. They were typically very slow at running queries and in many cases could not search the body of an e-mail, only the subject line and other headers. Gmail, in contrast, searched as fast and comprehensively as Google.com.

And it kept getting better. Initially, Gmail didn’t include your newest e-mails since, like Google.com, it incorporated new data only every half hour or so. That was fine for finding Web pages, but too slow for e-mail, and Buchheit iterated until it was fixed.

Google’s Gmail haters also took aim at Gmail’s heavy use of JavaScript, the programming language built into all Web browsers. When Gmail was under development, JavaScript was primarily known for powering annoying pop-up advertisements and juvenile animations, and detractors thought Buchheit was investing way too heavily in it. Some even advocated rewriting Gmail as native software that ran directly on your PC.

But as Buchheit played with JavaScript, he grew more impressed. He had begun tinkering with the language to fulfill a feature request from one of those first hundred users he was trying to delight. There was no way to implement the feature using a conventional HTML Web page, so Buchheit added some JavaScript. That worked so well, he began turning to JavaScript for other features. The language eventually made Gmail feel like a desktop e-mail program like Microsoft Outlook, as opposed to a clunky series of Web pages like Hotmail.com. For example, writ...