Cada vez que se habla sobre las condiciones de trabajo en Google se menciona la regla del 80/20: los ingenieros que trabajan en Google (la regla no rige para el personal administrativo) pueden dedicar el 20% de su tiempo a proyectos personales. Nota al margen: la regla del 80/20 (o mejor dicho, la implementación de un mecanismo de Innovation Time Off o ITO) no es un invento de Google. Hace décadas que 3M utiliza un mecanismo de ITO.

Sin embargo, no es tan frecuente la mención de un mecanismo tan importante como el anteriormente mencionado: la revisión entre pares. Al respecto, un artículo publicado en 2002 por la revista Fast Company cuenta que:

Most Fridays at Google, the search-engine company in Mountain View, California, Marissa Mayer and about 50 engineers and other employees sit down to do a search of their own. Mayer, an intense, fast-talking product manager, scribbles rapidly as the engineers race to explain and defend the new ideas that they’ve posted to an internal Web site. By the end of the hour-long meeting, six, seven, or sometimes even eight new ideas are fleshed out enough to take to the next level of development. Some of those ideas might become new features on Google, new code or search algorithms, or a new way to juice up the Google home page. “We really jam in there,” Mayer says.

Parece una buena forma de no incurrir en el Principio de Peter:

En una jerarquía, todo empleado tiende a ascender hasta alcanzar su nivel de incompetencia.

Dice Bernard Girard en El Modelo Google:

Estas revisiones entre pares ayudan a la creación de una jerarquía paralela basada en el desempeño técnico y en la reputación [...].

Y reproduce un fragmento de una entrevista a Eric Schmidt, CEO de Google, publicada por Fast Company:

If you don’t want to lose your geeks, you have to find a way to give them promotions without turning them into managers. Most of them are not going to make very good executives — and, in fact, most of them would probably turn out to be terrible managers. But you need to give them a forward career path, you need to give them recognition, and you need to give them more money.

Twenty years ago, we developed the notion of a dual career ladder, with an executive career track on one side and a technical career track on the other. Creating a technical ladder is a big first step. But it’s also important to have other kinds of incentives, such as awards, pools of stock, and nonfinancial kinds of compensation. At Novell, we just added a new title: distinguished engineer. To become a distinguished engineer, you have to get elected by your peers. That requirement is a much tougher standard than being chosen by a group of executives. It’s also a standard that encourages tech people to be good members of the tech community. It acts to reinforce good behavior on everyone’s part.

Sin embargo, Bernard Girard también escribe que el mecanismo de revisión entre pares vigente en Google:

[...] no es anónimo, y los revisores, los árbitros, los expertos encargados de la evaluación de los proyectos, se conocen entre sí y con frecuencia trabajan juntos, lo cual puede propiciar el desarrollo de comportamientos políticos, clientelismo o alianzas entre expertos, siguiendo el modelo del logrolling [...]. Si hemos de creer en los mejores testimonios, Google no estaría libre de este defecto.

PD: Se me ocurre que es probable que las reuniones mencionadas se complementen con el uso de Google Ideas (aparentemente similar a Digg, Menéame y otros sistemas de votación de noticias enviadas por usuarios) y otras herramientas que Google utiliza internamente.