Línea técnica vs. línea de gestión: diferencias entre Staff Engineer y Engineering Manager

En la mayoría de las organizaciones de ingeniería de software, llegar a un techo de nivel senior obliga a tomar una decisión que marcará el resto de la carrera: convertirse en gestor de personas o profundizar como experto técnico. Durante décadas, la industria asumió que la única vía de ascenso «real» pasaba por dejar de programar y empezar a gestionar equipos. Ese supuesto, sin embargo, ha sido cuestionado con fuerza por referentes como Camille Fournier (autora de The Manager's Path y ex CTO de Rent the Runway), Will Larson (autor de Staff Engineer: Leadership Beyond the Management Track) y Charity Majors (cofundadora y CTO de Honeycomb). Los tres han documentado, desde ángulos distintos, un modelo alternativo: la doble escala profesional, en la que la ruta de Individual Contributor (IC) —cuyo peldaño emblemático es el Staff Engineer— tiene el mismo peso, prestigio y compensación que la ruta de Engineering Manager.

Este artículo compara ambos roles en profundidad: qué hacen, qué habilidades exigen, cómo se relacionan entre sí y por qué cada vez más profesionales —y más empresas— apuestan por moverse entre ambos mundos en lugar de elegir uno para siempre.

I. Introducción a la doble escala profesional (Dual Career Ladder)

A. Origen histórico del modelo y adopción en la industria del software

La doble escala profesional no nació en Silicon Valley. El concepto se remonta a la década de 1950, cuando organizaciones de investigación como la NASA y los Bell Labs necesitaban retener a científicos de primer nivel que no tenían ningún interés en gestionar personas [1]. La lógica era simple: si la única forma de progresar era convertirse en jefe, la organización perdía a sus mejores investigadores en el momento en que dejaban de investigar.

La versión moderna, orientada específicamente a la ingeniería de software, tiene un hito muy concreto: en marzo de 2015, Camille Fournier publicó en el blog de ingeniería de Rent the Runway una de las primeras escalas de carrera públicas con una distinción clara entre niveles de gestión y niveles IC, acompañada de una hoja de cálculo y un documento de texto largo con expectativas detalladas por nivel [3]. Fournier explica que, en aquel momento, la mayoría de las empresas que redactaban «escaleras» de carrera lo hacían contratando consultoras como Radford, copiando la escala de una gran empresa donde habían trabajado antes, o tomando prestada la plantilla de una empresa amiga; muy pocas partían de cero con recursos propios [3]. La publicación abierta de la escala de Rent the Runway influyó en compañías como Medium, Spotify y muchas otras que, en los años siguientes, publicaron sus propios marcos, algunos inspirados directamente en ese trabajo original y otros con enfoques distintos [3]. Hoy, según datos de Radford/Aon de 2023, un 67% de las empresas tecnológicas ofrece alguna forma de doble escala profesional, aunque muchas siguen luchando por lograr una paridad real entre ambas rutas [1].

B. Equivalencia de nivel, impacto y compensación económica entre IC y Management

El principio rector de una doble escala bien diseñada es que ambas rutas ofrezcan compensación, seniority e influencia equivalentes en cada nivel: un Staff Engineer y un Engineering Manager deberían percibir una compensación total comparable [1]. La siguiente tabla, adaptada de los marcos de nivelación usados por firmas de compensación como Radford/Aon y por grandes tecnológicas, ilustra cómo se hace corresponder cada peldaño de la ruta de gestión con su equivalente IC [1]:

La paridad, sin embargo, no se logra solo con una tabla: exige auditorías salariales anuales, autoridad real de decisión técnica para los IC senior —no solo un rol consultivo— y visibilidad deliberada ante el liderazgo, invitando a los Staff Engineers a las mismas reuniones estratégicas que a los directores [1]. Sin estas tres formas de paridad (compensación, decisión y visibilidad), los empleados «harán las cuentas» y elegirán la gestión aunque no sea la ruta adecuada para ellos [1].

C. El riesgo de forzar a ingenieros técnicos hacia puestos de gestión de personas

El patrón que la doble escala busca evitar es muy conocido: un ingeniero o ingeniera excepcional recibe como recompensa un ascenso a un puesto de gestión que nunca pidió. De pronto pasa sus días en reuniones individuales, redactando evaluaciones de desempeño y navegando la política de oficina en lugar de hacer el trabajo que lo hizo destacar. En menos de un año, está frustrado o se ha ido [1]. Charity Majors describe el mismo fenómeno desde otro ángulo: durante mucho tiempo hubo dos caminos tradicionales hacia la gestión —el tech lead, «el mejor ingeniero» del equipo al que se designa mánager y que, en el fondo, lo resiente pero lo acepta, y el gestor de carrera que en algún momento deja de escribir código y nunca vuelve, perdiendo empleabilidad técnica con el tiempo [2][7]. Sin una escala paralela creíble, la organización corre el riesgo descrito por la literatura de recursos humanos: perder a un gran ingeniero y ganar, a cambio, un mánager mediocre [1]. Un dato lo confirma desde el lado de la retención: el 52% de los individual contributors afirma que dejaría una empresa que solo ofrece una ruta de gestión [1], y el 60% de los mánagers primerizos tiene un desempeño por debajo de lo esperado en sus dos primeros años [1], evidencia de que ascender por ascender rara vez funciona bien para nadie.

II. El perfil del Staff Engineer (Línea Técnica / IC)

A. Los tres pilares del rol Staff+: visión estratégica, ejecución y potenciación de los demás

Tanya Reilly, en su libro The Staff Engineer's Path, propone un marco de tres pilares para entender qué hace, en la práctica, un ingeniero Staff+: pensamiento de conjunto (big-picture thinking), ejecución y «leveling up» o potenciación de otros, todo ello apoyado sobre una base sólida de conocimiento técnico [12]. El primer pilar exige que el ingeniero sea capaz de aportar contexto para que las decisiones de la organización no queden atrapadas en óptimos locales: si cada equipo solo ve sus propios intereses, el conjunto de decisiones tiende a maximizar el beneficio de cada equipo por separado, no el de la organización [12]. Reilly resume esta idea con una frase que resulta clave para entender la relación con la gestión: «a nivel Staff+, tu mánager debería traerte información y compartir contexto, pero tú deberías decirle qué es importante tanto como él a ti» [12]. El segundo pilar, ejecución, cubre la gestión del tiempo, el «capital social» que se acumula con confianza y credibilidad, y la capacidad de liderar proyectos grandes o desbloquear los que están estancados [12]. El tercer pilar, potenciar a otros, es el que distingue a un Staff Engineer de un simple experto técnico solitario.

B. Responsabilidades nucleares: dirección tecnológica, perspectiva técnica y trabajo integrador

Will Larson describe el rol de forma muy concreta: definir la dirección tecnológica de la empresa, casi como un «product manager a tiempo parcial para la tecnología», traduciendo necesidades organizacionales en estrategias técnicas accionables [4][10]. A esto se suma la capacidad de inyectar perspectiva de ingeniería en decisiones de negocio, aportando un criterio técnico crítico justo en los momentos en que puede cambiar el rumbo de una decisión [4]. Finalmente, está el llamado «glue work» o trabajo integrador: exploración de problemas ambiguos pero cruciales y todas esas tareas que mantienen unidos a los proyectos y a los equipos, aunque no figuren en ningún tablero de tareas [4][10]. Para quienes se inician en la disciplina y todavía están definiendo su ruta —por ejemplo, quienes provienen de roles descritos en nuestro artículo sobre qué hace un desarrollador backend— este conjunto de responsabilidades marca el horizonte de hacia dónde puede evolucionar la práctica técnica sin necesidad de gestionar personas.

C. Los cuatro arquetipos de Will Larson: Tech Lead, Architect, Solver y Right Hand

Uno de los aportes más citados de Will Larson es la observación de que las escalas de carrera suelen definir un único conjunto uniforme de expectativas para el nivel Staff, cuando en realidad ese título esconde varios roles distintos [5][6][13]. Tras entrevistar a decenas de ingenieros Staff+, Larson identificó cuatro arquetipos recurrentes [5][6][13]:

• Tech Lead: guía el enfoque y la ejecución de un equipo o un grupo reducido de equipos, colabora estrechamente con uno o pocos mánagers y suele ser el primer contacto cuando hay que reorganizar la hoja de ruta. Es el arquetipo más común, presente en prácticamente toda empresa con cultura ágil, y suele ser la primera experiencia Staff de muchos ingenieros porque su trabajo diario se parece mucho al de un ingeniero senior [5][6][13].
• Architect: responsable de la dirección, calidad y enfoque de un dominio técnico crítico —el diseño de API de la empresa, el stack de frontend, la estrategia de almacenamiento o la infraestructura cloud—, combinando conocimiento profundo de las restricciones técnicas con las necesidades del negocio y una visión de varios años [5][6][13].
• Solver: se sumerge en problemas arbitrariamente complejos hasta encontrar una solución viable, ya sea enfocándose en un área durante mucho tiempo o saltando de un punto crítico a otro según lo guíe el liderazgo organizacional [5][6][13].
• Right Hand: extiende la atención de un ejecutivo, tomando prestados su alcance y su autoridad para operar organizaciones especialmente complejas, aportando ancho de banda de liderazgo adicional [5][6][13].

Larson advierte que ser Staff Engineer no es solo ocupar uno de estos roles, sino la intersección entre el rol, el comportamiento, el impacto real y el reconocimiento de la organización a todo ello [5][6][13]. Quienes buscan profundizar en las bases técnicas necesarias para acceder a cualquiera de estos cuatro arquetipos pueden revisar también nuestra comparativa de lenguajes de programación backend más utilizados, ya que el dominio profundo de sistemas suele ser prerrequisito de la etapa Staff.

D. La evolución de la tarea técnica: de picar código a la delegación para el crecimiento del equipo

Un patrón que Larson documenta con claridad en el arquetipo de Tech Lead es la transformación del propio trabajo técnico con el tiempo: al principio de su carrera, estos ingenieros implementan los proyectos más complejos del equipo, pero llegado cierto punto empiezan a delegar sistemáticamente ese trabajo [5][6][13]. Lo hacen por dos razones: para que sus compañeros crezcan y porque reconocen que el impacto del equipo aumenta a medida que se reduce su propio bloque de código escrito [5][6][13]. Es la misma idea que aparece en el pilar de «potenciación de otros» de Tanya Reilly: la mentoría y, sobre todo, el sponsorship —abogar activamente por otros y elevarlos dentro de la organización— es lo que produce impacto duradero, más allá de cualquier proyecto individual [4][10][12].

III. El perfil del Engineering Manager (Línea de Gestión)

A. La gestión como un oficio nuevo: personas, dinámicas sociotécnicas y desarrollo de carrera

Charity Majors sostiene una tesis incómoda pero influyente: la gestión de personas es una habilidad nueva, distinta a la ingeniería, que exige tiempo y esfuerzo para desarrollarse a un nivel decente, y que el tiempo dedicado a desarrollar esa habilidad es tiempo que se deja de invertir en habilidad técnica [7]. De ahí se desprende una consecuencia práctica: un equipo merece un mánager que realmente quiera gestionar personas, que tenga un interés genuino en los procesos sociotécnicos, en los sistemas y en nutrir las carreras de su gente —no alguien que ocupa el puesto a regañadientes porque «le tocó» o porque era la única persona disponible [2][8].

B. Requisitos de competencia técnica para la gestión: evaluación independiente y resolución de conflictos

El punto más polémico de la postura de Majors es que los equipos de ingeniería merecen un mánager cuyas habilidades técnicas estén lo suficientemente frescas y sólidas como para evaluar de forma independiente el trabajo de su equipo, guiar su desarrollo y resolver conflictos técnicos [2][8]. Existen muchos equipos donde esto no ocurre —el mánager se apoya por completo en un tech lead para saber si algo es bueno o malo, o para desarrollar a las personas— y, según Majors, aunque ese modelo puede funcionar, es una posición mucho más débil: delegar una porción tan grande del propio criterio a otra persona, sin poder evaluarlo de forma independiente, no es una buena situación [2][8]. Por eso defiende que los mejores mánagers de línea nunca están a más de un par de años de haber hecho trabajo técnico de primera mano, porque no hay sustituto para la credibilidad que se gana demostrando capacidad práctica y, más importante aún, buen criterio [2][8].

C. Desmitificación del management: rechazo de la idea de la gestión como única vía de ascenso

Majors enumera una serie de supuestos sobre la gestión que considera, literalmente, erróneos: que es un viaje sin retorno, que gestionar es en sí mismo un ascenso, que se gana más dinero, que es la mejor forma de tener influencia, que una vez que empiezas a gestionar querrás seguir subiendo en el organigrama, que es la única oportunidad real de progreso profesional, y que los mejores ingenieros son automáticamente los mejores mánagers [2][8]. Todo eso, en su opinión, es «basura», y sostiene esos supuestos producen mánagers que no quieren gestionar o que llegaron al puesto por las razones equivocadas [2][8]. Esta desmitificación conecta directamente con el espíritu de la doble escala: si la gestión no es una promoción sino un cambio de oficio, entonces la ruta IC no puede tratarse como una vía de segunda categoría. Para quienes están evaluando dar el salto —en cualquiera de las dos direcciones— conviene revisar también cómo comunicar ese cambio de rumbo profesional; nuestra guía sobre cómo redactar un currículum técnico para perfiles de ingeniería de software ofrece pautas útiles para reflejar tanto logros técnicos como de liderazgo de personas ante un comité de contratación.

IV. Análisis comparativo e interacción entre ambos roles

A. Alcance de impacto: estrategia técnica de producto vs. liderazgo y estructura de equipo

La diferencia central entre ambos roles no es de jerarquía sino de naturaleza del trabajo. El Staff Engineer opera como una suerte de «product manager técnico»: define visión y estrategia tecnológica, participa en decisiones de arquitectura y aporta criterio técnico independiente en discusiones de negocio [4][10][12]. El Engineering Manager, en cambio, construye y sostiene la estructura del equipo, gestiona el desarrollo de carrera de cada persona, resuelve dinámicas sociotécnicas y es responsable último de la salud del equipo como sistema humano [2][7][8]. Camille Fournier, autora de The Manager's Path y ex CTO de Rent the Runway, ha insistido en entrevistas en que ambos roles requieren aprender a manejar relaciones interdisciplinarias —por ejemplo, con producto— evitando que el mánager se convierta en un simple «teléfono descompuesto» entre ingenieros y stakeholders, y procurando que los ingenieros reciban reconocimiento directo por sus logros [11].

B. Dinámica colaborativa bidireccional entre Staff Engineer y Engineering Manager

Ambos roles no compiten: se necesitan mutuamente. En el arquetipo de Tech Lead descrito por Larson, el Staff Engineer trabaja en pareja estrecha con uno o pocos mánagers dentro de un área acotada [5][6][13]. Tanya Reilly formaliza esa relación con una idea muy citada: a nivel Staff+, el mánager debe aportar información y contexto organizacional, pero el ingeniero debe, con la misma intensidad, decirle al mánager qué es realmente importante desde el punto de vista técnico [12]. Es una relación de doble sentido, no una cadena de mando: el Engineering Manager aporta contexto de negocio y prioridades de personas; el Staff Engineer aporta profundidad técnica y visión de sistema. Cuando esta colaboración funciona bien, se refleja también en procesos organizativos más amplios, como el diseño de las trayectorias de aprendizaje de los nuevos ingenieros; de hecho, muchas de las prácticas que documentamos en nuestra guía sobre cómo diseñar un proceso de onboarding técnico eficaz dependen precisamente de esta coordinación entre quien define la estrategia técnica y quien gestiona el desarrollo de las personas.

C. La movilidad y el modelo del péndulo ingeniero-mánager para preservar empleabilidad y opcionalidad

Charity Majors popularizó, a partir de un artículo de 2017 y su continuación de 2019, la metáfora del «péndulo ingeniero-mánager»: en lugar de identificarse permanentemente como «ingeniero» o como «mánager», conviene pensarse como tecnólogo o líder técnico que se mueve entre ambos roles a lo largo de una carrera de treinta o cuarenta años [2][7][8][14]. Su argumento parte de una constatación práctica: aprender a gestionar personas toma tiempo —ella estima unos dos años para alcanzar un nivel decente— y ese tiempo invertido en desarrollar habilidades de gestión implica, casi inevitablemente, una pérdida gradual de destreza técnica, un «deslizamiento» que otros comentaristas sitúan entre tres y cinco años si la persona permanece exclusivamente en gestión [7]. La consecuencia, según Majors, es que quien sube la escalera de forma ingenua —asumiendo que la gestión es un camino de una sola dirección y que siempre hay que seguir ascendiendo— corre el riesgo de quedar atrapado, perdiendo empleabilidad y, con frecuencia, satisfacción profesional [2][7][8].

La alternativa que propone es comprometerse plenamente con la gestión con los ojos bien abiertos, o bien oscilar deliberadamente como un péndulo entre liderazgo técnico y de personas, preservando así opcionalidad futura [7]. Majors defiende que los mejores líderes técnicos que ha conocido en su carrera han pasado por ambos roles y han desarrollado ambos conjuntos de habilidades [2][8]. No es una idea sin matices: John Barton, quien siguió precisamente esa trayectoria de péndulo —desarrollador, luego líder de ingeniería, luego de nuevo cofundador técnico—, cuestiona si el péndulo es realmente el ideal a perseguir o simplemente la mejor respuesta posible dentro de un statu quo que en sí mismo podría mejorarse, por ejemplo logrando que más mánagers técnicos permanezcan cerca del código de forma sostenida en lugar de oscilar entre extremos [7]. Con independencia de qué postura resulte más convincente, el consenso de fondo se mantiene: nadie debería sentirse obligado a renunciar de forma permanente y unidireccional a su identidad técnica —ni a su identidad de liderazgo de personas— para tener una carrera larga, interesante y con opciones abiertas [2][7][8].

En última instancia, la existencia de una doble escala profesional sólida, con paridad real de compensación, decisión y visibilidad, es lo que permite que esta elección —o este péndulo— sea genuinamente libre. Sin ella, la ruta de gestión seguirá siendo, en la práctica, la única «promoción» disponible, y las organizaciones seguirán perdiendo a sus mejores ingenieros por el camino equivocado.