Give Engineers Room

The Google Way: Give Engineers Room

By BHARAT MEDIRATTA; as told to JULIE BICK
New York Times, October 21, 2007

http://www.nytimes.com/2007/10/21/jobs/21pre.html

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.

Photo:
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.
—————-