Cómo trabaja Google

Jonathan Rosenberg llevó a Larry Page un calendario con los productos que Google iba a sacar en los dos años siguientes. Había señalado cuándo debía estar listo cada uno y en qué momentos se pediría la aprobación de los responsables. Con aquel calendario delante, la dirección podía seguir el trabajo conforme fueran llegando las fechas.

Larry Page quiso saber qué había pasado otras veces con un plan así. Le preguntó si había visto a un equipo terminar antes de lo previsto o entregar un producto mejor que el que figuraba en el calendario. A Jonathan Rosenberg nunca le había ocurrido. Llevaba pocos meses en Google y había recurrido a una forma de organizar el trabajo que ya conocía. Larry Page le pidió que hablara con los ingenieros que iban a construir los productos. Eran quienes podían decir qué trabajo exigía una mejora y quienes, al hacerla, podían encontrar otra manera de resolver el problema.

En Cómo trabaja Google, Eric Schmidt y Jonathan Rosenberg vuelven a los años en que tuvieron que dirigir la empresa mientras aprendían a trabajar con esos equipos. Los fundadores habían dado a los ingenieros margen para decidir sobre lo que hacían. Al llegar más gente, una consulta que se podía resolver entre dos mesas podía acabar pasando por varios despachos. Los autores se preguntan cómo creció Google sin que la gente que sabía resolver una dificultad tuviera que esperar a que alguien se la devolviera en forma de encargo.

El calendario de Jonathan Rosenberg señalaba el día en que saldría cada producto. Para quienes lo construían, ese día abría otra parte del trabajo. Una vez fuera de la empresa, el programa iba a pasar por ordenadores distintos y a manos de gente que lo usaría a su manera. Las dificultades que encontrara esa gente podían cambiar lo que el equipo tenía que preparar después. El libro sigue el recorrido de esas noticias desde el momento en que alguien se encontraba con un problema hasta que otra persona podía probar una forma de arreglarlo.

Ficha técnica del libro

Campo	Datos de la edición
Título	Cómo trabaja Google
Subtítulo	Liderazgo, estrategia e innovación
Autores	Eric Schmidt y Jonathan Rosenberg, con Alan Eagle
Título original	How Google Works
Primera publicación	2014
Edición	Edición digital en español, febrero de 2015
Editorial	Conecta
Traducción	Vicente Fernández Herrasti
ISBN	9786071136671
Extensión	384 páginas según el catálogo de la edición
Tema	Dirección de Google, crecimiento de una empresa tecnológica, organización del trabajo y creación de productos para internet.
Materias	Cultura de empresa, liderazgo, estrategia empresarial, selección de personal, entrevistas de trabajo, comunicación interna, toma de decisiones, desarrollo de productos, innovación, experimentación y plataformas abiertas.
Enlace de compra	https://link.amazon/B00k4SAzY

¿Cómo se trabaja cuando las decisiones llegan a quienes hacen el trabajo?

¿Qué puede hacer quien encuentra un fallo que le toca a otro?

A las cinco y cinco de la mañana del lunes, Jeff Dean envió un correo con un enlace. Al abrirlo se podía probar una manera distinta de colocar los anuncios en el buscador de Google. En el mismo mensaje venían ejemplos para comparar lo que ofrecía la prueba con lo que los usuarios seguían viendo en ese momento.

Las búsquedas que permitían comparar las dos versiones venían de unas hojas que Larry Page había dejado en la cocina el viernes. Las había impreso después de comprobar que varias páginas respondían bien a lo que pedía, mientras que algunos anuncios de al lado ofrecían algo distinto. Marcó esos anuncios antes de colgar las hojas en el tablón. Quien pasara por allí podía leer las palabras que había escrito Larry Page y volver a hacer la misma búsqueda.

Esa posibilidad cambió el trabajo de quienes vieron el papel. Para investigar una queja sobre anuncios hace falta conocer al menos dos cosas. Una es lo que apareció en pantalla. La otra es la búsqueda que llevó hasta allí. Si falta esa segunda parte, un anuncio de abogados parece estar en su sitio porque, visto por separado, ofrece un servicio comprensible. Al devolverlo a la página donde alguien está buscando una Kawasaki H1B, se ve que la coincidencia entre letras y números ha llevado al buscador por otro camino.

Jeff Dean y sus compañeros trabajaban en búsquedas. Sabían cómo volver a crear aquella página y podían examinar los anuncios que acompañaban a los resultados. El libro cuenta que ninguno de los cinco formaba parte del equipo responsable de la publicidad. Quienes llevaban ese trabajo podrían aprovechar la prueba porque lo que habían encontrado los ingenieros se podía enseñar en la misma pantalla que había dado origen a la queja.

En el correo, Jeff Dean explicaba por qué el programa llegaba a ofrecer anuncios de tan poca ayuda. La solución que habían probado añadía una valoración del parecido entre lo que el usuario pedía y lo que ofrecía cada anunciante. Piensa en lo que ocurre cuando varias empresas quieren aparecer al lado de una búsqueda. El sistema necesita decidir qué lugar ocupa cada una y puede dejar alguna fuera. La cantidad que estén dispuestas a pagar y los clics que consigan aportan información, pero para detectar el fallo del tablón hacía falta saber también si estaban hablando de lo mismo que la persona que buscaba.

La prueba servía para examinar esa valoración sin confundir una muestra con una reparación terminada. Los resultados del correo enseñaban cómo respondía el programa en determinadas consultas. Si las búsquedas elegidas mejoraban, había motivos para seguir trabajando en la propuesta. Quedaba comprobar qué sucedía en más páginas y en qué consultas podía equivocarse el nuevo cálculo, algo que solo podía verse con otras pruebas. Los autores señalan que el peso dado a la relación con la búsqueda acabaría formando parte de la base del sistema de anuncios.

Eric Schmidt y Jonathan Rosenberg vuelven a aquel episodio, con Alan Eagle, en un artículo sobre cómo se abordan los fallos en Google. Larry Page hizo visible un problema sin tener que asignarlo a cinco personas. Los ingenieros pudieron darle una primera respuesta porque reconocieron una dificultad dentro del trabajo que conocían y compartían el criterio con el que juzgar el resultado. Los autores describen un lugar donde ese tiempo dedicado a probar se aceptaba y donde el grupo que llevaba los anuncios podía aprovechar el trabajo de sus compañeros. Del tablón salió un aviso que permitía repetir el fallo. Del correo salió una propuesta que los demás podían volver a poner a prueba antes de decidir si servía.

¿Qué pasa si a quien ve el fallo le cuesta contarlo?

Los ingenieros que vieron el aviso de Larry Page podían volver a hacer las búsquedas y estudiar los anuncios que aparecían. Antes de que alguien pudiera ayudar, había hecho falta que el fallo saliera de la pantalla donde se había descubierto. Las hojas en la cocina permitieron que lo vieran personas que sabían cómo comprobarlo.

En Los líderes comen al final, Simon Sinek examina un momento anterior. Una persona ve una dificultad y, antes de contarla, calcula si será señalada por haberla encontrado o por haber intervenido. Mientras hace esa cuenta, los compañeros que podrían ayudar siguen sin saber qué pasa. La protección que propone Simon Sinek tiene un efecto sobre ese trabajo. Permite que el aviso llegue a quienes pueden usarlo, incluso cuando la persona que lo da tenga algo que corregir ella misma.

Qué puede detener el trabajo	Cómo trabaja Google	Los líderes comen al final
El aviso queda sin examinar	Quien sabe reparar puede estar esperando a que le asignen el fallo.	Quien lo conoce puede temer lo que le ocurra al comunicarlo.
Qué hace falta abrir	Espacio para estudiar la reparación y enseñarla a los demás.	Una vía para hablar y recibir ayuda cuando todavía hay tiempo.
Qué sigue siendo necesario	Comprobar que el cambio ayuda a quien usa el producto.	Averiguar qué ocurrió y quién debe actuar para resolverlo.

Los dos libros permiten mirar lo que ocurre si alguien de otra sección descubre que se están enviando pedidos a una dirección antigua. Si teme que se le culpe por sacar el tema, hay que empezar por recibir su aviso sin convertirlo en una acusación. Si el aviso ya ha llegado y esa persona sabe reproducir el error, la cuestión cambia. Puede reunir dos pedidos en los que haya ocurrido y enseñar dónde sigue guardada la dirección anterior. Esa comprobación ahorra tiempo a quien deba corregirla, incluso si el cambio definitivo lo tiene que autorizar otra persona.

El margen para ayudar depende de qué tarea se abre. Examinar dos pedidos permite avanzar sin cambiar los datos de nadie. Corregir en bloque todas las direcciones exige comprobar cuáles pertenecen a clientes que sí se han mudado. La protección que pide Simon Sinek se necesita en ambos momentos. El margen para actuar que muestran Eric Schmidt y Jonathan Rosenberg puede empezar por una prueba pequeña y crecer cuando el equipo ya sabe a qué pedidos afectará la corrección.

¿Qué puede arreglar quien recibe las devoluciones?

Pongamos que Maite abre una caja devuelta al empezar su turno en la tienda de telas. Dentro hay dos cortinas igual de largas. La clienta había pedido una corta para el radiador y otra que llegara hasta el suelo.

La orden que lee Maite en el papel dice que el juego lleva dos piezas, pero las medidas aparecen en un recuadro que queda doblado debajo de la solapa. Busca la caja anterior, que devolvió otra clienta, y encuentra la segunda medida en el mismo sitio. Llama a Berto, que envuelve los pedidos.

—¿Me enseñas la hoja cuando te llega? Quiero ver en qué parte pone lo de la caída.

Berto saca la que tiene delante. Él recibe los papeles plegados para que se vea el número por fuera y comprueba la medida de arriba. La otra queda escondida al dar la vuelta a la hoja.

—Tengo tres pedidos de esos preparados para esta tarde —dice, señalando la estantería—. Los envolví de la misma forma.

Maite baja las tres cajas. Mientras Berto acaba un pedido que ya tiene abierto, ella las revisa con la cinta de medir y encuentra otra pareja de cortinas iguales. Puede cambiar una sin tocar el resto del pedido. Le deja el paquete apartado y escribe las dos medidas juntas al lado del número. Berto prepara la hoja siguiente con los datos en el mismo lugar.

—Desde el mostrador podéis anotar las dos antes de doblar el papel —le dice—. Aquí voy a comprobar cada caída al cogerla.

El encargado llega cuando están cerrando las cajas. Maite le enseña el recuadro que quedaba debajo del pliegue y la anotación que permite ver las dos medidas. Él les pide que conserven el papel de esa tarde para mover las casillas cuando encargue el siguiente talonario. Para la clienta de la primera caja ya tienen la pieza corta. Maite la llama antes de mandarla para saber si quiere que llegue a su casa o prefiere pasar a recogerla.

¿Cómo se prepara una empresa para la llegada de un rival mucho mayor?

Una parte importante de las visitas que recibía Google en 2003 llegaba desde Internet Explorer. Alguien abría aquel programa para ver páginas de internet y podía usarlo para entrar en Google. Internet Explorer pertenecía a Microsoft, que podía servirse de su presencia en los ordenadores para dar a conocer su propio buscador.

Michael Moritz, inversor y miembro del consejo de Google, llamó a preparar una respuesta ese verano. En el correo que mandó a Eric Schmidt usó el nombre que tenían dentro de la empresa para Microsoft. Le pidió que presentaran en agosto el plan para competir con Finlandia. Pensaba en un trabajo que llegaría a las personas que construían los productos, a quienes los vendían y a quienes se ocupaban del dinero. También se habló de reorganizar la empresa y de buscar otras formas de ganar ingresos. Entre las cosas que quería ver estaba el calendario de productos.

Ese calendario tenía sentido para un consejero que necesitaba saber si las tareas avanzaban. Se podía volver a él después de unos meses y cotejar lo que se había prometido con lo que se había entregado. Para elegir de antemano qué mejoras iban a salir, en cambio, hacían falta datos sobre un trabajo en el que iban a surgir mejoras a medida que avanzaran. Un equipo podía recibir el encargo de preparar una función y comprobar, al empezar a usarla, que el esfuerzo rendiría más si arreglaba otra parte de la búsqueda. Si había comprometido una fecha para la primera, cambiar de tarea tenía un coste dentro de la empresa, aun cuando fuera lo más conveniente para quien usaba el servicio.

Jonathan Rosenberg ya había llevado a Larry Page un calendario de productos con fases y permisos antes de recibir el encargo de Michael Moritz. Había previsto lo que Google sacaría a lo largo de dos años. Larry Page le preguntó por ocasiones en las que los equipos hubieran superado aquel tipo de plan y por los productos que habían resultado mejores de lo que se había prometido. Las preguntas dejaban a la vista algo que un calendario explica mal. Es posible cumplir una fecha y haber renunciado por el camino a una mejora que nadie podía poner en el papel al principio.

El plan que Eric Schmidt y Jonathan Rosenberg acabaron presentando daba al consejo una forma de saber qué defendería Google. La empresa trataría de mejorar la calidad de sus productos y de facilitar que la gente pudiera usarlos. Era una manera de conservar usuarios. A medida que llegara más gente, los anunciantes encontrarían más personas a las que mostrar sus ofertas. El documento contenía algunas medidas para hacer frente al rival y dejaba abiertos el presupuesto, el calendario detallado y otros datos que habría incluido un plan de negocio como el que se había pedido.

Los cambios posteriores permiten entender qué podía caber dentro de esa decisión. Para responder a una consulta local, por ejemplo, resulta útil enseñar en qué parte de una ciudad está un comercio. Ofrecer mapas daba al buscador una forma de responder que una lista de páginas podía dejar a medias.

Ampliar los idiomas en que se podía usar era otra manera de atender a gente que ya tenía acceso a internet y podía encontrar dificultades con la búsqueda. Cada mejora tenía sus propios requisitos técnicos y podía llegar cuando hubiera condiciones para prepararla.

Los autores cuentan esos cambios desde la perspectiva de quienes trabajaron en Google. Microsoft llegó a competir con sus propios servicios de búsqueda. Para entender cómo se preparó Google conviene volver a la gente que abría Internet Explorer. Microsoft tenía un medio de llegar a esas personas. Google podía trabajar para que, cuando ellas escogieran dónde buscar, encontraran una razón para volver.

¿Qué parte de un plan podemos revisar mientras seguimos trabajando?

Michael Moritz quería saber cómo se preparaba Google para competir con Microsoft. Un plan con fechas permitía presentar compromisos al consejo, pero la fecha de un producto iba a fijarse cuando los ingenieros aún podían descubrir una manera mejor de hacerlo. La respuesta que describen Eric Schmidt y Jonathan Rosenberg mantuvo un rumbo reconocible. La búsqueda tenía que seguir sirviendo a quien la usaba, mientras el equipo conservaba margen para cambiar la forma de conseguirlo.

Guy Kawasaki se ocupa de otra decisión sobre el futuro en El arte de empezar 2.0. Webvan quería atender pedidos de supermercado por internet y preparó una ampliación con grandes almacenes. Un almacén podía hacer falta para servir muchos pedidos. Construirlo antes de conocer ese volumen dejaba pagos que habría que atender incluso si los pedidos tardaban. En el plan de Google se podía corregir una fecha. En el de Webvan había que mirar cuánto costaría deshacer un compromiso de construcción una vez firmado.

La diferencia se ve cuando el equipo recibe una noticia después de decidir. Si una prueba del buscador muestra una manera mejor de ordenar las páginas, puede cambiar el trabajo de las próximas semanas y avisar de cuánto tardará. Si se ha comprometido a pagar por un almacén, una bajada de pedidos permite cambiar lo que se construya después, mientras los pagos ya acordados siguen llegando. Las dos decisiones tienen un futuro abierto, pero el equipo conserva un margen distinto según lo que haya prometido.

