Resumen del libro Team Geek
Pablo Santos Luaces. Decano CPIICyL
En estas últimas semanas he estado leyendo algunos libros y siempre que puedo suelo tomar notas para que me sirvan después para acordarme o incluso para escribir algo. Este post lo escribí originalmente para el blog interno de la empresa, pero después he pensado que podría ser interesante publicarlo en el Colegio.
El libro del que voy a hablar se llama Team Geek (), es de 2012 y fue Javier Garzás quien me habló de él hace uno o dos años, una vez que coincidimos en la UVA.
Es un libro de moda sobre equipos, de alguna forma un Peopleware moderno.
Está escrito por dos ingenieros de Google, que además fueron programadores de Subversion y los contrató Google para implementar SVN sobre BigTable (su mega sistema cloud). Se centra en cómo gestionar equipos de ingenieros, haciendo hincapié además en cómo dirigir bien si antes has estado en desarrollo.
Longitud y estilo del libro
En total son unas 200 páginas, es fácil de leer, pero no entra en ser desesperantemente ligero (me he estado leyendo The Software Craftsman, que ya hablaré sobre él, y ese es más flojo en ese aspecto) y cuenta cosas interesantes.
Comienzo con un resumen de los capítulos.
Pablo Santos Luaces. Decano CPIICyL
En estas últimas semanas he estado leyendo algunos libros y siempre que puedo suelo tomar notas para que me sirvan después para acordarme o incluso para escribir algo. Este post lo escribí originalmente para el blog interno de la empresa, pero después he pensado que podría ser interesante publicarlo en el Colegio.
El libro del que voy a hablar se llama Team Geek (), es de 2012 y fue Javier Garzás quien me habló de él hace uno o dos años, una vez que coincidimos en la UVA.
Es un libro de moda sobre equipos, de alguna forma un Peopleware moderno.
Está escrito por dos ingenieros de Google, que además fueron programadores de Subversion y los contrató Google para implementar SVN sobre BigTable (su mega sistema cloud). Se centra en cómo gestionar equipos de ingenieros, haciendo hincapié además en cómo dirigir bien si antes has estado en desarrollo.
Longitud y estilo del libro
En total son unas 200 páginas, es fácil de leer, pero no entra en ser desesperantemente ligero (me he estado leyendo The Software Craftsman, que ya hablaré sobre él, y ese es más flojo en ese aspecto) y cuenta cosas interesantes.
Comienzo con un resumen de los capítulos.
Capítulo 1 – The myth of the genius programmer
Insiste en que es mejor trabajar en equipo, que lo de pensar que quieres ser un mega genio trabajando solo, y que nadie vea lo que haces porque van a ponerlo en duda, es mala idea… cosas de ese estilo pero bien argumentadas.
Introduce el concepto de “bus factor”: cuánta gente tiene que atropellar un autobús para que el proyecto esté en riesgo (por aquello de que los equipos muy pequeños tienen más riesgo).
Habla también de las oficinas abiertas, de que el tema de “oficinas con puertas” ya no se lleva (no tengo claro que tenga razón, por sentido común más que nada).
Introduce el concepto de HURT que es central en el libro y una de las ideas con las que quedarse como gestor de proyecto (realmente HRT, pero pronunciado hurt): humility, respect and trust (y mete la U para que suene bien). Cómo gestionar las críticas de otros, ser abierto para las code reviews, etc.
Capítulo 2 – Building an awesome team culture
El capítulo se centra en explicar que hay que intentar definir a propósito una cultura, un estilo de hacer las cosas, desde el principio, de modo que luego la gente que se una al equipo se adapte a esa cultura y la adopte como propia.
Si no lo haces, vendrá alguien que lo hará por ti, y que igual no es el espíritu que quieres para el equipo (se pone en la piel de los fundadores y primeros empleados).
Y que el estilo del equipo se contagia. En plan que si aceptas las críticas, pues todos lo harán, que si todo el mundo se trata a gritos, también se contagia, etc, etc.
Habla de hacer un “mission statement” del equipo, pero evitando chuflas tipo gran empresa para que no quede patético, pero que puede ayudar a definir objetivos y cultura. Esto me recuerda siempre a los fabulosos posters de http://despair.com que son una crítica muy dura de los de verdad que te encuentras en muchos sitios.
Incide en los “meetings eficientes” y referencia al artículo de Paul Graham sobre por qué los ingenieros odiamos las reuniones, cuándo planificarlas, etc. A raíz de esto en nuestro equipo hemos decidido cambiar los daily sprints al final de la mañana.
Como nota Paul Graham es el autor del libro Hackers and Painters, todo un clásico. Me lo he leído a trozos, nunca entero, pero es muy, muy interesante. El capítulo 6 “how to make wealth” es toda una explicación del capitalismo y de la cultura de las startups. Muy bueno. Siempre confundía este libro con otro muy famoso, The Cathedral and the Bazaar – se puede encontrar en PDF open source).
Sigue el capítulo haciendo recomendaciones sobre cómo usar ciertas herramientas a nivel de equipo: el chat, el email, docus de diseño, comentarios, issue trackers…
Capítulo 3 – Every boat needs a captain
Habla de la visión anticuada de manager y de la tendencia nueva de “líder de equipo”. Más fácil decirlo que hacerlo, claro. Pone ejemplos interesantes y hace recomendaciones de cómo gestionar bien la situación si pasas de ingeniero a manager, incluso cómo gestionar las relaciones con tus amigos, qué hacer y qué no, no ser demasiado blando, etc.
Introduce anti-patrones como no contratar “low performers”, tampoco gente que siempre te siga la corriente, no intentar ser amigo de todo el mundo, etc. Y también patrones de cosas que debes hacer.
Me ha resultado interesante y siempre se sacan puntos a mejorar o directamente a corregir.
Capítulo 4 – Dealing with poisonus people
Este capítulo me lo he leído ya muy por encima, así que no tengo todos los detalles.
Trata de cómo gestionar gente dañina para el equipo. Desde los choques de egos, la gente demasiado perfeccionista (ideas sobre cómo reconducir su energía), hasta directamente troles (esto centrado en proyectos open source) con la mítica frase “don’t feed the troll” que me suena de haberla leído en más sitios.
Capítulo 5 – The art of organizational manipulation
Lo mismo con este, lo he pasado por encima. Parece interesante para cualquiera que esté en una gran empresa (y en Google saben ya un rato de esto) porque trata de cómo navegar grandes organizaciones y los problemas derivados de la política, ideas de cómo gestionarlo, etc. Incluso cómo pedir a un ejecutivo que haga algo… para ser efectivo y que te haga caso.
Capítulo 6 – Users are people, too
Expande la orientación original del libro y se extiende a cómo gestionar la relación con los clientes.
Nada más arrancar hace una parodia del típico comercial que todo técnico odia: “don’t be this guy” dice.
Y luego sigue con cosas interesantes sobre la usabilidad del software: hacer una curva de entrada sencilla, que la velocidad es súper importante, no intentar que el software haga de todo porque es contraproducente, no “ser vago” dejando el problema de elegir al usuario … y aquí mete otra captura que merece la pena:
La verdad es que no he leído tampoco el capítulo con calma y en detalle, y aunque parece que no va mucho con el resto del libro, es de los que merece la pena leer porque son las típicas cosas que como técnicos solemos pensar que “no van con nosotros”. En el caso de mi equipo creo que muchas de este estilo, seguro que no todas, las hemos aprendido a base de años de trabajo.
Conclusión
El libro es interesante pero decir que es un Peopleware moderno me parece demasiado.
No sé, Peopleware me parece muy superior, aunque quizá sea muy subjetivo y opine eso porque en su momento me influyó mucho y ahora este me toca menos. No obstante, si siguiera dando clase lo recomendaría a mis alumnos y les mandaría leerlo 🙂