Toda empresa mede quantas features um engenheiro entregou. Poucas medem quanto esse engenheiro aumentou a capacidade de entregar de quem está em volta. A segunda medição é onde o Staff Engineer aparece, e ela quase nunca entra na review de desempenho.
Uma semana qualquer
- Uma tarde revisando com dois sêniors a arquitetura de um serviço novo, antes de três semanas de retrabalho
- Uma hora num 1:1 com um sênior travado em problema de design, destravando dois sprints de trabalho
- Uma manhã escrevendo guia de decisão para um padrão recorrente, usado por 8 engenheiros no semestre
- Meia tarde conduzindo revisão de incidente e transformando a falha em mudança de processo
Nenhuma das quatro entra como feature entregue. Todas mudam o que o time consegue fazer na semana seguinte.
Padrões como trabalho principal
Sem padrão escrito, cada engenheiro decide sozinho como organizar código, fazer log, estruturar teste e versionar API. A soma vira inconsistência que aparece em code review, onboarding e manutenção, e some com cada nova contratação.
Padrão resolvido uma vez devolve tempo em toda iteração seguinte: ninguém repete a discussão de estrutura, e o revisor olha para o problema em vez da forma. Steve McConnell trata de práticas de construção consistentes em Code Complete, 2ª edição (Microsoft Press, 2004), e o custo de cada escolha tomada em contexto diferente.
Mentoria técnica de profundidade
Um Staff Engineer ensina um sênior a pesar trade-off, a enxergar a consequência de uma decisão em sistema grande e a defender esse raciocínio em reunião com produto e vendas.
Will Larson descreve em Staff Engineer (O'Reilly, 2021) a influência ampliada como parte do papel, com a mentoria como um dos canais. O que o sênior aprende na conversa entra nas revisões que ele faz e nos artefatos que ele escreve, e chega a mais gente do que a dupla.
Visão de sistema
Time afundado no próprio backlog enxerga o backlog. Dois times constroem funcionalidade que vai colidir e a colisão aparece na semana do lançamento.
Richard Cook explica em "How Complex Systems Fail" (1998) que falha em sistema complexo envolve interação entre componentes, e não defeito de um componente isolado. Quem enxerga essas interações evita retrabalho, corta incidente de produção e mantém os investimentos técnicos de times diferentes apontando para o mesmo lugar.
O que muda em 6 a 12 meses
- O time discute menos o que é código bom, porque o padrão existe e é lido
- Sêniors ganham escopo maior e ficam mais tempo no cargo
- Incidente de produção por decisão de design ruim cai
- Onboarding encurta porque o sistema é legível para quem chega
Esses resultados não aparecem num sprint. Aparecem em trimestres, e a review de desempenho que conta features não os captura.
O custo de não ter o papel
Retrabalho que um padrão claro evitaria. Rotatividade de sênior sem caminho técnico. Incidente que uma decisão melhor teria impedido. Some os três num trimestre e compare com o custo do salário, em tempo cheio ou sob demanda.
