La carrera de staff engineer: contribución individual a escala
Lo he visto pasar una docena de veces. Tu mejor ingeniero senior toca techo. Lleva tres años siendo «senior», es la persona a la que todos acuden cuando hay que tomar una decisión técnica difícil, y no quiere gestionar personas. Así que lo asciendes a engineering manager, porque es el único «ascenso» que puedes ofrecerle.
Seis meses después está quemado. Has perdido a tu mejor IC por un rol que nunca quiso.
Es el modo de fallo más predecible —y más evitable— de las organizaciones de ingeniería. La solución es una carrera real de staff engineer: no un cambio de título, sino un rol genuinamente distinto, con otro alcance, otras expectativas y otro tipo de impacto.
Qué hace realmente un staff engineer
El mayor malentendido es pensar que un staff engineer es un senior que lleva más tiempo o escribe más código. No es así. El salto de senior a staff es un cambio en la unidad de entrega. Un ingeniero senior entrega funcionalidades. Un staff engineer entrega resultados que atraviesan equipos, sistemas o la organización entera.
El libro Staff Engineer de Will Larson identifica cuatro arquetipos. No todos los staff engineers encajan limpiamente en uno, pero los arquetipos ayudan a entender el abanico de formas que adopta el rol en la práctica.
El tech lead
Es el arquetipo más común. El staff engineer tipo tech lead está integrado en un equipo —o en un grupo de equipos— y marca la dirección técnica. Define la visión, toma las decisiones de arquitectura y se asegura de que el trabajo del equipo mantenga la coherencia. Suele ser quien decide «vamos a usar este patrón y no aquel», y luego escribe la primera implementación para demostrar que funciona.
La diferencia con un senior que hace funciones de tech lead: alcance y autoridad. Un tech lead de nivel staff es dueño de la dirección técnica de un dominio, no solo de una funcionalidad. Toma decisiones que condicionan cómo trabajan varios equipos.
El arquitecto
El arquitecto trabaja a nivel de toda la organización y define cómo encajan los sistemas entre sí. No responde del output de un equipo concreto: responde de la coherencia técnica de todo el producto o la plataforma. Piensa en quien diseña las fronteras entre servicios, el flujo de datos entre sistemas y las interfaces sobre las que construyen los equipos.
Este arquetipo es más habitual en organizaciones grandes, donde la coordinación entre equipos es genuinamente difícil. En una startup de 15 personas probablemente no necesitas un arquitecto dedicado. Con 80 ingenieros, casi seguro que sí.
El solucionador
Al solucionador se le asignan los problemas más duros: los que nadie más consigue resolver. Un problema de rendimiento enquistado desde hace meses. Una migración a la que todo el mundo tiene miedo. Una capacidad técnica nueva que nadie del equipo ha construido antes.
Los solucionadores rotan entre equipos y proyectos. Su trabajo no va de ownership continuado, sino de aplicar una habilidad técnica profunda a problemas concretos de alto impacto. Cuando el problema está resuelto y la solución transferida, pasan al siguiente.
La mano derecha
El arquetipo más infrecuente. La mano derecha amplía la capacidad de un líder senior: asiste a las reuniones a las que el VP no llega, desbloquea decisiones entre equipos, representa a ingeniería en las conversaciones con dirección. Exige a la vez una credibilidad técnica profunda y olfato organizativo.
Por qué importa esta carrera
Las empresas que no construyen una carrera de staff engineer pagan un impuesto oculto por tres vías.
Fuga de talento. Tus mejores ICs se marchan a empresas que sí la tienen. Un senior de Google o Stripe que ve «Staff», «Senior Staff» y «Principal» por encima sabe que puede crecer una década sin gestionar a nadie. Si en tu empresa el techo es «Senior Engineer», estás empujando a esa gente hacia la salida.
Managers a regañadientes. Cuando la gestión es el único camino hacia más sueldo y más título, acabará gestionando gente que no debería gestionar. Lo hace por el dinero y el reconocimiento, no porque se le dé bien ni lo disfrute. El resultado: un equipo con un manager mediocre y un gran IC perdido.
Deuda arquitectónica. Sin ICs senior cuyo trabajo explícito sea pensar a nivel de sistema, las decisiones de arquitectura se toman por comité, por inercia o directamente no se toman. El resultado son sistemas que crecen en direcciones contradictorias porque nadie respondía de la coherencia.
El rol cambia de forma a medida que la empresa escala
En una startup de 10 personas, el «staff engineer» es quien acumula más contexto. No hay carrera formal: alguien hace de ancla técnica, escribe código a diario y, de paso, da forma a todo el codebase.
En una empresa de 50, el rol se formaliza. Es dueño de un dominio: la capa de datos, el sistema de pagos, la infraestructura. Toma decisiones que afectan a varios equipos y dedica tiempo real a documentos de diseño y a alinear equipos.
A partir de 200 ingenieros, los staff engineers tienen charters por escrito, influyen en los roadmaps y pueden ejercer autoridad informal —la famosa línea de puntos— sobre ingenieros de otros equipos. La navegación organizativa que exige el rol es considerable.
El error que más veo en startups es copiar la versión de gran empresa. Un staff engineer de startup debería seguir escribiendo código el 50-60% de su tiempo, mientras impulsa las decisiones de arquitectura que mantienen el codebase viable a medida que el equipo crece.
Construir la carrera en paralelo a la de gestión
El modelo más simple es una escalera dual:
- Carrera técnica (IC): Engineer, Senior Engineer, Staff Engineer, Senior Staff Engineer, Principal Engineer
- Carrera de gestión: Engineering Manager, Senior Engineering Manager, Director of Engineering, VP of Engineering
Las decisiones de diseño críticas:
Paridad salarial. Un Staff Engineer debería cobrar lo mismo que un Engineering Manager; un Senior Staff, lo mismo que un Director. Si la carrera de gestión paga más en cada nivel, la carrera técnica es un premio de consolación y todo el mundo lo sabe.
Criterios de promoción distintos, no rebajados. Promocionar a staff exige evidencia de impacto técnico entre equipos: decisiones de arquitectura lideradas, problemas duros que nadie más pudo resolver, ingenieros que trabajan mejor gracias a esa persona.
Alcance, no antigüedad. La diferencia entre senior y staff no son cinco años más de experiencia: es operar a otro alcance. Un senior que escribe código excelente dentro de los límites de un equipo durante una década es un gran senior — no un staff engineer.
Línea de reporte. Los staff engineers suelen reportar a un director o a un VP. Su alcance supera al de un solo equipo, y quien los gestione debería evaluar su impacto entre equipos.
Evalúa impacto a nivel de sistema, no actividad
Un marco aproximado de lo que sí debería evaluarse en un staff engineer:
- Dirección técnica — ¿Los sistemas en los que influye tienen una arquitectura coherente? ¿Los equipos toman mejores decisiones técnicas gracias a su implicación?
- Multiplicación de fuerza — ¿El resto de ingenieros es más eficaz gracias a sus documentos de diseño, sus revisiones de código, su mentoría o sus herramientas?
- Ejecución en problemas duros — ¿Ha liderado personalmente la solución de los retos técnicos más difíciles de la organización?
- Comunicación — ¿Sabe escribir una propuesta técnica que un ejecutivo no técnico pueda seguir? ¿Sabe conducir una revisión de diseño que termine en alineación y no en discusión?
Lo que no debería evaluarse: número de PRs fusionadas, líneas de código escritas o asistencia a las ceremonias del sprint. Para alguien cuyo impacto principal es a nivel de sistema, esas métricas son peores que inútiles.
La parte honesta
No toda empresa necesita una carrera formal de staff engineer. Si tienes diez ingenieros y piensas seguir siendo pequeño, «Senior Engineer» como último peldaño es suficiente. Los problemas empiezan pasados los 20-30 ingenieros, cuando tus mejores ICs miran hacia arriba y ven un techo. Construye la carrera antes de que tu mejor IC acepte una oferta en otro sitio.
En Conectia nos especializamos en incorporar ingenieros senior y de nivel staff a equipos en crecimiento. Es gente que ya ha operado a nivel staff: ha sido dueña de la dirección técnica, ha liderado decisiones entre equipos y ha hecho mentoría de otros ingenieros. Cuando los integramos en el equipo de un cliente, aportan no solo ejecución, sino el pensamiento a nivel de sistema que hace escalar una organización de ingeniería.
¿Buscas ICs que operen con alcance de staff engineer desde el primer día? Habla con un CTO.
