¿Manager o seguir como IC? La guía para decidir

Si eres ingeniero senior o líder técnico y estás atorado entre convertirte en Engineering Manager o seguir como contribuidor individual, déjame ahorrarte el primer error: convertirte en manager no es el siguiente escalón de tu carrera. Es una carrera distinta. Y no es tu única opción. Existe una tercera ruta, la de Staff o Principal, donde creces sin gestionar a nadie. Esta guía junta todo lo que he aprendido, escribiendo sobre esto y acompañando a decenas de personas en exactamente esta decisión, para que elijas con los ojos abiertos.

Escribo para una persona muy específica: llevas años como IC, eres bueno en lo técnico, y de repente sientes que "lo que sigue" es management, aunque no tengas del todo claro si eso es lo que quieres. Yo hice esa transición a finales de 2019, después de más de diez años escribiendo código sin nadie a mi cargo. No te hablo desde la teoría. Y una advertencia de entrada: esto es un marco para pensar, no una lista de vacantes. No es terapia. Si lo que traes es una crisis de salud mental, eso se trabaja con un profesional, no con una guía de carrera.

La pregunta correcta no es "¿acepto el ascenso?". Cuando tu empresa te quiere mover a manager porque eres la persona más capaz del equipo, te lo vende como un ascenso: más sueldo, mejor título, más prestaciones. Y tú lo evalúas como si fuera una versión mejor del mismo trabajo. No lo es. Las habilidades que te hicieron bueno como IC no son las que te van a hacer bueno como manager. Escribir buen código no se traduce en resolver problemas organizacionales, ni en entender las aspiraciones de cinco personas y alinearlas con el negocio. Convertirte en manager no es un ascenso dentro de tu carrera; es un cambio de carrera completo. Misma industria, quizá el mismo equipo, pero otras responsabilidades. Confundir empleo con carrera es lo que mete a la gente en problemas: un ascenso mejora tu empleo actual; un cambio de carrera te pone a jugar un juego nuevo, con reglas que no conoces. Aceptar sin saber que cambiaste de juego es una receta de burnout.

Antes de decidir hacia dónde, conviene separar dos cosas que casi todos amontonan: tu carrera y tu empleo. Tu empleo es esta chamba, esta empresa, este título. Tu carrera es el arco de quince o veinte años del que este empleo es apenas combustible. Ocúpate por tu carrera, no por tu trabajo. Esta empresa no va a ser la última donde ejerzas lo tuyo, y todo el conocimiento que generes aquí te lo vas a llevar: se lo prestas a la empresa, pero es tuyo.

Empecemos por lo que de verdad quieres, no por el título. Yo ordeno todo el esfuerzo de una carrera en tres cubetas: lo que tengo que hacer, lo que quiero hacer, y lo que me conviene hacer. La salud está en que ninguna cubeta se coma a las otras, y en mantener la de "tengo que" lo más delgada posible. La forma más rápida de que pierda interés en algo es sentir que tengo que hacerlo. Aplícalo a esta decisión: ¿estás volteando a ver management por un jalón externo (para crecer, para ganar visibilidad, porque es "lo que sigue") o por un deseo genuino de hacer ese trabajo? Son caminos muy distintos, y el primero rara vez se sostiene.

Hay una pregunta que separa el hobby de la profesión: ¿por qué quieres ser delantero? Que algo te llame la atención, que te lata, no es lo mismo que quererlo de tiempo completo. Puedes ser un portero buenísimo, de los que hacen ganar al equipo, y aun así quemarte persiguiendo el rol más vistoso solo porque brilla más. La carrera de un futbolista tiene fecha de caducidad; de porteros hay uno, de delanteros hay ocho. No te midas con un estándar que nunca fue el tuyo. Dos preguntas que le hago a la gente y te dejo de tarea: ¿cuándo fue la última vez que te sentiste orgulloso de tu trabajo (no en tu trabajo, la preposición importa), y describe la situación? Y transpórtate diez años al futuro y descríbeme un día. Si tu respuesta es "lo mismo que hoy pero un nivel más arriba", eso, por sí solo, ya te está diciendo algo sobre para dónde no quieres ir.

