Un CTO en una reunión de roadmap. Otro revisando la arquitectura de un microsservicio. Un tercero respondiendo preguntas técnicas de ingenieros en Slack a las 11 de la noche.
En los tres casos, el CTO está haciendo trabajo de Staff Engineer. No es culpa de estos CTOs, están llenando un vacío real. Pero el costo para la empresa es alto, y muchas veces invisible.
Lo que hace un CTO (o debería hacer)
El papel del CTO es estratégico y externo. Los buenos CTOs pasan la mayor parte del tiempo en:
- Alineación entre estrategia de negocio y estrategia técnica
- Construcción y evolución de la organización de ingeniería, contratación, estructura, cultura
- Relacionamiento con inversores, socios y clientes a nivel técnico
- Toma de decisiones sobre tecnología que impactan la competitividad a largo plazo
- Representación de la ingeniería en el board y en las decisiones de producto
El CTO mira hacia afuera y hacia el futuro. Cuando un CTO está sumergido en decisiones de implementación, el futuro técnico de la empresa queda sin dueño.
Lo que hace un Staff Engineer (o debería hacer)
El Staff Engineer opera internamente, con foco técnico profundo. Su trabajo típico incluye:
- Visión técnica de largo plazo de la arquitectura y de los sistemas
- Definición de estándares, guías y decisiones que múltiples equipos siguen
- Liderazgo de proyectos técnicos de alto impacto y alta complejidad
- Mentoría de ingenieros séniores y creación de un ambiente de crecimiento técnico
- Puente entre las necesidades técnicas de los equipos y la dirección estratégica de la empresa
El Staff Engineer mira hacia adentro y hacia el presente. Garantiza que lo que se está construyendo hoy se esté construyendo bien.
Por qué los roles se confunden
La confusión ocurre por dos motivos principales:
1. La empresa creció sin llenar el rol. El CTO fundador era el Staff Engineer original de la empresa. Con el crecimiento, el rol de CTO evolucionó, pero nadie asumió el trabajo técnico profundo. El CTO lo absorbe porque no tiene alternativa.
2. El CTO prefiere el trabajo técnico. Muchos CTOs llegaron al cargo desde trayectorias técnicas. La parte estratégica y organizacional es menos familiar, a veces menos cómoda. Es más fácil, y más satisfactorio a corto plazo, resolver un problema de arquitectura que construir un proceso de reclutamiento técnico.
En ambos casos, el resultado es el mismo: el trabajo estratégico del CTO queda comprimido, y el trabajo de Staff Engineering queda siendo hecho por alguien cuyo costo de oportunidad es demasiado alto para estar en esa función.
El costo real de la superposición
Cuando el CTO está en modo Staff Engineer, algunas cosas dejan de ocurrir:
- La estrategia técnica de largo plazo queda sin nadie a cargo
- La organización de ingeniería queda sin desarrollo intencional
- Nadie aporta input adecuado en las decisiones de negocio con implicación técnica
- El CTO se vuelve reactivo, apagando incendios en vez de prevenirlos
- Oportunidades de producto y mercado se escapan porque la tecnología no acompaña
Al mismo tiempo, el trabajo de Staff Engineering queda siendo hecho por alguien que no tiene el tiempo, el foco ni el mandato correcto para hacerlo bien.
Cómo separar los roles en la práctica
La separación no va de jerarquía, va de claridad de alcance y responsabilidad.
El CTO define hacia dónde necesita ir la organización técnica. El Staff Engineer define cómo llegar allí y garantiza que los equipos están en el camino correcto. Son socios, no rivales.
En empresas en etapa inicial, el CTO puede acumular ambos roles por algún tiempo, pero con conciencia de que lo está haciendo y con un plan claro de cuándo y cómo separarlos. En empresas con más de 15 a 20 ingenieros, la superposición empieza a tener un costo mensurable.
Cuando el Staff Engineer viene de afuera
Para empresas que no tienen un Staff Engineer interno o que necesitan perspectiva externa, traer un Staff Engineer bajo demanda es una forma eficiente de resolver el problema sin los costos y riesgos de una contratación full-time.
Un Staff Engineer consultor entra con un alcance definido (arquitectura de un nuevo producto, elevación técnica de un equipo, diagnóstico de un sistema legado) y libera al CTO para volver al trabajo que solo él puede hacer.
La pregunta que muchos CTOs se hacen después de esa experiencia es simple: "¿Por qué tardé tanto en hacerlo?"