Qué decisión se está preparando	Cómo trabaja Google	El arte de empezar 2.0
Qué debe orientar el plan	Dar al usuario un producto que le sirva mejor frente a otras opciones.	Ajustar la capacidad de reparto a los pedidos que pueden sostenerla.
Dónde cuesta más volver atrás	En una fecha prometida antes de conocer el trabajo que exige el producto.	En el dinero comprometido para instalaciones que aún esperan pedidos.
Qué se vuelve a mirar	Las pruebas del producto y lo que los ingenieros han aprendido.	Los pedidos, el tiempo necesario para ampliar y los gastos durante la espera.

Un plan que conserva estas diferencias puede indicar qué trabajo sigue abierto y qué compromiso tiene ya un coste. Quien necesita tomar una decisión con ese documento delante sabrá si puede esperar al resultado de una prueba o si tiene que intervenir antes de firmar. Una empresa puede mantener el propósito de servir más pedidos y preparar espacio por etapas. La otra puede mantener el propósito de mejorar la búsqueda y reservar las fechas para aquello que ya se sabe construir.

¿Qué pasa con un plan de reparto cuando aparecen las horas de entrega?

Si una imprenta ofrece llevar los folletos de una feria a todos los pueblos de la comarca, puede calcular el coste con las distancias que figuran en el mapa. Eso hace Elena con su hermano Julián. Al unir los pueblos cercanos, le salen tres vueltas para su furgoneta.

La mujer que organiza la feria les da una lista con las personas que podrán recibir los paquetes. Elena llama a la primera, que abre su tienda al mediodía. En el pueblo siguiente esperan al repartidor a las ocho de la mañana, antes de que salga el panadero con su furgoneta. En el mapa quedan a diez minutos. Con esas horas, llevar los dos paquetes en la misma vuelta le ocupa casi media jornada.

—Yo había contado con hacer los dos pueblos seguidos —le dice Elena a su hermano.

Julián acerca el mapa y señala los otros pueblos que hay cerca.

—Después del panadero puedo ir a estos tres. Si alguien tiene las llaves, me da tiempo antes de que abra la tienda.

—Llama a los tres antes de que empecemos a mover horas —le pide Elena—. Puedo ir yo a uno si se queda fuera, pero necesito saber cuándo salgo de la imprenta.

Julián tenía el número de una empresa que alquila furgonetas. Podían reservar otra para el día del reparto, con un pago por adelantado. Deja el papel del alquiler al lado del mapa. Si consigue juntar las entregas que se pueden hacer por la mañana, podrán usar la suya por la tarde para llevar el paquete que quede.

Al terminar las llamadas, Julián tiene dos nombres y una dirección nueva. En un pueblo pueden dejar las cajas en el taller de la cooperativa durante toda la mañana. Otro tiene un bar que abre a las siete. La tercera entrega será en un polígono que queda cerca del panadero. Con esos lugares apuntados, empieza a trazar los viajes desde las puertas que estarán abiertas, usando el mapa para calcular cuánto tarda entre una y otra.

Elena mantiene el precio de los folletos y vuelve a calcular el del reparto con una sola furgoneta. La vuelta que parecía más larga en el papel se puede hacer entera por la mañana. Para llegar a la tienda abierta tendrá que reservar parte de la tarde. Antes de mandar el presupuesto, Elena le enseña a la mujer de la feria dónde se recogerá cada caja. La organizadora repasa los puntos y se queda un momento en el de la tienda.

—Si los folletos están ahí después de comer, los puedo repartir por la tarde —dice—. Voy a avisar a las dos personas que tenían pensado pasar por la mañana.

¿Qué se aprende al trabajar cerca de quien hace otra tarea?

En el despacho de Amit Patel trabajaban cinco personas y se esperaba a una sexta. Para hacerle sitio, el ingeniero llegó a cortar por la mitad una de las mesas. La habitación seguía siendo pequeña para todos los que tenían que sentarse allí.

Amit Patel siguió buscando sitio y se fijó en el despacho de Eric Schmidt, que llevaba poco tiempo en Google. La habitación que le habían asignado al llegar ya la usaban varios ingenieros, de modo que había elegido una más pequeña que tenía al lado. Aquel era el sitio que Amit Patel consideraba espacioso al compararlo con el suyo. Cuando pidió que le ayudaran a mover las cosas, el personal de las oficinas se negó a trasladarlas allí. Las llevó él mismo. Los dos acabaron trabajando en el mismo cuarto durante varios meses.

La experiencia le sirve a Eric Schmidt para contar lo que puede pasar cuando se distribuye el espacio de un modo distinto al que suele acompañar a los cargos. Antes había trabajado en los laboratorios Bell y recordaba lo que le ocurrió a uno de sus jefes. El hombre tenía un despacho frío y compró una alfombra para cubrir el suelo de cemento. El departamento de personal le hizo retirarla porque su puesto estaba por debajo del nivel al que correspondía aquella clase de comodidad. El suelo siguió siendo el mismo. El criterio para decidir si el hombre podía cubrirlo se encontraba en el rango que tenía dentro de la empresa.

Al sentar juntos a quienes llevan trabajos relacionados se puede cambiar el camino que recorre una duda. En las oficinas que Eric Schmidt y Jonathan Rosenberg describen en el libro, les interesaba que las personas que diseñaban un producto trabajaran cerca de las que organizaban su desarrollo. Quien prepara una función conoce el punto en el que le está costando hacerla. Quien sigue el uso del producto puede saber qué parte está causando problemas a la gente. Al mirar ambos lo mismo, pueden averiguar si el esfuerzo que requiere una solución se corresponde con la dificultad que querían quitarle al usuario.

Esa conversación se puede tener a distancia, pero para conseguirla hay que preparar el encuentro o escribir lo que se necesita saber. Al redactar un mensaje, quien pregunta ya ha decidido qué parte del problema merece contarse. Si deja fuera un detalle porque le parece pequeño, la otra persona tendrá que descubrirlo cuando compruebe el trabajo, o quedarse con la información que ha recibido. Sentarse cerca permite enseñarlo mientras se está haciendo y dejar que el compañero pregunte por cosas que el mensaje habría dado por entendidas.

La proximidad tiene un límite que los autores señalan al hablar de las oficinas. Después de una conversación, alguien puede necesitar concentrarse durante un rato o hacer una llamada que requiere privacidad. Describen salas pequeñas y otros rincones que permitían apartarse del grupo cuando hacía falta. Una vez hecha esa tarea, la persona podía volver a su mesa junto a sus compañeros. La habitación tranquila servía para resolver una necesidad del trabajo y quedaba disponible para quien la tuviera en el siguiente momento.

En el despacho de Eric Schmidt se sentaron cerca dos personas con responsabilidades muy distintas. Para decidir qué mesas conviene juntar cuando hay que preparar un producto, los autores se fijan en quién podrá responder cuando surjan las preguntas de cada día. Quien trabaja con los datos de uso puede necesitar hablar mucho más con quien diseña la pantalla que con alguien que ocupa su mismo puesto en otro equipo. Si tiene que levantarse de su mesa para buscar a alguien, merece la pena mirar a quién se dirige y qué le lleva a hacerlo.

¿Qué conversaciones conviene acercar a la mesa de trabajo?

Lo que sucede entre mesas	Cómo trabaja Google	El trabajo no tiene por qué ser una locura
Una consulta breve	Compartir despacho permite enterarse de una duda cuando aparece.	Si requiere hablar durante un rato, los compañeros pueden usar otra sala.
Alguien trabaja en otra tarea	La cercanía permite oír información que también puede servirle.	Una sala tranquila permite conservar el hilo de lo que está haciendo.
Qué debe ofrecer el lugar	Un encuentro fácil entre quienes necesitan información del otro.	Un sitio para hablar y otro donde la voz no llegue a todas las mesas.

El despacho que Eric Schmidt compartió con Amit Patel ponía a un responsable y a un ingeniero a pocos pasos. Parte de la información que llegaba a uno podía servir al otro. La conversación podía empezar cuando la pregunta tenía delante a quien conocía un antecedente o podía buscar un dato. Esa posibilidad se perdía si para cada duda había que averiguar primero con quién hablar y conseguir un hueco para verlo.

En El trabajo no tiene por qué ser una locura, Jason Fried y David Heinemeier Hansson estudian qué ocurre si la voz de dos compañeros llega a quienes están tratando de seguir otra tarea. Una consulta resuelta en dos minutos puede ahorrar una espera a quien la hace. Para una tercera persona, esos mismos dos minutos pueden partir una explicación que tendrá que volver a leer. La oficina de Basecamp conservaba salas para hablar y aplicaba una regla parecida a la de una biblioteca en el espacio compartido de trabajo.

Antes de elegir entre acercar dos puestos o darles más separación conviene seguir el camino de una consulta. Si una empleada toma los pedidos y otro prepara las entregas, pueden necesitar confirmarse varias veces una dirección o una hora. Una espera en esa mesa pasa al cliente. Si una persona está revisando contratos y recibe cada una de esas consultas desde el asiento de al lado, tendrá que recobrar el hilo cada vez. Mantener cerca los dos puestos de pedidos y dar a la revisión de contratos una mesa más tranquila permite atender ambas tareas.

La cercanía cambia de valor cuando cambia lo que se hace. Una pregunta de unos segundos puede abrir un asunto que exige sentarse y comparar dos documentos. Tener otro lugar disponible permite que los dos compañeros sigan hablando y que los demás continúen trabajando. La decisión sobre el espacio empieza por saber quién necesita oír esa conversación y en qué momento deja de ser necesaria para quienes comparten la sala.

¿Qué permite que un empleado discrepe de quien fundó la empresa?

Sergey Brin propuso dedicar un equipo de Google a una idea para los anuncios. El grupo trabajaba a las órdenes de Sridhar Ramaswamy, que prefería dedicar ese tiempo a otra cosa y se lo dijo antes de que los ingenieros cambiaran de tarea.

Sergey Brin tenía un grupo de ingenieros y dos propuestas sobre la mesa. Su primera salida fue repartir a la gente. La mitad se pondría con su idea y el resto seguiría trabajando según lo que indicara Sridhar Ramaswamy. En un reparto como ese, las dos personas conservan la posibilidad de hacer algo de lo que quieren. Si las dos ideas se pueden probar con poco esfuerzo y el resultado es difícil de prever, hacer una prueba de cada una puede aportar información que la discusión por sí sola no daría.

El mismo reparto se vuelve costoso cuando hay razones suficientes para descartar una de las opciones antes de empezar. Las horas de media plantilla quedan comprometidas con un trabajo que puede dejar de servir en cuanto alguien examine la dificultad de llevarlo a cabo. La otra mitad, mientras tanto, dispone de menos manos para hacer el trabajo que quede en pie. Sridhar Ramaswamy mantuvo su desacuerdo, por lo que la conversación pasó del reparto de personas a los motivos para llevar a cabo cada propuesta.

El libro cuenta lo que ocurrió después a partir de lo que el propio Sridhar Ramaswamy relató en una reunión de Google. Tras discutir las dos ideas, se dejó de lado la del fundador. Eric Schmidt y Jonathan Rosenberg señalan que Sergey Brin entendía los datos y el funcionamiento del servicio. Podía seguir las objeciones y examinar en qué afectaban a lo que se proponía hacer. Esa capacidad le permitía aprovechar la discusión incluso cuando acababa cambiando su propia decisión.

La persona que hace el trabajo necesita algo más que un permiso general para opinar. Tiene que poder señalar el punto en que una propuesta deja de convencerla y contar qué ha visto. Quien tiene el poder de decidir puede ayudar con preguntas. Si se duda de un cambio porque ocupará más horas de las previstas, cabe averiguar qué paso las consume y si el resultado compensa ese esfuerzo. Si la duda surge por un posible fallo, lo que hace falta discutir es en qué condiciones aparecería. Son maneras de averiguar qué parte de la objeción puede comprobarse. Ninguna requiere saber cuánto cobra quien la ha hecho.

Los autores entienden que plantear una objeción fundada forma parte del trabajo, precisamente porque quien ve una dificultad puede tener información que a los demás les falta. Esa responsabilidad alcanza a quien prefiere hablar poco delante de sus superiores. También compromete a quien dirige la reunión. Si acepta preguntas al presentar una idea y sigue adelante sin examinar ninguna respuesta, los demás aprenden pronto que hablar cambia poco. En esta ocasión hubo tiempo para explicar el desacuerdo aun después de que el fundador ofreciera una manera de repartir el trabajo.

Repartir el equipo tenía un coste que solo se entendía mirando qué quedaría en manos de cada mitad. Si para preparar una prueba hacían falta personas con conocimientos distintos, separar al grupo podía dejar a los dos trabajos sin alguien que necesitaban. Ante esa dificultad, los responsables podían decidir qué parte de cada idea comprobar primero. En la conversación que recuerda Sridhar Ramaswamy, seguir hablando permitió resolver la disputa antes de que alguien tuviera que organizar ese reparto.

Dar sitio a las objeciones tampoco equivale a dejar el asunto abierto cada vez que alguien prefiere otra cosa. El equipo necesita saber qué va a hacer. En el caso de los anuncios, la discusión acabó con una decisión sobre la propuesta, tomada antes de separar a los ingenieros. El fundador pudo cambiar lo que había pedido y el responsable del grupo se ahorró el reparto que habría tenido que hacer para complacer a ambos.

¿Qué hace que un producto pueda crecer?

¿Cómo se encuentra una página útil entre miles que usan la misma palabra?

Un enlace lleva de una página de internet a otra. Quien escribe sobre una universidad puede dejar uno para que el lector encuentre la página donde consultar qué se estudia allí. Si alguien lo pulsa, llega a la dirección elegida por quien escribió el texto.

Para Larry Page y Sergey Brin, esa elección podía servir al ordenar una búsqueda. Los buscadores que conocían en los años noventa se apoyaban en el contenido de cada página. Una página que mencionaba la palabra escrita por el usuario podía llegar a la lista de resultados. El problema se notaba al elegir cuál convenía mostrar arriba. Una librería cercana a una universidad podía hablar mucho de ella sin ofrecer lo que alguien espera encontrar en el sitio de la institución. Si las dos aparecían muy arriba, la persona tenía que comprobar cuál le servía y volver al buscador cada vez que abriera una página equivocada.

Larry Page había planteado esa dificultad durante una visita a una empresa que tenía un buscador. Le indicaron que escribiera una consulta más detallada. Eso podía ayudar a quien ya sabía qué universidad quería encontrar o qué palabra adicional distinguiría el resultado. El usuario que empezaba a buscar tenía menos con qué afinar. Para ayudarle desde el principio, convenía aprovechar una información de la que él carecía y que estaba repartida por las propias páginas.

En Stanford, Larry Page y Sergey Brin trabajaron con los enlaces que conectaban unas páginas con otras. Al recorrer la web, el programa podía registrar de dónde salía cada enlace y a qué página llevaba. Si mucha gente había indicado la misma página desde sitios diferentes, había razones para examinarla con más atención.

El método que dio lugar a PageRank permitía distinguir el peso de esas indicaciones. Los enlaces que llegaban de páginas a las que otros remitían podían pesar más. Una indicación que salía de una página bien conectada tenía un valor distinto de otra que aparecía en un lugar aislado.

Ese peso general ayudaba a ordenar las páginas. Para responder a una búsqueda, el programa necesitaba combinarlo con señales que le dijeran si la página tenía relación con las palabras escritas. Una página muy conocida sobre trenes podía tener muchos enlaces y seguir siendo de poca ayuda en una consulta sobre universidades. La utilidad venía de poder elegir, entre páginas que guardaban relación con el asunto, cuáles tenían motivos para merecer una posición más visible. Los enlaces eran una parte importante de esa elección y el buscador tenía otros medios para juzgar los resultados.

Había un trabajo previo a la búsqueda. Un programa tenía que recorrer páginas y reunir la información que luego usaría al recibir una consulta. Gracias a eso, podía devolver resultados sin ponerse a visitar toda la web cada vez que llegaba una pregunta. La lista guardada también tenía que revisarse conforme aparecían páginas nuevas o desaparecían otras. Si se quedaba antigua, sería fácil señalar como buena una dirección que ya no respondía o pasar por alto una página que acababa de aparecer.

