- Quando um Staff Engineer é necessário e qual é a diferença em relação ao Engineering Manager?
- Muitos engenheiros e gerentes ficam confusos com esses dois papéis
- EMs que querem evitar gestão de pessoas e focar em tecnologia, ou Senior Engineers que querem assumir liderança técnica, costumam ter essa dúvida
- É importante entender com clareza as responsabilidades e o escopo de cada função
Perguntas que já me fizeram
- EM: "Quero focar em tecnologia em vez de gestão de pessoas. Staff Engineer seria uma boa opção para mim?"
- Senior EM: "Tenho trabalho de gestão demais. Devo contratar um Staff Engineer para assumir a parte técnica?"
- Staff Engineer: "Na prática estou fazendo o papel de gerente de equipe e gosto disso. Devo migrar para EM?"
- Senior Engineer: "Quais são as responsabilidades de um Staff Engineer? Parece um desenvolvedor aposentado."
- New Staff Engineer: "O que significa 'dotted reporting line'? Já tenho um gestor direto, então preciso me preocupar com outro gerente?"
Quando um Staff Engineer é necessário?
- Engenheiros constroem e mantêm tecnologia, mas tecnologia não existe sozinha
- Ela é uma solução para um problema, e o problema é definido como produto
- O produto presta um serviço para usuários finais ou clientes internos
- O produto é um meio para resolver problemas dos usuários, por exemplo:
- um app que mede a distância de corrida e compartilha com outros usuários
- um site de reserva de hotéis
- uma plataforma de infraestrutura usada por outras equipes
- um sistema de registro de ponto
- Os engenheiros que desenvolvem esses produtos normalmente fazem parte de equipes lideradas por um Engineering Manager (EM)
- O EM tem accountability sobre os membros da equipe (engenheiros) e sobre os artefatos técnicos (artifacts) que eles produzem
- Mas, nos casos abaixo, pode ser difícil cumprir toda essa responsabilidade plenamente:
- quando a equipe é muito grande
- quando a tecnologia é complexa demais
- ou quando as duas coisas acontecem ao mesmo tempo
- Nesses casos, o tempo e a energia (bandwidth) do EM ficam insuficientes, e torna-se difícil responder perfeitamente tanto por pessoas quanto por tecnologia
- Se o EM tem dificuldade para dar conta de tudo, é possível considerar duas estratégias de delegação:
- Delegar trabalho administrativo:
- otimizar processos e ferramentas de RH
- ou contratar um assistente para reduzir a carga da gestão de pessoas
- pode parecer exagero ter um assistente dedicado para uma única equipe, mas há casos em que várias equipes compartilham um mesmo assistente
- também é possível usar ferramentas de IA para substituir parte de tarefas mecânicas, como agendamento, respostas a dúvidas de gestão e coleta de feedback
- bons sistemas de RH reduzem drasticamente a carga gerencial
- Delegar trabalho técnico:
- é possível contratar um Staff Engineer para dividir a carga técnica
- Porém, assistentes ou IA não podem substituir o núcleo das responsabilidades do EM, que são atividades centradas em pessoas, como:
- formar uma boa equipe
- mentoria
- avaliação de desempenho
- contratação, entre outras
- Por outro lado, passar todo o trabalho técnico para o Staff Engineer é considerado um anti-pattern
- o Staff Engineer não deve funcionar como o tradutor técnico do EM
- o EM também precisa manter um certo nível de responsabilidade técnica
- Portanto, é essencial que o Engineering Manager mantenha senso técnico, e para maneiras de preservar essa capacidade, veja How can engineer leaders stay technical?
Situações em que um Staff Engineer é útil
- Um Staff Engineer pode gerar valor real para a organização em casos como:
- quando existe uma carga técnica difícil demais para o EM absorver
- por exemplo: muito legado exigindo manutenção contínua
- quando existem soluções complexas que atravessam várias equipes ou exigem conhecimento técnico profundo
- também existem casos em que o próprio EM não é técnico, embora isso não seja uma boa prática
- quando é possível atribuir accountability clara sobre parte do trabalho técnico
- quando o escopo da tecnologia ultrapassa o limite que um único EM consegue gerenciar
- O Staff Engineer deve ser responsável pela tecnologia, não por pessoas
- isso não inclui gestão de membros da equipe ou avaliações de desempenho
- Como organização, produto e pessoas variam, não existe uma aplicação universal para todos os contextos
- Observação: responsibility e accountability são conceitos parecidos, mas diferentes, e para detalhes veja Accountable vs Responsible
- Um Staff Engineer deve ter as seguintes características:
- entendimento profundo de tecnologia e alta fluência técnica
- accountability técnica clara
- por não ter responsabilidade de gestão de pessoas, dispõe de mais tempo para investir em tecnologia
- Em contrapartida, o EM também não deve se afastar totalmente da responsabilidade técnica
- ele ainda precisa participar e compreender a tecnologia em alguma medida
- O verdadeiro valor do Staff Engineer surge da liderança técnica em múltiplas equipes
- Colocar um Staff Engineer dentro de apenas uma equipe pode gerar problemas como:
- sobreposição de responsabilidade técnica
- confusão de papéis e, no fim, a ineficiência de dividir uma mesma função em vários títulos
Casos excepcionais em que ele pode atuar no nível de equipe
- Em geral, o Staff Engineer foca em liderança técnica entre equipes, mas nas situações abaixo ele pode atuar temporariamente no nível de equipe:
- quando um novo EM precisa entender rapidamente uma stack legada
- quando um novo Staff Engineer está começando o onboarding por um escopo menor
- quando há dívida técnica demais e os indicadores de saúde do sistema se deterioraram
- quando a complexidade técnica torna a manutenção difícil
- Nesses casos, um Staff Engineer alocado a uma equipe deve ser uma configuração temporária
-
O verdadeiro valor do Staff Engineer
- atuar como conector entre equipes (glue)
- trabalhar lado a lado no campo com outros engenheiros e levar a voz deles para a liderança
- normalmente os engenheiros conversam com mais sinceridade com colegas engenheiros do que com quem controla salário, férias e avaliação
- exercer liderança técnica profunda
- diferente do EM, ele tem menos reuniões, 1:1s e tarefas gerenciais, então pode focar no desenvolvimento da capacidade de engenharia e da profundidade técnica
-
O maior risco: o Ivory Tower Architect
- tornar-se um teórico abstrato distante dos problemas reais e do código
- esse problema é discutido em detalhes em Ivory Tower Architect
O papel do Staff Engineer em sistemas que abrangem várias equipes
- O Staff Engineer é mais adequado para exercer liderança técnica sobre o sistema como um todo, e não apenas uma equipe
- No ensaio de Will Larson, são apresentados 4 arquétipos de Staff Engineer:
- Tech Lead: líder técnico dentro da equipe
- Architect: projetista da arquitetura do sistema
- Solver: solucionador de problemas técnicos complexos
- Right Hand: braço direito de líderes da organização técnica
- É forçado chamar o Tech Lead de uma equipe de Staff Engineer apenas porque ele aparece assim em um diagrama
- o valor de um Staff Engineer de verdade vem da coordenação entre equipes e da integração técnica
- veja Introduction to Staff Engineering
- Staff Engineer não é apenas um cargo, mas uma postura baseada em liderança técnica
- esse papel envolve coordenação técnica e resolução de problemas em diferentes equipes e produtos
- exerce influência mesmo sem autoridade formal sobre pessoas ou produto, guiando a estratégia e a direção técnica da organização
- diferente do Engineering Manager, gera valor mais pela profundidade técnica e pela colaboração entre áreas do que pela gestão
- também se envolve no trabalho prático e ajuda no crescimento de outros engenheiros por meio de mentoria
- Nas organizações reais, os sistemas técnicos não ficam restritos a uma única equipe; eles podem estar distribuídos entre várias equipes ou fortemente conectados entre si
- nesses casos, é necessário um Staff Engineer dedicado responsável pelo sistema como um todo
- independentemente de qual equipe cuida de cada parte, é preciso ter visão sistêmica e senso de responsabilidade pelo sistema inteiro
O Staff Engineer precisa passar não só pela tecnologia, mas também por pessoas e produto
- Ponto principal: a tecnologia não fala nem escuta o outro lado sozinha
- tecnologia não pode existir isoladamente; ela ganha sentido por meio das pessoas (engenheiros) e do produto (problema)
- Para gerar valor de verdade, o Staff Engineer precisa necessariamente passar por:
- colaboração com engenheiros
- alinhamento com a equipe de produto
- Por isso, o Staff Engineer costuma ter uma estrutura de reporte em linha pontilhada (dotted reporting lines)
- é um vínculo informal, mas importante, para conectar colaboração e compromissos entre áreas
- Algumas pessoas mais observadoras perguntam por que, no diagrama, há setas do Staff apontando para posições inferiores
- motivo 1: boa liderança se baseia em colaboração, não em autoridade
- o Staff Engineer leva a EMs ou PMs de equipes pedidos de melhorias técnicas de forma colaborativa
- não deve ser uma imposição unilateral, e sim uma forma de cooperação que considera os engenheiros e o roadmap do produto
- motivo 2: o Staff Engineer é um IC (Individual Contributor), então não tem subordinados diretos formais
- se houver canais regulares de conversa com EMs/PMs, o ideal é que não sejam apenas para reporte, mas para discutir em mão dupla:
- o estado atual da tecnologia (status quo)
- a visão técnica (vision) para resolver problemas de produto
- a estratégia técnica organizacional (strategy) necessária para isso
- Para organizar essa estrutura de reporte mais entrelaçada e ajudar no alinhamento técnico e de produto entre equipes,
- um documento de estratégia organizacional (strategy document) pode ser muito útil
- uma boa base para isso está em Strategy basics
-
Diagnóstico (Diagnosis)
- após investigar o espaço do problema, identifica-se qual é a questão central a resolver e por quê
- isso explica por que a estratégia é necessária
- envolve identificar sintomas e causas-raiz, e analisar por que isso importa agora
- em estratégias ruins, essa parte costuma ser omitida ou se limita a descrever o estado atual
- um bom diagnóstico exige investigação objetiva e postura quase de detetive
-
Política orientadora (Guiding Policy)
- é a abordagem de alto nível para resolver o problema identificado
- foca na solução e alinha a organização como um todo
- fornece direção sem exigir repensar cada detalhe tático toda vez
- estratégias ruins não conectam essa política (HOW) ao diagnóstico (WHY)
-
Ações coerentes (Coherent Actions)
- são planos de ação concretos para resolver o problema diagnosticado de acordo com a política
- deixam claro quem (WHO), o quê (WHAT) e quando (WHEN)
- a chave aqui é a coerência, para que equipes diferentes avancem em harmonia na mesma direção
Outra forma de reduzir o escopo técnico a uma única equipe: modelo Kebab vs Cake
- Também é possível desenhar a estrutura organizacional de forma que a tecnologia não se espalhe entre várias equipes, e sim seja resolvida dentro de uma única equipe
- Um modelo representativo disso é o Kebab vs Cake
- uma abordagem estrutural que organiza equipes com base na jornada do consumidor, reduzindo o escopo da responsabilidade técnica
- para mais detalhes, veja Kebab vs Cake organization
-
Arquitetura Kebab
- as equipes são organizadas em torno das funcionalidades oferecidas
- a jornada do usuário atravessa entregas de várias equipes
- vantagem: autonomia e acoplamento frouxo
- desvantagem: risco de handoffs
-
Arquitetura Cake
- as equipes são organizadas em torno da jornada do usuário
- a carga cognitiva é gerenciada por meio de camadas de abstração
- vantagem: ownership de ponta a ponta e menos handoffs
- desvantagem: risco de aumento da carga cognitiva
- O Staff Engineer não é apenas um papel técnico; ele deve atuar como owner responsável pelo sistema como um todo, com três elementos:
- Conhecimento (Knowledge):
- entendimento profundo da stack tecnológica e do problema de produto
- capacidade de explicar isso e, quando necessário, implementar diretamente
- Mandato (Mandate):
- posição que lhe permita opinar sobre como a tecnologia deve evoluir e ser mantida
- Responsabilidade (Responsibility):
- responsabilidade pela saúde do sistema, incluindo incidentes, dívida técnica, documentação, fragmentação técnica etc.
- O Staff Engineer não é um papel puramente técnico, e soft skills são essenciais para liderar tecnicamente a organização
- comunicação com influência, colaboração, liderança e similares são necessárias
- Porém, se houver foco excessivo apenas em soft skills, surgem problemas como:
- apresentar apenas ideais distantes da realidade, sem participar de codificação ou resolução concreta de problemas
- o risco de degenerar em um Ivory Tower Architect
Encerrando
- Nem toda organização precisa de Staff Engineers. Em casos como os abaixo, eles podem não ser necessários:
- quando o EM tem capacidade técnica suficiente para liderar diretamente a tecnologia da equipe
- quando a stack tecnológica está saudável e é fácil de manter
- quando a tecnologia se resolve dentro de uma única equipe, com pouca dependência entre equipes (o modelo organizacional Cake é um exemplo)
- quando a organização é madura o suficiente para operar bem o sistema inteiro sem um owner específico
- Por outro lado, em organizações que têm Staff Engineers, é preciso deixar claro:
- o ownership técnico
- e dar ao Staff Engineer accountability explícita por essa responsabilidade
- Resumo dos pontos principais:
- Ivory Tower Architect deve ser evitado (falta de realismo)
- dividir uma mesma função em vários títulos é ineficiente
- um EM não técnico também é ineficiente
- Por fim, este texto não é uma regra absoluta, mas um ensaio de referência
- como organização, tecnologia, produto, operação e pessoas são sempre diferentes, é importante julgar com flexibilidade conforme o contexto
- evite imitação cega (cargo culting) → veja o texto relacionado
4 comentários
Parece que são os braços direitos do CTO
Engenheiro staff: a pessoa que você vai incomodar quando já tentou de tudo e não deu certo.
Ahahahah, me identifico demais
Não tem muito a ver com o conteúdo do texto, mas eu estava refletindo sobre
accountabilityeresponsibility, então o link abaixo me ajudou bastante.https://blog.alexewerlof.com/p/accountable-vs-responsible