Cómo liderar equipos tech sin tocar código todos los días

El mito del tech lead programador full-time

Si pensás que ser tech lead significa programar más y mejor que el resto del equipo, tengo malas noticias: estás condenado al fracaso. Los mejores líderes técnicos que conozco programan menos que sus desarrolladores junior, y sus equipos son los que mejor performan.

Esto no es una contradicción. Es una realidad que cuesta aceptar, especialmente cuando venís de ser el "crack" que resolvía todos los bugs complejos. Pero cuando agarrás el rol de tech lead, tu trabajo cambia completamente.

La diferencia está en entender que tu impacto ya no se mide en líneas de código, sino en cuánto podés multiplicar la efectividad de todo el equipo.

Por qué programar todo el día te convierte en cuello de botella

Cuando estás con los auriculares puestos, deep work, resolviendo esa feature compleja, ¿qué pasa con el resto?

El equipo se traba esperando tus decisiones. Ese pull request que necesita review desde ayer. La arquitectura de la nueva funcionalidad que solo vos tenés clara en la cabeza. El junior que está hace dos horas stuck con un error que vos podés resolver en cinco minutos.

Perdés contexto del big picture. Mientras estás optimizando ese algoritmo, no ves que el equipo de producto cambió los requirements. O que el de QA encontró un patrón de bugs que indica un problema arquitectural más grande.

Te convertís en el héroe tóxico. Sí, tóxico. Cada vez que salvás el día con una solución brillante a último momento, estás enseñándole al equipo que dependen de vos. Y eso no escala.

He visto tech leads burnearose porque creían que tenían que codear como developer senior y liderar al mismo tiempo. Es insostenible.

Las tareas que realmente mueven la aguja

Desbloquear al equipo constantemente

Tu nuevo trabajo es ser un desbloqueador profesional. Esto significa:

• Reviews rápidas y útiles: No perfectas, útiles. El código perfecto que llega tarde vale menos que el código bueno que llega a tiempo.
• Decisiones arquitecturales ágiles: Preferible una decisión OK ahora que la decisión perfecta en dos días.
• Resolución de dependencias: Hablás con otros equipos para que el tuyo no se frene esperando APIs o datos.

Context switching como superpoder

Los developers odian las interrupciones porque rompen el flow. Pero vos tenés que desarrollar tolerancia al context switching. Tu flow ahora es mantener fluyendo a otros.

Esto incluye:

• Saltar entre problemas técnicos completamente diferentes
• Cambiar de conversaciones con producto a debugging con el equipo
• Alternar entre visión estratégica y detalles de implementación

Multiplicar conocimiento

Cada vez que resolvés algo solo, perdés una oportunidad de enseñar. Los mejores tech leads que conozco practican el "teaching by doing":

• Pair programming estratégico en problemas complejos
• Documentación just-in-time de decisiones importantes
• Mentoring informal durante code reviews

Cuándo y cómo seguir programando

No digo que no programes nunca. Pero sí que seas estratégico sobre cuándo hacerlo.

Programá para explorar: Cuando hay incertidumbre técnica, un spike rápido vale más que tres reuniones especulando. Pero después pasáselo a alguien del equipo para implementar.

Programá para enseñar: Agarrá las tareas que te permiten mostrar patrones o decisiones arquitecturales importantes. Hacelo en pair programming o con alguien mirando.

Programá lo crítico y urgente: Cuando se cae producción o hay un deadline imposible, metés manos. Pero después delegás el refactor y la limpieza.

No programes las tareas fáciles: Si podés resolver algo en 30 minutos que al resto del equipo les lleva 2 horas, dejá que se lo lleve otro. Van a aprender y vos vas a tener tiempo para cosas que solo vos podés hacer.

El arte de delegar sin micromanagear

La parte más difícil de dejar de programar todo es aprender a delegar bien. Y la mayoría lo hace mal.

Define el qué, no el cómo: Explicás el problema y el resultado esperado. Dejás que el equipo proponga el approach. Solo intervenís si van por un camino que sabés que no funciona.

Hacé check-ins, no micromanagement: "¿Cómo va? ¿Te trabaste en algo?" es muy diferente a "¿Ya terminaste la función que te dije que uses el patrón Strategy como te expliqué ayer?"

Tolerá que las cosas se hagan diferente: Si el resultado es el esperado y el código es mantenible, importa poco que no sea exactamente como vos lo hubieras hecho.

Los indicadores de que estás liderando bien

Sabés que estás en el camino correcto cuando:

• El equipo toma decisiones técnicas sin consultarte todo: Tienen suficiente contexto y confianza para resolver problemas solos.
• Las estimaciones mejoran: Porque hay menos dependencias de vos y menos bloqueos.
• El onboarding de nuevos miembros es más rápido: Porque el conocimiento no está centralizado en tu cabeza.
• Podés tomarte vacaciones sin que se prenda fuego todo: El equipo funciona independientemente.

Este último es el test definitivo. Si no podés desconectarte una semana sin que el equipo se trabe, todavía no estás liderando, estás siendo un cuello de botella.

La transición no es fácil

Dejar de ser el héroe programador para convertirte en facilitador es un cambio mental enorme. Vas a sentir que no estás "haciendo nada" algunos días. Vas a extrañar la satisfacción inmediata de resolver un bug complicado.

Pero cuando veas a tu equipo crecer, tomar ownership de los proyectos y resolver problemas que antes solo vos podías resolver, vas a entender que tu nuevo impacto es muchísimo mayor.

El mejor tech lead no es el que mejor programa. Es el que hace que todo el equipo programe mejor.

Preguntas frecuentes

¿Y si pierdo skills técnicos por no programar tanto? Los skills de arquitectura, debugging y code review se mantienen. Los de sintaxis específica podés refreshearlos cuando haga falta. Tu rol ahora requiere breadth más que depth.

¿Cómo manejo la presión de management que quiere que "también programe"? Mostrás resultados del equipo, no tuyos individuales. Si el team delivery mejoró, cumpliste. Si management no lo entiende, explicás que optimizar para tu output individual significa suboptimizar el output del equipo.

¿Qué hago si alguien del equipo programa mejor que yo? Celebrás. Tenés a alguien que puede manejar los challenges técnicos más complejos mientras vos te enfocás en hacer que todo el sistema funcione mejor. Un tech lead inseguro compite con su equipo. Un buen tech lead los potencia.