Sharing is good for you (and for Google)

[UPDATED]: Joe has some more to say on how the 20% thing works.

Google has been rightly proud about both the quality and the quantity of talent they've been able to attract. It's been a long time since we've heard a company complaining that there aren't enough good people to hire. And when it's Google saying it, you can believe it, since they certainly aren't constrained by price.

Google is also justifiably proud of their 20% time policy. They've made investments by hiring great talent. And they've invested 20% of their time in informal, personal R&D. So the question now becomes, "how does Google get those developers to produce the maximum amount of useful code?"

Joe Beda, formerly of MS, now hailing from Google, outlines some of Google's development practices that allow Google to get the highest return on their investment.

1. Everybody has access to all the code.

2. Developers can switch teams easily.

3. Teams share information freely

The first three practices are all about openness: open code, open teams, open information. As I have argued before, I think companies spend far too much energy hiding information from different sub-groups of employees. Google shows us how eliminating bureaucracy and disseminating information widely through out the company is a good thing.

One of the arguments frequently marshaled by open source advocates is that, “there are more smart people who don’t work for you company than there are who do.” The same is true inside a company — especially a large one like Google. What Google is really doing is a kind of internal open source, and the same practices that work for the open source community work here. (And don’t forget, they’re also doing some real open source as well with Google Code.)

Also, it’s worth noting how these practices also parallel some of the best practices from XP, particularly, “Everyone owns all the code,” and “Make project schedules short and achievable.” (from Joe Beda in his comments.) I don’t think that’s an accident.

4. Developers are required to spend 20% of their time on another project.

The 20% rule is a hard sell. I think it makes a lot of sense, and there are sound business reasons for it. First of all, it’s a really smart way to do R&D. There is no way that you can predict where (or who) good ideas are going to come from. Creating a special R&D department or sending off a hand-picked team to create the Next Big Thing™ shuts out far more ideas that it generates. This gives everyone in the company the chance to work on something innovative, or to fix something that they see broken. And it gives Google the widest possible chance of developing another hit product in house.

Really smart engineers are likely to work on personal projects anyway. That’s just what geeks do. Sponsoring that activity just makes it more likely that the engineer will keep his ideas “in the family,” and gives Google a claim on the idea that doesn’t take a lawsuit to enforce.

5. The environment and philosophy encourage problem-solving, risk-taking and innovation.

These are wonderful attributes, and I’d love to work at a company with that kind of DNA. But if your company doesn’t start that way — and if those qualities don’t flow down from the leadership — then I’m not sure there is much that can be done to change that.

People have been saying for a while now that Google is building a giant, distributed super-computer. That their real expertise is not in search, but it systems.

If you step back and squint a little, it looks to me like they’re pursuing the same policy for their engineering teams: Aggregate as many smart people as you can. Make sure that they can communicate with each other as efficiently as possible. Spread knowledge widely. Make sure that lots of different people are involved, so no one failure can take down a project. Much like the GoogleOS, Google is build a team of engineers that aspires to be bigger and badder than anything that has come before. So they’ve got the system: now it’s time to turn it loose and see what emerges.

UPDATE: Ross Mayfield advances some very similar arguments in his presentation for OSBC. Ross suggests that, “open source could improve management practices, if we can get past treating our employees as competitors. Through sharing, innovation proliferates.”