- ¿Cuándo se necesita un Staff Engineer y en qué se diferencia de un Engineering Manager?
- Muchos ingenieros y managers sienten confusión entre ambos roles
- Están reflexionando sobre esto EM que quieren evitar la gestión de personas y enfocarse en la tecnología, así como Senior Engineers que quieren asumir liderazgo técnico
- Es importante entender con claridad las responsabilidades y el alcance de cada rol
Preguntas que me han hecho
- EM: "Quiero enfocarme en la tecnología en lugar de la gestión de personas. ¿Sería adecuado para mí un rol de Staff Engineer?"
- Senior EM: "Tengo demasiadas tareas de gestión. ¿Debería contratar a un Staff Engineer para delegarle el trabajo técnico?"
- Staff Engineer: "En la práctica estoy cumpliendo el rol de manager del equipo y me gusta. ¿Debería pasarme a EM?"
- Senior Engineer: "¿Cuáles son las responsabilidades de un Staff Engineer? Parece como un desarrollador retirado."
- New Staff Engineer: "¿Qué significa una ‘relación de reporte punteada’? Tengo un line manager, ¿también debo prestarle atención a otro manager?"
¿Cuándo hace falta un Staff Engineer?
- Los ingenieros crean y mantienen tecnología, pero la tecnología no existe por sí sola
- Es una solución a un problema, y el problema queda definido como producto
- El producto brinda un servicio al usuario final o al cliente interno
- El producto es un medio para resolver problemas de los usuarios, por ejemplo:
- una app que mide la distancia recorrida al correr y la comparte con otros usuarios
- un sitio web de reservas de hoteles
- una plataforma de infraestructura usada por otros equipos
- un sistema de reporte de asistencia
- Los ingenieros que desarrollan estos productos por lo general forman parte de equipos liderados por un Engineering Manager (EM)
- El EM tiene accountability sobre los miembros del equipo (ingenieros) y sobre los artifacts técnicos que producen
- Pero en los siguientes casos puede ser difícil asumir toda esa responsabilidad por completo:
- cuando el equipo es muy grande
- cuando la tecnología es demasiado compleja
- o cuando se dan ambas cosas al mismo tiempo
- En ese caso, el tiempo y la energía (bandwidth) del EM se quedan cortos, y le resulta difícil cumplir a la perfección con su responsabilidad tanto sobre las personas como sobre la tecnología
- Si al EM le cuesta cumplir con su responsabilidad, puede considerar dos estrategias de delegación:
- Delegar trabajo administrativo:
- optimizando procesos y herramientas de HR
- o contratando un asistente para reducir la carga de gestión de personas
- puede parecer excesivo tener un asistente dedicado a un solo equipo, pero también hay casos en que varios equipos comparten uno
- también es posible reemplazar parte del trabajo mecánico con herramientas de AI para coordinar agendas, responder preguntas de gestión o recopilar feedback
- un excelente sistema de HR puede reducir radicalmente la carga de gestión
- Delegar trabajo técnico:
- se puede contratar a un Staff Engineer para compartir la carga técnica
- Sin embargo, un asistente o la AI no pueden reemplazar el trabajo centrado en personas que forma parte de las responsabilidades clave del EM, como:
- construir un buen equipo
- mentoría
- evaluaciones de desempeño
- contratación, entre otros
- Por otro lado, transferirle todo el trabajo técnico a un Staff Engineer se considera un anti-pattern
- el Staff Engineer no debe convertirse en el traductor técnico del EM
- el EM también debe mantener un cierto nivel de responsabilidad técnica
- Por eso, es indispensable que un Engineering Manager conserve criterio técnico, y
Situaciones en las que un Staff Engineer resulta útil
- Un Staff Engineer puede aportar valor real a la organización en casos como estos:
- cuando existe una carga técnica que el EM no puede absorber fácilmente
- por ejemplo, si hay mucha tecnología legacy que requiere mantenimiento continuo
- si existen soluciones complejas que atraviesan varios equipos o requieren conocimiento técnico profundo
- también hay casos en los que el propio EM no es técnico, aunque es un patrón poco recomendable
- cuando se le puede asignar accountability clara sobre una parte del trabajo técnico
- cuando el alcance de la tecnología supera el límite de lo que un solo EM puede gestionar
- El Staff Engineer debe tener responsabilidad sobre la tecnología, no sobre las personas
- no incluye tareas como gestionar miembros del equipo o hacer evaluaciones de desempeño
- Como la situación depende de la organización, el producto y las personas, no se puede aplicar una regla universal a todos los casos
- Nota: responsibility y accountability son conceptos sutilmente distintos, y
- Un Staff Engineer debería tener las siguientes características:
- comprensión profunda de la tecnología y alta alfabetización técnica
- accountability técnica clara
- como no tiene responsabilidad de gestión de personas, dispone de más tiempo para invertir en tecnología
- Aun así, el EM tampoco debe desligarse por completo de la responsabilidad técnica
- sigue necesitando involucrarse en cierta medida y comprender la tecnología
- El valor real del Staff Engineer aparece en el liderazgo técnico a través de varios equipos
- Tener un Staff Engineer dentro de un solo equipo puede generar problemas como:
- superposición de responsabilidades técnicas
- confusión de roles y, al final, la ineficiencia de dividir un solo rol en varios títulos
Casos excepcionales en los que puede operar a nivel de equipo
- En general, el Staff Engineer se enfoca en liderazgo técnico entre equipos, pero en ciertas situaciones también puede actuar temporalmente a nivel de equipo:
- cuando un EM nuevo necesita entender rápido un stack tecnológico legacy
- cuando un Staff Engineer nuevo hace onboarding empezando por un alcance pequeño
- cuando hay tanta deuda técnica que los indicadores de salud del sistema se han deteriorado
- cuando la complejidad técnica dificulta demasiado el mantenimiento
- En esos casos, un Staff Engineer a nivel de equipo debería ser una configuración temporal
-
El verdadero valor de un Staff Engineer
- cumple un rol de glue entre equipos
- trabaja junto con otros ingenieros en el terreno y transmite su voz hacia la dirección
- normalmente, los ingenieros hablan con más honestidad con otros ingenieros colegas que con alguien que controla su salario, sus vacaciones o su evaluación
- ejerce un liderazgo técnico profundo
- a diferencia del EM, tiene menos reuniones, 1:1 y trabajo de gestión, por lo que puede concentrarse en desarrollar su capacidad de ingeniería y su profundidad técnica
-
El mayor riesgo: Ivory Tower Architect
- convertirse en un teórico abstracto alejado de los problemas reales o del código
- este problema se trata con más detalle en Ivory Tower Architect
El rol del Staff Engineer en sistemas que abarcan varios equipos
- El Staff Engineer es especialmente adecuado para un liderazgo técnico que cubra todo el sistema, no solo un equipo
- En el ensayo de Will Larson se presentan 4 arquetipos de Staff Engineer:
- Tech Lead: líder técnico dentro del equipo
- Architect: diseñador de arquitectura de sistemas
- Solver: solucionador de problemas técnicos complejos
- Right Hand: mano derecha de quien lidera la organización técnica
- Llamar Staff Engineer al Tech Lead dentro de un equipo, como aparece en el diagrama, es algo forzado
- el verdadero valor del Staff Engineer surge de la coordinación entre equipos y de la integración técnica
- consulta Introduction to Staff Engineering
- Staff Engineer no es solo un cargo, sino una postura basada en liderazgo técnico
- este rol se encarga de la coordinación técnica y de resolver problemas a través de distintos equipos y productos
- ejerce influencia sin autoridad formal sobre personas o productos, y guía la estrategia y la dirección técnica de toda la organización
- a diferencia del engineering manager, genera valor más por su especialización técnica profunda y su colaboración entre organizaciones que por la gestión
- también se involucra directamente en el trabajo práctico y cumple un rol de mentor para ayudar al crecimiento de otros ingenieros
- En organizaciones reales, los sistemas técnicos no se limitan a un solo equipo, sino que están distribuidos entre varios equipos o fuertemente conectados entre sí
- en esos casos, hace falta un Staff Engineer dedicado que se responsabilice del sistema completo
- sin importar qué parte lleve cada equipo, se necesita una visión integral del sistema y sentido de responsabilidad sobre él
El Staff Engineer no pasa solo por la tecnología, sino también por personas y producto
- Punto clave: la tecnología no habla ni escucha a la otra parte por sí sola
- la tecnología no puede existir aisladamente; adquiere sentido a través de las personas (ingenieros) y del producto (el problema)
- Para que un Staff Engineer genere valor de verdad, necesariamente debe pasar por lo siguiente:
- colaborar con los ingenieros
- coordinarse con el equipo de producto
- Por eso, el Staff Engineer tiene líneas de reporte punteadas (dotted reporting lines)
- es un vínculo no formal pero importante para la colaboración entre áreas y los compromisos organizacionales
- Algunas personas observadoras preguntan por qué en el diagrama hay flechas que van desde Staff hacia posiciones más abajo
- razón 1: el buen liderazgo se basa en colaboración, no en autoridad
- el Staff Engineer transmite a los EM o PM de equipo solicitudes para mejorar la tecnología de manera colaborativa
- no deben ser órdenes unilaterales, sino una forma de trabajo conjunta que considere a los ingenieros y el roadmap de producto
- razón 2: como Staff Engineer es un IC (Individual Contributor), no tiene subordinados directos formales
- si existe un canal regular de conversación con EM/PM, no debería servir solo para reportar, sino para hablar en doble vía sobre:
- el estado actual (status quo) de la tecnología
- la visión (vision) tecnológica para resolver problemas de producto
- la estrategia (strategy) técnica de la organización para lograrlo
- idealmente, estas tres cosas deberían discutirse en una conversación bidireccional
- Para ordenar esta estructura de reporte entrelazada y ayudar a alinear tecnología y producto entre equipos,
- un documento de estrategia de toda la empresa (strategy document) resulta muy útil
- lo básico sobre esto puede verse en Strategy basics
-
Diagnóstico (Diagnosis)
- después de investigar el espacio del problema, se identifican los asuntos clave que hay que resolver y por qué
- explica por qué hace falta una estrategia
- identifica síntomas y causas raíz, y analiza por qué son importantes ahora
- en una mala estrategia, esta parte suele omitirse o limitarse a describir el estado actual
- un buen diagnóstico requiere investigación objetiva y una actitud casi detectivesca
-
Política orientadora (Guiding Policy)
- es un enfoque de alto nivel para resolver el problema identificado
- se enfoca en la solución y alinea a toda la organización
- da dirección sin necesidad de replantear cada detalle táctico
- una mala estrategia carece de conexión entre esta política (HOW) y el diagnóstico (WHY)
-
Acciones coherentes (Coherent Actions)
- es el plan de acción concreto para resolver, según la política, los problemas detectados en el diagnóstico
- deja claro quién (WHO), qué (WHAT) y cuándo (WHEN)
- la clave es la coherencia, para que distintos equipos avancen en armonía hacia la misma dirección
Otra forma de reducir el alcance técnico a un solo equipo: el modelo Kebab vs Cake
- También se puede diseñar la estructura organizacional para que la tecnología no abarque varios equipos y pueda resolverse dentro de un solo equipo
- Una forma representativa de hacerlo es el modelo Kebab vs Cake
- un enfoque estructural que organiza equipos según el recorrido del usuario para reducir el alcance de la responsabilidad técnica
- para más detalle sobre este modelo, consulta Kebab vs Cake organization
-
Arquitectura Kebab
- los equipos se organizan alrededor de las capacidades que entregan
- el recorrido del usuario atraviesa los artifacts de varios equipos
- ventaja: autonomía y acoplamiento débil
- desventaja: riesgo de handoffs
-
Arquitectura Cake
- los equipos se organizan alrededor del recorrido del usuario
- la carga cognitiva se gestiona mediante capas de abstracción
- ventaja: ownership end-to-end y menos handoffs
- desventaja: riesgo de mayor carga cognitiva
- El Staff Engineer no es un simple rol técnico, sino un owner responsable del sistema completo, y debe contar con estas 3 cosas:
- Knowledge:
- comprensión profunda del stack tecnológico y del problema de producto
- debe poder explicarlo y, si hace falta, implementarlo directamente
- Mandate:
- una posición desde la cual pueda opinar sobre cómo debe evolucionar y mantenerse la tecnología
- Responsibility:
- responsabilidad sobre la salud del sistema (incidentes, deuda técnica, documentación, fragmentación técnica, etc.)
- El Staff Engineer no es un rol puramente técnico; para liderar técnicamente a la organización, las soft skills son esenciales
- se requieren comunicación con influencia, colaboración, liderazgo, etc.
- Sin embargo, si se inclina demasiado hacia las soft skills, pueden surgir problemas como:
- presentar ideales desconectados de la realidad sin participar en la codificación o en la resolución real de problemas
- el riesgo de degradarse en un Ivory Tower Architect
Cierre
- No todas las organizaciones necesitan un Staff Engineer. En casos como los siguientes, puede no hacer falta:
- cuando el EM tiene suficiente capacidad técnica para liderar directamente la tecnología del equipo
- cuando el stack tecnológico está saludable y es fácil de mantener
- cuando la tecnología queda contenida dentro de un solo equipo y casi no hay dependencias entre equipos (el modelo organizacional Cake es un ejemplo)
- cuando la organización es lo bastante madura como para operar bien el sistema completo sin un owner específico
- En cambio, si la organización sí tiene Staff Engineers, debería dejar en claro lo siguiente:
- definir con claridad el technical ownership
- y otorgar al Staff Engineer accountability clara sobre esa responsabilidad
- Resumen clave:
- hay que evitar al Ivory Tower Architect (no es realista)
- dividir un rol en varios títulos es ineficiente
- un EM no técnico también es ineficiente
- Por último, este texto no es una ley absoluta, sino un ensayo de referencia
- como cada organización, tecnología, producto, operación y persona son distintos, es importante juzgar con flexibilidad según el contexto
- evita la imitación ciega (cargo culting) → ver artículo relacionado
4 comentarios
Me da la impresión de que son los brazos derechos del CTO
Ingeniero staff: la persona a la que vas a molestar cuando ya intentaste de todo y no funcionó.
Jajaja, totalmente identificable
No está muy relacionado con el contenido del artículo, pero como yo justo había estado reflexionando sobre la diferencia entre accountability y responsibility, el siguiente enlace me resultó de gran ayuda.
https://blog.alexewerlof.com/p/accountable-vs-responsible