de Roy Osherove
Por qué lo he leído
Ya tengo unos años de experiencia en esto de desarrollar software. No me veo capaz todavía de liderar un gran equipo de desarrollo, pero me siento más inclinado hacia un liderazgo técnico que un liderazgo de gestión. Así que, ¿por qué no aprender un poco sobre un rol que tengo ganas de hacer?
Qué esperaba
El nombre del autor me sonaba de algo, no sé exactamente de qué, pero no recuerdo haber leído algún otro libro suyo. Pero me sonaba que era un autor muy práctico, con muchísima experiencia en la industria del software, por lo que esperaba un libro de lleno de vivencias y experiencias. Quizá una historia que guiara al lector por el camino de crear un equipo autoorganizado (que está tan de moda ahora con las metodologías ágiles).
Qué encontré
Encontré una descripción de las fases en las que se puede encontrar un equipo de desarrollo, bueno, la visión del autor, pero algo es algo. El libro también está lleno de ejemplos y consejos sobre cómo mejorar el equipo, cómo hacer que miembros de un equipo mejoren en su carrera profesional.
También, una sección del libro está dedicada a testimonios de absolutos expertos en la materia. Estos últimos capítulos están llenos de experiencias reales y de consejos de gente brillante y con una ingente cantidad de experiencia en el desarrollo de software.
Conclusiones
El libro consta de varias partes. Comienza describiendo las fases en las que se puede encontrar un equipo de desarrollo, y cómo avanzar de una a otra, hasta conseguir el equipo perfecto.
Es un libro muy buen-rollista, tanto que a veces da la impresión de ser un libro de autoayuda. Pero el libro está lleno de consejos super útiles. Quizá se echa de menos la parte contraria, por ningún lado se encuentra cómo arreglar problemas dentro del equipo. Supongo que no era el objetivo del libro.
La última sección del libro, la dedicada a los testimonios, tiene muchísimo valor. Los mejores de los mejores ponen su granito de arena en el libro y dedican unos consejos al lector que de otra forma sería imposible recopilar.
Si lo que te interesa es el aspecto técnico del desarrollo, éste puede ser un libro para ti. Puedes leer mis notas en Notas sobre Notes to a software team leader.
Qué he aprendido
- Usar la autoridad debe ser el último recurso. Ayudar a cada uno a encontrar su camino ayuda a que ambas partes ganen.
- Comunicación y traducción de información son habilidades críticas de un líder.
- Necesitas discutir, influenciar, negociar y no decirle a la gente lo que debe hacer.
- Dar feedback es una técnica muy efectiva, pero debe ser de confianza, concreto, constructivo, e incluir contexto.
- Un líder técnico debería programar, aunque no mucho, pero sobre todo debería practicar pair programming, design y code reviews y también debería buscar que no se genere demasiada deuda técnica.
Frases que me gustaría recordar
- El autor identifica tres formas de liderar un equipo: comando y control, coach y facilitador. Simétricamente, identifica tres fases en las que se puede encontrar un equipo: supervivencia, aprendizaje, auto-organización.
- Para salir de la fase de supervivencia, hay que preocuparse de una cosa: crear tiempo libre (slack time) como un estándar en tu flujo de trabajo.
- Esto es por lo que te pagan: para hacer las cosas mejor y de la forma más profesional, clara y transparente posible. Te pagan por llevar al equipo a un nivel donde hacen las cosas profesionalmente, para llevar al equipo al próximo nivel de rendimiento y profesionalismo. Para ello, quizá tengas que tomar algunos riesgos.
- Para salir del modo de supervivencia, debes pasar al menos el 50% del tiempo con ellos. Lo primero que hay que hacer es una inversión de tiempo, y el que debe comenzar eres tú (no reuniones, quizá horas extra,…)
- El aprendizaje más rico y verdadero es cuando damos un salto en el conocimiento, no estando seguros en la parte plana del gráfico (hace referencia a un gráfico de aprendizaje de planicies seguidos de saltos, como escalones).
- Sumergirse en una nueva cultura de formas de trabajar es dar un salto cualitativo de conocimiento. Jugar a lo seguro no lo es.
- Crear un lenguaje de compromiso es un paso esencial para que los miembros del equipo mantengan sus promesas con los demás.
- Cuando la gente se te acerque con un problema, rétale a que lo resulva por sí mismo, pero que sepa que te tiene a tí como mentor, pero déjale claro que tú no vas a solucionar el problema.
- Miembros del equipo se pueden llevar deberes a casa, pero tiene que ser voluntario, no lo deben tomar como trabajo.
- Los problemas más difíciles de resolver nunca son técnicos, suelen involucrar a las personas.
- Un buen líder técnico mantiene siempre un ojo puesto en la calidad. Cuando el equipo crece, las personas de más confianza cumplen parte de esta misión.
- Una buena táctica para tener un equipo feliz es animar al equipo a usar un período de tiempo semanal para aprender nuevas habilidades o tecnologías.
- Las ideas de cambio deberían venir tanto de tí como de miembros del equipo.