Del código al liderazgo

5 min read

Te promovieron a tech lead (líder técnico). Felicidades. Ahora la pregunta incómoda: ¿alguien te explicó qué se supone que hagás?

Para la mayoría, la respuesta es no. Un día sos la persona que más rápido resuelve tickets, y al siguiente estás en reuniones todo el día, tu equipo espera dirección, y esa sensación extraña aparece: “hoy no programé nada… ¿trabajé?”.

La transición de IC (Individual Contributor — Contribuidor Individual) a líder técnico es probablemente el cambio de carrera más brusco en nuestra industria, porque lo que te trajo hasta aquí — ser excelente resolviendo problemas técnicos vos mismo — es exactamente lo que ahora tenés que dejar de hacer.


El cambio mental #1: tu producción ya no es tu código

Como IC, tu valor se medía en lo que entregabas: features, fixes, diseños. Como líder, tu valor se mide en lo que tu equipo entrega. Es una multiplicación, no una suma: si dedicás dos horas a desbloquear a tres personas, produjiste más que en ocho horas programando solo.

La trampa clásica del líder nuevo: seguir tomando las tareas más difíciles para uno mismo. Se siente productivo, pero tiene dos efectos tóxicos: te convertís en el cuello de botella del equipo, y le robás a los demás la oportunidad de crecer con los problemas interesantes.

El cambio mental #2: delegar no es botar trabajo

Delegar bien es un arte con tres niveles:

  • Delegar la tarea: “Implementá este endpoint según esta especificación”. Útil con personas junior.
  • Delegar el problema: “Los clientes se quejan de la lentitud del reporte. Investigá y proponé una solución”. Ideal para personas mid-level.
  • Delegar el área: “Sos el responsable de la calidad de nuestro pipeline de datos”. Para personas senior que están listas para crecer.

El error común es delegar la tarea a todos por igual. Las personas senior se aburren con especificaciones detalladas, y las junior se ahogan con áreas completas. Ajustá el nivel a cada persona.

El cambio mental #3: el silencio ya no es neutral

Como IC, si no decías nada en la retro, no pasaba nada. Como líder, tu silencio es un mensaje. Si alguien hace un mal trabajo y no decís nada, acabás de comunicar que ese nivel es aceptable. Si alguien hace un gran trabajo y no lo reconocés, acabás de comunicar que el esfuerzo extra no vale la pena.

El feedback — positivo y correctivo — es ahora parte central de tu trabajo, no algo que hacés cuando sobra tiempo. Y las conversaciones difíciles que postergás no desaparecen: crecen.

El cambio mental #4: las reuniones son tu nuevo IDE

Sí, hay reuniones inútiles y hay que combatirlas. Pero muchas de esas reuniones que antes veías como “interrupciones del trabajo real” ahora son el trabajo real: destrabar dependencias con otro equipo, negociar el alcance con producto, dar contexto para que tu equipo pueda decidir sin vos. La pregunta ya no es “¿cuánto programé hoy?” sino “¿cuántas decisiones buenas habilité hoy?”.

El cambio mental #5: seguí tocando código, pero distinto

No tenés que abandonar el código por completo — pero cambia tu relación con él. Reglas prácticas que me funcionaron:

  • Nunca tomés tareas en el camino crítico del sprint. Si te absorbe una reunión urgente, el sprint no puede depender de vos.
  • Tomá tareas pequeñas: mejoras de herramientas internas, documentación técnica, prototipos exploratorios.
  • Usá los code reviews como tu ventana al código: es la forma más eficiente de mantenerte al día con el sistema sin bloquear a nadie.

Los hábitos de las primeras semanas

1. Tené conversaciones 1:1 (uno a uno) con cada persona del equipo. Preguntá: ¿qué te motiva? ¿qué te frustra? ¿en qué querés crecer? Las respuestas son tu mapa para delegar bien.

2. Bloqueá tiempo de concentración en tu calendario. Si no lo hacés, las reuniones se comen la semana completa. Dos bloques de dos horas, defendidos como si fueran reuniones con el CEO.

3. Escribí tus decisiones. Cada decisión técnica importante merece un registro corto: qué se decidió, por qué, qué alternativas se descartaron. Tu equipo lo va a consultar más de lo que creés.

4. Buscá otro líder que te mentoree. Todos los desafíos que vas a enfrentar, alguien ya los enfrentó. Un café mensual con un líder más experimentado vale más que diez libros.


La pregunta que nadie hace en voz alta

“¿Y si no me gusta?” — Es una posibilidad real y está bien. Liderar no es un ascenso obligatorio, es un cambio de carrera. Algunas de las mejores personas técnicas que conozco probaron el liderazgo, descubrieron que no era lo suyo, y volvieron a IC con más contexto y sin arrepentimientos. Eso no es un fracaso; es información valiosa sobre vos mismo. Las carreras técnicas modernas (staff engineer, principal engineer) permiten crecer sin gestionar personas.


Conclusión

Nadie te explica la transición de IC a líder porque es difícil de explicar: hay que vivirla. Pero el resumen es este: dejás de ser la persona que resuelve los problemas para convertirte en la persona que construye el equipo que los resuelve.

El día que veas a alguien de tu equipo resolver con elegancia un problema que antes solo vos podías resolver, vas a entender de qué se trata todo esto. Y la satisfacción — te lo adelanto — es más grande que la de cualquier deploy exitoso.

Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.


Referencias:
The Manager’s Path — Camille Fournier
Turn the Ship Around! — L. David Marquet
Cómo ganar amigos e influir sobre las personas — Dale Carnegie

Leave a Reply

Your email address will not be published. Required fields are marked *