O que é um Staff Engineer — e como parei de fazer para começar a multiplicar
O título mudou, mas a mudança maior foi no modelo mental. Staff engineering não é ser um senior melhor — é uma forma diferente de criar impacto.
Quando eu era desenvolvedor júnior, meu trabalho era fazer tarefas. Quando fui ficando mais sênior, meu trabalho foi fazer tarefas mais complexas. Em algum ponto, percebi que o caminho de crescimento não era continuar fazendo coisas mais e mais complexas — era ajudar outros a fazer coisas complexas.
Essa percepção demorou mais do que deveria para se solidificar.
Staff engineer é um título que significa coisas diferentes em lugares diferentes. Em alguns lugares é um senior glorificado. Em outros é essencialmente um tech lead sem gerência. No contexto onde trabalho, staff engineer significa algo específico: você tem escopo além do seu time imediato, e seu impacto é medido pelo impacto de outros engenheiros, não pelo código que você escreve diretamente.
Isso muda tudo sobre como você passa o seu tempo.
A transição mais difícil foi parar de ter vontade de resolver problemas eu mesmo. Quando um engenheiro no time traz um problema técnico complexo, o instinto é pensar na solução e compartilhar. Mas se eu faço isso, o que acontece? O problema daquela vez é resolvido. O engenheiro aprende a resposta, mas não aprende o processo de chegar lá.
Staff engineering em plataforma é sobre multiplicar capacidade. Cada hora que eu invisto em ajudar um engenheiro a resolver um problema sozinho — fazendo perguntas em vez de dar respostas, revisando o raciocínio em vez de fornecer o correto, pedindo que explique a abordagem antes de sugerir a minha — essa hora retorna mais do que se eu tivesse simplesmente resolvido.
Golden paths são o exemplo mais concreto disso. Um golden path é uma forma prescrita de fazer algo — deploy, autenticação, observabilidade. Em vez de cada time descobrir como fazer deploy de forma segura, ou como instrumentar um serviço corretamente, você constrói o caminho de menor resistência que já segue as práticas corretas.
Quando o golden path funciona bem, você não precisa revisar cada PR para verificar se o time seguiu a prática correta. A prática correta é o caminho mais fácil de seguir. Você não precisa fazer reunião explicando como fazer deploy. O deploy funciona da forma certa por default.
Isso é multiplicação: um investimento de tempo que retorna em centenas de PRs que você não vai revisar.
A parte invisível do trabalho de staff aumentou muito. Code review, sim — mas também: ler documentos de design de outros times e dar feedback antes da implementação começar. Facilitar conversas onde dois times têm visões divergentes sobre uma decisão técnica. Identificar padrões de problema que aparecem em múltiplos times e propor solução sistêmica em vez de ponto a ponto. Escrever análise técnica que um gerente pode usar para tomar decisão de investimento.
Nenhum desses trabalhos aparece no seu commit log.
O que me ajudou a fazer essa transição foi mudar a pergunta que eu fazia sobre o meu tempo. Em vez de "qual é a coisa mais importante que eu posso construir hoje?", comecei a perguntar "o que eu posso fazer hoje que vai fazer outros engenheiros mais eficazes pela próxima semana?"
Às vezes a resposta é escrever uma RFC que define um padrão. Às vezes é passar uma hora com um engenheiro desbloqueando um problema de design. Às vezes é criar documentação que ninguém vai agradecer mas todo mundo vai usar.
O que ninguém conta sobre staff engineering: você vai ter dias onde não escreveu uma linha de código e vai se perguntar se foi útil. Você vai precisar de novos indicadores de que está gerando valor — porque o código não é mais o indicador principal.
Para mim, os melhores indicadores são: algum time resolveu um problema sozinho que antes precisaria de mim? Algum engineer tomou uma boa decisão de design sem me consultar? Algum sistema está funcionando melhor porque a plataforma que construí facilitou fazer a coisa certa?
Quando a resposta for sim, foi um bom dia.
Essa semana: pensa nos últimos problemas técnicos que você resolveu. Algum deles vai ser resolvido de novo, por outra pessoa, daqui a seis meses? Se sim, o que você poderia fazer hoje para que aquela pessoa resolvesse mais rápido, melhor, ou sem precisar de ajuda? Documentação, automação, ou simplesmente um comentário melhor no código — qualquer um desses é investimento em multiplicação.