El día que dejé de ser el mejor programador del equipo
Era un proyecto de integración con 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, sin nadie a quien preguntarle.
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. El sistema era opaco por diseño: una caja negra comercial que no había sido pensada para este tipo de conexión. No había documentación porque era la primera vez que se hacía exactamente esto.
Al cuarto día me di cuenta de algo que no tenía que ver con el código. Había dejado de ser Tech Lead. No revisaba avances del equipo. No desbloqueaba a nadie. Había desaparecido dentro de un problema técnico mientras el resto seguía sin dirección — esperando decisiones que yo no estaba tomando, con dudas que yo no estaba resolviendo, con un proyecto que avanzaba en paralelo sin que nadie lo estuviera pilotando. Lo más incómodo no fue reconocer el error. Fue entender por qué lo había cometido: 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 ejecutarlas bien. Me había escondido en el trabajo que dominaba para evitar el trabajo que más importaba.
El problema no es técnico
Hay una narrativa cómoda sobre este tipo de situaciones. Dice que el Tech Lead recién promovido comete este error por exceso de confianza — cree que sigue siendo el mejor programador del equipo y no sabe delegar. La solución, según esa narrativa, es aprender a soltar el control.
Esa narrativa está equivocada. O al menos, está diagnosticando el síntoma y llamándolo enfermedad.
Lo que realmente ocurre no es arrogancia. Es que el rol cambia antes de que la identidad lo haga. El Tech Lead recibe nuevas responsabilidades, pero su sistema interno de valoración — lo que considera un buen día de trabajo, lo que le genera satisfacción, lo que interpreta como "estar siendo útil" — sigue calibrado para el trabajo anterior. Y ese sistema no se actualiza por decreto. No cambia porque alguien te diga que ahora eres líder. No cambia porque leas un libro sobre management.
Cambia cuando el coste de no cambiarlo se vuelve visible. Y a veces ese coste lo paga el equipo antes de que tú lo veas.
En mi caso, el cuarto día fue ese momento. Pero hay Tech Leads que nunca llegan a ese momento — porque el equipo aprende a trabajar alrededor de ellos, porque el proyecto sale adelante de todas formas, porque nadie nombra lo que está pasando. El problema no desaparece: se vuelve invisible, que es peor.
Lo que mides determina lo que eres
Durante años, el criterio de éxito de un buen ingeniero es relativamente claro. Código que funciona. Problemas resueltos. Sistemas que no se caen. Hay una legibilidad en ese trabajo que resulta adictiva: el feedback es rápido, los resultados son tangibles, y la calidad de tu contribución es medible casi en tiempo real.
El liderazgo técnico no funciona así. El feedback es lento, indirecto y frecuentemente ambiguo. ¿El equipo está avanzando bien porque tú estás haciendo bien tu trabajo, o a pesar de que no lo estás haciendo? ¿La decisión de arquitectura que tomaste hace tres semanas fue buena? No lo sabrás hasta dentro de meses. ¿La conversación difícil que tuviste con el product manager la semana pasada tuvo impacto? Quizás. Quizás no. Quizás lo tuvo pero de una forma que nunca podrás atribuirte directamente.
Este cambio en la naturaleza del feedback no es un detalle menor. Es el mecanismo por el que el Tech Lead recién promovido regresa sistemáticamente al trabajo de IC: porque ese trabajo tiene un ciclo de recompensa que el liderazgo todavía no tiene para él. No es irracionalidad. Es que las valoraciones subjetivas de las personas — lo que perciben como valioso, lo que les genera sensación de competencia, lo que interpretan como progreso — no se sincronizan automáticamente con el nuevo título.
James Clear, en Atomic Habits, describe cómo el cambio de comportamiento sostenido requiere un cambio de identidad, no solo de acciones. El problema es que la mayoría de los Tech Leads intenta cambiar las acciones — "voy a delegar más", "voy a hacer más one-on-ones" — sin cuestionar la identidad desde la que operan. Y la identidad sigue siendo la del mejor programador del equipo. La del que resuelve los problemas más difíciles. La del que, cuando hay una crisis técnica, es el primero en abrir el terminal.
El error que nadie nombra
Hay un patrón que se repite con suficiente frecuencia como para que valga la pena nombrarlo con precisión. El Tech Lead que flaquea no suele ser el que ignora sus responsabilidades de liderazgo. Suele ser el que las posterga en favor de un problema técnico que parece urgente — y que frecuentemente lo es.
La trampa es que el problema técnico siempre parece más urgente. Tiene un deadline visible. Tiene un error que está bloqueando algo concreto. Tiene la estructura de un problema que se puede resolver. Las responsabilidades de liderazgo, en cambio, son difusas: no hay un ticket que diga "dar dirección al equipo esta tarde" ni un error en los logs que indique "el equipo no sabe hacia dónde va".
El resultado es predecible. Mientras el Tech Lead persigue el problema técnico, el vacío de liderazgo lo llena alguien más — o no lo llena nadie. En el primer caso, el Tech Lead pierde influencia sobre decisiones que importan. En el segundo, el equipo toma decisiones localmente óptimas que son globalmente incoherentes. Ambos escenarios son costosos. Ninguno aparece en el sprint review.
Lo que hace difícil salir de este patrón es que el Tech Lead que lo vive no lo percibe como un fallo de liderazgo. Lo percibe como estar siendo útil. Está resolviendo un problema real. Está contribuyendo. La disonancia entre lo que siente que está haciendo y lo que el equipo necesita que haga es exactamente el tipo de brecha que nadie menciona en las conversaciones sobre transición a roles de liderazgo.
Redirigir, no abandonar
La solución que se suele proponer a este problema es aprender a soltar. Delegar más. Confiar en el equipo. Alejarse del código.
Eso es, en el mejor de los casos, un consejo incompleto. En el peor, es contraproducente.
Un Tech Lead que abandona la profundidad técnica pierde la única cosa que lo hace diferente de un project manager. Su credibilidad con el equipo depende de que entienda el problema desde dentro, no desde un dashboard. Su capacidad de tomar buenas decisiones de arquitectura depende de que siga teniendo un modelo mental preciso de los sistemas. Su utilidad en una conversación con un ingeniero senior depende de que pueda seguir el argumento técnico sin necesitar que se lo expliquen desde cero.
El cambio que se necesita no es de cantidad — menos código, más reuniones. Es de dirección. La excelencia técnica que antes se aplicaba a resolver problemas propios tiene que redirigirse hacia amplificar la capacidad del equipo para resolver problemas sin ti.
Eso tiene implicaciones concretas. Cuando aparece un problema técnico difícil, la pregunta relevante no es "¿puedo resolverlo yo?" sino "¿quién del equipo puede resolverlo, y qué necesita de mí para hacerlo?" Cuando hay una decisión de arquitectura, la pregunta no es "¿cuál es la solución correcta?" sino "¿cómo construyo el contexto para que el equipo llegue a una buena decisión con la información que tienen?" Cuando hay una crisis, la pregunta no es "¿dónde está el bug?" sino "¿qué está bloqueado y quién está bloqueado?"
Esto no es renunciar a la excelencia técnica. Es aplicarla a un nivel diferente. Camille Fournier lo describe con precisión en The Manager's Path: el Tech Lead usa su expertise a mayor escala para que todo el equipo mejore. La palabra clave es escala. No es menos técnico. Es técnico de una forma que multiplica, no que suma.
Lo que nadie te dice sobre la transición
Hay algo que los libros sobre liderazgo técnico mencionan poco, probablemente porque es incómodo de admitir: la transición a Tech Lead implica un período en el que eres peor en tu trabajo de lo que eras antes.
No porque hayas perdido habilidades técnicas. Sino porque las habilidades que ahora importan más — leer la dinámica del equipo, gestionar la incertidumbre de un proyecto sin información completa, tener conversaciones difíciles con stakeholders — son habilidades que estás desarrollando desde cero mientras sigues siendo responsable de resultados.
Tara Forsyth describe en The Staff Engineer's Path cómo los ingenieros en roles de influencia sin autoridad formal tienen que aprender a operar desde un tipo de poder diferente — no el poder de quien tiene la respuesta técnica, sino el poder de quien hace las preguntas correctas, crea el contexto adecuado y elimina los obstáculos que el equipo no puede eliminar solo. Ese cambio no es natural. Requiere construir una nueva identidad profesional desde la que operar, y esa construcción lleva tiempo y produce fricción.
Lo que ayuda no es fingir que la transición es fácil. Lo que ayuda es tener claridad sobre qué tipo de contribución estás intentando hacer ahora, y medir tu trabajo con ese criterio — no con el criterio del IC que fuiste.
En mi caso, salir del rabbit hole de la integración significó reconocer que el problema no era técnico: era que yo era el cuello de botella. Asigné a otro ingeniero del equipo la investigación, le di contexto de todo lo que había encontrado en cuatro días, y me dediqué a lo que debería haber estado haciendo desde el principio: revisar el estado del resto del proyecto, desbloquearlo donde había fricción, y tener la conversación con el cliente sobre el riesgo de timeline que nadie había tenido todavía.
El ingeniero resolvió la integración en día y medio. No porque fuera mejor que yo. Sino porque tenía algo que yo no tenía después de cuatro días peleando con el mismo problema: perspectiva fresca. Y yo lo sabía — pero me había costado cuatro días admitirlo porque hacerlo implicaba aceptar que mi contribución más valiosa no era estar en las trincheras.
La pregunta que cambia el marco
Hay una pregunta que, desde entonces, uso como señal de alarma cuando noto que estoy tirando hacia el trabajo técnico en lugar del trabajo de liderazgo: ¿Estoy haciendo esto porque es lo que más valor aporta ahora mismo, o porque es lo que más cómodo me resulta?
No siempre la respuesta es que debería soltar el teclado. A veces el trabajo técnico es exactamente lo que el equipo necesita de ti en ese momento. Pero la pregunta fuerza honestidad sobre la motivación real — y esa honestidad es el único punto de partida válido para tomar la decisión correcta.
El Tech Lead que sigue midiendo su valor en output individual no es un mal líder por falta de habilidad. Es un líder que todavía no ha actualizado el sistema con el que se mide. Ese sistema se construyó durante años de trabajo técnico y funcionó bien — hasta que dejó de ser el sistema correcto para el rol. Actualizarlo no es un acto de humildad ni de renuncia. Es simplemente reconocer que el trabajo cambió, y que la identidad tiene que cambiar con él.
Si este análisis te resultó útil, la newsletter semanal va más profundo cada semana. Sin motivación barata. Sin frameworks de cinco pasos. Pensamiento real sobre los problemas reales que enfrenta un Tech Lead.