Eric Schmidt y Jonathan Rosenberg usan el caso para explicar cómo se puede mejorar un producto al descubrir una manera distinta de utilizar algo que ya está ahí. En este caso eran los caminos que los propios autores de las páginas abrían para sus lectores. Quien usaba el buscador se beneficiaba de ese trabajo sin ver las conexiones que había detrás. Podía distinguir el cambio al hacer una búsqueda conocida y encontrar más arriba la página que antes había tenido que ir a buscar entre muchas otras.

¿Qué podemos descubrir al cambiar lo que contamos?

Una página podía mencionar varias veces una palabra y ofrecer poco a quien la estaba buscando. Larry Page y Sergey Brin estudiaron otra pista. Si desde una página alguien enviaba a sus lectores a otra mediante un enlace, esa relación podía dar información sobre la página de destino. El buscador podía tenerla en cuenta al ordenar lo que mostraba, junto a la coincidencia con las palabras de la búsqueda.

En Moneyball, Michael Lewis recoge una duda de Bill James sobre la cuenta de errores de los defensores de béisbol. Un jugador puede correr hasta una pelota y perderla al intentar cogerla. Otro puede quedarse tan lejos que nadie anote un error a su nombre. La cuenta dice qué fallos se han registrado con una regla concreta. Para conocer cuántas jugadas resuelve un defensor interesa ver también a cuántas llega.

Qué se quiere averiguar	Cómo trabaja Google	Moneyball
La decisión	Qué páginas conviene poner delante para una búsqueda.	Qué ayuda puede dar un jugador en el campo.
Qué se añade a la observación	Las relaciones entre páginas, incluyendo de dónde viene un enlace.	Las jugadas a las que un defensor llega y las que resuelve.
Qué sigue abierto	Si una página bien enlazada responde a la consulta concreta.	Cómo rendirá el jugador en otras condiciones de juego.

El cambio importante está en qué se puede ver con la información añadida. El buscador puede reconocer la relación entre dos páginas incluso si utilizan palabras distintas para hablar del mismo asunto. En el campo, observar la jugada completa permite ver una diferencia de alcance entre dos defensores incluso cuando la cuenta de errores se queda igual. En los dos casos, el nuevo dato recupera un trabajo que antes quedaba fuera de la comparación.

Una página con muchos enlaces puede ser útil para una pregunta y quedar lejos de lo que necesita otra persona. Un jugador que llega a muchas pelotas puede entregar parte de esa ventaja si pierde demasiadas al intentar cogerlas. Para corregir una medida conviene conservar el problema por el que se empezó a medir. Google tenía que poner delante un resultado útil para esa búsqueda. Un equipo necesita saber qué pasa con los corredores cuando el jugador interviene. Esas preguntas permiten decidir qué peso merece cada dato y cuándo hay que mirar otra parte del trabajo.

¿Qué puede ganar una empresa al dedicarse a resolver una sola tarea?

A finales de los años noventa, en Google se preguntaban cuánto tardaba una persona en encontrar lo que había ido a buscar. Que la página de resultados se abriera pronto era una parte del trabajo. Una vez que aparecía, las primeras direcciones tenían que conducir a sitios que le sirvieran.

Eric Schmidt y Jonathan Rosenberg describen cinco aspectos que usaban para saber si mejoraban. A la rapidez y el acierto se añadía la facilidad de uso, pues había gente que apenas sabía moverse por internet y necesitaba entender cómo buscar. Les interesaba cubrir más páginas y mantener al día lo que aparecía en la lista. Esas dos últimas cosas podían cambiar el valor de una buena respuesta. Si faltaban muchas páginas, el buscador elegía entre menos opciones de las que el usuario tenía a su alcance. Si usaba información antigua, podía ayudarle a encontrar un sitio cuyo contenido ya había cambiado.

Aquellos criterios daban trabajo distinto a las personas que construían el mismo servicio. Al ver que las búsquedas tardaban, podían revisar cómo respondía el programa que preparaba la lista. Si descubrían que el resultado llegaba enseguida pero dejaba fuera páginas útiles, la dificultad estaba en otra parte. El equipo podía averiguar qué páginas le faltaban y por qué el buscador no había pasado por ellas. Así se mantenían ocupados con problemas diferentes sin perder de vista qué tenía que poder hacer la persona al abrir Google.

En aquellos años, otras empresas de internet se orientaban hacia los portales. Querían que la primera página que viera alguien le permitiera acceder a varios servicios, desde las noticias hasta el correo. Les convenía ofrecer también una manera de buscar. Según cuentan los autores, compañías como Yahoo, Netscape y AOL podían confiar esa tarea a Google, mientras se ocupaban de la oferta más amplia que querían reunir en su propia página. Google, a su vez, tenía una vía para llegar a personas que entraban en internet por otro sitio.

Esa relación ayuda a entender por qué la especialización podía servirle para crecer. Un buscador capaz de atender más consultas podía prestar servicio desde otras páginas. Cada compañía que lo incorporaba tenía resuelta una parte del trabajo que necesitaba hacer y Google podía seguir dedicando tiempo a mejorarla. El acuerdo dependía de que a la otra empresa le siguiera siendo útil. También exigía que el buscador pudiera atender ese aumento de consultas sin perder la rapidez y el acierto que daban sentido a incorporarlo.

La diferencia se veía en lo que cada empresa esperaba que hiciera su visitante. Al portal le podía interesar que alguien pasara de las noticias al correo sin salir de allí. Google necesitaba ayudar a quien buscaba a continuar en otra parte.

Por eso, al pie de algunas listas ofrecía enlaces a otros buscadores. Una persona que seguía descontenta podía probar allí y conocer la diferencia por su cuenta. La página de Google le había facilitado un paso incluso cuando la respuesta que necesitaba quedaba fuera de sus primeros resultados.

Los autores señalan otra consecuencia de hacer más fácil la búsqueda. Las páginas que publicaban noticias, información o entretenimiento podían recibir a gente que antes tenía más dificultades para dar con ellas. El trabajo de Google y el de esos sitios se encontraban durante un momento. Una empresa le enseñaba a la persona por dónde seguir y la otra tenía preparada la página que merecía la visita. Para que aquella tarea especializada siguiera sirviendo, Google necesitaba volver a hacer bien ese recorrido cada vez que alguien llegara con otra pregunta.

¿Qué ocurre cuando otros fabricantes pueden usar el mismo programa?

En 2005, Google compró Android, que trabajaba en un sistema para teléfonos móviles. El programa tenía que ocuparse de tareas básicas como dar acceso a las aplicaciones y hacer que el aparato respondiera a lo que pedía su dueño. Para que alguien pudiera usarlo, primero tenía que llegar instalado en un teléfono.

Dentro de Google se discutió quién podría usar el programa para construir esos teléfonos. Andy Rubin y su equipo se inclinaban al principio por mantenerlo cerrado. Sergey Brin propuso permitir que otros lo utilizaran. Eric Schmidt y Jonathan Rosenberg cuentan que en aquel mercado había varios sistemas y que abrir Android les daba una manera de extenderlo con más rapidez. Google podía preparar una base y empresas de distintos lugares podían apoyarse en ella para hacer sus propios teléfonos.

La diferencia se aprecia al mirar cómo llega un móvil a la tienda. Hay que decidir qué piezas lleva y cómo va a funcionar, fabricarlo y encontrar una manera de vendérselo a quien pueda usarlo. Una empresa que desarrolle el programa puede conocer bien esa primera parte y depender de otras para llevar a cabo las siguientes. Al compartir el código de Android, que reúne las instrucciones escritas para que funcione, Google dejaba que los fabricantes hicieran su parte sin empezar de cero cada vez que diseñaban un aparato.

En noviembre de 2007 se presentó la alianza que impulsó aquella base compartida. Reunía a empresas que hacían teléfonos, compañías de telefonía y fabricantes de piezas, entre otras. Cada participante podía ocuparse de un trabajo que ya conocía. Los acuerdos para usar el sistema podían abrirle caminos distintos hasta las tiendas. Eso tenía una consecuencia para Google. Incluso si uno de esos fabricantes vendía menos de lo esperado, el programa podía llegar a personas que escogieran otro de los modelos preparados por los demás.

Compartir el punto de partida daba más trabajo de coordinación. Las empresas podían modificar el sistema para que se ajustara a un teléfono. Si esas versiones se alejaban demasiado entre sí, quien preparaba una aplicación podía encontrarse con que funcionaba en un aparato y daba problemas en otro. Para quien compraba el teléfono, esa diferencia salía a la luz al intentar instalar algo que esperaba poder usar. De ahí la importancia de contar con requisitos comunes que permitan comprobar qué puede esperar un desarrollador cuando prepara su aplicación para un teléfono compatible.

La apertura se refería a la base de Android. Jonathan Rosenberg explica en un texto sobre la apertura de productos que quien comparte un programa pone a disposición de otros las instrucciones que lo hacen funcionar. Un fabricante puede usar el código de esa base conforme a sus licencias. Para incorporar la tienda Google Play y otros servicios de Google hay requisitos distintos. Esta diferencia explica cómo pueden convivir dos decisiones dentro del mismo sistema. Compartir el programa de partida permite que otras compañías lo usen y adapten. Decidir qué aparatos pueden llevar un servicio de Google corresponde a las condiciones de ese servicio y a las comprobaciones que exige.

Los autores relacionan la extensión de Android con el paso del ordenador al teléfono como vía para entrar en internet. Cuanta más gente pudiera conectarse con un móvil, más ocasiones tendría de utilizar un buscador mientras estaba fuera de casa o del trabajo. Google podía ayudar a que esos aparatos llegaran a manos de más personas sin ocuparse de hacerlos todos. A los fabricantes les quedaba la responsabilidad de terminar cada teléfono y a la empresa que compartía la base le quedaba el trabajo de mantener algo sobre lo que mereciera la pena seguir construyendo.

¿Qué gana una empresa al dejar sitio para las herramientas de otras?

Un fabricante de teléfonos podía participar en Android sin tener que inventar desde cero todas las instrucciones con las que funciona un móvil. Podía trabajar sobre una base compartida y preparar su propio aparato. Los creadores de aplicaciones encontraban más lugares donde ofrecer sus programas conforme aparecían teléfonos que podían utilizarlos.

En La empresa invencible, Alexander Osterwalder, Yves Pigneur, Alan Smith y Fred Etiemble permiten mirar otra forma de apertura. Microsoft admitió Linux en Azure, el servicio mediante el que alquilaba capacidad de sus ordenadores a otras empresas. Una compañía que ya utilizaba Linux podía estudiar el traslado de sus programas sin empezar por cambiarlos para que funcionaran con Windows. Lo que se abría en ese caso era el acceso a un servicio de pago conservando herramientas que el cliente ya conocía.

Las dos decisiones dejan sitio a trabajo ajeno, pero lo hacen en momentos diferentes. Android ofrece una base sobre la que un fabricante puede construir algo que aún prepara. Azure recibe aplicaciones que una empresa ha construido y necesita seguir utilizando. Para el fabricante, una dificultad importante es qué podrá modificar antes de sacar el teléfono. Para quien traslada sus programas, lo primero puede ser conocer qué podrá dejar tal como está. La respuesta cambia quién acepta probar el servicio y qué se le puede pedir para empezar.

Abrir el acceso deja trabajo pendiente en los dos casos. Un fabricante puede adaptar el teléfono a las piezas que ha escogido y tendrá que comprobar si siguen funcionando las aplicaciones que sus compradores esperan utilizar. Una empresa puede conservar Linux y dedicar tiempo a trasladar sus archivos sin perder lo que necesita para seguir trabajando. El primer caso pide mirar qué debe permanecer en común entre aparatos distintos. El segundo pide mirar qué puede conservar un cliente al cambiar el lugar donde funcionan sus programas.

La diferencia se nota al decidir qué cambio aceptar. Si un fabricante adapta Android y una aplicación deja de funcionar en su teléfono, la dificultad aparece al intentar mantener algo en común con los otros aparatos. En Azure, una empresa puede empezar llevando un programa que ya le sirve. Tendrá que comprobar qué otras cosas de su trabajo dependen de dónde se ejecuta. Mantener el programa evita rehacer una parte, pero una prueba con los archivos que usa a diario puede mostrar que el traslado exige adaptar el resto. En ambos casos, la primera comprobación útil es la que hace quien va a trabajar con lo que se abre.

En qué consiste abrir	Cómo trabaja Google	La empresa invencible
Quién necesita entrar	Fabricantes y creadores de aplicaciones.	Empresas que quieren llevar sus programas a otros equipos.
Qué pueden aprovechar	Una base de trabajo compartida para preparar nuevos productos.	El sistema que ya utilizan para trabajar.
De dónde puede venir el beneficio	De que más aparatos y programas puedan funcionar juntos.	De vender capacidad y servicios a clientes con herramientas distintas.

¿Qué puede cambiar cada grupo cuando todos usan la misma hoja de rutas?

Imaginemos una asociación de ciclistas que presta a sus grupos una hoja para anotar por dónde salen. En cada ruta escriben el pueblo de partida y el lugar donde dejan el coche, para que otro grupo pueda hacer el mismo recorrido sin llamar a quien lo apuntó.

A Eva le interesa usar la hoja con gente que lleva poco tiempo saliendo. Tiene rutas en las que un tramo de piedras obliga a bajarse de la bicicleta. Le vendría bien señalarlo, igual que señala dónde se puede llenar la botella. Su grupo decide añadir dos casillas en su propia copia. Cuando la manda al grupo de Tomás, él ve las casillas nuevas y quiere aprovecharlas para anotar un cruce cerca de su casa.

—¿Tú escribes el pueblo aquí, debajo del nombre de la ruta? —le pregunta Tomás—. En la copia anterior lo teníamos al principio. La leo en el teléfono y es lo primero que busco.

—Lo moví para dejar sitio a lo de las fuentes —dice Eva—. Si queréis, volvemos a ponerlo donde estaba.

Al hablarlo, sale otra diferencia. El grupo de Tomás conoce dos pueblos con el mismo nombre y ya se ha equivocado al cargar uno en el mapa. Les gustaría añadir la provincia en todas las fichas, incluso en las que ya están hechas. Eva pide ver cómo quedaría. Cuando la nueva casilla aparece junto al pueblo, a ella le siguen cabiendo las notas sobre las piedras y las fuentes.

—Dejamos arriba el pueblo, la provincia y dónde aparcar —dice Tomás—. Debajo podéis poner las notas que os sirvan.

Eva guarda una copia vacía con esas tres casillas en el mismo sitio y otra con sus notas. Un mes más tarde, un grupo que sale desde la costa añade dónde se puede volver en tren si alguien tiene que acortar el recorrido. Cuando manda la hoja, Tomás puede incorporar la ruta a la carpeta común con el mismo orden que las demás. Quien abra la ficha sabrá dónde empieza el recorrido y, al bajar a las notas, encontrará los horarios que ha apuntado el grupo de la costa.

¿Cómo elegir a quién incorporar al equipo?

¿Qué se puede saber de un candidato antes de entrevistarlo?

La oferta de trabajo que recibió Jonathan Rosenberg llegó al día siguiente de la entrevista. Creyó que la consultora podía estar llamando a dos candidatos, porque se había presentado al mismo puesto un hombre al que consideraba mejor preparado.

El entrevistador le explicó qué había inclinado la decisión. Su ayudante había atendido a los dos mientras esperaban. El otro candidato la había tratado mal, según le contó, y ella había tenido una buena experiencia con Jonathan Rosenberg. Mientras aguardaba, él se había puesto a hablar con ella y, al enterarse de que pensaba viajar a California, le había recomendado lugares de su tierra. Hasta que recibió la llamada, desconocía que la mujer hubiera podido influir en la decisión.

La consultora disponía de dos clases de información sobre una misma visita. La entrevista permitía valorar lo que cada hombre sabía hacer y cómo explicaba su preparación para el puesto. La ayudante podía hablar de cómo se habían dirigido a ella, que era la persona a la que tenían delante antes de sentarse con quien iba a examinarlos. Se trataba de una parte corta de la visita que podía perderse si la empresa preguntaba solo a quienes habían ocupado el despacho.

