Staff Engineer: como geri-los sem micromanagement

Gerir um Staff Engineer é um exercício de equilíbrio. Se estiveres demasiado presente, bloqueias alguém que precisa de espaço para ter impacto em grande escala. Se não estiveres suficientemente presente, perdes a visibilidade sobre o que acontece e não podes ajudá-lo a navegar nos aspetos organizacionais e políticos que fazem parte do seu papel.

A maioria dos EMs engana-se num sentido ou noutro. Aqui explicamos como encontrar o equilíbrio certo.

Compreender o que precisam

Um Staff Engineer não é um Senior Engineer com mais experiência. É um nível diferente com um âmbito distinto. O seu impacto já não é medido em PRs ou funcionalidades – é medido na qualidade técnica das decisões de uma equipa inteira, na capacidade de fazer avançar temas transversais e na influência arquitetónica a 6-18 meses.

Este âmbito implica necessidades específicas. Precisam de autonomia para explorar e de tempo para pensar sem estarem no fluxo constante do delivery. Precisam de visibilidade sobre a estratégia e as prioridades da organização para que o seu trabalho esteja alinhado. E precisam de ser reconhecidos pelo seu impacto real – não pela sua atividade superficial.

Este último ponto é crucial. Um Staff Engineer que submete poucos commits esta semana porque está a refletir sobre a arquitetura dos próximos 6 meses não está a "trabalhar mal". Um manager que mede o desempenho apenas pela atividade visível cria um ambiente onde os Staff Engineers passam o tempo a justificar o seu valor em vez de o criarem.

A armadilha do micromanagement

O micromanagement de um Staff Engineer adota muitas vezes formas subtis. Não é "mostra-me o teu código antes de o submeteres". É "porque não estiveste naquela reunião?", "avançaste no tema que falámos?", "envia-me um resumo do que estás a fazer esta semana".

Estes pedidos parecem razoáveis; um manager tem o direito de saber o que se passa na sua equipa. Mas para um Staff Engineer significam outra coisa: não confias no meu julgamento sobre como usar o meu tempo e obrigas-me a prestar contas com uma granularidade que não é a correta.

A consequência a longo prazo: os melhores Staff Engineers saem. Não imediatamente; tentam adaptar-se, oferecendo os relatórios esperados enquanto fazem o seu trabalho. Mas com o tempo, ao tornar-se o ambiente demasiado restritivo para o seu modo de funcionamento, procuram outra coisa.

Manter-se informado sem bloquear

A interface correta com um Staff Engineer não é um relatório semanal, mas um 1:1 de qualidade, talvez menos frequente, mas denso em conteúdo. O objetivo não é "o que fizeste esta semana?", mas "onde estás bloqueado?", "o que posso desbloquear eu a nível organizacional?", "como posso ajudar-te a ter mais impacto?".

Não precisas de saber tudo o que fazem. Precisas de saber: o seu trabalho está alinhado com as prioridades estratégicas? Há bloqueios organizacionais que só tu podes resolver? Sentem-se reconhecidos pelo seu impacto real?

Estas três perguntas, colocadas regularmente num espaço de confiança, dão-te tudo o que precisas sem entrar nos detalhes da execução diária.

O impacto e a visibilidade

Um problema recorrente para os Staff Engineers: o seu trabalho é difícil de tornar visível. Um Senior Engineer submete PRs; isso é mensurável. Um Staff Engineer passa duas semanas a construir um consenso em torno de uma decisão de arquitetura; isso não aparece nas métricas habituais.

O teu papel como manager é amplificar a visibilidade desse impacto. Não no lugar deles, mas criando os espaços onde possam partilhá-lo: revisões de design, tech talks, conversas com outras equipas. E mencionando explicitamente, nas revisões de desempenho e nas conversas com a tua própria direção, o que essa pessoa tornou possível.

É uma forma de gestão invisível mas essencial. O Staff Engineer que sabe que o seu manager compreende e valoriza o seu tipo de impacto está infinitamente mais alinhado e empenhado do que aquele que deve justificar constantemente como emprega o seu tempo.

No Moston, podes anotar estas contribuições não quantificáveis (decisões influenciadas, temas desbloqueados, alinhamentos alcançados) e tê-las à mão quando chegar o momento de falar delas. A memória managerial não deve esquecer o que não se mede facilmente.