Elección de tecnología en un equipo
Hace una semanas alguien hacía la siguiente pregunta por twitter:
Mi opinión sobre esto es bastante clara. La elección de la tecnología debería basarse en necesidades reales del negocio o del equipo, basada en datos.
La motivación del equipo en función de la tecnología es una estrategia que algunas empresas usan para retener y especialmente para atraer talento, pero en mi experiencia a largo plazo crea problemas, por ejemplo elegir el nuevo lenguaje de moda (cough cough elixir) y que luego te cueste la vida encontrar gente con ese conocimiento.
¿Estoy diciendo que los miembros del equipo no deberían elegir la tecnología? No, no. Todo lo contrario, deberíamos empoderar a los equipos y que sean ellos quienes decidan que herramienta es la mejor para resolver un problema, pero no confundir eso con elegir una herramienta solo por motivar a la gente.
Lo ideal es que los equipos tengan una visión holística del sistema y tengan la información y las habilidades necesarias para elegir que herramientas usar. De hecho el poder elegir la tecnología está relacionado con mayores índices de retención pero no confundamos con elegir lo que nos de la gana solo porque queremos aprender a usarlo. Muchas empresas lo que hacen es establecer una estrategia técnica para poner unos límites que nos ayuden a tener estos debates, en esa estrategia técnica se suele definir cosas como qué tipo de servicios se usan, que lenguajes o qué tipo de arquitecturas están permitidas, etc. Por ejemplo:
Se permite el uso de Python y Java.
Los servicios siempre estarán en proveedores cloud.
La recomendación es arquitecturas orientada a eventos.
Y cualquier cosa que se salga de ahí tiene que pasar un proceso para aprobarse, donde se tiene que demostrar la necesidad real.
En el caso de que estéis entre dos cosas que tienen el mismo beneficio para la empresa, las mismas ventajas, etc pues perfecto elegir la que más motive, pero que no sea la única razón. Vamos a imaginarlo al revés, dejamos que el equipo elija una herramienta porque tienen ganas de aprender eso, es la nueva moda. ¿Qué pasa cuándo a tu equipo llegue gente con motivaciones diferentes, les dejarás que elijan otra tecnología nueva para motivarles?. Parece una receta perfecta para tener deuda técnica, y poner trabas a la movilidad entre equipos, algo que también es clave para la retención. Porque si dejamos al equipo elegir tecnología solo por motivarles, acabaremos teniendo tecnologías diferentes en función del equipo. A veces se nos olvida las ventajas de que una empresa sea consistente con la elección de la tecnología, por mencionar algunas:
Mejor movilidad entre equipos como decía antes.
Productividad. Por ejemplo, es más fácil invertir en herramientas para desarrollo (imaginad herramientas como mutation testing, guías de estilo, etc).
El ramp-up de la gente es más fácil pues a través del tiempo y de la experiencia de la gente se acaba mejorando la experiencia y mejorando la documentación. Así como que habrá más gente que pueda ayudar a mentorizar o revisar.
La máquina de hiring está más engrasada. (por ejemplo no necesitas entrenar a gente para entrevistar en cada lenguaje, tecnología que tenéis).
Dicho esto, hay margen para que la gente aprenda nuevas cosas aunque no se puedan usar en la empresa/equipo. Cosas que yo he hecho en el pasado y han funcionado muy bien:
Talleres. En algunas empresas he traído a expertos en algún área para enseñar al equipo (por ejemplo kubernetes, prometheus o cassandra) , además eran talleres en abierto y se podía apuntar gente de fuera. Era un win-win porque el equipo aprendía una nueva tecnología y por ende, si realmente se podía usar para nuestro caso de uso. Y segundo, funcionaba muy bien para atraer talento en la empresa.
Clubs de lectura. Dónde leíamos un libro y compartíamos los aprendizajes y cómo podían aplicar a nuestros problemas.
Compartir artículos cada semana y debatir sobre ellos. Compartíamos artículos de cosas que habíamos identificado que necesitamos mejorar o aprender y luego debatíamos entre todos como usarlo. Por ejemplo: Testing, estructuras de datos, …
También hacíamos talleres internos. Si alguien quería aprender algo pero no tenía cabida en la empresa o no estaba claro su beneficio, esa persona podía dedicar algún tiempo a aprender esa tecnología pero a cambio tenía que enseñar al resto del equipo los aprendizajes.
Ahora, aquí es clave ser muy claro con las expectativas! si esa tecnología no se puede usar en la empresa, déjalo claro. Lo peor que puedes hacer es que la gente piense que ese aprendizaje y esfuerzo es para empezar a usarlo de manera inmediata en la empresa y que luego no sea posible.
Si queréis profundizar este artículo es muy muy bueno.
”The most common pitfall when empowering your teams to choose tools is to take an extreme stance—for example, giving your engineers zero choice in the matter or giving your engineers too much choice.”