En el capítulo sobre contratación, Jonathan Rosenberg y Eric Schmidt retoman el episodio para explicar por qué acostumbraban a escuchar a sus ayudantes después de una entrevista. Si una persona está a cargo de recibir al candidato, puede verlo pedir ayuda o resolver un pequeño problema de la visita. Lo que ocurre antes de entrar sirve para hacer una pregunta que el currículo deja abierta. ¿Cómo trata a un compañero cuando necesita que le facilite el trabajo? Esa pregunta cobra más importancia si, una vez contratado, pasará la jornada pidiendo datos, hablando con clientes o coordinando entregas con gente de distintos puestos.

El episodio ayuda a ver hasta dónde llega esa información. Jonathan Rosenberg recuerda que le dio consejos de viaje a la ayudante. Ese gesto explica que ella tuviera ocasión de conocerlo, pero el hecho de que ambos pudieran hablar de California dependía en parte de una coincidencia. Otra persona podría esperar en silencio y tratar a todo el mundo con respeto. Si se usa la conversación para buscar al más simpático, el juicio vuelve a depender de lo bien que hayan encajado dos personas en un encuentro breve. El detalle que la consultora pudo examinar fue cómo se había comportado cada candidato con alguien que estaba haciendo su trabajo.

En el fragmento del libro que publicaron en Fortune, los autores abren otra pregunta al imaginar una espera larga en el aeropuerto de Los Ángeles con una persona de la empresa. La espera sirve para pensar si el futuro compañero escucha, se interesa por lo que otros saben y tiene asuntos de los que hablar. Puede ser alguien muy distinto a quien hace la entrevista. Si ambos ven una cuestión de manera diferente y son capaces de mantener la conversación, esa diferencia puede ayudarles cuando trabajen juntos y haya que entender un problema desde varios lados.

Durante un proceso de selección, esas señales ganan valor cuando se pueden describir y estudiar junto con el resto de lo que hizo el candidato. Una opinión de recepción puede señalar qué palabras empleó al pedir ayuda o cómo respondió cuando le dijeron que le tocaba esperar. Quien lea el informe podrá saber en qué se apoya esa valoración y darle el peso que corresponda al puesto. En la historia de Jonathan Rosenberg, la conversación de recepción aportó lo que faltaba para entender la diferencia entre dos visitas. La ayudante podía contarlo porque ella misma había recibido a los dos candidatos.

¿Cuándo deja de ayudar otra entrevista?

Google llegó a permitir treinta entrevistas para decidir sobre un mismo puesto. Aquel límite debía poner fin a la espera de un candidato, que podía seguir recibiendo citas mientras en la empresa quedara alguna duda.

El límite apareció después de que un aspirante pasara por más de treinta entrevistas sin que el equipo supiera si quería hacerle una oferta. Eric Schmidt y Jonathan Rosenberg recuerdan la cantidad de trabajo que se había dedicado a una candidatura que seguía pendiente. La primera solución fue fijar un número que impidiera alargar otra candidatura del mismo modo. Para averiguar cuánto podía rebajarse ese número, Google tuvo que estudiar qué añadía cada entrevista al conjunto.

Una entrevista puede aportar una observación que cambie el juicio de quienes ya se han formado una opinión. Eso ocurre si la persona que pregunta ve al candidato hacer una tarea que los demás tenían pendiente de comprobar. Una vez cubierta esa parte del trabajo, pedirle que la vuelva a hacer con alguien distinto puede servir de confirmación. Según avanza el proceso, esa confirmación cuesta el tiempo de otra cita. Para saber si merecía la pena pagar ese coste, Google estudió el valor de las entrevistas a medida que sumaba nuevas evaluaciones. En el análisis que describen Eric Schmidt y Jonathan Rosenberg, la mejora en la precisión que aportaba cada entrevistador a partir del quinto era inferior al uno por ciento. La empresa acabó dejando el máximo en cinco.

La cifra procede del proceso que estudiaron. Conviene leerla junto con otra decisión del libro. En la época que describen, Google programaba las entrevistas para media hora. Los autores proponían reservar los quince minutos siguientes para que el entrevistador escribiera sus observaciones. Ese tiempo le permitía conservar los detalles de una respuesta antes de que llegara la siguiente cita. Si la conversación iba bien y merecía ampliarse, podían buscar un hueco para continuar. Acortar el tiempo previsto tenía un sentido distinto al de poner un límite a toda la serie. Lo primero buscaba aprovechar cada conversación. Lo segundo preguntaba cuántas conversaciones aportaban información suficiente para actuar.

Para entender la diferencia, pensemos en la información que recibe quien debe hacer la oferta. Las cuatro primeras personas podrían haber escrito informes extensos y haberse detenido todas en la misma parte del puesto. Si dejan sin examinar una tarea importante, el quinto encuentro puede aportar más que cualquiera de los anteriores. En cambio, cuando la tarea ya se ha visto y las observaciones coinciden, la siguiente cita puede volver a traer el mismo dato. Antes de convocarla conviene mirar qué se sabe y señalar qué respuesta se espera obtener.

La compañía volvió a publicar años después cifras de otra revisión de sus datos. En 2017 informó de que, en la muestra examinada, cuatro entrevistas permitían anticipar con un 86 por ciento de confianza si una persona debía ser contratada. La medida de aquel anuncio y la mejora descrita en el libro responden a preguntas distintas. Una mira la confianza que daba el conjunto de cuatro entrevistas en esa muestra. La otra mide cuánto añadía seguir después de la cuarta. En los dos casos, la empresa estudió sus propias entrevistas para saber qué obtenía del tiempo que pedía a los candidatos.

El tope de cinco podía ayudar incluso antes de entrevistar al primero. Si el puesto exigía tratar con clientes y resolver averías, quien organizara las citas podía pedir a una persona que observara una tarea y a otra que se ocupara de la segunda. Al reunir las notas, podría distinguir una duda sobre el candidato de un hueco que se debía a las preguntas elegidas. Si a nadie se le había pedido que viera cómo explicaba una avería al cliente, el expediente seguiría sin responder a esa pregunta por muchas notas que incluyera sobre la reparación.

El caso de las treinta citas permite entender qué cambia al poner ese tiempo en la cuenta. A quien prepara la siguiente entrevista le toca saber de qué parte del trabajo hablará y qué información espera aportar. La persona encargada de decidir puede aprovechar lo que ya han visto los entrevistadores y pedir una comprobación más si encuentra una razón para hacerla. Si la duda que queda procede de que cada entrevista ha preguntado por lo mismo, el tiempo sirve mejor cuando la nueva pregunta se prepara antes de volver a llamar al candidato.

¿Por qué conviene que varias personas revisen una contratación?

Quienes revisaban una contratación en Google recibían un expediente del candidato. La recomendación del jefe que quería incorporarlo iba acompañada de información que los demás podían examinar antes de que se le hiciera una oferta.

Urs Hölzle preparó el sistema de comités cuando la empresa sumaba empleados con rapidez. Los fundadores y Eric Schmidt habían observado que parte de quienes se incorporaban quedaban por debajo del nivel que consideraban necesario. Larry Page propuso que la dirección revisara todas las ofertas. Durante años leyó las que llegaban al final del proceso, después de que otros grupos las hubieran examinado. Los autores explican que organizaron el sistema dando prioridad a la calidad de las incorporaciones, incluso si esa revisión les llevaba más tiempo.

El jefe que busca a alguien conoce qué tareas están sin atender y qué compañero tendrá que dejar parte de su trabajo para ocuparse de ellas. Esa información ayuda a entender qué espera del candidato. El comité incorpora otra pregunta. Una vez resuelta la necesidad de hoy, ¿qué trabajo podrá hacer la misma persona si cambia el equipo o aparece una tarea distinta? En una empresa que se está haciendo grande, esa posibilidad pesa porque contratar supone incorporar a alguien que seguirá allí cuando el puesto, el proyecto o el propio jefe hayan cambiado.

Para que esa pregunta se pudiera discutir, el expediente reunía informes de entrevistas, antecedentes de trabajo y referencias. Cuando eran útiles se añadían muestras del trabajo del candidato. Los miembros del comité recibían la misma documentación, que era la base que podían utilizar para decidir. Si una observación importante faltaba, su autor debía dejarla por escrito antes de que pudiera valorarse. Eso daba a los demás ocasión de leerla, compararla con las otras y preguntar qué había ocurrido durante la entrevista.

La utilidad del expediente dependía de cómo se recogieran los hechos. Una nota alta permite localizar una valoración favorable, pero necesita lo que vio el entrevistador para que alguien que no estuvo allí pueda juzgarla. Los autores cuentan que se incorporaban datos sobre las notas que había puesto cada entrevistador en ocasiones anteriores. Eso permitía saber si una persona tendía a dar notas altas a casi todos los candidatos o si reservaba ese resultado para pocos. Dos notas idénticas podían haberse concedido usando criterios diferentes. Antes de darles el mismo peso, el comité tenía la posibilidad de conocer cómo se habían puesto.

También importaba preparar el informe para que se pudiera leer. Un resumen corto permitía encontrar las razones principales, mientras que la documentación completa daba acceso a lo que había detrás. Hasta una nota de estudios podía necesitar explicación si se había puesto con una escala distinta a la que el comité conocía. Mantener ese detalle junto al número evitaba que la comparación cambiara por la forma en que lo habían escrito.

El sistema pedía separar la capacidad de proponer a alguien de la autorización para incorporarlo. El jefe podía decir que el candidato no era adecuado para el puesto o explicar ante el comité por qué le parecía una buena elección. Sus observaciones seguían contando, pero se examinaban junto a las de quienes habían entrevistado a la persona y podían decir qué habían visto. Algunos responsables se resistieron a ceder esa parte de su trabajo. Para sostener el reparto, la empresa tenía que aceptar que una recomendación regresara al equipo si faltaba apoyo suficiente para tomar una decisión.

Ese tiempo adicional tiene sentido cuando permite examinar la propuesta desde una distancia que el responsable del puesto difícilmente tendrá. Mientras él procura cubrir una plaza que necesita ya, quienes leen el expediente pueden preguntar en qué trabajo se ha visto al candidato, qué puede aportar más adelante y qué falta saber. Para responderles sirve poco que el jefe lo recomiende con fuerza. Hace falta que el comité pueda seguir su razonamiento hasta las entrevistas y las muestras de trabajo en las que lo apoya.

¿Qué merece quedar escrito antes de que hablen los demás?

Un comité que va a estudiar una contratación recibe informes de personas que vieron al candidato en momentos distintos. Le sirve saber qué hizo ante cada pregunta, porque una descripción como «me gustó» deja pendiente qué trabajo se observó. El informe gana valor cuando quien estuvo allí deja por escrito ese hecho antes de que la opinión de otro le sugiera cómo recordarlo.

En Ruido, Daniel Kahneman, Olivier Sibony y Cass R. Sunstein estudian cómo cambia una reunión si cada persona registra primero su juicio. Cuando alguien anuncia su valoración al empezar, los demás pueden verse respondiendo a esa cifra. Cuando ya han escrito la suya, pueden explicar dónde diferían antes de oír a nadie. Esa distancia permite preguntar qué información llevó a cada respuesta.

Antes y durante la reunión	Cómo trabaja Google	Ruido
Qué se prepara por separado	El informe de lo que ocurrió en cada entrevista.	La valoración propia antes de conocer la de otros.
Qué se examina en común	Las pruebas de trabajo reunidas en el expediente.	La razón de las diferencias iniciales.
Qué pueden ocultar varias firmas	Que varios entrevistadores midieron la misma capacidad y dejaron otras fuera.	Que todos partieron de la misma opinión y la repitieron.

Pensemos en dos personas que entrevistan a quien podría incorporarse a un equipo de mantenimiento. Una le pide que siga los pasos de una avería ya conocida. La otra le entrega una máquina que se detiene por una causa distinta de la habitual. La primera puede escribir que el candidato siguió el procedimiento entero y la segunda que comprobó una pieza antes de localizar la causa. Si ponen en común esos hechos, el comité puede ver qué parte del trabajo conoce y dónde necesitaría más información.

Si los dos hubieran estudiado la misma avería, dos informes independientes seguirían ofreciendo una observación limitada. El comité de Google permite revisar qué parte del trabajo ha quedado cubierta por el conjunto. La separación que piden los autores de Ruido permite además averiguar si dos valoraciones llegaron por caminos distintos. En el momento de decidir, ambas cosas importan. Un expediente puede contener opiniones muy independientes sobre una sola habilidad y dejar sin observar otra que hace falta para el puesto.

¿Qué pesa más al elegir a quien prepara los pedidos?

Supongamos que una empresa de recambios busca a alguien para encargarse de los pedidos del almacén. Nuria, una de las candidatas, ha trabajado en un negocio más pequeño y conoce las piezas que venden. En la primera entrevista reconoce las que Fabio le pone delante y explica para qué sirve cada una.

Al día siguiente, Irene le pide que prepare un encargo con piezas colocadas en dos estanterías. Entre ellas hay un tornillo que se vende en bolsas de diez. Nuria lee en el papel que el cliente ha pedido veinte, coge dos bolsas y las cuenta antes de dejarlas en la caja. Irene anota lo que ve mientras Nuria sigue con el encargo. En la misma hoja apunta que ha necesitado ayuda para encontrar una referencia nueva, cuyo nombre se parece al de otra que estaba en el estante de al lado.

Fabio se cruza con Irene a la salida y le pregunta si la candidata le ha gustado tanto como a él. Irene tiene la hoja a medio escribir.

—Te lo cuento en la reunión. Quiero dejar apuntado dónde se ha atascado antes de que se me olvide cómo ha sido.

Cada uno entrega sus notas y Celia, que lleva el almacén, se sienta con ellos a leerlas. Fabio cuenta que Nuria identificó las piezas a simple vista. Irene les enseña el papel de la prueba, indicando la referencia que buscó con ayuda.

—Esa pieza cambia según el modelo —dice Celia—. Si manda la que está al lado, el cliente tendrá que volver.

—Buscó el número en la lista antes de abrir la caja —precisa Irene—. Cuando le enseñé dónde estaban las referencias nuevas, volvió a comprobarlo.

Celia necesita que la persona que entre sepa cuándo debe preguntar. Puede dedicarle dos mañanas a enseñarle dónde se colocan los recambios nuevos, igual que ha hecho con otras personas que conocían el oficio. Para elegir entre Nuria y el segundo candidato, les pide a Irene y a Fabio que miren cómo resolvió cada uno ese encargo. El otro candidato encontró antes el estante, pero dio por hecho que las dos referencias servían y metió la pieza equivocada.

Al ofrecerle el puesto a Nuria, Celia le dice qué trabajo hará con ella en los primeros días. El primer día, Celia le entrega una lista con los nombres que han dado a las piezas nuevas. Le pide que la lleve al estante donde está el recambio de la prueba. Antes de cerrar la primera caja con un pedido de verdad, comprobarán juntas el número que figura en la bolsa.

¿Cómo hacer que la información llegue a quien decide?

¿Para qué escuchar a quien discrepa cuando ya hay una mayoría?

Google abrió su buscador local en China en enero de 2006. El servicio mostraba un aviso cuando dejaba resultados fuera por exigencia de las autoridades. El aviso permitía saber que faltaba información. Quien estaba haciendo la búsqueda seguía sin poder verla desde esa página.

Había discrepancias dentro de la empresa desde que se planteó ofrecer ese servicio. Sergey Brin se oponía a participar en la censura. Eric Schmidt creía que estar en China podía facilitar el acceso a información y abrir alguna posibilidad de mejora. La empresa siguió adelante con un equipo en el país. Sus ingenieros mejoraron el buscador para las personas que lo usaban allí y, según cuentan los autores, tanto las visitas como los ingresos fueron aumentando hasta finales de 2009.

