Liderazgo Técnico
El liderazgo técnico es sobre todo sustracción
El trabajo no consiste en añadir más decisiones, más opiniones, más output. Consiste en proteger lo que importa de todo lo que no importa.
5 min
La mayoría de los equipos de ingeniería no tienen problemas por falta de buenas ideas. Los tienen porque tienen demasiadas, y nadie está eliminando las equivocadas.
El problema del instinto
Cuando alguien se convierte en líder técnico, el primer instinto suele ser hacer más. Más revisiones, más opiniones, más presencia en cada canal. La transición parece una expansión de responsabilidad, así que parece que debería implicar una expansión del output.
A menudo produce lo contrario. Un líder técnico que toca todo se convierte en un cuello de botella. Su contexto es irremplazable; su disponibilidad no.
El mejor instinto es preguntarse qué se puede eliminar. ¿Qué decisiones no necesitan tomarse aún? ¿Qué reuniones producen alineamiento que un documento podría haber proporcionado? ¿Qué discusiones técnicas son un sustituto de una pregunta de producto que nadie ha respondido?
La sustracción es más difícil de ver y de celebrar que la adición. Eso es parte de por qué se practica poco.
Lo que realmente multiplica un equipo
El trabajo con más palanca que hace un líder técnico generalmente no está en el historial de commits.
Es la conversación que evitó un desvío de tres meses. La revisión de arquitectura que detectó una asunción antes de que se convirtiera en una restricción. La redirección silenciosa de una discusión que estaba a punto de producir un consenso del que todos se habrían arrepentido. La decisión de no escalar un conflicto que habría costado dos semanas y un ingeniero.
Estas intervenciones son invisibles en retrospectiva porque nada sucedió. El buen liderazgo técnico a menudo parece que nada salió mal, que no es lo mismo que no haberse hecho nada.
Los ingenieros más visiblemente productivos — los que entregan funcionalidades, cierran tickets, escriben código — no suelen ser los que multiplican al equipo. El multiplicador es la persona que hace que el trabajo de todos sea más coherente.
La trampa de la autoridad
Los líderes técnicos tienden a invertir demasiado en decisiones técnicas y demasiado poco en claridad.
La razón es estructural. Las decisiones técnicas son donde su experiencia es legible. Revisión de código, diseño de sistemas, arquitectura — estos son dominios donde un ingeniero senior ha ganado credibilidad y se siente en terreno sólido.
La claridad es más difícil. Requiere sacar a la luz las asunciones no dichas en un documento de requisitos. Requiere hacer preguntas incómodas sobre prioridades cuando dos cosas que parecen importantes están en tensión. Requiere decir “creo que aún no hemos acordado cuál es el problema” a una sala que quiere hablar de soluciones.
Ese trabajo no es glamuroso. No produce output visible. Pero la dirección poco clara cuesta más que las malas decisiones técnicas, porque se multiplica en cada persona del equipo.
Cuándo escribir el código
Hay momentos en que un líder técnico definitivamente debería escribir el código.
Cuando el equipo está bloqueado en algo que requiere contexto poco común. Cuando una decisión necesita explorarse en lugar de debatirse. Cuando un prototipo responderá una pregunta más rápido que cualquier discusión. Cuando el valor moral de trabajar junto al equipo supera el coste de oportunidad de no multiplicarlo.
Pero estos son momentos específicos, no el modo por defecto. El modo por defecto es: ¿quién es la persona adecuada para hacer esto, y qué necesita para hacerlo bien?
Esa pregunta es más útil que la mayoría de las revisiones de código.
La contratación como decisión técnica
Las decisiones técnicas más importantes que toma un líder suelen ser sobre personas.
Quién se une al equipo cambia el código que se escribe. Cambia los estándares que son implícitamente aceptables. Cambia la capacidad del equipo para absorber complejidad y tomar buenas decisiones bajo presión.
Un equipo con altos estándares de contratación que tarda seis meses en cubrir un puesto a menudo supera a un equipo que lo cubre en seis semanas con alguien que casi encaja. La diferencia se acumula de la misma manera que la deuda técnica — lentamente, de forma invisible, hasta que se vuelve innegable.
La mayoría de los equipos tratan la contratación como una interrupción del trabajo real. Los líderes que la entienden como el trabajo real tienden a construir resultados diferentes.
El output
El liderazgo técnico no es una versión más senior de la ingeniería de software. Es un trabajo diferente con diferentes puntos de palanca y diferentes modos de fallo.
Los ingenieros que son buenos en esto no son necesariamente los que escriben el mejor código. Son los que entienden lo que el equipo necesita para ser efectivo, y que están dispuestos a proporcionarlo — sea o no visible, celebrado o interesante.
El output no son commits. El output es de lo que el equipo es capaz.