Lo que muchas veces está debajo de todo esto es un cambio de deseo: ya no quieres ser solo el ejecutor de las ideas de alguien más, quieres ser parte de la idea. Quieres entender el problema de alguien y resolvérselo, no nada más entregar un deliverable. Es una pregunta más existencial de lo que parece: ya te demostraste que puedes entregar proyectos, ¿y ahora qué? Está bien llegar ahí. Pero nombrarlo cambia la decisión, porque "ser parte de la idea" no te obliga a ser manager. Hay varias formas de conseguirlo.

El escalafón de tu empresa no es tu ruta de carrera. Son cosas distintas y vale la pena separarlas antes de cualquier decisión. El que es senior en la empresa A es junior en la empresa B: misma persona, mismas habilidades, solo cambió el contexto, y cae a un cinco por ciento de eficiencia porque no conoce a nadie, no tiene reputación, no conoce el sistema. No hay un estándar de industria real: en unos lugares el Staff hace de todo, en otros no existe y pasas de senior a manager directo. Usamos un lenguaje común (más o menos sabemos qué significa "senior"), pero cada empresa lo define según de dónde saca su dinero. Así que el paso después de senior no es, por default, convertirte en manager. El menú está abierto, y hay al menos tres rutas legítimas. Ninguna es superior en abstracto; la mejor es la que embona con lo que a ti te energiza.

1. Seguir como IC y profundizar. Te vuelves referente técnico, tomas problemas más ambiguos y de mayor alcance, y tu impacto deja de medirse en líneas de código. La chamba del senior, de hecho, es resolver un problema una sola vez: en vez de trapear el piso todos los días, arreglas la fuga. Ojo: incluso esta ruta, la de "no gestionar a nadie", te va a exigir soft skills y colaboración. No hay salida del trato con las personas, solo distintas dosis.
2. Convertirte en Engineering Manager. Tu materia prima deja de ser el código y pasa a ser el equipo: su bienestar, su crecimiento, sus procesos, su alineación con el negocio. Es el tema de buena parte de esta guía.
3. Tomar la ruta Staff o Principal. La tercera opción que casi nadie menciona: una carrera de IC de altísimo nivel, sin reportes directos. En la cima de la escalera técnica, al ingeniero ya no se le pide que resuelva problemas, sino que los prevenga: un Principal casi ejecuta a nivel directivo, no pide permiso, conoce la estrategia de negocio y de producto, y decide. No es un premio de consolación; donde la implementan bien, pesa tanto como un director.

Y aquí un detalle que libera: pasar de IC a management es un movimiento horizontal, no vertical. Muchas veces nos ponemos el pie solitos creyendo que, como son caminos distintos, no podemos usar nada de nuestro pasado. Falso. En buena medida es cuestión de reinterpretar tu experiencia desde una óptica de management. De hecho, los arquetipos se están compactando: lo que llamábamos Staff (el expertise técnico para respaldar decisiones, el expertise social para ejercer influencia, y la visión de producto para decidir estratégicamente) es justo la aglomeración de habilidades que se va a estabilizar. Vale la pena desmontar la idea de que la única forma de participar en esta industria es como programador.

Si te vas por management, entiende qué es en realidad. Es demasiado fácil llegar a un puesto de EM pensando que el trabajo es asignar tickets y perseguir fechas. El Engineering Manager, a diferencia de un Project Manager, es un habilitador: toma las necesidades del negocio, las mastica, y las convierte en oportunidades de crecimiento para su equipo. Si a un Tech Lead le pones ese problema, muchas veces te va a decir "no entiendo de qué me hablas", y está bien: no es su chamba. Una forma de verlo es el peso: el Tech Lead se enfoca setenta por ciento en ingeniería y treinta en negocio; como EM ese peso se invierte. El TL necesita el contexto de negocio suficiente para no tomar malas decisiones técnicas; el EM tiene que cargar contexto suficiente para ver venir la regulación a cuatro años. Cambia también cómo planeas: al EM no le importa cómo llegas de A a B, esa es la chamba del TL; el EM pone el milestone y el sandbox, y el equipo ve el camino. Antes entregábamos proyectos y nadie cuestionaba el porqué; hoy es outcome-based, y al negocio le importan los resultados, no que hayas completado proyectos. Como EM eres accountable de resultados, no de proyectos.