En diciembre de aquel año, la empresa detectó un ataque contra sus sistemas. La investigación encontró, entre otras cosas, intentos de acceder a cuentas de correo de activistas. Larry Page, que había estado de acuerdo con Eric Schmidt en seguir operando allí, pasó a apoyar la propuesta de Sergey Brin de dejar de filtrar las búsquedas. Era una decisión sobre lo que haría Google con un servicio que su equipo llevaba años mejorando. La comprobación del ataque explicaba por qué se reabría la discusión, pero quedaba por decidir qué iba a hacer la empresa cuando lo anunciara.

En una primera reunión, Eric Schmidt pidió que los participantes volvieran después de examinar la información, preparados para defender una posición. La cita siguiente fue el domingo 10 de enero. Sergey Brin abrió la reunión repasando durante más de una hora lo que habían averiguado. Quienes hablaron después podían discutir tanto la respuesta al ataque como las consecuencias de dejar de aceptar los filtros. Para unos, mantener el servicio les dejaba una posibilidad de influir en lo que ocurría allí. Para otros, la empresa ya tenía motivos suficientes para dejar de participar en esa forma de censura.

Eric Schmidt sabía que los dos fundadores se inclinaban por la segunda opción. Habría podido acortar la reunión al conocer sus posturas. Dejó que continuara y pidió una votación cuando el grupo ya había discutido los argumentos. La mayoría apoyó a Sergey Brin. Votar permitió que quedara recogida también la posición de quienes temían perder durante mucho tiempo la posibilidad de ofrecer el servicio en aquel mercado. El libro distingue esa posibilidad de hablar y defender un punto de vista del acuerdo completo, que en este caso seguía sin existir.

Una vez elegida la dirección, quedaba convertirla en pasos que los equipos pudieran llevar a cabo. El primer anuncio hizo públicos el ataque y el propósito de dejar de filtrar. La empresa se dio un tiempo para tratar con las autoridades las condiciones en que podría mantener un servicio sin aplicar ella misma la censura. En marzo, cuando ese buscador local dejó de ofrecer búsquedas, empezó a enviar a los usuarios al servicio de Hong Kong. Allí Google servía resultados sin filtrar por su parte, pero el acceso desde el continente seguía expuesto a bloqueos.

Quienes tenían que llevar el cambio a la práctica vivían consecuencias distintas. Los autores recuerdan que, al presentar la decisión ante empleados de Google, parte de la plantilla aplaudió de pie. En China, había personas preocupadas por su puesto de trabajo y por su seguridad. Según el relato del libro, Alan Eustace y miembros del equipo local ayudaron a sostener el trabajo allí durante el cambio. Acordar una decisión entre quienes dirigían la empresa dejaba pendiente acompañar a la gente que tendría que trabajar con sus efectos al día siguiente.

Cuando Google explicó la decisión a sus empleados, el equipo de seguridad repasó el ataque y cómo había llegado la dirección a su acuerdo. Para quienes trabajarían con el cambio, saber por qué se había tomado y qué pasos quedaban pendientes era parte de la ayuda que necesitaban. La mayoría había resuelto la pregunta sobre los filtros, mientras que las dificultades que otros señalaron durante la discusión empezaban a verse en los equipos que dependían de aquel servicio.

¿Qué necesita saber quien tiene que decidir después de escuchar objeciones?

La dirección de Google tenía que elegir qué hacer con su buscador en China después de los ataques informáticos descubiertos en 2009. Al discutirlo, Eric Schmidt y Sergey Brin sostenían posiciones distintas. Escuchar ese desacuerdo servía para conocer qué consecuencias veía cada uno, incluso si la empresa acababa tomando una decisión que uno de los dos habría resuelto de otra manera.

En El coach de Silicon Valley, Eric Schmidt, Jonathan Rosenberg y Alan Eagle cuentan cómo Bill Campbell acompañaba a responsables que necesitaban entender una dificultad antes de volver a hablar con su equipo. Podía seguir la explicación hasta que quien hablaba reconociera una pregunta pendiente. Si le habían atribuido a un compañero una razón sin preguntarle, la conversación con Bill Campbell podía ayudarle a reconocer esa suposición y a preparar la conversación con el compañero.

Las dos conversaciones tienen usos distintos antes de una decisión. Cuando la objeción ya está sobre la mesa, los responsables necesitan oír de quien la plantea qué consecuencia quiere evitar. Pueden estudiar si tienen margen para atenderla o si deberán asumirla. Si lo que circula es una explicación sobre por qué otro se opone, conviene volver a esa persona. Responder en la reunión a una razón que ella nunca dio puede llevar a cambiar un plan sin haber atendido su dificultad.

En qué punto está la decisión	Cómo trabaja Google	El coach de Silicon Valley
Quién puede aclarar qué ocurre	La persona que defiende una posición distinta explica sus razones.	La persona implicada puede aclarar lo que el responsable cree haber entendido.
Para qué se habla	Para conocer las consecuencias de cada opción antes de elegir.	Para separar una observación de una suposición y preparar una consulta.
Dónde sigue el trabajo	En la decisión y en explicar qué se ha aceptado al tomarla.	En la conversación que el responsable aún tiene que mantener.

Un desacuerdo puede sobrevivir a una decisión y seguir siendo útil. Si alguien había advertido de un coste, el equipo puede dejarlo señalado y mirar después cuánto se ha cumplido. Si la dificultad procedía de una suposición sobre otra persona, el trabajo es distinto. Hay que comprobar qué sabía esa persona y qué necesitaba. Con esa comprobación se puede volver a la mesa a discutir una consecuencia real en vez de intentar que todos coincidan sobre una historia incompleta.

Las dos miradas también cambian lo que conviene dejar por escrito al salir de la sala. En el caso de Google, a quien iba a preparar el cambio le servía conocer qué pérdida preocupaba a quienes defendían la otra opción, pues podía encontrársela al poner en práctica lo decidido. En la conversación que propone Bill Campbell, una nota tendría otra función si aún falta hablar con alguien. Puede guardar la pregunta pendiente sin dar por probada la explicación que ha ofrecido otro. Es la diferencia entre prepararse para una consecuencia que se ha discutido y comprobar primero de dónde viene una dificultad.

¿Quién puede parar una reserva antes de que alguien haga el viaje?

Pensemos en Lucía, que atiende por teléfono las reservas de un hotel. Le queda libre una habitación en la planta baja, con espacio para girar junto a la cama, y una clienta quiere reservársela a su padre. Antes de hacerlo le pregunta si su padre puede entrar por la puerta principal con la silla de ruedas.

Lucía está preparando la confirmación de la reserva cuando Mauro, el conserje, le recuerda que el albañil ha quitado la rampa para cambiar las baldosas. Lucía abre el correo donde tiene la fecha de la obra.

—Aquí pone jueves. Para cuando lleguen habrá acabado.

—El jueves viene a poner las baldosas —dice Mauro—. Esta mañana me ha pedido que deje el paso cerrado hasta el viernes.

El padre de la clienta llega el jueves después de comer. Lucía aparta la reserva y pregunta por la puerta del patio. Mauro la abre para que la vean desde fuera. Si quitan un macetero, se puede pasar por la verja con espacio de sobra. El último tramo tiene un escalón que él solía salvar con una rampa portátil. La trae del almacén y la coloca delante de Lucía. Al abrir la puerta hacia fuera, la hoja tropieza con el borde de la rampa y apenas gira.

—Sujétame la puerta un momento —dice Lucía, quedándose en el patio—. Voy a medir cuánto abre antes de darles una respuesta.

Mauro mantiene la puerta abierta mientras Lucía mide el hueco. Ella anota la distancia en la misma hoja donde tiene el nombre de la clienta y llama al número de la reserva. Le explica qué obras están haciendo y le da la medida de la puerta del patio.

—La silla de mi padre es más ancha —dice la mujer—. ¿Podríamos entrar por otro sitio?

Lucía vuelve a mirar la hoja de la obra. La entrada principal seguirá cerrada a la hora en que lleguen. Recuerda que en el hotel de la calle de abajo tienen una habitación a pie de calle y se ofrece a llamar antes de que la mujer tenga que cambiar el viaje.

—Si me guardan la habitación hasta esta tarde, puedo decírselo a mi padre en cuanto llegue a casa —responde la mujer.

Lucía confirma con el otro hotel que la habitación sigue libre y le pasa el teléfono a la clienta. Después borra de su pantalla el importe de la reserva y anota en la hoja de recepción hasta cuándo estará retirada la rampa. Antes de irse, Mauro deja la medida de la puerta del patio junto a esa fecha. Si alguien llama por la tarde, la persona que lo atienda podrá hablarle de las dos entradas antes de cobrarle la habitación.

¿Qué puede cambiar al reunirse cada día para tomar una decisión?

Google podía empezar a mostrar sus anuncios a quienes buscaban información en AOL. La propuesta de 2002 traía una condición que preocupaba a Eric Schmidt. Google tendría que garantizarle a su socio una cantidad de dinero que los anuncios aún tenían que producir.

AOL ya reunía a personas que buscaban en internet y a empresas que pagaban por aparecer ante ellas. Para Google, hacerse cargo del servicio suponía llegar a esos anunciantes sin tener que atraerlos uno a uno a su propia página. El acuerdo le daba esa posibilidad desde el momento en que empezara a funcionar. Los ingresos tardarían en llegar y serían inciertos. Si quedaban cortos, el socio tendría derecho a cobrar la cantidad garantizada. En esa diferencia entre el momento de comprometerse y el momento de cobrar estaba el riesgo que veía Eric Schmidt.

Omid Kordestani dirigía las conversaciones con AOL y compartía su preocupación. Larry Page y Sergey Brin estaban dispuestos a arriesgar más porque pensaban en lo que podían ganar al trabajar con aquel socio. David Drummond, el principal abogado de la empresa, y el consejo veían con buenos ojos aceptar. El consejo pensaba que Google podría pedir dinero prestado si llegaba a faltarle efectivo. Eso daba respuesta a una parte del problema, la de cómo cubrir un posible agujero, pero la empresa seguía necesitando averiguar hasta qué punto corría el riesgo de tenerlo.

Las primeras reuniones no resolvieron el desacuerdo. Eric Schmidt dispuso que durante seis semanas se reunieran a diario a las cuatro. Con esa cita reservada, cada persona podía volver sobre lo que quedaba abierto sin esperar a que todos encontraran otra fecha. La reunión del día siguiente también les mostraba pronto cuándo habían regresado con los mismos argumentos. El libro cuenta que, al principio, eso fue precisamente lo que ocurrió. A fuerza de repetir la discusión tuvieron motivos para buscar qué les faltaba para avanzar.

La información que podían reunir estaba dentro de Google. El equipo ya gestionaba anuncios y podía estudiar mejor cómo estaba funcionando el sistema que tendría que utilizar si aceptaban. Con esos datos revisaron el riesgo que habían atribuido al trato. La garantía seguía formando parte de la negociación. Lo que iba cambiando era el cálculo que les permitía comparar cuánto tendrían que pagar con lo que podrían conseguir por los anuncios. El plazo hizo que ese trabajo tuviera una fecha en la que debía servir para elegir.

Eric Schmidt y Jonathan Rosenberg cuentan que los análisis fueron reduciendo la preocupación del equipo. Finalmente, Google aceptó un trato que recogía en lo esencial las condiciones de AOL. El rendimiento posterior superó las garantías, un resultado que permite comprender por qué el compromiso pudo sostenerse, pero que nadie tenía delante en la negociación. Lo que el equipo tenía antes de firmar eran observaciones sobre su propio servicio y una estimación construida con ellas. Habría sido posible aceptar la misma oferta al principio, guiándose por el deseo de crecer. Aquel recorrido les permitió saber qué podían sostener de ese pronóstico antes de arriesgar el dinero.

La frecuencia de las reuniones ayudó porque había una pregunta que podía trabajarse entre una tarde y la siguiente. Quienes analizaban los anuncios tenían dónde llevar lo que encontraran y el grupo podía revisar el cálculo mientras seguía negociando. Para una tarea que necesitara esperar varias semanas a que aparecieran datos nuevos, una reunión diaria podía ocupar el tiempo que hacía falta para obtenerlos. En el acuerdo con AOL, los datos ya estaban a su alcance y Google debía responder en un plazo. La cita de las cuatro daba a ese trabajo un lugar donde convertirse en una decisión.

¿Cómo ayuda una respuesta breve a que el trabajo siga?

Una persona puede recibir un correo con una tarea para ella y ver que varios compañeros han recibido una copia. El mensaje les da a todos la misma información. Para quien tiene que hacer el trabajo queda una pregunta distinta. ¿Cuándo esperan que lo entregue?

Si contesta que ha leído el correo, quien se lo envió sabe que la petición ha llegado. Conocer la fecha permite ir un paso más allá. Pensemos en un equipo que va a mandar a sus clientes un aviso con el nuevo horario. La persona que prepara el envío pide por correo a una compañera que compruebe a qué hora cerrarán los viernes. Pone en copia a quienes atienden al público porque necesitan estar al tanto. Mientras la compañera busca la información, puede avisar de que la tendrá a la mañana siguiente. Quien prepara el envío sabe cuándo puede terminarlo y los demás conocen el punto en que ha quedado.

Si todos responden confirmando que han leído el correo, aumentan los mensajes sin cambiar la hora en que el equipo podrá hacer el envío. La información que faltaba sigue en manos de la misma persona. Ayuda distinguir a quienes tienen una tarea de quienes solo necesitan conocer su resultado. Los autores recomiendan pensar en eso cuando un correo útil llega a alguien que puede pasarlo a quien lo necesita. En el caso del horario, las personas que atienden al público necesitan saber cuándo empieza a aplicarse y a qué hora cerrarán. Pueden recibir esas dos informaciones cuando estén disponibles.

La fecha prometida ayuda también a quien debe comprobar el horario. Si para confirmarlo necesita hablar con otra persona, puede señalar el correo y volver a él cuando obtenga la respuesta. Los autores explican que separaban los mensajes en los que podían actuar al leerlos de los que exigían más trabajo. Guardaban estos últimos de forma que pudieran encontrarlos sin volver a buscarlos entre todos los correos recibidos. Si al día siguiente la compañera consigue confirmar la hora, puede contestar en el mismo intercambio, donde siguen la petición y la fecha en que debía resolverse.

Quien necesita la respuesta tiene su parte del seguimiento. En el fragmento del libro que publicaron en TIME, Eric Schmidt y Jonathan Rosenberg cuentan que, al enviar una petición pendiente, guardaban una copia identificada para poder volver a ella. Si se acerca la fecha de envío y falta confirmar la hora, la persona que prepara el aviso puede recuperar el mensaje y preguntar partiendo de lo que habían acordado. Un asunto de correo que mencione el horario del viernes facilita encontrar la conversación. Un título que diga solo «Una pregunta» obliga a abrir más mensajes para saber cuál contiene la petición.

El silencio funciona de manera distinta cuando el correo solo comunica algo que ya puede ponerse en marcha. Los autores cuentan que quienes trabajaban con ellos podían interpretar por lo general que tenían vía libre si no recibían objeciones. La costumbre de responder pronto cuando era necesario permitía sostener ese acuerdo. En el caso del horario, el mensaje que pide comprobar una hora necesita una respuesta con ese dato. El silencio puede servir más adelante, cuando el equipo ya conoce el horario y ha acordado cómo avisar si queda una corrección.

Si la compañera confirma la hora del viernes dentro del plazo, el mensaje de vuelta permite terminar el aviso. Quienes necesitan usar ese dato pueden recibir la decisión en un correo que diga cuándo comienza a aplicarse. Conservar la conversación donde se comprobó el horario permite regresar a ella si alguien encuentra después una diferencia entre el aviso y lo que figura en el tablón de la entrada.

¿Qué cambia cuando un jefe reserva tiempo para escuchar preguntas?

Marissa Mayer reservaba unas horas del miércoles por la tarde para recibir a quien quisiera hablar con ella. Quienes llegaban con una pregunta escribían su nombre en una pizarra cerca del despacho, donde podían ver si había otras personas esperando.

