Toda empresa mide cuántas features entregó un ingeniero. Pocas miden cuánto ese ingeniero aumentó la capacidad de entregar de quienes lo rodean. Esa segunda medición es donde aparece el Staff Engineer, y casi nunca entra en la review de desempeño.
Cualquier semana
- Una tarde revisando con dos seniors la arquitectura de un servicio nuevo, antes de tres semanas de retrabajo
- Una hora en un 1:1 con un senior trabado en un problema de diseño, destrabando dos sprints de trabajo
- Una mañana escribiendo una guía de decisión para un patrón recurrente, usada por ocho ingenieros en el semestre
- Media tarde conduciendo una revisión de incidente y convirtiendo el fallo en cambio de proceso
Ninguna de las cuatro entra como feature entregada. Las cuatro cambian lo que el equipo puede hacer la semana siguiente.
Estándares como trabajo principal
Sin estándar escrito, cada ingeniero decide solo cómo organizar el código, hacer log, estructurar tests y versionar APIs. La suma se vuelve inconsistencia que aparece en code review, onboarding y mantenimiento, y se va con cada contratación nueva.
Un estándar resuelto una vez devuelve tiempo en cada iteración siguiente: nadie repite la discusión de estructura y quien revisa mira el problema y no la forma. Steve McConnell trata prácticas de construcción consistentes en Code Complete, 2ª edición (Microsoft Press, 2004), junto con el costo de cada elección tomada en un contexto distinto.
Mentoría con profundidad
Un Staff Engineer le enseña a un senior a pesar un trade-off, a ver la consecuencia de una decisión en un sistema grande y a defender ese razonamiento en una reunión con producto y ventas.
Will Larson describe la influencia ampliada como parte del rol en Staff Engineer (O'Reilly, 2021), con la mentoría como uno de sus canales. Lo que el senior aprende en la conversación entra en las revisiones que él hace y en los artefactos que él escribe, y llega a más gente que la pareja.
Visión de sistema
Un equipo hundido en su propio backlog ve el backlog. Dos equipos construyen features que van a chocar y el choque aparece en la semana del lanzamiento.
Richard Cook explica en "How Complex Systems Fail" (1998) que la falla en un sistema complejo implica interacción entre componentes, y no el defecto de un componente aislado. Quien ve esas interacciones recorta retrabajo, corta incidentes de producción y mantiene las inversiones técnicas de equipos distintos apuntando al mismo lugar.
Qué cambia en 6 a 12 meses
- El equipo discute menos qué es código bueno, porque el estándar existe y se lee
- Los seniors ganan mayor alcance y se quedan más tiempo en el puesto
- Bajan los incidentes de producto por decisiones de diseño débiles
- El onboarding se acorta porque el sistema se entiende a la primera
Nada de esto aparece en un sprint. Aparece en trimestres, y una review de entregables no lo captura.
El costo de dejar el rol fuera
Retraballo que un estándar claro habría evitado. Rotación de seniors sin camino técnico. Un incidente que una mejor decisión habría prevenido. Suma los tres de un trimestre y compáralos con el costo del sueldo, en tiempo completo o bajo demanda.