El corazón de todo esto es contraintuitivo para quien viene de construir: los buenos managers no resuelven los problemas ellos mismos. Habilitan a otros para que los resuelvan. A veces la mejor forma de aportar es solo poner a las dos personas correctas en contacto. Yo mismo, al inicio, no pude evitar caer en la comodidad de tomar decisiones por mi cuenta y repartir tickets, hasta que me di cuenta de que esa forma de trabajo no solo me creaba más chamba, sino que frenaba el crecimiento de mi equipo. Ahí hizo clic que para ser un buen manager tenía que preocuparme más por habilitar que por hacer. Toda la capacidad de delegar se destila en una sola cosa: confías en tu equipo o no. Y si conectas un interés real de la persona con el problema que le pones enfrente, la delegación se resuelve sola: vienen ellos a quitarte los pendientes de encima. Un buen día lo ves de cerca en las 1on1s y en cómo das y recibes feedback; es, en gran medida, el trabajo. Cuidado, eso sí, con quedarte atrapado en ser "el confiable" que todo lo resuelve: eso te hace necesario, no poderoso, y te drena.

Vale la pena separar dos palabras que se usan como sinónimos: management y liderazgo no son lo mismo. Un líder inspira acciones; un manager moldea procesos y hace que las cosas sucedan. Un buen líder que es mal manager puede tener buenos resultados (el equipo lo rescata); un buen manager que es mal líder, muy malos. La combinación buena es rarísima y es la que hace lodo. Y hay una verdad incómoda: para ser buen manager, a veces tienes que apagar al líder y tragarte un mal rato. Correr gente no es divertido, es de lo peor, y aun así uno termina apreciando la complejidad del rol. Si tu razón para querer el puesto es que "te gusta la gente", ten claro que el trabajo también incluye lo que a la gente no le gusta.

El feedback loop del management es larguísimo, y por eso el ritmo importa tanto. Como desarrollador compilas y en segundos sabes si funcionó. Cuando tomas una decisión para prevenir el burnout de tu equipo, puedes tardar meses en saber si sirvió, porque el bienestar de una persona no se mide en datos discretos: tienes que leer tendencias, no puntos sueltos. Para quien ama la retroalimentación inmediata del código, ese cambio de reloj es lo más difícil de todo. Y hay una trampa cultural encima: en Latinoamérica nos acostumbraron a glorificar el trabajo duro y a confundir estar ocupado con estar aportando, así que al llegar a un rol de gerencia buscamos maneras de mantenernos ocupados. Piensa en las mascarillas de oxígeno del avión: primero la tuya, luego ayudas a los demás. Un Engineering Manager quemado es como wifi sin internet: sería menos frustrante no tenerlo. Un buen líder se respeta a sí mismo y pone límites antes de terminar quemado. Aquí ayuda pensar el burnout como un system prompt que ya no cabe: cargas todo tu contexto, no puedes forkear una instancia fresca y no quemada, y ese compounding, si no lo manejas, es justo el desgaste.

Es una decisión cara de revertir, así que primero calibra el riesgo. A mí me gusta pensar cualquier decisión como un corte de cabello, una gorra, o un tatuaje. El corte de cabello es totalmente reversible y se arregla solo: tomas la decisión, si funciona, chido, y si no, el tiempo lo resuelve sin que hagas nada. La gorra (o una camisa que compraste cara y no te gustó) es reversible, pero te deja un sunk cost incómodo cada que abres el clóset: la regalas, la vendes o te la pones, no hay respuesta correcta, pero se resuelve. El tatuaje es reversible solo a un costo real y repetido: le puedes dar reversa a estar todo rayado, pero para deshacerlo vas a tener que volver a sufrir, en dinero, en sesiones, en tiempo y en dolor. Pasar de manager de vuelta a IC es más tatuaje que corte de cabello: muchas organizaciones no tienen una ruta limpia de regreso, y "bajar" se lee (injustamente, pero se lee) como fracaso, con costo de banda salarial, de contexto técnico oxidado y hasta de reputación. La buena noticia es que casi siempre puedes convertir el tatuaje en un corte de cabello: no te comprometas del todo de golpe, párte la decisión en pasos chiquitos y reversibles. A eso llegamos al final.

