Son las 6 de la tarde de un jueves y tienes tres cosas para resolver antes de cerrar la semana: un 1:1 con un developer senior que viene rindiendo por debajo de lo esperado y todavía no sabe que lo notaste, una discusión con Producto sobre qué feature sale del sprint porque el equipo no llega, y un mensaje de Slack de un stakeholder que quiere saber por qué el proyecto se atrasó dos semanas. No vas a escribir ni una línea de código en todo el día. Y aun así, de las tres cosas, la que peor manejes hoy es la que más te va a costar la semana que viene.
Eso es un martes cualquiera para un Engineering Manager (EM), y es un trabajo bastante distinto al que hacías como developer senior, aunque en el papel suene parecido.
Dicho de forma directa: un Engineering Manager (EM) es quien responde por la entrega sostenible de un equipo de ingeniería, resolviendo lo que bloquea a las personas (prioridades poco claras, fricción con otros equipos, falta de contexto, problemas de desempeño) para que cada developer pueda hacer su mejor trabajo. No es el título más senior a nivel de código dentro del equipo. Es quien asume la responsabilidad de que el equipo, como conjunto, funcione.
Engineering Manager no es lo mismo que Tech Lead
La confusión es comprensible porque en muchas empresas, sobre todo las más chicas, una sola persona hace ambas cosas. Pero son roles distintos y vale la pena separarlos, incluso si en tu empresa actual conviven en la misma persona.
Un tech lead conserva autoridad técnica: define arquitectura, revisa decisiones de diseño complejas y muchas veces sigue escribiendo código en las partes más difíciles del sistema. Su influencia viene de la competencia técnica, no de tener gente a cargo.
Un EM gestiona personas, prioridades y remoción de bloqueos. Decide (o negocia) qué entra al sprint, tiene las conversaciones difíciles de desempeño, define quién trabaja en qué, y absorbe la fricción organizacional para que el equipo no tenga que lidiar con ella directamente. Su influencia viene de tener autoridad formal sobre las personas y sobre las prioridades del equipo, no de ser quien mejor entiende el código.
En empresas grandes y maduras, ambos roles suelen coexistir, con reporte formal al EM y autoridad técnica delegada al tech lead. En empresas más chicas, es común que el EM también haga de tech lead, sobre todo en equipos de pocas personas. Ninguna de las dos estructuras es incorrecta. Lo que sí conviene tener claro antes de aceptar un rol de EM es cuál de las dos versiones estás aceptando, porque cambia bastante cuánto tiempo técnico real te queda.
Un ejemplo típico de cómo se ve la diferencia en la práctica: un tech lead puede pasar una tarde entera revisando línea por línea el diseño de una migración de base de datos con el equipo. Un EM, ese mismo día, puede pasarla entera en 1:1s, ajustando el roadmap con Producto y resolviendo un conflicto de prioridades entre dos equipos. Ambos trabajos importan. Ninguno reemplaza al otro, y confundirlos suele ser la raíz de expectativas poco claras sobre qué se espera de cada rol.
Qué mide a un EM (y no se parece a lo que te medía como IC)
Como developer senior, tu trabajo se medía en cosas visibles: features entregadas, calidad del código, PRs mergeados, la dificultad técnica de lo que resolviste. Como EM, las métricas cambian casi por completo.
Un EM se mide, formal o informalmente, por la entrega predecible del equipo (no la tuya, la del equipo completo), la retención de las personas que le reportan, el crecimiento real de esas personas en el tiempo, y la salud del proceso: cuánta fricción hay entre el equipo y el resto de la organización, cuánta claridad tienen las prioridades, cuánto ruido hay en las reuniones.
Esto tiene una consecuencia que a muchos senior IC les cuesta anticipar: el buen trabajo de un EM suele ser invisible. Nadie nota el conflicto entre dos developers que resolviste en un 1:1 antes de que escalara. Nadie nota la prioridad mal definida que corregiste con Producto antes de que el equipo perdiera dos semanas construyendo lo que no había que construir. Si necesitas ver el resultado de tu trabajo reflejado en algo que se pueda señalar (un feature en producción, un commit, un demo), la parte más importante del trabajo de EM te va a resultar frustrante, porque justamente esa parte no deja rastro visible cuando sale bien.
En la práctica, esto se traduce en rituales concretos: 1:1s semanales con cada persona del equipo, skip levels ocasionales si además gestionas a otros managers, y revisiones de desempeño que funcionan como herramienta real de desarrollo y no como trámite anual. La calidad con la que sostengas esos rituales importa tanto como cualquier número de entrega, aunque no aparezca en ningún dashboard.
El trade-off que nadie te cuenta: dejas de programar en serio
Nadie te lo dice con esta claridad en la entrevista, así que lo decimos acá: si pasas a EM, dejas de programar en serio. No de un día para el otro, y en muchas empresas todavía vas a poder meter mano en algo puntual, revisar un PR complicado, resolver un bug crítico un fin de semana. Pero la cantidad de tiempo hands-on que te quedaba como senior IC (ya reducida si venías de un rol más senior) baja a algo marginal.
En términos de calendario, el cambio es notorio: pasas de tener bloques de varias horas libres para concentrarte en un problema técnico a un día fragmentado en reuniones de 30 minutos, con huecos de 15 entre una y otra. Eso no es un detalle menor de organización personal: cambia por completo el tipo de trabajo cognitivo que puedes sostener durante el día.
Si tu identidad profesional está construida alrededor de ser quien mejor programa del equipo, este cambio te va a doler más de lo que esperas. No es un problema de habilidad, es un problema de a qué le dedicas la energía todos los días. Vas a pasar de resolver problemas técnicos concretos a resolver problemas humanos, casi siempre más ambiguos y menos prolijos que un bug con stack trace.
Hay gente senior que prueba el rol de EM, extraña profundamente el trabajo técnico diario, y vuelve a un rol de IC sin que eso sea un fracaso. Es información valiosa sobre qué te da energía en el trabajo, y es mucho mejor descubrirlo probando el rol seis meses o un año que arrepintiéndote una década después.
Cuándo tiene sentido pasar de senior IC a EM (y cuándo no)
El buen fit tiene señales bastante concretas. Si te energiza más destrabar a alguien que estaba estancado que mergear tu propio PR, es una señal fuerte. Si te interesa genuinamente multiplicar tu impacto a través de las decisiones de otros, más que a través de tus propias manos, también. Y si tienes paciencia real (no aspiracional) con problemas humanos desprolijos (una persona que rinde por debajo de lo esperado, dos developers que no se llevan bien, un stakeholder que pide algo poco razonable), el trabajo diario de EM te va a resultar sostenible en vez de agotador.
El mal fit también tiene señales claras, y vale la pena ser honesto con uno mismo sobre esto. Buscar el rol de EM para escapar de la ambigüedad técnica (cansarte de tomar decisiones de arquitectura difíciles, por ejemplo) es una mala razón, porque el rol tiene su propia ambigüedad, solo que sobre personas en vez de sistemas. Buscarlo por el título o por el prestigio, sin querer de verdad el trabajo diario de gestionar personas, tampoco funciona: se nota rápido, tanto para ti como para el equipo que te reporta.
Hay una zona intermedia que vale la pena nombrar: probar el rol de forma temporal, cubriendo una licencia o liderando un equipo chico por unos meses, es una de las formas más económicas de saber si el trabajo te queda bien antes de comprometerte de lleno. Si tu empresa ofrece esa opción, tiene sentido tomarla antes de decidir en el vacío.
Vale la pena mencionar algo que muchas empresas maduras tienen pero que no siempre se comunica bien: un track de carrera IC que llega a niveles comparables al de EM (senior, staff, principal engineer), con compensación equivalente en las bandas más altas. No es universal (depende mucho de la empresa y de qué tan formalizado tenga ese camino), pero si estás evaluando el salto, vale la pena preguntar explícitamente por las bandas de compensación de EM frente a Staff o Principal Engineer en esa empresa en particular, antes de asumir que gestionar personas es el único camino hacia arriba.
El nivel de trayectoria senior que suele preceder este salto tiene menos que ver con años de experiencia y más con cómo entiendes tu propio criterio técnico: vale la pena tener eso claro antes, revisando cómo se define el seniority real en equipos de desarrollo. Ser EM no te va a quedar bien si lo tomas como un ascenso automático. Te va a quedar bien si entiendes que es un trabajo distinto, con su propio oficio, que consiste en hacer que las cosas sucedan a través de otras personas.
