Llevamos ya un tiempo hablando de cómo la IA afecta al trabajo de los desarrolladores. Hay artículos, estudios, debates y opiniones para todos los gustos. Pero hay un rol sobre el que se habla mucho menos: el Engineering Manager.
¿Qué pasa con las personas que lideran equipos técnicos? ¿Cómo cambia su día a día con la IA? ¿Les afecta o no les afecta?
Mi experiencia es que les afecta, y mucho. Pero no de la forma que muchos esperan. No es que la IA venga a quitarles trabajo. Es que les permite hacer ese trabajo con una profundidad que antes era muy difícil de conseguir.
La IA como amplificador, no como sustituto#
Antes de entrar en el detalle práctico, quiero dejar claro el marco mental desde el que escribo esto.
La IA no viene a hacer el trabajo del EM. Viene a amplificar la capacidad de quien la usa.
Un EM que no sabe escuchar, que no tiene criterio técnico, que no entiende a las personas de su equipo, no va a volverse bueno por usar IA. Uno que sí tiene esas capacidades va a poder aplicarlas con una profundidad y una escala que antes no eran posibles.
Es el mismo principio que ocurre con los desarrolladores: un buen desarrollador con IA es mucho más productivo; uno sin criterio produce basura más rápido.
La diferencia en el caso del EM es que los efectos son más difusos y más lentos de observar. No se miden en líneas de código o tickets cerrados. Se miden en la calidad de las decisiones, en la madurez de los artefactos que produce el equipo, en cómo se sienten las personas semanas o meses después.
La trampa del “siempre hubo demasiado que hacer”#
Hay algo que cualquier EM reconocerá: la sensación crónica de que no hay tiempo para todo.
Un Engineering Manager vive entre dos mundos. Por un lado, el mundo técnico: requerimientos, arquitectura, decisiones de diseño, deuda técnica, code reviews, planificación. Por otro, el mundo de las personas: one-on-ones, feedback, desarrollo de carrera, gestión de conflictos, motivación, contratación.
Y en el centro de todo eso, las reuniones. Muchas reuniones.
El resultado es que muchas cosas importantes se hacen con menos profundidad de la que deberían. Los requerimientos quedan vagos porque no hubo tiempo de afinarlos. Las historias técnicas se escriben a medias porque el sprint empieza mañana. El feedback al equipo es más superficial de lo que debería porque la semana ha sido una locura.
La IA no elimina ese problema de raíz, pero sí cambia cuánto puedes hacer en el tiempo que tienes. Y eso marca una diferencia real.
1. Generación de requerimientos: del caos a la claridad#
Una de las partes más complejas del rol de EM es la traducción. Recibes input del negocio, del producto, de stakeholders con ideas más o menos formadas, y tienes que convertir eso en algo que un equipo técnico pueda ejecutar.
Hace unos meses recibí una petición de negocio que era básicamente una idea a medias. Antes, habría convocado una reunión de refinamiento, habríamos pasado la primera media hora descubriendo huecos en vivo, y el equipo habría salido con sensación de que todavía no estaba claro. En cambio, pegué ese idea a la IA y le pedí que identificara lo que faltaba:
- ¿Qué casos de uso no están cubiertos?
- ¿Qué asunciones se están haciendo implícitamente?
- ¿Qué preguntas habría que hacerle antes de empezar?
En diez minutos tenía una lista de seis preguntas concretas. Algunas las podia responder yo mismo, otras hacia falta hablarlas con negocio. Llegué al refinamiento con algo tan trabajado que la sesión se convirtió en buscar la mejor solución técnica, no en encontrar un hueco que no este definido, no en una construcción desde cero.
No estás delegando el pensamiento. Estás usando la IA para asegurarte de que no se te escapa nada antes de comprometerte con un scope.
2. Historias técnicas: el detalle que antes no había tiempo de escribir#
Si los requerimientos son el qué, las historias técnicas son el cómo. Y aquí la diferencia que puede marcar la IA es aún más pronunciada.
Una historia técnica bien escrita no es solo “implementar el endpoint de autenticación”. Es:
- Qué librerías usar y por qué
- Qué patrones se esperan
- Qué consideraciones de seguridad hay que tener en cuenta
- Cómo debería probarse
- Qué dependencias tiene con otras partes del sistema
- Qué podría salir mal
Ese nivel de detalle hace que un desarrollador pueda arrancar una tarea sin bloqueos, sin interpretaciones subjetivas y sin necesitar estar preguntando cada dos horas. Reduce el tiempo de onboarding en tareas, reduce errores y reduce retrabajo.
El problema es que escribir historias a ese nivel de detalle requiere tiempo. Y en la mayoría de los equipos, ese tiempo no existe. Así que las historias se escriben justas, y el conocimiento implícito vive en la cabeza de alguien —normalmente la persona más senior del equipo o el propio EM.
Con la IA, ese proceso se acelera drásticamente. Le das el contexto del sistema, la arquitectura existente, los patrones que usáis, y le pides que ayude a expandir una historia. El resultado no es perfecto, pero es un punto de partida mucho mejor que una línea y media en Jira. Lo que antes era un artefacto pobre por falta de tiempo, ahora puede ser un documento técnico real que sirva de referencia durante la implementación y que además quede como documentación del sistema.
3. Gestión de personas: el sparring que no siempre tienes cerca#
Esta es la parte que menos se menciona cuando se habla de IA y liderazgo, y para mí es la más interesante.
Gestionar personas es difícil. No porque las personas sean difíciles —aunque a veces lo son— sino porque cada situación es única, los contextos son complejos y rara vez hay una respuesta obvia. Y el EM suele tomar esas decisiones solo, o con muy poca ayuda.
¿Cómo le doy feedback a alguien que está bajando su rendimiento sin desanimarle? ¿Cómo gestiono la situación entre dos personas del equipo que no se llevan bien? ¿Cómo le explico a alguien que no va a obtener la promoción que esperaba? ¿Cómo ayudo a alguien a crecer cuando ya ha tocado techo en su rol actual?
Antes, para hablar de estas cosas, necesitabas acceso a otro manager de confianza, a un mentor, a RRHH, o simplemente lo resolvías solo con más o menos acierto.
Recuerdo una situación concreta: tenía que hablar con alguien del equipo sobre un patrón de comportamiento que estaba afectando la dinámica del grupo. Era una conversación delicada, con mucho contexto acumulado, y yo tenía claro el problema pero no cómo articularlo sin que sonara a ataque personal. Le describí la situación a la IA, con todo el contexto, y le pedí que me ayudara a ver si había ángulos que no estaba considerando. Me señaló dos cosas que no había pensado. La conversación fue mucho mejor de lo que hubiera sido sin esa preparación.
La IA no reemplaza al mentor humano. Pero puede ser un sparring disponible en cualquier momento, sin agenda, sin sesgos propios sobre las personas implicadas, y con la capacidad de ayudarte a estructurar tu pensamiento antes de actuar.
Lo mismo aplica para la preparación de one-on-ones. Un one-on-one bien preparado no es una reunión donde repasas el estado del sprint. Es una conversación donde tienes claro qué quieres explorar, qué feedback tienes que dar, qué preguntas abiertas quieres hacer para entender cómo está la persona, y qué seguimiento vas a hacer de lo que hablasteis la semana pasada. Preparar eso para cada persona del equipo, cada semana, requiere tiempo y energía mental. Con la IA puedes llegar mucho más preparado: le describes el contexto de la persona, le pides que te ayude a formular el feedback de forma constructiva, que te sugiera preguntas para explorar determinado tema.
No toma la decisión por ti. Pero te ayuda a llegar a esa decisión con más información, más perspectiva y más preparación.
4. Los límites que hay que tener en cuenta#
Sería deshonesto escribir todo esto sin mencionar lo que no funciona, o lo que hay que vigilar.
La IA no conoce a tu equipo. Puedes darle contexto, pero ese contexto lo filtras tú, con tus sesgos. Si describes a alguien del equipo de una forma parcial, la IA va a trabajar con esa descripción parcial. El riesgo es que refuerce tu punto de vista en lugar de cuestionarlo. Hay que pedirle explícitamente que juegue al abogado del diablo.
El sobreuso lleva a la uniformidad. Si todos los requerimientos tienen la misma estructura porque los pasaste por el mismo prompt, pierdes el criterio propio. La IA es un primer borrador, no el producto final. El juicio sigue siendo tuyo.
La confidencialidad es real. En conversaciones sobre personas del equipo, hay que ser cuidadoso con qué información compartes y con qué herramienta. No es un problema sin solución, pero sí es algo que hay que pensar antes de hacerlo de forma irreflexiva.
No sustituye la conversación real. Ninguna preparación con IA reemplaza la escucha activa en el momento. La IA te ayuda a llegar preparado; lo que pasa en la conversación depende de ti.
Lo que cambia realmente#
Si tuviese que resumir qué cambia en el día a día de un EM con la IA, diría esto:
La brecha entre lo que sabes que deberías hacer y lo que realmente tienes tiempo de hacer se reduce.
Siempre supe que los requerimientos deberían estar más trabajados. Siempre supe que las historias técnicas deberían tener más detalle. Siempre supe que las conversaciones difíciles merecen mejor preparación. El problema no era el conocimiento. Era el tiempo y la energía.
Lo que más me sorprendió no fue la velocidad. Fue la calidad de la preparación. Llegas a las conversaciones con más perspectiva, a los refinamientos con menos huecos, a las decisiones con más ángulos considerados. Y eso se nota, aunque no se mida fácilmente.
La IA no te da más horas en el día. Pero sí te permite hacer más con las horas que tienes. Y para un rol donde la calidad de lo que haces tiene un impacto multiplicador sobre todo el equipo, eso importa mucho.
¿Tú ya la estás usando para gestionar tu equipo, o todavía la tienes reservada solo para el código?