Debajo de la reversibilidad hay algo más profundo: la identidad. Casi todas las carreras hoy son una máquina de Rube Goldberg gigante, y tú eres una pieza pequeña de un mecanismo que, en el mejor de los casos, le resuelve un problema a alguien muy lejos de ti. Mientras más cerca del inicio de la máquina estás, más acrobacias mentales tienes que hacer para sentir que tu contribución importa. Por eso conviene, con tiempo, separar tu identidad de tu empleo y diversificar tus fuentes de satisfacción como diversificas inversiones: tu relación con producto, con tu manager, con cada persona del equipo, con la estrategia. Por temporadas unas están prendidas más que otras, y está bien; administras tu atención y tu energía como un recurso finito y rebalanceas el portafolio. No cuelgues todo tu "¿voy bien?" del título, que además es un indicador con un feedback loop larguísimo. Tú no eres tu carrera: la chamba es un enabler de otras cosas, es transaccional, está construida para ser efímera. Tu vida personal es la que corre en producción, sin rollback.

Y ya que hablamos de títulos: el título es un lagging indicator. Piénsalo como la lluvia. Un leading indicator es la señal de que algo va a pasar: huele a tierra mojada, va a llover. Un lagging indicator es la evidencia de algo que ya pasó: te levantas, el piso está mojado, llovió, punto. El promotion es un lagging indicator de un comportamiento que ya sostuviste. A mi gente le digo: si quieres ser Staff, te empiezo a tratar como Staff un año antes, no para regalarte el título, sino para encontrar el delta de habilidades que te falta; cuando lleves seis meses ejecutando a ese nivel, entonces sí llega el reconocimiento, porque ya te lo ganaste. El título que tienes hoy es tu baseline, el mínimo. Por eso, paradójicamente, la mejor forma de subir es casi olvidarte del título y enfocarte en la categoría de problemas que puedes quitarle a tu manager. Uno recibe una promoción cuando le roba la chamba al manager. Y una advertencia técnica: por más chingona que sea tu arquitectura, un pull request no cambia los incentivos que hacen que a alguien lo promuevan; el esfuerzo técnico apunta para el otro lado. Si vas a pedir el paso, aprende a pedir el ascenso sin sonar arrogante.

Ninguna de estas rutas se decide en el vacío: se decide dentro de una empresa con reglas. Y las reglas de una empresa no están en los manuales. Follow the money: ¿a quién le va mejor? Pueden decir misa, pero los incentivos son los que gobiernan el comportamiento, y ahí están las verdaderas reglas del juego, implícitas. ¿Cómo vas a jugar bien un juego cuyas reglas no conoces? Piensas que lo estás haciendo bien y resulta que no. Una vez que las haces explícitas, puedes decidir si quieres jugar y cómo. Antes de cualquier táctica, verifica la estrategia: arma primero los bordes del rompecabezas. ¿Estás en la industria correcta? ¿Del lado correcto del negocio? ¿Es el timing correcto? Y una pregunta que ahorra sufrimiento: no toda empresa necesita un Engineering Manager; algunas necesitan un PM con nociones de ingeniería. Porque el código ya no es el moat: van a ser las personas de producto que sepan de código las que tengan las posiciones más estables. Si tu empresa no tiene una ruta Staff real, con banda salarial equivalente a management, entonces "seguir creciendo sin gestionar" es una promesa vacía y te están empujando a management por falta de alternativas, no por vocación. Esa sola pregunta cambia toda tu decisión.

Vale la pena mirar a tu equipo con lente de economista. ¿Eres un centro de costos o un centro de ingresos? Un centro de costos tiene techo finito (hay un límite de cuánto le puedes ahorrar a la empresa); un centro de ingresos es, en teoría, infinito. La pregunta útil es cómo conviertes un cuello de botella en una oportunidad. Y detrás de eso: el valor es utilidad por escasez. Algo vale más cuando es muy útil y escaso; útil pero fácil de conseguir es barato. ¿Cuál es el oro, el diamante de tu empresa? ¿Dónde está el recurso escaso? Ahí está tu palanca, y ahí es donde tu verdadero stack deja de ser React o Go y pasa a ser incentivos e influencia. Y sí, eso incluye la política, que en los equipos se sataniza sin razón: lo que muchos llaman política es la capacidad de hacer trade-offs. Puede que a ti no te importe, pero a la política sí le importas tú. Donde hay personas, hay política.