Mientras duraban las visitas, los compañeros con quienes compartía despacho solían buscar otro sitio para trabajar. Eric Schmidt y Jonathan Rosenberg reconocen el origen de ese horario en la universidad. Un profesor puede estar ocupado durante gran parte del día y reservar unas horas para que los alumnos vayan a verlo. Así les permite preguntarle por un trabajo sin tener que pedirle un favor cada vez que necesitan hablar. En la oficina de Google, la pizarra y los asientos cercanos hacían que esa idea pudiera funcionar también con varias personas esperando a la vez.

Una de las dificultades que resuelve ese sistema aparece antes de tener a la otra persona delante. Alguien que acaba de llegar a una empresa puede recibir permiso para hablar con cualquier jefe y desconocer cuándo interrumpirlo. Puede que haya visto a otros entrar a su despacho, pero ellos ya saben en qué momentos pueden acercarse o cuánto tiempo suele durar la conversación. Reservar un horario pone esa información al alcance de cualquiera que necesite ayuda. El acceso depende menos de haber aprendido cómo se hacen las cosas al trabajar allí durante un tiempo.

Los autores recuerdan que entre los que esperaban cerca de la oficina había jóvenes responsables de productos. En Google, ese trabajo consiste en ayudar a que un servicio que la empresa está preparando llegue a quienes lo van a usar. Al decidir qué debe hacer el equipo, surgen dudas que alguien con más experiencia puede ayudar a resolver. Para hablar de una de ellas, el responsable puede llevar lo que ya ha visto y explicar dónde se ha quedado. El turno le da ocasión de mostrar el asunto y contestar preguntas sobre él, algo que se vuelve más difícil si tiene que explicar toda la situación por escrito antes de saber cuándo podrá hablar.

En el mismo capítulo, Eric Schmidt y Jonathan Rosenberg cuentan que Urs Hölzle puso a disposición de su equipo un manual sobre su propia manera de trabajar. Explicaba que acostumbraba a hablar de forma directa y pedía que le avisaran si creían que estaba equivocado. Su equipo tenía miles de personas, de modo que podían consultar la guía cuando la necesitaban. Una práctica resolvía cuándo y dónde acercarse. La otra ayudaba a entender qué podía pasar al hacerlo. Si alguien dispone de un turno pero teme que se interprete una objeción como un ataque, sigue teniendo un motivo para callarse. Si conoce la forma en que el jefe prefiere recibir un comentario y carece de un momento para hablar, le queda una barrera distinta.

El horario de Marissa Mayer ofrecía un encuentro, cuyo valor dependía de lo que ocurriera dentro del despacho. Una visita puede servir para resolver una duda y volver al trabajo, o permitir que aparezca un asunto que exige una conversación con más gente. En el segundo caso, escuchar al que ha venido ayuda a saber quién falta y qué parte puede atender cada uno. Los turnos semanales sirven para abrir esa vía. Si la dificultad requiere atención antes del miércoles, la empresa necesita una forma de hacerla llegar sin esperar al siguiente horario.

Aquel despacho compartido podía recibir a gente que venía de otros equipos porque alguien había reservado el lugar y el tiempo para escucharla. La pizarra ordenaba el acceso y permitía que, cuando una persona saliera, la siguiente supiera cuándo entrar. Quien acababa de llegar a Google podía llevar una pregunta, esperar su turno y contársela a Marissa Mayer sin depender de conocer antes a alguien que lo llevara hasta ella.

¿Qué se aprende al poner a prueba una idea?

¿Cómo se prueba una idea que parece demasiado grande?

En 2002, Larry Page se planteó si una persona podría encontrar en internet lo que estaba escrito en un libro sin tener el ejemplar delante. Con el título se podía localizar una obra conocida. A él le interesaba llegar hasta su contenido, donde alguien podía encontrar una palabra que desconocía o una referencia que ni siquiera sabía en qué libro buscar.

Los libros de papel seguían fuera del alcance del buscador. Si quería encontrar una palabra en una página, Google tenía que empezar por conseguir una copia que el ordenador pudiera manejar. Es fácil imaginar cómo se hace con una hoja suelta. En cambio, un libro exige pasar las hojas una a una y conseguir una imagen de cada cara que se quiere leer. El tiempo que se dedica a esa tarea se repite con cada ejemplar, desde el más delgado hasta el que cuesta mantener abierto sobre una mesa.

Larry Page montó una cámara en un trípode y la colocó encima de una mesa de su despacho. Con Marissa Mayer a cargo de pasar las páginas, empezó a sacar fotos al paso que marcaba un metrónomo. Era el mismo aparato que ayuda a llevar el compás a quien practica con un instrumento. Usado allí, les permitía sostener un paso regular y ver qué cantidad de trabajo se podía hacer con cada golpe. La prueba se podía poner en marcha sin esperar la llegada de una máquina hecha a medida.

Eric Schmidt y Jonathan Rosenberg cuentan que, a partir de aquel ensayo, pudieron calcular lo que costaba llevar un libro al ordenador y estimar si un proyecto mayor era posible. En una primera cuenta, el tiempo por página permitía pasar a una cifra por libro. Para llevarla a una colección entera habría que saber cuántas personas podían hacer el trabajo a la vez y qué parte de la jornada dedicarían a preparar cada ejemplar, volver a tomar una foto o resolver un tropiezo. El ensayo daba una medida inicial con la que empezar a hacer esas preguntas. Las respuestas podían cambiar al trabajar con más libros y equipos distintos.

Una imagen tomada desde arriba permite mirar la página. Para encontrar dentro de ella las palabras escritas, el ordenador tiene que distinguir las letras y convertirlas en texto. Una fotografía movida o una palabra que se pierde en el pliegue junto al lomo complican ese trabajo. De ahí que, al estudiar un sistema para miles de ejemplares, interese observar a la vez cuánto tarda y qué calidad tiene lo que entrega. Una máquina que haga más fotos en un minuto puede dejar más páginas pendientes si las letras resultan difíciles de leer.

Con el tiempo, Google Libros trabajó con bibliotecas y editoriales. Cada acuerdo permitía poner nuevas obras al alcance de quien las buscaba. Podía aparecer la ficha de un libro o verse parte de su contenido, según la obra y los permisos disponibles. Esa parte del proyecto requería decisiones que seguían abiertas al terminar la prueba del despacho. Una cámara podía ayudar a calcular cuánto llevaría fotografiar las páginas. Decidir cuáles se podían enseñar y de qué manera exigía hablar con quienes podían dar acceso a los ejemplares o autorizar su uso.

Si la primera cuenta hubiera mostrado que el esfuerzo era demasiado grande, el equipo habría podido averiguar qué movimiento retrasaba la tarea antes de organizar una colección entera. Al comprobar que podía hacerse a un ritmo razonable, quedaba por encontrar un sistema con el que repetirlo con más libros. La estimación servía para tomar esa decisión. En la mesa del despacho solo hacía falta que dos personas siguieran el compás. Fuera de allí, cada nuevo ejemplar tendría que pasar por un trabajo que pudiera hacer más gente y que dejara las páginas listas para buscar en ellas.

¿Qué podemos averiguar con lo que ya tenemos a mano?

Larry Page y Marissa Mayer pudieron fotografiar las páginas de un libro con una cámara y contar cuánto tardaban. La prueba hacía visible un trabajo que el plan de digitalizar libros daba por posible. Antes de pedir equipos o formar un grupo más grande, tenían una manera de calcular qué esfuerzo podía exigir una parte de ese proyecto.

En El manual del emprendedor, Steve Blank y Bob Dorf piden averiguar qué ocurre en la jornada de quien podría utilizar o comprar lo que se está preparando. Supongamos que alguien quiere vender cubiertas para resguardar de la lluvia los puestos de flores de un mercado. En su taller puede medir cuánto tarda en montar la cubierta una persona con las herramientas que trae el paquete. Para saber si una florista podría hacerlo antes de abrir, necesita conocer cuándo le dejan entrar en el recinto y en qué momento tiene que estar atendiendo.

El lugar de la primera prueba depende de qué duda puede detener el proyecto. Si la cubierta exige media hora para montarse, se puede descubrir en el taller antes de pedir tiempo a los vendedores del mercado. Si se monta rápido pero la florista tiene que colocar primero todos los cubos, habrá que ver desde dónde puede sujetarla con el puesto ya lleno. En cada caso se puede empezar con algo sencillo porque ya se sabe qué habrá que mirar. La cubierta que resuelve las dos dificultades puede seguir esperando otra comprobación con quien deba pagarla o autorizar su instalación.

La duda que hay delante	Cómo trabaja Google	El manual del emprendedor
Qué se quiere aprender primero	Cuánto trabajo lleva copiar las páginas.	Qué necesita hacer la persona que podría usar el producto.
Qué permite responder	Realizar la operación y observar cuánto tarda.	Seguir la tarea donde se hace y conocer sus condiciones.
Qué obliga a volver a probar	Un cambio de formato, de equipo o de cantidad.	Una dificultad del lugar, otro modo de uso o la decisión de quien paga.

La primera respuesta merece guardarse con las condiciones en que se obtuvo. Los minutos de la cámara sirven para estudiar el paso que Larry Page y Marissa Mayer realizaron con aquel libro. El tiempo que ha tenido una florista para montar la cubierta sirve para ese puesto y para la hora a la que entró. Si hay que atender libros de otro tamaño o puestos con menos espacio, el equipo dispone de una referencia con la que decidir qué cambia y qué necesita repetir antes de ampliar el trabajo.

¿Cuántas cajas se pueden preparar con el tiempo y la gente que hay?

Una cooperativa que prepara cuarenta cajas de fruta para el mercado puede recibir el encargo de hacer doscientas para una fiesta. Imaginemos a Pilar con el pedido delante. Cada caja llevará la misma cantidad que las del mercado. El comprador quiere recogerlas todas a las ocho del sábado.

El viernes, Pilar y Omar pueden usar el local durante tres horas. Pilar calcula que, si llaman a dos compañeros más, tendrán gente suficiente para pesar, colocar y cerrar las cajas. Omar mira dónde ponen las que ya están llenas. Con las del mercado ocupan el espacio que hay junto a la puerta. En cuanto apilan unas cuantas, solo queda un hueco por donde pasar con el carro.

—Antes de decir que sí, hagamos mañana cuarenta con cuatro personas —propone—. Déjame apartar las primeras veinte como si fueran a quedarse hasta el sábado.

—La fruta sí la tenemos —dice Pilar—. Si encontramos dónde meter las cajas, puedo llamar a otros dos para que pesen.

El día de la prueba ponen a una persona en la báscula, otra va llenando las cajas y las otras dos cierran y llevan las cajas llenas a la salida. Mientras hay sitio para dejar las primeras, las cuatro pueden seguir trabajando. Al llegar a la caja veintiséis, Omar pide que paren el carro. Para subirlo por la rampa tiene que pedirle a Pilar que mueva la pila que acaban de hacer. La báscula queda libre un rato, con la fruta en la mesa y las cajas esperando sitio.

Pilar apunta que necesitaron una hora para preparar las primeras veinticinco cajas, las que pudieron apilar dejando libre la rampa. El viernes pueden usar el local de cinco a ocho. Si el comprador manda una furgoneta después de las seis, tendrán una tanda lista y les quedará tiempo para hacer otra en cuanto se lleve la primera. Lo llama para preguntarle a qué hora puede mandar la furgoneta.

—A las seis y media podría estar ahí —le contesta—. ¿Cuántas le dais al conductor?

—Veinticinco el viernes y otras veinticinco el sábado. Podemos hacer más si tenéis a alguien que se las vaya llevando, pero para las doscientas habría que buscar sitio y abrir el local más horas.

El comprador necesita cerrar el pedido esa tarde y confirma las cincuenta que Pilar puede preparar. Buscará las demás en otra cooperativa. Cuando la furgoneta llega el viernes, la pila está apartada de la rampa y Pilar puede subir el carro sin pedirle a nadie que mueva las cajas. Tras la recogida, Omar lleva las cajas vacías a la báscula. Antes de llenarlas deja libre el pasillo por el que sacarán las del sábado.

¿Qué ayuda a que otros se sumen a una idea?

En Google había una lista de correo en la que los empleados podían dar a conocer sus ideas. Cuando Kevin Gibbs escribió a esa lista en 2004, incluyó un enlace que sus compañeros podían abrir para comprobar cómo funcionaba lo que estaba haciendo.

El enlace llevaba a una prueba del buscador. Kevin Gibbs había preparado un sistema que, a partir de unas pocas letras, enseñaba varias maneras de continuar la búsqueda. El usuario podía elegir una de ellas cuando coincidía con lo que tenía pensado escribir. Quien quisiera comprobar si aquello era cómodo tenía que actuar como cualquier persona que busca algo, poniendo las primeras letras y esperando a ver qué palabras aparecían en pantalla.

Para que la ayuda llegara en ese instante, el programa tenía que trabajar mientras alguien escribía. Kevin Gibbs utilizó búsquedas anteriores para que las propuestas tuvieran un orden y pudieran aparecer primero las que más gente había hecho. Si se trataba de una consulta habitual, era fácil que la persona encontrara pronto la expresión que llevaba en la cabeza. Si estaba buscando algo poco común, podía seguir escribiendo y prescindir de la ayuda. El programa le ofrecía maneras de seguir y el usuario conservaba la posibilidad de poner la suya.

Un compañero que solo recibiera una descripción podría preguntarse si de verdad merecía la pena cambiar la página en la que ya sabía buscar. Al abrir la prueba podía comprobar cuánto tardaban en salir las propuestas o qué sugería el programa después de una letra más. Hasta una búsqueda que funcionara mal le daba información que podía compartir con Kevin Gibbs. Cuando alguien señalaba lo que había escrito y lo que se le había ofrecido, ambos podían volver sobre ese caso. De esa manera, las conversaciones empezaban sobre algo que las dos personas habían visto.

El libro cuenta que varios ingenieros se unieron al proyecto. Google dejaba que sus empleados dedicasen parte de su tiempo a trabajos que ellos mismos eligieran, siempre que atendieran sus responsabilidades. Esa libertad permitía que Kevin Gibbs abriera un camino desde su puesto, pero reunir un equipo suponía que otras personas quisieran acompañarlo. Quien veía la página funcionando se podía hacer una idea de lo que era capaz de aportar. Un compañero podía reconocer un fallo en el orden de las sugerencias y saber dónde mirar. Otro podía ver que las palabras tardaban en aparecer y ayudar a averiguar qué retrasaba su llegada. Son maneras distintas de ayudar a partir de lo que se podía observar en la misma prueba.

En diciembre de 2004 se abrió Google Suggest al público como parte de Google Labs, el espacio donde la empresa dejaba probar servicios que seguían en desarrollo. El uso por parte de más personas permitía ver qué ocurría con búsquedas muy diferentes de las que solían hacer los empleados. En 2008, la función empezó a ofrecerse por defecto en la página principal de Google. Quien solo quisiera escribir de la manera habitual podía continuar haciéndolo, mientras las propuestas aparecían para quien quisiera usarlas.

Entre la primera prueba y aquella incorporación a la página principal pasaron varios años. La decisión que Kevin Gibbs podía tomar al principio era más pequeña. Tenía una versión que respondía a lo que alguien escribía y una lista de compañeros a la que podía hacérsela llegar. Quienes se unieron encontraron una página sobre la que ya podían trabajar. El siguiente avance no dependía de que todos compartieran la imagen que tenían en la cabeza al leer el correo. Podían empezar por una búsqueda que quisieran hacer funcionar mejor.

¿Quién puede dibujar una calle que falta en el mapa?

Google se encontró con lugares para los que podía conseguir imágenes tomadas desde el aire y en los que seguía siendo difícil encontrar un plano con las calles dibujadas. Desde arriba se veía una parte de la ciudad. Quien necesitaba llegar a una dirección tenía que poder reconocer por dónde entrar y en qué punto se unía una vía con la siguiente.

