El día que dejé de ser el mejor programador del equipo
Un ingeniero acaba de recibir el título de Tech Lead. La semana anterior era el que resolvía los bugs que nadie más entendía, el que reescribía en dos horas lo que a otros les costaba dos días, el que revisaba cada PR crítico porque su criterio era el más afilado del equipo. El viernes le dieron el rol. El lunes se sienta frente a su primer sprint como líder y toma una decisión que parece obvia: se asigna las tres tareas más difíciles del backlog.
Es la decisión equivocada. Y lo peor es que la tomó por las razones correctas.
El instinto que funcionó durante cinco años
Hasta ese lunes, su función era clara. Producir el mejor código posible, el más rápido, el que menos fallaba. Cinco años de refuerzo le enseñaron que su valor se medía en output individual, y el sistema se lo confirmó con cada promoción. Ahora el título cambió. El instinto no.
Cuando ve las tres tareas difíciles del backlog, su cerebro hace el cálculo de siempre: yo soy el que las resuelve mejor, luego yo debo resolverlas. La lógica es impecable dentro del marco antiguo. El problema es que el marco antiguo ya no describe su trabajo.
Aquí está la primera tensión real, y no es trivial resolverla.
Dos formas de leer el mismo backlog
Un Tech Lead puede mirar ese backlog de dos maneras, y ambas tienen defensores serios.
La primera: el líder toma las tareas de mayor riesgo técnico porque su criterio reduce la probabilidad de fallo en lo que más importa. Si el sistema de pagos tiene un bug sutil de concurrencia, ¿quién mejor que la persona con más contexto para cazarlo? Esta lectura no es estúpida. En un equipo pequeño, con un incidente en producción y sin tiempo, es exactamente lo que hay que hacer. El liderazgo técnico incluye ensuciarse las manos cuando el riesgo lo justifica.
La segunda: el líder deja las tareas difíciles al equipo y se dedica a otra cosa — coordinar, desbloquear, revisar. Esta lectura tampoco es gratuita. Si el equipo nunca toca lo difícil, nunca crece, y el líder se convierte en el cuello de botella de todo lo importante. Un sistema donde una sola persona resuelve lo crítico es un sistema con un único punto de fallo, y ese punto de fallo se va de vacaciones dos semanas en agosto.
Fíjate en lo incómodo de la situación. Ambas lecturas funcionan en algún contexto. Elegir la equivocada tiene costo: en un caso, un fallo en producción que se pudo evitar; en el otro, un equipo que no aprende y un líder que no escala. La pregunta no se resuelve con una regla. Se resuelve preguntando mejor.
¿Qué está optimizando realmente cuando se asigna la tarea difícil?
Empecemos por ahí. Cuando el nuevo Tech Lead se asigna las tres tareas más duras, ¿qué variable está intentando maximizar?
La respuesta honesta es: la calidad del output de esas tres tareas. Y probablemente lo consiga. Las resolverá bien, rápido, con menos bugs que nadie. Pero fíjate en lo que esa respuesta asume — asume que el objetivo del rol sigue siendo la calidad de su output. Y ese es precisamente el supuesto que el título acaba de invalidar.
Su rol ya no se mide por lo que produce. Se mide por lo que produce el equipo. Son dos funciones distintas, y la segunda no es una versión más grande de la primera. Camille Fournier lo formula sin adornos en The Manager's Path: el error más común del nuevo tech lead es reducir el rol a "ser el mejor ingeniero del equipo". No lo es. Es un rol de liderazgo que además usa la experiencia técnica — el orden de esas palabras importa.
Entonces reformulemos la decisión. La pregunta no es "¿quién resuelve mejor esta tarea?". Es "¿qué configuración del equipo produce el mejor resultado sostenido en el tiempo?". Y esa pregunta tiene una propiedad que la primera no tenía: no la puede responder él solo.
El conocimiento que él no tiene
Aquí conviene detenerse en algo que el instinto del IC ignora por completo.
El Tech Lead que se asigna las tareas difíciles decide desde una premisa oculta: que él tiene toda la información necesaria para saber quién debe hacer qué. Pero no la tiene. No sabe que la ingeniera junior lleva tres meses estudiando el sistema de concurrencia por su cuenta y está lista para un reto que la haga crecer. No sabe que el senior que parece el candidato obvio está quemado y agradecería una tarea más rutinaria esta semana. No sabe que dos personas del equipo tienen contexto sobre ese módulo que él perdió hace seis meses cuando cambió de área.
Ese conocimiento existe. Está repartido en las cabezas del equipo. Y ninguna decisión que el líder tome en solitario puede incorporarlo, porque por definición él no lo posee.
El IC no necesitaba ese conocimiento. Trabajaba con lo que tenía en su propia cabeza y eso bastaba. El Tech Lead que sigue operando así toma decisiones peores no por falta de talento, sino porque decide con una fracción de la información relevante mientras cree tenerla completa. Cuanto mejor era como IC, más peligroso es este punto ciego: la confianza que ganó resolviendo solo lo empuja a seguir decidiendo solo.
¿Y cómo se accede a un conocimiento que está distribuido y que él no tiene? No adivinándolo. Creando las condiciones para que emerja — preguntando, delegando con margen, observando quién resuelve qué y cómo. La asignación deja de ser un acto de autoridad y se vuelve un mecanismo para que el equipo revele lo que sabe de sí mismo.
El error de creer que el futuro del sprint es predecible
Hay un segundo supuesto enterrado en "me asigno las tres tareas difíciles". El supuesto de que ya sabe, el lunes, cómo se va a desarrollar el sprint.
No lo sabe. Ninguna de las tres tareas es tan predecible como parece en el tablero. La difícil puede resultar trivial una vez alguien la mira de cerca; la que parecía rutinaria puede esconder el problema real. El plan perfecto de asignación que traza el lunes choca con la realidad el miércoles, cuando aparece un incidente que no estaba en ningún backlog.
Un IC absorbe esa incertidumbre concentrándose: baja la cabeza y resuelve lo que tiene delante. Un Tech Lead no puede darse ese lujo, porque si baja la cabeza sobre su tarea difícil, deja al equipo sin nadie que responda cuando el miércoles se tuerce. Fournier cuenta el caso exacto en The Manager's Path: el tech lead brillante que se mete en un refactor mientras el product manager, aprovechando su ausencia, arrastra al resto del equipo a comprometer fechas imposibles sobre un diseño malo. El código quedó impecable. El proyecto se hundió.
Lo que ese líder optimizó — su rabbit hole técnico — era exactamente lo que no debía optimizar. Su valor esa semana estaba en la sala donde se tomaban los compromisos, y no estaba en ella.
La conclusión no es que el líder no deba programar nunca. Es que su disponibilidad tiene un valor que su output individual ya no tiene. El IC que se compromete al 100% con una tarea es un buen IC. El Tech Lead que se compromete al 100% con una tarea es un líder que se acaba de sacar del juego. Necesita holgura. Necesita poder soltar lo que tiene entre manos el miércoles sin bloquear el sprint entero.
Redirigir la excelencia, no renunciar a ella
Aquí es donde muchos lo entienden mal, y por eso el rol les resulta un duelo.
Interpretan todo lo anterior como "deja de ser bueno técnicamente, ahora tu trabajo es coordinar". Y lo viven como una pérdida — cambiaron aquello en lo que eran excelentes por reuniones y hojas de cálculo. Esa interpretación produce Tech Leads amargados o Tech Leads que sabotean el rol volviendo a escondidas al código difícil.
La excelencia técnica no se abandona. Se redirige. La misma capacidad que usaba para escribir el mejor código ahora se aplica a un objeto distinto: elevar el nivel técnico de todo el equipo. Su criterio ya no produce una PR excelente. Produce cinco ingenieros que escriben PRs mejores porque él revisó, preguntó, señaló el patrón que no veían. The Staff Engineer's Path lo describe como el salto de tener impacto a través de tu trabajo a tenerlo a través de tu influencia sobre el trabajo de otros — el mismo músculo técnico, multiplicado en vez de gastado en una sola tarea.
Piensa en la aritmética. El líder que resuelve la tarea difícil suma una tarea difícil bien resuelta. El líder que enseña a tres personas a resolver tareas difíciles multiplica la capacidad del equipo durante meses. La primera opción se siente mejor el viernes — hay algo tangible, un commit con su nombre. La segunda no da satisfacción inmediata, y ahí está la trampa.
Por qué el rol cambia antes que la identidad
Llegamos al núcleo del caso. El título cambió el viernes. La identidad no.
Durante cinco años, la identidad de esta persona se construyó sobre una ecuación: yo valgo lo que produzco. Cada refuerzo la reforzó. No es una creencia que se sostenga a nivel consciente — es lo que siente cuando ve el backlog el lunes. El tirón hacia la tarea difícil no es una decisión racional que pueda argumentar; es la respuesta automática de alguien cuya idea de sí mismo aún se mide en output individual.
Por eso la solución no es informativa. No basta con leer que el rol es distinto y asentir. Lo entiende y aun así se asigna las tareas difíciles, porque la identidad no cambia por comprender un argumento. Cambia por repetición de una conducta nueva hasta que deja de sentirse ajena. Es el mecanismo que James Clear describe en Atomic Habits: los cambios de identidad duraderos no vienen de decidir ser otra persona, vienen de acumular pequeñas evidencias de que ya lo eres. Cada vez que delega la tarea difícil y ve al equipo resolverla, deposita una prueba de que su valor ya no depende de resolverla él.
La primera vez duele. Ve la tarea, sabe que la haría en la mitad de tiempo, y la suelta igual. El viernes no tiene un commit brillante que mostrar y siente que no hizo nada. Esa sensación es el precio de la transición, y confundirla con incompetencia es lo que devuelve a tanta gente al código difícil.
¿Cómo se sabe que la identidad empezó a moverse? Cuando ver crecer a otro produce la misma satisfacción que antes producía resolverlo uno mismo. Ese día la ecuación se reescribió. No por una epifanía. Por veinte lunes seguidos soltando la tarea difícil.
Lo que este caso enseña más allá del backlog
Esto generaliza a cualquier transición de rol donde el reflejo que te trajo hasta aquí es exactamente el que te frena ahora. El IC que se vuelve Tech Lead, el Tech Lead que se vuelve manager, el manager que se vuelve director: en cada salto, la conducta que el sistema premió durante años se convierte en el principal obstáculo del rol nuevo, y el título cambia meses antes de que la identidad lo alcance.
El diagnóstico útil no es preguntarte si tienes las habilidades del rol nuevo. Es preguntarte qué estás optimizando por reflejo, y si eso que optimizas sigue siendo lo que el rol necesita. El nuevo Tech Lead optimizaba la calidad de su propio output porque durante cinco años eso fue lo correcto. La trampa no fue la arrogancia. Fue seguir midiéndose con una vara que su rol acababa de retirar.
La próxima vez que te asignes por instinto la tarea más difícil del sprint, detente en el instinto antes que en la tarea. Pregúntate qué versión de ti la está reclamando. Y si es la versión que ya no describe tu trabajo, suéltala — no porque hayas dejado de ser bueno, sino porque ahora tu criterio vale más repartido en cinco personas que concentrado en un commit.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.