Un apunte de contexto que no puedes ignorar: cambiarte de empresa por un mejor título no siempre es la decisión correcta, porque tu reputación no viaja contigo. Por eso, si te vas a estrenar como EM, optimiza para el equipo, no para la tecnología: si eres dev móvil, tu mejor probabilidad de éxito es ser manager de un equipo móvil, para recargarte en tu hands-on mientras aprendes a gestionar. No buscas el puesto soñado de EM; buscas una silla en la mesa.

Antes de aceptar, haz estas preguntas. "Ser manager" significa algo distinto en cada empresa, así que no te quedes con el título:

• ¿Esta empresa de verdad necesita un Engineering Manager, o un Project Manager con nociones técnicas?
• ¿Existe una ruta Staff o Principal real y con dientes, con banda salarial equivalente? Si no, "crecer sin gestionar" es humo.
• ¿Cuáles son exactamente las tareas y expectativas del puesto? Pide que te describan una semana típica.
• ¿A quién voy a reportar y cómo se ve un buen manager para esta organización? Vas a heredar su definición de éxito.
• ¿Cómo se ve el regreso? Si en seis meses quiero volver a IC, ¿existe el camino o me quedo atrapado?
• Y una para ti, no para ellos: ¿estoy corriendo hacia management, o huyendo de algo en mi rol actual?

El experimento reversible de 30/60/90 días. Como la decisión es cara de revertir, no la tomes como salto de fe: trátala como un experimento con hipótesis y fecha de revisión. Esto es convertir el tatuaje en corte de cabello. Si puedes, negocia un periodo de prueba explícito:

• Días 1 a 30, observa. Deja de meter las manos al código de forma reactiva. Dedica el tiempo a 1on1s, a entender a cada persona y a mapear cómo se toman las decisiones. Anota, sin filtro, qué te energiza y qué te drena.
• Días 31 a 60, habilita. Resiste la tentación de resolver tú. Tu métrica ya no es lo que tú entregas, es lo que tu equipo logra desbloquear. Practica delegar de verdad, no repartir tickets.
• Días 61 a 90, evalúa. Relee tus notas. ¿La semana que más disfrutaste fue de management, o de las horas sueltas en que te sentaste a programar? Sé brutalmente honesto. Si extrañas construir, no es un fracaso: es información carísima que conseguiste barata, antes de que la decisión se volviera irreversible.

Un experimento de noventa días te cuesta un trimestre. Descubrir a los tres años que tomaste la ruta equivocada te cuesta muchísimo más.

Un último marco, porque cambia el tablero de todos: la IA. El código dejó de ser la moneda de cambio, y hasta los Engineering Managers están escribiendo cuatro veces más código que hace seis meses. La lección no es "vuélvete manager para escapar del teclado". Es que el leverage se está moviendo: de saber diez mil tecnologías a conectar un sentido de servicio con habilidades técnicas suficientemente buenas y con criterio de producto. Elijas IC profundo, Staff o management, esa es la apuesta que conviene hacer.

Si quieres seguir jalando el hilo, esta guía se apoya en, y se complementa con, varias piezas: lo que aprendí en mis primeros años como Engineering Manager, cómo es un día en la vida de un EM, qué hace realmente un senior, y, si ya estás liderando, el caso del tech lead que no pone límites.

Si estás justo en esta decisión

No te digo qué decidir. Te acompaño a que llegues a tu propia respuesta.

Eso es lo que hago en mis sesiones de coaching 1:1: ponemos en orden el contexto, leemos las reglas del juego y convertimos una situación ambigua en decisiones que puedas sostener. Con los criterios correctos y sin autoengaños. Y está bien si no lo quieres hacer solo.

Cómo trabajo el coaching 1:1

Trabajo con pocas personas a la vez. Si no hay encaje, te lo digo antes de empezar.