2007年10月20日 星期六

The Google Way: Give Engineers Room

Preoccupations

The Google Way: Give Engineers Room

這些字眼preoccupations和 room等都是雙關語
Published: October 21, 2007

GOOGLE engineers are encouraged to take 20 percent of their time to work on something company-related that interests them personally. This means that if you have a great idea, you always have time to run with it.

Skip to next paragraph
Noah Berger for The New York Times

Bharat Mediratta taking part in a “grouplet” meeting at Google, reflecting its emphasis on allowing employees time for independent projects.

It sounds obvious, but people work better when they’re involved in something they’re passionate about, and many cool technologies have their origins in 20 percent time, including Gmail, Google News and even the Google shuttle buses that bring people to work at the company’s headquarters in Mountain View, Calif.

If your 20 percent idea is a new product, it’s usually pretty easy to just find a few like-minded people and start coding away. But when the thing you really want to work on is to make a broad change across the whole organization, you need something new — you need a “grouplet.”

These grouplets have practically no budget, and they have no decision-making authority. What they have is a bunch of people who are committed to an idea and willing to work to convince the rest of the company to adopt it.

Consider the collection of engineers who wanted to promote “agile programming” inside the company. Agile programming is a product development approach that incorporates feedback early and often, and was being done in a few scattered parts of the organization.

The Agile grouplet formed to try to take this idea and spread it throughout the organization. It did so by banding together and reaching out to as many groups as it could to teach the new process. It created “Agile Office Hours” when you could stop by and ask questions about the process. It handed out books and gave internal talks on the topic. It attended staff meetings and created the concept of the “Agile Safari,” in which you could volunteer to work for a time in groups that were using Agile, to see how it ticks.

When you’re moving as fast as Google is, you don’t always get the chance to button up the little things, and over time they build up and become annoying. In addition to the efforts of our professional quality assurance team, we have the Fixit grouplet, which coordinates special Fixit days when it tries to have our engineers focus on solving one class of problems. Sometimes we have Documentation Fixits, when we try to catch up on all the internal documentation that we have let slide.

Or my favorite: the Customer Happiness Fixit, when we fix all those little things that bug our users and make them sad — for example, when the hotkeys aren’t just right on mobile phones. Many of these events come with special T-shirts and gifts to reward the engineers who take a little time out to work on them.

In my 20 percent time, I started the Testing grouplet. This was born of the idea — not mine — that if developers wrote automated tests as they wrote their code, their code would be better for it. Less time fixing bugs means more time building stuff.

We started with engineers from all over the company meeting every couple of weeks to brainstorm. Slowly, over time, we started turning into activists, planning to actually start improving things.

We started building better tools and giving informal talks to different technical groups. We started building a curriculum for our Nooglers — newly hired Google employees — so that they would start off right. With our pooled 20 percent time, we slowly turned the organization on its axis and made developer testing a common part of the development practice.

Google works from the bottom up. If you have a great technical idea, you don’t have your V.P. send out a memo telling everybody to use it. Instead, you take it to your fellow engineers and convince them that it’s good. Good ideas spread fast, and this approach keeps us from making technical mistakes. But it also means that the burden falls upon you to spread your idea.

In the Testing grouplet, our idea was to have developers start writing their own tests. But no matter how hard we tried, we weren’t reaching engineers fast enough in our growing organization. One day, toward the end of a long brainstorming meeting, we came up with the idea of putting up little one-page stories, called episodes, in bathroom stalls discussing new and interesting testing techniques. Somebody immediately called it “Testing on the Toilet,” and the idea stuck.

We formed a team of editors, encouraged authors to write lots of episodes and then bribed Nooglers with books and T-shirts to put up episodes every week. The first few episodes touched off a flurry of feedback from all corners of the campus. We received praise and flames, but mostly what we heard was that people were bored and wanted us to hurry and publish the next episode.

Eventually, the idea became part of the company culture and even a company joke, as in, “Excuse me, I need to go read about testing.” That’s when we realized that we had what we needed: a way to get our message out.

OF course, the grouplets need guidance to make sure they are aligned with the company interest. Having a lot of people who are self-organizing can be powerfully positive or negative, and not every idea is a good one. To help deal with that, a number of grouplet organizers meet once a week to make sure they are not at cross-purposes.

But when you give engineers the chance to apply their passion to their company, they can do amazing things.

Bharat Mediratta is a software engineer at Google.

沒有留言:

網誌存檔