Cuando un equipo de desarrollo alcanza cierto tamaño, el código ya no se rompe sólo por un null pointer; se rompe por emociones mal gestionadas. La llegada de un líder externo suele destapar celos, miedo al reemplazo y una pregunta silenciosa: «¿por qué él y no yo?» Gestionar ese momento es tan crucial como la elección del patrón que sostendrá el producto.
La herida invisible del ascenso ajeno.
La literatura sobre team psychology describe el fenómeno como dissonant promotion: la sensación de que mi valor retrocede cuando otro avanza (Harvard Business Review). En ParaIngenieros.org hemos insistido en que culpar consume más energía que resolver. Sin embargo, el resentimiento es humano y aparece con fuerza en equipos técnicos, donde la reputación se asocia a la brillantez individual.
Dos historias reales que enseñan más que cualquier manual.
Marco, el Tester Senior impecable que prefirió marcharse.
En un banco, un compañero —Marco— dominaba los flujos bancarios y mantenía al equipo de QA en pie durante las pruebas de estrés. Cuando me nombraron coordinador, Marco sintió que el techo descendía sobre él. Su perfeccionismo y carácter combativo, ideales para detectar un bug crítico a medianoche, eran menos útiles para negociar con arquitectura o defender un presupuesto. El día que se convocó la primera reunión de cierre de sprint, presentó la renuncia. Fue a otra firma como analista sénior; el sueldo mejoró, el rol no. La moraleja: ser el mejor en lo operativo no te convierte, por arte de magia, en la mejor apuesta de liderazgo.
Lucía, la desarrolladora bombera que nunca quiso apagar incendios de gestión.
En una fintech, Lucía era la salvadora del repositorio: refactorizaba, ayudaba a los juniors y aceptaba guardias sin rechistar. Creía que el siguiente paso natural era la jefatura. Pero en las dailies evitaba confrontar entregables mediocres y confiaba en que «alguien» pusiera orden. La dirección contrató a una arquitecta externa con maestría en diseño de software y un historial de despliegues complejos. Lucía interpretó el fichaje como traición y cayó en el desencanto. En su caso, la carencia no era técnica sino anímica: le costaba decir no, establecer estándares y asumir que un líder es, ante todo, quien toma la decisión incómoda.
Por qué el mejor IC puede ser un líder mediocre (y viceversa).
Cambiar de contribuidor individual a líder es mudarse de carrera. Según una encuesta de McKinsey, el 57 % de los líderes técnicos que fallan lo hacen por «dificultad para delegar y negociar», no por carencias de stack. A partir de cierto nivel, el impacto se mide en defectos evitados, rotación de talento y claridad de ruta, no en líneas de código o casos de prueba.
Estrategias para introducir nuevos líderes sin dinamitar la moral.
No existen panaceas, pero sí principios:
Transparencia desde el anuncio. Explica por qué se necesita el rol y qué competencias se buscan. Cuando compartimos en Slack el perfil deseado —“experiencia en negociación con banca, manejo de presupuesto y coaching”— Marco entendió que su fuerza era otra. El conflicto se suavizó, aunque no evitó su salida.
Rutas de carrera paralelas. Google y Spotify mantienen sendas duales: Staff Engineer o Engineering Manager. Así la excelencia técnica se premia sin obligar a nadie a gestionar personas (Re:Work).
Mentoría externa antes del ascenso. Tres meses de «liderazgo sombra» permiten probar al candidato sin arriesgar entregas. Lucía, por ejemplo, habría detectado su aversión al conflicto mucho antes.
Métricas compartidas. Usar indicadores de flujo —lead time, deployment frequency, bugs en producción— desplaza la competitividad individual y centra la conversación en el valor al cliente (DevOps Research & Assessment, 2024).
Cómo saber si tu mejor dev está listo para dirigir.
Plantea estas preguntas en una retro privada:
— ¿Disfrutas resolver discusiones de diseño tanto como programar?
— ¿Te sientes responsable de un bug que tú no escribiste?
— ¿Has dado feedback correctivo sin escudarte en Pull Requests?
Responder «no» no es un pecado: indica que la trayectoria natural es hacia expertise, no hacia gestión. Obligar un ascenso solo alimenta la estadística de burnout (Software Quality Journal).
Cuando contratar fuera es la mejor inversión
En proyectos que pivotan o escalan rápido, fichar un perfil sénior externo reduce curva de aprendizaje y eleva el estándar. La arquitecta que reemplazó la expectativa de Lucía implantó feature toggles y pipelines de CI/CD en tres meses; el lead time cayó un 22 % (Atlassian DevOps report). El reto es cuidar la narrativa interna: mostrar que el fichaje viene a reforzar, no a desplazar.
El Aprendizaje: liderazgo saludable.
El equipo ideal no es un escalón vertical sino una red donde cada nodo aporta desde su zona de fortaleza. Ascender a un experto sin habilidades de influencia puede costar más que contratar a un líder curtido; pero ignorar la ambición legítima de tus veteranos es invitar a la fuga de talento. La respuesta está en dos palabras: rutas claras. Si cada ingeniera sabe cómo crecer —profundizando o dirigiendo— los celos se transforman en mentoría y el producto lo celebra con menos bugs y más confianza.
¿Has vivido algo parecido? Comparte tu historia o pregunta en ParaIngenieros.org. Aprender de los errores ajenos sigue siendo la forma más barata de mejorar.