Esa diferencia ayuda a entender para qué servía Map Maker. Una fotografía muestra un cruce con el mismo detalle con que muestra un patio o un terreno. Un mapa hace otro trabajo. Indica qué parte de la imagen es una calle y adónde se puede llegar por ella. Para dar ese paso, Google abrió en 2008 una herramienta con la que cualquier persona podía aportar datos sobre los lugares que conocía, empezando por países entre los que estaba Pakistán.

Quien aportaba información podía acercarse con el mapa a su barrio y dibujar la calle siguiendo la imagen. Sobre el papel, el trabajo parece tan fácil como pasar un lápiz por donde se ve una línea. Al acercarse a un cruce aparece una dificultad. Un camino puede quedar oculto por los árboles o parecer unido a otro cuando entre los dos hay un muro. La persona que ha pasado por allí puede saber dónde se acaba y hasta qué punto se puede seguir. Cuando lo indica, añade a la imagen lo que ha aprendido caminando o conduciendo por esa zona.

Google permitía añadir más que calles. Si alguien situaba una escuela y otra persona dibujaba la vía por la que se llegaba a ella, cada aportación hacía más útil la otra. El nombre de la escuela ayudaba a encontrar el punto al que ir. El camino completaba la información al mostrar por dónde acercarse. Cuando ambas cosas podían verse juntas, la persona que consultaba el plano ganaba una manera de preparar el trayecto incluso desde otro barrio.

Abrir el mapa a quienes vivían allí dejaba una cuestión pendiente. Cada persona podía dibujar lo que conocía, pero el plano que acabaría consultando el resto necesitaba alguna forma de comprobar los cambios. La herramienta permitía a sus participantes revisar aportaciones antes de que se incorporasen al mapa general. Quien conociera bien el mismo lugar podía ver si una calle llegaba al punto indicado o si el trazo debía acabar antes. Los participantes podían mejorar así una parte del mapa sin tener que encargarse de toda la ciudad. Google, por su parte, ofrecía el lugar donde se reunían y revisaban esas aportaciones.

Eric Schmidt y Jonathan Rosenberg presentan el caso de Pakistán al hablar de lo que una empresa puede aprender de quienes usan sus servicios. En las primeras etapas, el equipo de Google enseñó cómo el dibujo de Islamabad se iba llenando con el trabajo de sus habitantes. Al mirar el plano de la capital en momentos distintos se veía cómo unas vías se juntaban con otras y daban forma a zonas que antes estaban casi vacías. Cada una de las personas que intervino tenía a su alcance solo una parte de lo que hacía falta. Al compartirla, ayudaba a construir un plano que ninguna de ellas habría podido hacer por su cuenta con la misma facilidad.

La información local puede cambiar. Se abren calles, se cierran pasos y un comercio se muda. Un mapa hecho una sola vez empieza a perder detalle en cuanto la ciudad se mueve. Con Map Maker, el mismo vecino que había trazado una calle podía volver a mirar ese lugar y señalar un cambio. Ahí se prolongaba el trabajo que empezaba con la primera aportación. La gente podía revisar el dibujo según lo que iba ocurriendo fuera de la pantalla.

¿Qué puede enseñar el público después de un primer lanzamiento?

El primer Chrome salió para Windows como versión de prueba en septiembre de 2008. Google tenía un navegador que ya permitía abrir páginas de internet y podía ponerlo en manos de gente que usaba su ordenador de maneras diferentes.

Antes de ofrecerlo al público, los técnicos podían comprobar si abría las páginas con las que trabajaban y qué pasaba al tener varias abiertas. Durante la prueba abierta aparecían más combinaciones. Un usuario podía entrar en una página que los ingenieros conocían poco y encontrar un fallo que en la oficina se producía con poca frecuencia. Cuando un problema sucede en un ordenador de fuera, saber que ha ocurrido es el primer paso para poder buscarlo. Con el permiso del usuario, Chrome podía mandar avisos automáticos sobre algunos de esos fallos.

En diciembre, Google retiró la etiqueta de prueba de aquella versión para Windows. En el anuncio explicó que los mensajes del público y los avisos automáticos habían ayudado a corregir problemas. Ese avance muestra qué hacía posible la primera salida del navegador. Una vez que el programa había empezado a utilizarse en otros ordenadores, sus creadores podían recibir información con la que seguir trabajando. Quien instalara Chrome en diciembre se encontraba con un programa que ya incorporaba parte de aquel trabajo.

Eric Schmidt y Jonathan Rosenberg utilizan Chrome para explicar otra decisión ligada a ese primer lanzamiento. En 2008 el navegador salió con poca publicidad. Google podía dar a conocer la existencia del producto sin gastar desde el comienzo lo que costaría intentar convertirlo en el navegador habitual de mucha gente. En mayo de 2009 la empresa anunció un ensayo de anuncios en televisión, que le permitía averiguar a su vez qué podía conseguir con ese medio. Con el tiempo, el uso del navegador siguió creciendo y los autores relacionan el impulso de promoción más amplio con el crecimiento que Chrome ya había conseguido.

En mayo de 2010 Google comunicó que el navegador había llegado a 70 millones de usuarios. Entre el día en que la empresa lo abrió al público y la fecha en que dio esa cifra, había tenido tiempo de escuchar a quienes lo usaban y revisar lo que ofrecía. También disponía de una señal para decidir cuánto esfuerzo dedicar a que más gente lo conociera. Había personas que ya habían elegido usarlo cuando podían seguir con el programa anterior. Llevarlo ante otras personas era una apuesta distinta al cabo de esos meses de uso.

La primera versión tenía que hacer bien las tareas que una persona necesitaba al abrir internet. El libro distingue ese cuidado de la amplitud del producto. Google empezó por Windows y dejó para después las versiones para otros sistemas. Así podía probar con un grupo amplio de ordenadores sin esperar a tener preparado el navegador para todos. Si una persona descargaba Chrome, la espera de otras versiones carecía de importancia siempre que la suya le permitiera abrir bien las páginas. La fecha de salida se podía adelantar concentrando el trabajo inicial en conseguir que esa parte funcionara.

Al considerar cuándo anunciar Chrome a más gente, el equipo tenía que separar lo que sucedía al instalar el programa de lo que sucedía al volver a usarlo. Una campaña podía llevar a muchas personas a descargarlo en una tarde. Si regresaban enseguida al navegador anterior, aquella primera visita contaría como una descarga aunque el producto hubiera dejado de acompañarlas. En cambio, cuando alguien seguía abriendo Chrome para hacer sus tareas, ponía a prueba el programa varias veces y en situaciones distintas. Ese recorrido permitía formular otras preguntas sobre qué le servía y qué problemas seguían apareciendo.

En un navegador, la empresa puede distribuir por internet una nueva versión cuando localiza y corrige un problema. Para una empresa que vende una máquina, sustituir una pieza en todos los aparatos que ya ha entregado supone otra clase de esfuerzo. Eric Schmidt y Jonathan Rosenberg señalan que, en esos casos, una manera de aprender consiste en poner a disposición del público una muestra o un modelo de prueba antes de fabricar grandes cantidades. En Chrome, la versión de septiembre pudo desempeñar esa función siendo ya útil para navegar. Cada ordenador que la usaba añadía una oportunidad de comprobar cómo funcionaba en un lugar que quedaba fuera de las pruebas de Google.

¿Para quién debe funcionar una primera versión?

El equipo de Chrome puso el navegador al alcance del público antes de dedicarle una campaña grande. Al dejar que la gente lo utilizara, podía observar cómo se extendía una herramienta que ya servía para entrar en páginas de internet. Los recursos de publicidad podían esperar mientras los usuarios decidían si querían volver a abrirla.

En El método Lean Startup, Eric Ries recoge el camino de SnapTax, una aplicación con la que Intuit quería ayudar a preparar la declaración de impuestos desde el móvil. La primera versión se dirigió a personas con declaraciones sencillas que solo habían trabajado en California. Ese límite dejaba fuera casos que exigían otras funciones, mientras las personas incluidas podían probar si la aplicación resolvía su trámite.

Decisión antes de ampliar	Cómo trabaja Google	El método Lean Startup
Qué se deja en manos de los primeros usuarios	Un navegador que ya permite entrar en páginas de internet.	Una aplicación para un tipo delimitado de declaración.
Qué puede crecer después	La difusión, si la gente encuentra motivos para usarlo.	Los tipos de declaración, a medida que se preparen para ellos las funciones necesarias.
Qué conviene observar	Si las personas lo prueban y siguen utilizándolo.	Si quienes cumplen las condiciones pueden acabar su trámite.

La primera versión puede ser pequeña por el trabajo que hace o por las personas a las que sirve. Chrome permite estudiar qué uso consigue un producto antes de gastar más en darlo a conocer. SnapTax deja ver otro límite. Si se invita a alguien cuya declaración contiene datos que la aplicación no puede recoger, su salida indica que ese caso quedó fuera. Para conocer si la ayuda funciona, interesa mirar qué ocurre con la persona a la que sí se preparó para atender.

La diferencia cambia dónde trabajar después. Si los primeros usuarios prueban el navegador y regresan al que ya tenían, poner más anuncios puede traer más pruebas sin resolver la causa del abandono. Si una aplicación permite a las personas previstas terminar su declaración, habrá información para estudiar cuál es el siguiente caso que merece atenderse. Hacerla llegar de golpe a más gente solo servirá para ese aprendizaje si se distingue quién puede terminar el trabajo y quién necesita una versión que aún se debe preparar.

Imaginemos que ambos equipos reciben la misma noticia una semana después. Muchas personas han probado el programa y pocas han terminado lo que empezaron. En Chrome interesaría saber si, después de abrir sus páginas habituales, tuvieron un motivo para volver al navegador de siempre. En SnapTax, antes de cambiar la aplicación, el equipo tendría que comprobar si quienes se quedaron a medias podían hacer su declaración con aquella versión. Si tenían ingresos de otro estado y ese caso quedaba fuera, ampliar el público habría cambiado el significado de la cifra. Si cumplían las condiciones y todos se detenían en la misma pregunta, ahí habría un punto concreto por el que empezar a trabajar.

¿Dónde se coge el autobús el sábado de mercado?

Si una empresa de autobuses ofrece una página para mirar dónde para cada línea, puede empezar por las dos que pasan por el hospital. Las otras seguirían con su horario en papel mientras un grupo de viajeros prueba la página. A Teresa le toca encargarse del primer sábado.

Teresa ha recorrido los mapas en el ordenador de la oficina. Sabe dónde aparece la parada que se usa cuando hay mercado y que, al seleccionar la línea, aparece una nota con el cambio del sábado. A primera hora se acerca a la calle desde la que solían salir los autobuses. Allí encuentra a Faustino, que quiere llegar al hospital para visitar a su hermano.

—Me sale que estoy en la parada —dice él, acercándole el teléfono—. Aquí me marca el punto azul.

En la pantalla se ven dos calles casi enteras. El punto azul señala dónde está Faustino. Teresa le pide que toque el nombre de la línea y aparece debajo la nota del sábado. Faustino desliza el dedo para intentar ver la calle que pone en el aviso. La dirección se sale de la pantalla.

—¿Y esa calle cuál es desde aquí? —le pregunta, mirando hacia los dos extremos de la plaza.

Teresa le enseña por dónde llegar y hace el camino con él hasta que ve el cartel de la otra parada. Desde allí llama a Andrés, que ha preparado los mapas. Le cuenta lo que estaba buscando Faustino y le pide que abra la página en su teléfono, empezando por la línea sin tocar ningún botón más.

—Estoy viendo la parada de los días de diario —dice Andrés—. El aviso lo puse donde sale el horario entero.

—El sábado, al entrar, necesitamos ver primero el sitio por donde pasa hoy. Detrás podemos dejar la parada del resto de la semana.

Antes del siguiente mercado, Andrés cambia la página de esas dos líneas. El sábado por la mañana, Teresa vuelve a la plaza y le pide a otra viajera que busque la parada en el móvil. Al abrir la página, la mujer encuentra la calle por la que puede cogerlo ese día. Tiene que pedirle que le señale por dónde se llega andando, de modo que Teresa apunta la esquina donde se pierde y la lleva a la siguiente reunión. La página sigue abierta para las mismas dos líneas. Teresa y Andrés dibujan el camino desde la plaza, marcando dónde se gira al llegar al quiosco. Quedarán allí el sábado siguiente, cuando pueden comprobar si a los viajeros que vienen por ese lado les sirve la indicación.

El sábado siguiente, una mujer abre el mapa cerca del quiosco, se orienta con la indicación y llega a la parada con tiempo. Teresa le pregunta qué ha mirado para decidir por dónde ir. La mujer le enseña la esquina marcada y vuelve a guardar el teléfono al ver llegar el autobús. Teresa apunta dónde había empezado a buscar. Si más adelante quieren abrir el mapa a otras líneas, tendrán que comprobar los caminos que siguen los viajeros desde otras calles.

¿Qué saben hacer quienes trabajaron en un proyecto que se cierra?

En la presentación de Google Wave, las personas que asistían pudieron ver en pantalla las letras que escribía alguien mientras iba formando una frase. El programa permitía seguir lo que hacía otra persona sin esperar a que enviara el mensaje.

Esa capacidad había salido de un equipo de Google en Sídney que se preguntó cómo podría funcionar el correo si se inventara de nuevo. Con un mensaje corriente, quien lo recibe lee la versión que alguien decidió mandar. Wave permitía que varias personas compartieran un espacio y vieran los cambios mientras estaban ocurriendo. Podían añadir contenido y trabajar sobre lo que otros habían puesto en la conversación.

En la demostración, el público vio cómo iba apareciendo aquella frase. Podía seguir lo que escribía alguien al otro lado y le resultaba fácil reconocer que los ingenieros habían resuelto un problema. Una vez fuera de la sala, la pregunta era si la gente iba a escoger ese espacio cada vez que necesitara hablar o trabajar con otra persona. Para que le sirviera, su compañero tendría que estar dispuesto a entrar también. Si ambos ya usaban el correo de costumbre, la ventaja tenía que ser suficiente para que quisieran cambiar la manera en la que resolvían aquella tarea.

Wave se presentó en 2009. El equipo fue introduciendo mejoras, pero la cantidad de personas que lo usaban se quedó por debajo de la que esperaba Google. En agosto de 2010, la empresa anunció que dejaría de desarrollarlo como producto separado. En ese anuncio se comprometió a mantenerlo disponible durante un tiempo y a preparar maneras de sacar el contenido que los usuarios habían guardado allí. A quien llevaba meses trabajando en Wave le hacía falta resolver esa cuestión para poder continuar fuera de él.

La retirada dejaba también decisiones dentro de Google. Un programa es una suma de piezas que se han hecho para resolver tareas. Cuando el producto al que pertenecen deja de tener el público que necesita, algunas de ellas siguen siendo útiles. La empresa anunció que aprovecharía parte de la tecnología en otros proyectos y había hecho públicas algunas de sus piezas para que otras personas pudieran usarlas. Eric Schmidt y Jonathan Rosenberg cuentan que parte del trabajo de Wave pasó a Gmail y a Google+. Lo que se había creado para una herramienta podía seguir dando servicio al incorporarse a otra.

En cuanto a las personas, los autores recuerdan que muchos de los ingenieros del equipo fueron buscados por otros grupos dentro de la empresa. Habían trabajado en problemas que esos grupos podían encontrar al crear sus propios productos. Pensemos en lo que supone hacer que varias personas vean los cambios de un escrito compartido. Hay que encontrar la manera de enviar cada cambio, mostrarlo a tiempo y conservar el trabajo que cada persona va haciendo. Los ingenieros que habían intervenido en Wave podían reconocer dificultades de ese tipo y trabajar a partir de lo que ya conocían.

Quien recibe el encargo de probar una idea difícil puede observar cómo se ha tratado a las personas que se arriesgaron antes. Si tras el cierre encuentra que la empresa busca dónde usar lo que sabe hacer aquel equipo, puede ver qué oportunidades seguirían disponibles si su propio proyecto terminara. Para quien tiene que decidir dónde invertir tiempo y dinero, la pregunta es distinta. Puede retirar el apoyo al producto si su uso no da motivos para continuar y buscar a la vez un lugar donde sus piezas y su gente hagan falta. En Wave hubo usuarios que tuvieron que preparar la salida, ingenieros que encontraron otras tareas y tecnología que continuó usándose en proyectos distintos. Cada uno necesitaba una decisión propia.

