Liderazgo técnico y generación de espacios

Reflexionando sobre mi trabajo los últimos años, donde he tenido que cumplir con ese rol dual de liderazgo técnico (tech lead, lead engineer) y manager de equipos (engineering manager, vp of engineering) en startups con equipos de producto e ingeniería pequeños (máximo 10-12 personas), me doy cuenta de que lo más valioso que he conseguido ha sido facilitar espacios de reflexión, discusión y aprendizaje continuo.

¿A qué me refiero cuando hablo de espacios? Realmente, a nada físico o temporal, sino a una manera de entender el trabajo del equipo y sus actividades en el día a día. En muchas ocasiones, especialmente en los contextos en los que yo me he desarrollado, nos vemos atrapados en un ritmo frenético de trabajo (con el objetivo de demostrar la viabilidad de la empresa, buscar su product market fit, conseguir una nuevo cliente, etc.) y ese rodillo puede sepultar las capacidades del equipo para abstraerse y ganar la perspectiva necesaria para servir como motor de cambio y mejora continua. Aunque seguro que no únicamente en startups se vive con prisa, ¿verdad? 🙂

Mis iniciativas en este ámbito han orbitado siempre en torno a los siguientes 3 puntos:

• Utilizar cada tarea (story, feature) como una oportunidad única para aprender: como desarrollador, no hay curso o taller que me haya enseñado más que el propio día a día escribiendo código y desafiando mi propia manera de hacer las cosas una y otra vez en búsqueda de soluciones alternativas que sean mejores (más sostenibles, escalables). Introducir en el equipo el mindset de que cada nueva tarea es una oportunidad para aprender y experimentar requiere tiempo, y constancia (y, especialmente, ¡no desdecirte a las primeras de cambio!), pero estás contribuyendo a crear un espacio de aprendizaje continuo en el día a día.
• Utilizar cada code review como un espacio de discusión: este espacio viene casi de gratis, ya que no son pocos los equipos que tienen integrado en su día a día la revisión de código a través de pull/merge requests. Me gusta fomentar un entorno donde las revisiones de código no sean únicamente un trabajo de revisión (valga la redundancia) sino que se utilicen como un instrumento de aprendizaje y conversación. Evidentemente, con matices, ya que no todas las merge requests contienen cambios tan interesantes como para generar un debate a su alrededor. Del mismo modo, no todos los debates merecen bloquear una merge request, por lo que debería ser natural continuar una discusión incluso habiendo fusionado ya los cambios propuestos (¡o incluso arrancar la discusión con la merge request ya cerrada!).
• Crear eventos recurrentes PARA el equipo: y aquí hablo únicamente de mi experiencia trabajando en empresas de producto. Hay pocas cosas que generen más inercia que un compromiso explícito por parte de la empresa en desarrollar una cultura de aprendizaje continuo. Sin necesidad de negociar cosas (tan importantes) como presupuestos de formación, es posible realizar pequeñas inversiones a través de actividades como clubs de lectura (una hora a la semana -¡en PrivacyCloud lleva funcionando desde 2017!), meetups internos donde integrantes del equipo puedan compartir hitos, realizar presentaciones sobre aprendizajes de las últimas semanas, ver alguna charla juntas, practicar una kata...

Y de manera tangencial...

• En mi experiencia, invertir tiempo en tener ciclos de feedback (muy) cortos fomenta sin lugar a dudas espacios de experimentación dentro del equipo. A todos los niveles. Si poner cambios en producción se puede hacer de manera autónoma, rápida y confiable, me animaré seguro a validar diferentes hipótesis lo antes posible. Si se cuenta con rituales como retrospectivas (en un contexto donde se puedan realizar de manera honesta) cada 1-2 semanas, abrazaré el cambio con mayor seguridad, ya que podré ir revisándolo cada poco.
• Las pull requests son un compromiso en el camino por alcanzar un trabajo 100% colaborativo (a través de pair o mob programming -dinámicas que aún no he conseguido interiorizar completamente ni ver aplicadas de manera recurrente en ningún equipo en los que he trabajado, pero que me encantaría). Razón de más para aprovechar esos tiempos de revisión para crear nuevos espacios de discusión.