El primer año liderando un equipo técnico suele ser el más difícil de toda la carrera, y no por falta de conocimiento técnico. La trampa mental más común es pensar "ahora que lidero, tengo que resolverlo todo yo": se traduce en jornadas maratonianas, delegación cero, y un equipo que se desmotiva mientras tú te quemas. La transición real de IC a líder técnico no es una cuestión de habilidades nuevas, es un cambio de mentalidad.

De hacedor a multiplicador

La mentalidad de IC, aplicada mal a un rol de liderazgo, suena así: "voy a resolver este bug crítico yo mismo", "voy a revisar todos los pull requests personalmente", "voy a diseñar toda la arquitectura porque solo yo la entiendo". El resultado es una persona muy productiva individualmente y un equipo estancado, dependiente de un único punto de fallo.

La mentalidad de líder técnico suena distinto: "¿quién del equipo puede resolver esto, y cómo le destrabo el camino?", "delego la mayoría de las revisiones de código y me quedo con las críticas", "facilito la decisión de arquitectura, pero la diseña quien la va a mantener". El resultado es menos código escrito por ti directamente, y un equipo que rinde mucho más de lo que rendiría bajo tu supervisión constante.

No hace falta dejar de programar del todo para ser un buen líder técnico —seguir escribiendo algo de código mantiene la credibilidad técnica—, pero si la mayor parte de tu semana sigue siendo código en vez de desbloquear a otros, probablemente no estás delegando lo suficiente.

Radical Candor: dar feedback que de verdad sirve

El feedback que evita el conflicto ("se ve bien", cuando en realidad el código es mediocre) parece amable pero no ayuda a nadie: la persona nunca sabe que hay algo que mejorar, y la mediocridad se normaliza. El feedback puramente agresivo ("esto está fatal", sin más contexto) tampoco funciona: desmotiva sin dar ninguna guía útil.

El marco de Radical Candor combina las dos cosas que sí funcionan juntas: importarte la persona de verdad, y desafiarla directamente. Algo como: "veo que añadiste validación de inputs, bien hecho. Pero esta cadena de if-else de ocho niveles es difícil de mantener — vimos un patrón de switch-case la semana pasada, apliquémoslo aquí. Confío en que te va a salir bien." El mensaje combina "me importas" con "esto no está a la altura todavía", y ninguna de las dos partes se sacrifica por la otra.

	Te importa la persona	No te importa
Desafías directo	Radical Candor (funciona)	Agresión gratuita (mal)
No desafías	Empatía ruinosa (mal)	Insinceridad manipuladora (peor)

Conversaciones difíciles: una estructura que funciona

Cuando alguien del equipo lleva un tiempo sin cumplir plazos o entregando código de baja calidad, evitar la conversación esperando que mejore solo, o dar feedback vago tipo "hay que mejorar", no cambia nada. Una estructura que sí funciona:

1. Plantea la conversación con antelación: "quiero hablar de cómo van las últimas semanas, 30 minutos, en privado, ¿te viene bien ahora?"
2. Describe hechos, no juicios: "en los últimos sprints hubo dos plazos que no se cumplieron y varias revisiones de código con comentarios repetidos. Quiero entender qué está pasando."
3. Escucha de verdad la explicación, sea lo que sea: burnout, algo personal, requisitos poco claros.
4. Combina empatía con claridad sobre qué tiene que cambiar concretamente, en términos verificables.
5. Pregunta qué necesita de ti para lograrlo — pair programming, mentoría, specs más claras.
6. Haz seguimiento: revisa en los días siguientes, reconoce el progreso explícitamente, y si no hay mejora en un plazo razonable, pasa a una conversación más formal sobre el futuro del puesto.

La clave es combinar franqueza con apoyo real: no es "estás fallando", es "aquí está la brecha, y aquí cómo te ayudo a cerrarla".

Seguridad psicológica en el equipo

Un equipo con baja seguridad psicológica esconde errores, evita disentir, y mata la innovación por miedo a quedar mal. Se construye lo contrario admitiendo tus propios errores en público ("ayer metí un bug en producción"), pidiendo ayuda abiertamente cuando no sabes algo, tratando los experimentos fallidos como aprendizaje válido en vez de fracasos, y agradeciendo explícitamente cuando alguien te lleva la contraria con un buen argumento.

La señal de que funciona: un ingeniero plantea "creo que esta arquitectura no es la correcta" y la respuesta es "cuéntame más" en vez de "ya está decidido". Esa apertura suele llevar a mejores decisiones que cerrar la conversación de entrada.

Proteger al equipo del caos organizativo

Cuando las prioridades cambian cada semana y la política interna es alta, parte del trabajo de un líder técnico es filtrar ese ruido antes de que llegue al equipo: traducir prioridades confusas en objetivos claros y estables, proteger el tiempo del equipo de reuniones que no aportan, y decir que no cuando algo no encaja con lo que ya está comprometido. Si desde arriba piden lanzar tres funcionalidades para el viernes y el equipo solo tiene capacidad real para una, la respuesta correcta no es aceptar y quemar al equipo — es volver con datos: "esto no es realista con el plazo actual, hay que priorizar."

El 1-a-1 semanal: la herramienta más infrautilizada

Una reunión individual semanal de al menos media hora, con una estructura simple —cómo va la persona en general, en qué está trabajando y qué le bloquea, qué quiere aprender y cómo puedes ayudar, y solo al final tu feedback si hace falta— detecta problemas mucho antes de que alguien decida irse. Cancelarla con frecuencia manda el mensaje de que no es prioridad; convertirla en un monólogo tuyo desaprovecha lo que debería ser el espacio de la otra persona.

Cuándo decidir tú y cuándo dejar que decida el equipo

Decidir todo tú mismo desactiva al equipo: si alguien pregunta "¿PostgreSQL o MongoDB?" y respondes con la decisión ya tomada, esa persona deja de sentirse dueña de la elección. Es mejor devolver la pregunta —"¿qué pros y contras ves tú?"— y dejar que sea el propio equipo quien llegue a la recomendación, mientras tú confirmas o matizas al final. Conviene decidir tú directamente cuando el tiempo apremia de verdad, cuando tienes información que el equipo no tiene, o cuando hay opiniones enfrentadas y alguien tiene que zanjar. El resto del tiempo, facilitar en vez de decidir ayuda al equipo a crecer.

Cuidar tu propio burnout

El riesgo de burnout en un rol de liderazgo es alto precisamente porque es difícil "desconectar" cuando sientes que los problemas del equipo son tuyos. Ayuda poner límites de horario reales, revisar si estás trabajando muchas más horas de las razonables (síntoma casi seguro de que no estás delegando lo suficiente), y hablar abiertamente con tu propio manager si el ritmo no es sostenible. Las señales de alerta se parecen a las de cualquier burnout: cinismo hacia el equipo, la sensación de que "nadie más puede hacer esto", resentimiento ante las reuniones, sueño que se resiente.

Lo esencial del primer año

• Cambiar el chip: multiplicador antes que hacedor (la parte más difícil)
• Dominar Radical Candor: cuidado genuino + desafío directo
• 1-a-1 semanales, sin excepciones
• Afrontar las conversaciones difíciles pronto, no evitarlas
• Construir seguridad psicológica real en el equipo
• Proteger al equipo del ruido organizativo
• Protegerte a ti mismo: límites y delegación

El primer año como líder técnico es, para casi todo el mundo, el más duro de la carrera. Para el segundo año, ya se vuelve instintivo.

Fuentes:

• The Manager's Path — Camille Fournier
• Radical Candor — Kim Scott