- A cultura centrada em produto das grandes empresas de tecnologia prioriza performance de curto prazo e visibilidade, enquanto em infraestrutura e ferramentas para desenvolvedores a sustentabilidade e o gerenciamento de sistemas são os principais valores
- O autor faz parte do time de ferramentas para desenvolvedores e infraestrutura do Google e prioriza a confiança e a eficiência dos engenheiros clientes acima da atenção da liderança executiva
- O stewardship de longo prazo por meio da gestão de sistemas acumulou contexto e experiência que levaram a inovações em projetos de grande escala como o Bigtrace
- Em vez de perseguir projetos com alto destaque, ele trata confiança e impacto técnico como ativos e ganha capital político para dizer “não” quando necessário
- Mesmo com o ciclo rápido da indústria de tecnologia, existe uma carreira baseada em profundidade e continuidade, que cria um modelo alternativo de impacto de longo prazo
Engenharia em mundos diferentes
- Equipes de produto são voltadas para clientes externos e têm seus resultados medidos por indicadores de curto prazo, como receita e usuários ativos mensais (MAU)
- Nesse ambiente, agilidade e visibilidade (spotlight) são essenciais para chamar a atenção da gestão
- Em contraste, equipes de infraestrutura e ferramentas para desenvolvedores têm como clientes engenheiros internos, construindo ferramentas e sistemas para suportar desempenho e depuração de produtos
- Há menos atenção da gestão e uma estrutura em que contratar PMs é difícil, o que torna a operação menos hierárquica e mais ascendente (bottom-up), com foco nos engenheiros
- O time define e resolve os problemas em que pode causar maior impacto, enquanto a liderança executiva valida esse impacto
O efeito composto da stewardship
- Em ambiente de produto, a velocidade é a moeda principal, enquanto em infraestrutura o principal ativo é o contexto
- Tratar engenheiros como recursos substituíveis elimina contexto e causa perda de conhecimento tácito do sistema
- O primeiro benefício do cuidado de longo prazo é a eficiência pela reconhecimento de padrões
- Ao permanecer por longo período em um domínio, novas solicitações se conectam a casos anteriores e são resolvidas mais rápido
- O segundo benefício é a inovação sistêmica
- Só com observação de longo prazo surgem problemas que podem ser resolvidos; o resultado disso é o Bigtrace
- No início de 2023, várias equipes do Google observaram que não conseguiam processar dados de rastreamento de desempenho em escala de terabytes a petabytes
- Após um ano de pesquisa de protótipo e coleta de feedback, o Bigtrace foi construído no início de 2024
- Hoje processa mais de 2 bilhões de traces por mês e é usado por mais de 100 engenheiros
- Se o autor tivesse escolhido mudanças curtas de projeto, o Bigtrace não existiria
O poder de dizer “não”
- Projetos de alta visibilidade recebem recursos e atenção, mas também trazem volatilidade política e risco de queda de qualidade
- O capital de confiança construído com gestão de longo prazo dá força para recusar a tentação da spotlight
- Exemplo: mesmo com a onda de IA, o time recebeu pedido para integrar um LLM ao Perfetto, mas respondeu com cuidado para manter precisão como valor central
- Em depuração de kernel, timestamps precisos são essenciais e não é possível aceitar alucinação
- Não significa dizer “não” para sempre; é uma postura de “adiar até que seja implementado corretamente”
A moeda alternativa do impacto
- Ao sair da atenção imediata, a visibilidade da liderança diminui, mas ganha-se outra moeda: confiança e utilidade técnica
- Shadow Hierarchy (hierarquia sombra)
- Em organizações de infraestrutura, é mais importante ser reconhecido pelo chefe da organização cliente do que pelo próprio chefe
- Exemplo: se o time do Pixel disser “sem o Perfetto não é possível depurar”, esse impacto segue pela cadeia da gestão executiva
- Isso funciona como advocacia baseada em confiança técnica, não em política, e também se torna uma evidência forte em avaliações de promoção
- Utility Ledger (livro-razão de utilidade)
- Utilidade: quando o time usa a ferramenta para consertar bugs, ela prova sua utilidade
- Criticidade: conexão direta com o sucesso de times de produto essenciais
- Onipresença: várias organizações compartilham os mesmos traces e colaboram entre si
- Escala: lidar com dados em nível de petabyte prova a robustez da arquitetura
- A combinação desses indicadores garante impacto contínuo que não treme em reorganizações de equipe
Tipos e escolhas de um Staff Engineer
- De acordo com o livro Staff Engineer, de Will Larson, existem vários tipos de staff engineer, incluindo Solver/Right Hand e Architect/Tech Lead
- O primeiro é o resolvedor de problemas que executa a vontade da liderança; o segundo é o proprietário de longo prazo de um domínio específico
- O autor se identifica com o segundo, dando valor a contexto técnico profundo e responsabilidade de longo prazo
- Esse caminho é frequentemente possível apenas em ambientes corporativos lucrativos, e depende de sorte e escolha
- Encontrar um bom time é sorte, mas permanecer por longo período e crescer para liderança é escolha
- Esses times podem não receber atenção externa, mas mantêm missão contínua e cultura de engenharia estável
Conclusão
- A indústria de tecnologia costuma repetir “mova rápido”, mas existe também um caminho de profundidade e paciência
- Mesmo sem perseguir a spotlight, é possível construir uma carreira significativa e com impacto
- O mais ambicioso é permanecer por longo tempo no espaço de um problema e construir sistemas sustentáveis
1 comentários
Comentários do Hacker News
Depois de mais de 25 anos trabalhando, o que aprendi é que, se você não assumir a autoria da sua própria história e dos seus resultados, alguém vai fazer isso no seu lugar
Especialmente em grandes empresas, é comum que pessoas populares levem o crédito
Não é necessário ficar sob os holofotes o tempo todo, mas deixar registros é importante
Você precisa documentar claramente suas contribuições, seja em documentos internos ou em apresentações externas
Se você não é popular, até num time de beisebol acaba ficando no banco; em seleções para pós-graduação ou na comunidade de ML acontece a mesma coisa
O mundo funciona como uma espécie de sistema de competição por popularidade
Se não basta apenas trabalhar e ser recompensado, e autopromoção vira algo obrigatório, então prefiro possuir e controlar meu próprio trabalho
Eu acho que, dentro de uma empresa, confiança é a moeda mais importante
Quando você participa de vários projetos bem-sucedidos ao longo do tempo, a liderança acaba percebendo esse ponto em comum
A promoção vem mais devagar, mas reputação e rede de contatos se acumulam e levam a um crescimento mais estável
Como já ganhou dinheiro suficiente, perde o interesse em crédito
Hoje isso está mais equilibrado para mim, mas parece que, para a maioria, não é assim
Esse texto é realmente muito bem escrito
Em vez de focar só na nuance de “eu odeio política”, é preciso entender a estrutura política de Infra e DevEx
Trabalhei por 5 anos como PM de infraestrutura no Slack e só fui aprender o processo de lançamento de produto no quarto ano
O ponto central era ajudar os clientes internos (engenheiros de produto) a terem sucesso, e o feedback de “Shadow Hierarchy” era decisivo para promoções
Quando você otimiza esse sucesso interno, a recompensa vem tanto em estabilidade quanto em carreira
Mas isso não é um código de trapaça que permite ignorar a natureza do negócio
O autor identificou bem a diferença de avaliação entre engenharia de produto e engenharia de infraestrutura
Ainda assim, a generalização baseada no ambiente específico do Google parece um pouco ingênua
Quando a situação do mercado ou as prioridades da liderança mudam, o valor que você acumulou também precisa ser redefinido
Ele enfatizou que seu texto não era um guia universal de sucesso e disse que outros ambientes exigem estratégias diferentes
Em grandes empresas, avaliações no estilo votação de popularidade são comuns
Muitas vezes as pessoas são avaliadas com base em critérios vagos como “liderança comunitária”
Mas eu acho que o valor real está em fazer um bom trabalho em silêncio e ajudar os outros
O engenheiro fica preso no dilema entre escolher código sólido ou autopromoção
No fim, desenhar incentivos adequados é a essência de como se administra uma organização
Na minha carreira de 25 anos, passei a maior parte do tempo trocando de empresa a cada 2 anos, mas na empresa atual já estou há 4 anos
Estou construindo uma plataforma interna e resolvendo problemas reais de clientes, e isso, independentemente da política, é o que me move todos os dias
Como engenheiro de infraestrutura e tooling, passei muito tempo no mesmo time, e o conteúdo deste texto bate bastante com a realidade
Às vezes há conquistas fáceis, mas na maior parte do tempo trata-se de trabalho técnico cotidiano, calmo e satisfatório
Eu também prefiro trabalhar em time de infraestrutura do que em time de produto
Fico mais livre dos caprichos da liderança e consigo focar na qualidade técnica
Hoje gosto de trabalhar discretamente melhorando a infraestrutura de outros times numa empresa de médio porte
O próprio fato de alguém precisar defender seu valor com um texto desses não é um bom sinal
Claro que autopromoção e carisma ajudam em promoções, mas não há necessidade de ir por esse caminho a ponto de piorar o mundo
Também precisamos de pessoas que trabalham em silêncio, como Wozniak
O autor só conseguiu evitar os holofotes porque já era Staff Engineer
Na época de startup, como já tinha conquistado confiança, não precisava se expor; mas em BigTech a política era mais pesada
Eu achava que meu objetivo de curto prazo era ganhar dinheiro e sair, mas ajudar estagiários mais jovens a serem reconhecidos era ainda mais difícil
Hoje, meus próprios projetos já me dão visibilidade, então não preciso me promover ativamente
Disse que, no Google, desde a época de L3, conseguiu reconhecimento suficiente por meio de compartilhamento e colaboração com outros engenheiros, sem perseguir os holofotes
Se você garante capital suficiente — seja social ou financeiro — consegue aguentar 3 anos, e, se o resultado aparece no segundo ano, os tropeços do início acabam sendo esquecidos
O problema é o risco quando você está errado
Mesmo se esforçando por um release sem bugs, no fim a realidade é que quem vira a noite resolvendo o problema é quem recebe elogios
Claro que sorte também conta, mas eu acredito que as oportunidades aparecem para quem está preparado