El día que dejé de ser el mejor programador del equipo
Era un proyecto de integración de un commerce engine privado — licencia anual, self-hosted, contrato enterprise con el cliente. El equipo tenía que conectarlo con el payment gateway interno. Nadie lo había hecho antes: sin documentación, sin precedentes.
Tomé la tarea. Era el más senior y asumí que era mi responsabilidad directa. Cuatro días después seguía atrapado en errores de integración. Cada bug resuelto abría otro. No había documentación porque era la primera vez que se hacía esa conexión.
Al cuarto día entendí algo que no tenía que ver con el código. Había dejado de ser Tech Lead. No revisaba avances. No desbloqueaba a nadie. Había desaparecido dentro de un problema técnico mientras el resto del equipo seguía sin dirección, y lo más incómodo fue entender por qué había elegido ese problema. El código era mi hábitat. Difícil, lleno de errores, pero familiar. Las responsabilidades de liderazgo me generaban más incertidumbre porque no sabía exactamente cómo hacerlas bien. Me había escondido en el trabajo que dominaba para evitar el trabajo que más importaba.
El refugio que no parece un refugio
La explicación cómoda es la arrogancia. El senior que no suelta el teclado porque cree que nadie lo hace tan bien como él. Esa lectura es falsa porque es demasiado halagadora — convierte un problema de identidad en un problema de ego, que es más fácil de confesar y más fácil de absolver.
Lo que me pasó no fue creer que era mejor que el equipo. Fue elegir, sin darme cuenta, el terreno donde mi valor era medible al instante. Un bug resuelto es una victoria con timestamp. Sabes exactamente cuándo lo lograste y exactamente cuánto valió. El liderazgo no tiene ese marcador. Desbloquear a alguien en una conversación de quince minutos puede ser la decisión más rentable de la semana, pero no produce un commit. No hay diff que lo demuestre.
Cuando un trabajo te devuelve señal clara de tu propio valor y otro trabajo te devuelve ambigüedad, gravitas hacia el primero. No por pereza. Por una valoración silenciosa que ni siquiera registras como decisión: prefieres la incomodidad conocida del código a la incomodidad desconocida del rol. El cerebro lo presenta como "esto es lo más urgente". Lo que en realidad significa es "esto es lo que sé hacer".
Y ahí está el problema real. Mi título había cambiado el lunes. Mi forma de medir mi propio valor seguía siendo la del viernes anterior.
El rol llega antes que la identidad
Cuando te promueven a Tech Lead, el cambio de rol es instantáneo. Lo firma alguien, lo anuncia un email, aparece en tu firma de correo. La identidad no se mueve a esa velocidad. Sigues siendo, durante semanas o meses, la persona que media tu valor en output individual — porque esa persona es la que recibió todas las recompensas durante años.
Aquí es donde la mayoría de los análisis del tema se equivocan. Tratan la transición como un problema de aprendizaje: aprende a delegar, aprende a dar feedback, aprende project management. Como si el obstáculo fuera la falta de habilidades. Las habilidades se aprenden. Lo que resiste es otra cosa.
Camille Fournier cuenta en The Manager's Path el momento en que se encontró gestionando a ingenieros más senior que ella técnicamente. Por primera vez no podía apoyarse en saber más que nadie como su herramienta principal de liderazgo. La salida no fue volverse mejor ingeniera que ellos. Fue redefinir qué era su trabajo: ayudarlos a tener éxito de cualquier forma que pudiera.
Ese reencuadre es más difícil de lo que suena, porque exige desmontar el sistema de valoración con el que llegaste hasta aquí. Durante toda tu carrera de IC, tu valor fue una función de lo que producías tú. Más features, mejor código, problemas más difíciles resueltos en solitario. Te promovieron precisamente por ser excelente en eso. Y el primer acto del nuevo rol es pedirte que dejes de medir tu valor de la única forma en que has sabido medirlo.
Nadie te dice esto en la promoción. Te dicen "enhorabuena" y te dan más responsabilidad. Lo que no te dicen es que la responsabilidad nueva es invisible en las métricas con las que tú evalúas si has tenido un buen día.
Por qué el equipo paga el coste antes que tú
Mientras yo perseguía el bug número catorce de la integración, el equipo no estaba parado. Estaba avanzando sin dirección, que es peor que estar parado. Tomaban microdecisiones de arquitectura sin saber si encajaban con el resto. Esperaban respuestas que no llegaban. Asumían prioridades que nadie había confirmado.
El conocimiento que ese proyecto necesitaba no estaba todo en mi cabeza. Estaba repartido. Un desarrollador del equipo había trabajado meses antes con un sistema parecido. Otra persona conocía el payment gateway interno mejor que yo porque había hecho mantenimiento sobre él. La información que yo necesitaba para desatascar la integración existía en el equipo — pero yo no estaba en posición de usarla, porque estar de cabeza en el problema me había sacado de la conversación donde esa información circulaba.
Este es el coste que no aparece en el primer recuento. Un Tech Lead que se convierte en el mejor IC del equipo no añade un IC excelente. Resta al único que tenía la vista del conjunto. El equipo no gana un programador más. Pierde su capa de coordinación, y la pierde precisamente cuando más la necesita, porque los proyectos sin precedentes son los que más coordinación exigen.
Fournier describe un patrón que reconocí con incomodidad: el tech lead brillante técnicamente que se mete en un rabbit hole de refactoring mientras el product manager, aprovechando su ausencia, arrastra al resto del equipo a comprometerse con entregas mal diseñadas y demasiado agresivas. El proyecto se vuelve un caos. ¿Y qué hace el tech lead? Va a por el siguiente refactor, convencido de que todos los problemas están en cómo está estructurado el código. Lo reconocí porque yo estaba haciendo la versión exacta de eso. Mi rabbit hole tenía nombre de integración, pero la dinámica era idéntica.
Redirigir la excelencia, no abandonarla
El error que se comete después de entender todo esto es tan grave como el original. La gente concluye que liderar significa programar menos, o no programar. Sueltan el teclado con resentimiento y se vuelven gestores que firman jiras y miran dashboards. Eso tampoco funciona porque tira por la borda lo único que te dio autoridad para liderar a ingenieros: saber de qué hablas.
La transición no pide renunciar a la excelencia técnica. Pide cambiar su punto de aplicación. The Staff Engineer's Path de Tanya Reilly insiste en algo que tardé en interiorizar: el ingeniero senior que asciende deja de medir su impacto por lo que construye con sus manos y empieza a medirlo por lo que hace posible que el equipo construya. La técnica no desaparece. Cambia de función. Pasa de ser la herramienta con la que resuelves el problema a ser la herramienta con la que decides cuál es el problema correcto, quién debería resolverlo, y qué decisión de arquitectura va a doler dentro de dos años.
Cuando volví al proyecto de la integración, no abandoné el problema técnico. Hice algo distinto con mi conocimiento técnico. Lo usé para partir la integración en piezas que distintas personas pudieran atacar en paralelo. Usé lo que sabía del payment gateway para escribir, en media página, las tres hipótesis más probables del fallo, y se las pasé a quien tenía contexto para validarlas. El bug se resolvió en día y medio. No lo resolví yo. Lo resolvió alguien con la información que yo no tenía, trabajando dentro de una estructura que yo sí podía construir porque entendía el problema lo bastante bien como para descomponerlo.
Esa es la redirección. La misma profundidad técnica, aplicada un nivel más arriba. No al código, sino a las condiciones bajo las cuales el equipo escribe el código.
La identidad cambia por repetición
El día que entendí todo esto no cambié. Entenderlo no es cambiarlo. Seguí sintiendo, durante meses, el tirón hacia el problema técnico cada vez que el liderazgo se ponía ambiguo. La diferencia es que aprendí a reconocer el tirón como lo que era: la atracción de lo familiar disfrazada de prioridad.
Atomic Habits de James Clear tiene una observación que se aplica directamente aquí, aunque Clear hablaba de hábitos personales y no de roles profesionales — la analogía se rompe en que un hábito es algo que tú decides repetir, y un rol implica a un equipo entero que depende de cómo lo ejerces. Pero el mecanismo central se sostiene: la identidad no se transforma por una decisión heroica. Se transforma por la acumulación de pequeñas acciones que votan a favor de una nueva versión de quién eres. Cada vez que eliges desbloquear a alguien en lugar de robarle el problema, depositas un voto. Cada vez que escribes el documento de decisión en lugar de escribir el código tú mismo, depositas otro. Ninguno de esos votos se siente como un cambio. La suma, a los seis meses, es una persona distinta.
No hay un día en que dejas de ser el mejor programador del equipo y te conviertes en Tech Lead. Hay cien decisiones pequeñas, casi todas incómodas, en las que eliges la ambigüedad del rol sobre la comodidad del código. El título te lo dan en un día. La identidad la construyes en los cien siguientes, y la construyes en contra de tu propio instinto, porque tu instinto fue entrenado durante años para hacer exactamente lo contrario.
Lo que puedes mirar esta semana
Mira en qué desapareciste esta semana. No qué hiciste — en qué te escondiste. Si hubo un problema técnico que tomaste porque era tuyo "por ser el más senior", pregúntate qué información tenía el equipo que tú no usaste, y qué quedó sin dirección mientras tú estabas de cabeza en ese problema.
La respuesta incómoda casi siempre tiene la misma forma: tomaste el trabajo cuyo valor podías medir, y dejaste sin hacer el trabajo cuyo valor no aparece en ningún diff. El primero te devolvía la sensación de ser bueno en algo. El segundo te habría obligado a ser, durante un rato, malo en algo nuevo.
Esa elección — entre la competencia conocida y la incompetencia necesaria — es el verdadero trabajo del primer año como Tech Lead. Y la haces cada semana, te des cuenta o no.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.