¿Cuánto trabajo merece una pieza de un proyecto que se cierra?

Al estudiar el cierre	Cómo trabaja Google	¡Abandona!
Qué seguía por conseguir	Que Google Wave reuniera usuarios suficientes para mantenerse como producto.	Que Glitch llegara a reunir y conservar el público necesario para sostener el juego.
Qué pudo tomar otro camino	Partes del trabajo técnico que pasaron a otros productos.	Una herramienta interna que acabaría dando lugar a Slack.
Cuándo conviene separar las decisiones	Al comprobar si otro equipo puede utilizar una parte del trabajo.	Al decidir cuánto más merece dedicar el equipo al juego en las condiciones de ese momento.

Cerrar Google Wave interrumpía el trabajo de sostenerlo como producto. Parte de la tecnología que habían preparado sus ingenieros podía servir por separado, de modo que la decisión sobre el servicio dejaba abierta otra pregunta. Los responsables de Gmail o Google+ podían examinar qué les resultaba útil dentro de su propio trabajo. Esa utilidad dependía de lo que cada equipo pudiera hacer con la pieza, incluso si el producto del que procedía había reunido poco público.

Annie Duke sigue en ¡Abandona! la decisión de cerrar Glitch. El juego había conseguido usuarios, pero la persona que tenía que decidir si seguía financiándolo necesitaba saber cuánto trabajo faltaba para que se sostuviera. Dentro de la empresa habían preparado una herramienta para hablar entre ellos que más tarde se convirtió en Slack. En el momento de cerrar el juego, su desarrollo como producto independiente pertenecía a un futuro que aún desconocían.

Los equipos de Google que incorporaron partes de Wave ya sabían a quién tenían que servir con sus propios productos. Podían preguntar si alguna de las funciones les ahorraría trabajo o mejoraría una tarea que los usuarios ya hacían. Al pasar de Glitch a Slack, el equipo tenía delante un problema distinto. Usaba su herramienta para hablar mientras preparaba un juego y necesitaba averiguar si a otros grupos les serviría para trabajos que podían ser muy diferentes. Eso requería dedicar tiempo a un producto que iba a tener que encontrar a su público.

La pregunta de Annie Duke se refiere al dinero y al trabajo que seguiría consumiendo el juego para llegar a sostenerse. Si el equipo decide retirarlo, lo que haya aprendido pasa a ser una opción para otro trabajo. Para estimar lo que vale esa opción hay que mirar qué le falta. Integrar una función en un programa que ya usa la gente exige comprobar que encaja con lo que ese programa hace. Ofrecer una herramienta interna como servicio independiente obliga a averiguar quién querrá incorporarla a su jornada y qué ayuda necesitará para empezar.

¿Cómo avisa la biblioteca a sus lectores cuando se retira el armario?

Supongamos que una biblioteca quiere que sus lectores recojan los libros después de la hora de cierre. Para probarlo alquila un armario de seis puertas y lo pone en el vestíbulo del centro cívico, donde se puede entrar hasta las diez. Cuando el personal deja un libro en uno de los huecos, envía a quien lo ha pedido el número que le permite abrir esa puerta.

Cada vez que se abre una de las puertas, el programa que la controla guarda la hora. Antes de renovar el alquiler, Belén revisa esas horas y ve que la mayoría de los libros se han recogido con el mostrador abierto. Entre las recogidas de la noche figura la del martes. La hizo una mujer que trabaja en la frutería y sale después del cierre de la biblioteca. Al día siguiente dejó un mensaje para dar las gracias. Raúl, que se ocupa de las reservas, lleva el mensaje a la reunión.

—Para ella sí cambia la hora —dice, señalando la recogida en la hoja de Belén—. Si quitamos el armario, tiene que venir en su día libre.

Belén le pasa las cuentas del trimestre. El alquiler cuesta lo mismo con los seis huecos llenos que si se abre una puerta por la noche. Con el dinero que tienen también pueden abrir el mostrador una tarde hasta las ocho, pero el horario no alcanzará a todos los que salgan más tarde.

—Los avisos de que ha llegado el libro, ¿dependen del armario? —le pregunta Belén.

Raúl enseña cómo se mandaban los mensajes antes de la prueba. Los jueves sacaba una lista de los libros que habían vuelto y avisaba a sus lectores, de modo que algunos podían tardar días en enterarse. Con el armario, el aviso sale en cuanto el libro se registra. Varios de los mensajes agradecen saber qué día pueden pasar, aun cuando vengan al mostrador.

—El mensaje lo manda el ordenador de aquí —dice Raúl—. Si el libro se queda en la estantería de reservas, podemos avisar igual.

Cuando termina el alquiler, devuelven el armario y conservan el aviso en el momento en que se aparta cada libro. En el mensaje añaden la tarde en la que el mostrador cerrará más tarde. Raúl llama a la mujer de la frutería para explicárselo.

—A las ocho sigo aquí —le dice ella—. ¿Puedo mandar a mi hijo cuando me llegue el mensaje?

Raúl le pide el nombre del hijo y le explica qué tendrá que enseñar en el mostrador. Antes de colgar, le dice qué día esperan recibir el libro que acaba de reservar. La mujer apunta la fecha en el calendario de la tienda para hablarlo con su hijo esa noche. Le avisará cuando reciba el mensaje y él podrá pasar al salir de clase.

¿Cómo preparar el trabajo para lo que pueda cambiar?

¿Cuánto trabajo se reserva a una idea que aún está por probar?

En 2002, Sergey Brin tenía delante la lista de los cien proyectos principales de Google. Al revisarla, pudo distinguir el trabajo que ya atendía a los usuarios de aquel que se encontraba en sus primeras pruebas. Entre los dos quedaban los productos que empezaban a tener público y seguían creciendo.

De los cien proyectos de la lista, unos setenta se ocupaban de los servicios que sostenían a la empresa. En ese grupo estaban el buscador y los anuncios que lo acompañaban, dos servicios que seguían necesitando atención cada día. Alrededor de veinte eran productos más recientes en los que la empresa ya había visto algún resultado. Los diez restantes tenían otra clase de dificultad. Eran trabajos nuevos que podían fallar con facilidad y que, si prosperaban, podían llegar a ser importantes. Según Eric Schmidt y Jonathan Rosenberg, lo que empezó como una forma de ordenar la lista acabó sirviendo de guía para repartir los recursos. Ese diez por ciento pertenecía a la empresa y podía repartirse entre proyectos. El tiempo que un empleado dedicaba a una propuesta que había elegido por su cuenta se decidía de otra manera.

Ese reparto obliga a reconocer en qué punto está cada trabajo. En el buscador, un cambio se puede estudiar sobre un servicio que tiene público. La empresa sabe que hay gente que entra y puede medir qué ocurre después de la modificación. Un producto reciente puede haber demostrado que le sirve a un grupo y necesita averiguar si puede atender a otro mayor. En un proyecto que acaba de comenzar, lo primero es descubrir si es capaz de hacer lo que se espera. Si las tres tareas tienen que competir presentando los mismos resultados, la que se encuentra en el último caso tiene que prometer lo que apenas ha podido probar.

Eric Schmidt explicó años después, en una entrevista con Tim Ferriss, que revisaban el reparto para que las prisas del trabajo diario dejaran sitio a proyectos que podrían servir dentro de varios años. Un problema en el buscador pide atención enseguida. Para que la prueba de una idea nueva siga teniendo alguien a su cargo al día siguiente, conviene saber qué parte del equipo se había comprometido a hacerla. Revisar la cuenta permitía ver si esa parte estaba desapareciendo cada vez que surgía una urgencia.

El grupo de ideas nuevas recibía una parte acotada. Gracias a ella, sus equipos podían investigar antes de pedir lo que costaría desarrollar la propuesta entera. El límite tenía otra consecuencia. Si una primera prueba salía mal, el trabajo pendiente seguía siendo una decisión que la empresa podía tomar sin tener ya todos los recursos entregados. Quien dirigía el proyecto podía revisar dónde había fallado y decidir si una prueba distinta tenía sentido, contando con lo que quedaba disponible.

Jonathan Rosenberg recuerda lo que vivió en Apple con el Newton, un aparato de bolsillo que permitía escribir sobre la pantalla con un lápiz especial. El programa debía leer las letras y convertirlas en palabras que el dispositivo pudiera utilizar. En las pruebas internas, a quienes habían trabajado en el desarrollo les resultaba más fácil conseguir que el Newton reconociera lo escrito. Hasta ellos adaptaban la manera de escribir para que funcionara. Quien lo comprara fuera de Apple usaría su letra de siempre y podía encontrarse con que el aparato entendía otra cosa.

La cantidad de trabajo ya dedicado al Newton hacía difícil revisar qué significaba aquella prueba. Si la empresa se quedaba con el hecho de que algunas personas conseguían que el programa leyera lo escrito, podía avanzar hacia el lanzamiento. Si se detenía en cómo lo conseguían, aparecía una tarea por resolver. El aparato tenía que entender a la gente que nunca había practicado con él. Esa diferencia resulta más fácil de examinar cuando queda tiempo para cambiar lo que se va a fabricar y está pendiente buena parte de lo que se pretende gastar.

Al reservar una parte para los proyectos inciertos, Google asumía que alguno podía tener un buen resultado y pedir más medios. El reparto de una primera prueba no tenía por qué ser el del año siguiente. Un equipo que comprobara que su producto funcionaba para el público al que se dirigía podía volver a pedir recursos aportando ese dato. Si se encontraba con una dificultad como la del Newton, convenía que la siguiente decisión dependiera de lo que sucedía con la escritura de sus futuros clientes, antes de convertir la experiencia de unas pocas personas en la respuesta de todo el público.

¿Qué información justifica mover personas de un proyecto a otro?

Google encontró en su lista de proyectos una diferencia entre el trabajo que sostenía el buscador y la publicidad, el de productos que empezaban a funcionar y el de ideas que aún podían fallar. Separarlos permitió preguntar cuánto esfuerzo recibía cada clase de trabajo. Una empresa puede ocupar a casi toda su gente atendiendo lo que ya tiene y enterarse de que nadie dispone de unas horas para probar lo que necesitará más adelante.

En La empresa invencible, Alexander Osterwalder, Yves Pigneur, Alan Smith y Fred Etiemble proponen mirar juntos los negocios actuales y las ideas que se están probando. Al volver sobre esa lista, la dirección puede enterarse de que una actividad pierde clientes o de que un equipo nuevo ha hecho una prueba que permite comprometer un poco más de dinero. La decisión se toma con la información que se tiene de cada proyecto, incluso cuando ya hay un reparto general para los distintos trabajos.

Qué hace falta decidir	Cómo trabaja Google	La empresa invencible
Cuánto se reserva para cada tipo de trabajo	Se reparte la atención entre el negocio principal, lo que empieza a crecer y lo que aún se explora.	Se miran juntas la actividad que ya vende y las ideas que necesitan pruebas.
Cuándo puede cambiar el reparto	Cuando lo nuevo ya muestra un resultado que merece más apoyo o el trabajo principal necesita sostenerse.	Cuando cambia lo que se sabe sobre la actividad, sus clientes o el riesgo que sigue abierto.
Qué error se puede detectar	Que un tipo de trabajo absorbe el tiempo de todos.	Que dos proyectos reciben el mismo trato pese a contar con pruebas distintas.

La diferencia importa si dos equipos necesitan a la misma persona. Uno atiende los pedidos de un producto que la empresa ya vende y ha descubierto que los retrasos se repiten cada viernes. El otro quiere averiguar si puede entregar un producto nuevo en una población cercana. Reservar tiempo para ideas nuevas permite que esa prueba llegue a hacerse. Decidir quién ayuda el viernes exige saber cuánto trabajo quedaría pendiente en los pedidos y qué necesita la prueba para ofrecer una respuesta.

Si el nuevo equipo ha hablado con varias tiendas, pero aún desconoce si alguna aceptará recibir un pedido, puede empezar por comprobarlo con una sola. Para organizar esa entrega puede pedirle al compañero que le ayude una mañana. Si después varias tiendas piden repetir y el transporte sigue saliendo demasiado caro, el mismo proyecto necesitará ayuda distinta. El reparto general permite que exista un lugar para probar. Revisar cada proyecto permite ver cuándo una hora más serviría para aprender algo y cuándo conviene devolverla al trabajo que sostiene los pedidos de esa semana.

¿Qué puede hacer una empresa cuando su ventaja empieza a desaparecer?

Quien compraba un ordenador de Sun Microsystems podía encargarle trabajos que quedaban fuera del alcance de otras máquinas de precio parecido. A una empresa que necesitaba terminar esas tareas para prestar un servicio le compensaba pagar por aquella diferencia.

En sus años de trabajo en Sun, Eric Schmidt vio cómo mejoraban los ordenadores con piezas de Intel y con el sistema Windows de Microsoft. Aquellas máquinas podían venderse a precios que los fabricantes de equipos especializados encontraban difíciles de igualar. Si año tras año iban ganando potencia, podían terminar sirviendo para trabajos por los que antes se pagaba más. La ventaja de Sun dependía en parte de cuánto tardarían los otros en llegar a ese punto.

Eric Schmidt recuerda haber planteado esa posibilidad a los responsables de Sun. En aquella conversación llegaron a la conclusión de que la empresa no podría reducir sus costes hasta competir en precio con la industria de ordenadores personales. Eso dejaba pendiente otra pregunta. Si vender la misma clase de máquina por menos dinero quedaba fuera de su alcance, ¿qué trabajo podría seguir resolviendo para sus clientes que valiera lo que cobraba?

Para empezar a averiguarlo, se podía distinguir a los clientes por lo que necesitaban hacer. Una empresa podía pagar por una máquina de Sun porque le ahorraba horas en un trabajo que hacía todos los días. Otra podía comprarla porque en aquel momento era la opción que le permitía hacer un trabajo que sus otros equipos no podían asumir. Si llegaba al mercado una máquina más barata capaz de completar esa segunda tarea, el cambio podía empezar por ese cliente. En el primero, habría que comprobar si la diferencia de tiempo seguía siendo lo bastante grande para justificar el precio. Comparar las máquinas haciendo ese mismo trabajo permitiría saber cuánto tiempo ganaba el cliente con una y qué ahorro tendría si compraba la otra.

La respuesta completa podía tardar. Mientras tanto, Sun podía observar las tareas que ya se estaban haciendo con ordenadores más baratos y preguntar a sus propios clientes cuándo pensaban sustituir los que tenían. Esas observaciones podían enseñar algo que el precio por sí solo dejaba fuera. Si los equipos más baratos empezaban a servir para un grupo reducido de tareas, la empresa podía estudiar a tiempo cuánto dependía de las ventas destinadas a ese grupo. Si la pérdida se extendía, podía mirar qué más necesitaban quienes la habían elegido hasta ese momento.

Según recuerda Eric Schmidt, la reunión terminó sin que quedara encargado un trabajo de fondo sobre aquella cuestión. Los ordenadores personales siguieron ganando capacidad y los servidores con Windows, que prestaban servicios a otros ordenadores dentro de las empresas, acabaron ganando terreno. Sun fue dando más peso a los programas. En 2009 Oracle anunció el acuerdo de compra y en enero de 2010 comunicó que había completado la adquisición.

Eric Schmidt y Jonathan Rosenberg recuperan lo ocurrido en Sun al hablar de preguntas que una empresa tiene motivos para hacerse antes de que cambie su mercado. En el momento en el que Eric Schmidt habló con los responsables, les era difícil saber en qué año los otros ordenadores llegarían a servir para las mismas tareas. Podían examinar cuáles estaban empezando a asumir, comprobar cuánto costaban y volver a hacer la cuenta cada vez que una de esas máquinas ganara capacidad. Esa tarea podía empezar con el siguiente ordenador que llegara al mercado, mientras Sun seguía vendiendo los suyos.