- Depois de trabalhar 4 anos como desenvolvedor de software no Google, ele saiu da empresa em 1º de fevereiro porque a estrutura de avaliação para promoções e os repetidos cancelamentos de projetos fizeram com que sentisse menos controle sobre a própria carreira
- As promoções não eram decididas pelo gerente direto, mas por um comitê de engenheiros e gerentes mais sêniores que não conheciam o candidato e analisavam o promo packet
- Melhorar pipelines legados, corrigir bugs, testar, documentar e dar suporte ao time eram tarefas realmente úteis, mas difíceis de registrar como impacto mensurável, o que pesou contra ele na primeira avaliação de promoção
- Depois, ao passar a escolher apenas trabalhos que ajudassem na promoção, recebeu a nota máxima de desempenho, Superb, mas falhou novamente na promoção devido a cancelamentos de projeto e realocações de equipe
- Por meio do Indie Hackers, descobriu uma alternativa em pequenos negócios de software rentáveis e decidiu tentar por alguns meses o KetoHub, um negócio baseado em Sia e a monetização de escrita
Os primeiros 2 anos no Google e a expectativa de promoção
- Nos dois primeiros anos após entrar na empresa, ele estava tão satisfeito que achava que ficaria lá por muito tempo
- Havia engenheiros brilhantes ao seu redor, além de ferramentas de desenvolvimento avançadas e refeições gratuitas
- Sua avaliação de desempenho recente foi Strongly Exceeds Expectations, e o gerente lhe disse que a promoção para o próximo nível, Senior Software Engineer, estava próxima
- O gerente considerava que ele já tinha capacidade para atuar no nível sênior, mas disse que era preciso um projeto adequado para provar isso ao comitê de promoção
Como funcionava o processo de promoção no Google
- No Google, o gerente direto não podia promover diretamente um subordinado e também não tinha direito a voto
- A decisão sobre a promoção era tomada por um pequeno comitê formado por engenheiros de software e gerentes de nível mais alto que viam o candidato pela primeira vez naquele dia
- O candidato precisava montar e enviar um promo packet
- Cartas de recomendação de colegas de equipe
- Documentos de design que escreveu
- Um texto curto explicando por que seu trabalho justificava a promoção
- O comitê analisava os pacotes de vários candidatos em conjunto e decidia em um único dia quem seria promovido
- No começo, ele achava que esse modelo reduziria vieses e política interna, além de avaliar de forma justa a qualidade do código e o julgamento de engenharia
Por que melhorar um pipeline legado não aparecia na avaliação
- Sua principal responsabilidade era um antigo pipeline de dados legado
- Estava em modo de manutenção havia anos, mas sofria pressão com o aumento de carga
- Frequentemente morria em silêncio ou gerava saídas incorretas
- Não havia documentação desde o documento inicial de design, então diagnosticar incidentes podia levar dias
- Ele fez várias melhorias para estabilizar o pipeline
- Corrigiu dezenas de bugs
- Escreveu testes automatizados para evitar a recorrência dos bugs
- Removeu milhares de linhas de código morto e de código que podia ser substituído por bibliotecas modernas
- Documentou o que aprendeu para que o conhecimento não ficasse só na cabeça de uma pessoa
- Na avaliação de promoção, esse trabalho esbarrou no problema de não ser quantificável
- Ao encontrar bugs, o número total de bugs parecia até aumentar
- Ao mudar o sistema para falhar rapidamente em vez de ignorar anomalias em silêncio, as métricas de incidentes também aumentaram
- O tempo que os desenvolvedores levavam para corrigir falhas caiu muito, mas não havia métrica que acompanhasse isso
- Às vezes ele adiava seus próprios projetos por semanas ou meses para reduzir o risco de lançamento do trabalho dos colegas
- Era a decisão certa para o time, mas não parecia impressionante no promo packet
- Para o comitê, os projetos dos colegas pareciam trabalhos importantes que exigiam maior coordenação, enquanto o trabalho dele parecia algo facilmente interrompível
- O resultado da primeira avaliação de promoção foi que havia evidência insuficiente de que ele conseguia lidar com complexidade técnica e de que havia causado impacto no Google
Como sua forma de trabalhar mudou após a recusa
- Depois da primeira recusa, ele achou que bastava continuar fazendo o mesmo bom trabalho, mas registrando melhor tudo
- Mesmo quando o time recebia muitos alertas falsos por e-mail, ele não os corrigia imediatamente e antes tentava criar uma métrica de frequência de alertas para deixar um histórico
- Assim, poderia mostrar um gráfico na época da promoção provando que os alertas diminuíram
- O projeto que recebeu depois parecia favorável para promoção
- Dependia fortemente de machine learning, uma área importante no Google
- Automatizava um trabalho que centenas de pessoas faziam manualmente
- Ele teria de orientar um desenvolvedor júnior, algo que normalmente conta pontos em avaliações de promoção
O episódio do presente de fim de ano e a percepção de uma “relação comercial”
- O Google encerrou sua antiga tradição de presentes luxuosos de fim de ano e, com esse orçamento, comprou Chromebooks para estudantes de baixa renda, ganhando manchetes
- Em uma conversa entre funcionários sobre isso, um empregado disse que a relação entre Google e funcionários era uma relação comercial
- Aquela conversa o levou a perceber que Google e ele não formavam exatamente uma comunidade, mas uma relação em que ele prestava um serviço em troca de dinheiro
- Se o comitê de promoção não recompensava corrigir bugs nem apoiar o time, então passou a reconsiderar por que deveria gastar tempo com esse tipo de trabalho
Otimização para promoção e mudança no padrão de qualidade
- A lição tirada da primeira recusa acabou parecendo errada mais tarde
- Em vez de apenas empacotar melhor o mesmo trabalho, ele passou a escolher exclusivamente trabalhos que o comitê de promoção queria ver
- A nova estratégia era perguntar antes de começar qualquer tarefa se ela ajudaria na promoção; se não ajudasse, ele não fazia
- Seu padrão de qualidade de código também caiu
- A pergunta mudou de “isso vai ser sustentável pelos próximos 5 anos?” para “isso aguenta até eu ser promovido?”
- Bugs que não ameaçavam o lançamento do projeto não eram registrados nem corrigidos
- Ele se desvinculou de responsabilidades de manutenção
- Parou de se voluntariar em eventos de recrutamento no campus
- Reduziu de 1 ou 2 entrevistas por semana para 0
Cancelamentos repetidos de projeto e perda de controle sobre a carreira
- Com a mudança de prioridades, um projeto que parecia favorável para promoção foi transferido para uma equipe irmã na Índia
- Em troca, ele recebeu um projeto sem documentação, construído sobre uma infraestrutura descontinuada, mas que era um componente importante da produção
- O novo trabalho era separar esse sistema do código da equipe irmã e migrá-lo para um novo framework, mantendo a operação em produção e as métricas de performance
- Do ponto de vista da promoção, isso representava meses de retrocesso
- O projeto cancelado não foi lançado, tornando inúteis dois meses de trabalho
- Foram necessárias semanas para entender o novo sistema
- Manter a operação poderia consumir tempo extra em trabalho repetitivo
- Em 6 meses, foi a terceira vez que ele foi realocado no meio de um projeto, e em todas elas o motivo não foi a qualidade do seu trabalho, mas estratégia da alta gestão ou mudanças na equipe
- O Google dizia que não era possível julgar um trabalho antes da conclusão do projeto, mas ao mesmo tempo interrompia projetos no meio e atribuía novas tarefas, dificultando essa conclusão
- Sua carreira passou a depender de um comitê anônimo que o avaliava por cerca de uma hora e de decisões gerenciais sobre as quais ele não tinha influência
A última tentativa de promoção e a decisão de sair
- Como já havia investido 3 anos no Google em busca de promoção, decidiu fazer uma última tentativa antes de sair
- Seis semanas antes do fim do ciclo de desempenho, o projeto foi cancelado de novo e, desta vez, o time inteiro foi cancelado junto
- No Google, isso era comum o bastante para existir até um eufemismo: defrag
- O projeto do time foi transferido para a equipe irmã na Índia
- Os integrantes tiveram de recomeçar em outras áreas da empresa
- Mesmo assim, ele se candidatou à promoção e recebeu a nota máxima de desempenho, Superb
- Essa nota era dada a cerca de 5% dos funcionários em cada ciclo
- O comitê de promoção entendeu que, nos 6 meses mais recentes, ele havia mostrado claramente trabalho em nível sênior
- Esses 6 meses foram justamente o período em que ele trabalhou de forma otimizada para promoção
- Ainda assim, não foi promovido porque 6 meses não eram considerados um histórico longo o suficiente
- O gerente disse que, se ele mantivesse o mesmo nível por mais 6 meses, a chance de promoção seria alta, mas como já ouvia a promessa de “promoção em 6 meses” havia 2 anos, decidiu ir embora
Indie Hackers e o plano de desenvolvimento independente
- Na mesma época, ele descobriu o Indie Hackers
- O Indie Hackers era uma comunidade online de fundadores de pequenos negócios de software
- Em vez de pessoas sonhando com startups gigantes, o foco era em quem queria criar negócios pequenos e lucrativos capazes de pagar as contas
- Antes disso, ele achava que para se tornar fundador de software precisava seguir o caminho de startup ao estilo Silicon Valley
- Entendia esse caminho como passar a maior parte do tempo captando investimento e se preocupando em atrair o próximo milhão de usuários
- A proposta do Indie Hackers era uma alternativa diferente
- Muitos membros começavam seus negócios com a própria poupança ou como projetos paralelos ao trabalho principal
- Não precisavam responder a investidores
- Também não precisavam provar seu valor a um comitê anônimo
- As desvantagens também eram claras
- A renda era menos estável
- Havia muito mais riscos fatais
- Se ele cometesse no Google um erro que causasse uma perda de 10 milhões de dólares, poderia escrever um postmortem e aquilo seria tratado como oportunidade de aprendizado; para um pequeno fundador, isso poderia significar o fim do negócio e uma grande dívida
- Ainda assim, o que o atraía nos fundadores do Indie Hackers era o fato de tomarem suas próprias decisões, quer o negócio explodisse de crescimento, quer ficasse estagnado por anos
- Depois de sair, o plano era testar vários projetos por alguns meses cada para ver a reação
- Continuar desenvolvendo o KetoHub e validar seu potencial de monetização
- Criar um negócio sobre a tecnologia de armazenamento distribuído Sia
- Dedicar mais tempo à escrita e encontrar formas de monetizá-la
- O Google foi um bom emprego e um lugar onde aprendeu habilidades valiosas, mas ele concluiu que sempre existirão empregadores como o Google, enquanto a liberdade de começar a própria empresa não estará sempre disponível
1 comentários
Opiniões do Hacker News
O mesmo autor também vem publicando uma série interessante de retrospectivas anuais sobre o processo de tentar lançar vários negócios de software, tratando da situação financeira de forma bastante franca.
Se você tem interesse em fazer um negócio de software crescer por bootstrap, vale muito a leitura:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
Histórias de sucesso são ouvidas com frequência, e é fácil falar alto quando se tem sucesso, mas é preciso lembrar que a realidade é que a maioria das empresas fracassa. Este autor encontrou algo que dava dinheiro no terceiro ano, mas a maioria não tem folga para aguentar tanto tempo sem renda.
É raro encontrar alguém que escreva de forma tão identificável e honesta. Acompanho há anos, e é uma excelente fonte de inspiração.
Em qualquer carreira, a lição mais importante é que “o cliente não é o cliente”. Os clientes de verdade são as pessoas que determinam aumento salarial, bônus e promoção.
Cliente é quem paga por um produto ou serviço que considera valioso; normalmente é o gerente ou, como no caso do texto original, um comitê de promoção. Sob essa perspectiva, faz sentido operar a carreira como um negócio e se mover na direção de entregar valor mais rapidamente a quem pode trocar dinheiro por valor. Em negócios, também é comum o cliente mudar de ideia, o mercado mudar seus critérios e você perceber que estava focando no lugar errado. Se você não entrega o que o cliente quer, ele pode facilmente ir para outra pessoa; portanto, é preciso mudar continuamente a estratégia e se ajustar ao cliente.
No fim, o cliente de verdade nem é uma pessoa, e sim um processo. Perseguir com paixão boas ideias que ajudam as pessoas é o melhor ponto tanto para a carreira quanto para a sociedade. O trecho do original mostra bem isso: “É natural que meu destino esteja nas mãos de um comitê misterioso que nunca me encontrou. Eles não devem estar contaminados por favoritismo ou política, e reconhecerão meu código de alta qualidade e minhas decisões de engenharia afiadas.”
Esse padrão leva à queda na qualidade do produto e à piora da dinâmica das equipes. É melhor buscar empresas que reprimam explicitamente esse fluxo inevitável, ou onde ele ainda não tenha surgido. Todos se sentem melhor quando se produz boa qualidade e isso é reconhecido.
Quando se cria algo sob encomenda, o que o comprador quer pode ser diferente do que realmente é necessário, e ele pode continuar insatisfeito até o fim. Quando se trabalha para um chefe, o chefe também pode atrapalhar. Não basta fazer apenas o que o cliente quer; o chefe pode mandar fazer “do meu jeito”, e por causa disso o cliente pode acabar não recebendo o que queria. Mesmo quando o cliente compra algo para outra pessoa, a indireção pode levar ao fracasso, algo que acontece com frequência em software corporativo sob medida.
É difícil concordar totalmente com este texto. É muito frustrante quando um projeto desmorona antes de ser concluído, mas também parece que o autor estava ali só pela promoção
Promoções são boas, mas não ficou suficientemente explicado por que isso foi tão decisivo a ponto de ele ir embora. Se o único motivo para ficar no emprego é a expectativa de um cargo melhor, isso pode ser um mau sinal. Depois, em 4 anos no Google, ele ganhou dinheiro suficiente para a vida toda e, com essa estabilidade financeira, fez uma escolha de alto risco que a maioria não conseguiria bancar. De todo modo, fico feliz que ele tenha encontrado algo que combina com ele, e espero que use essa estabilidade para criar algo útil e impactante
Todos esses elementos costumavam ser muito públicos, com montes de apresentações, slides, documentos etc. Importava saber em que nível você estava e em que nível estava a pessoa com quem você falava. O objetivo não era ser um bom engenheiro nem criar um bom produto, mas fazer apenas o trabalho que levaria um comitê sem nome a aumentar aquele número mágico. Mesmo que você não tenha entrado no Google por esse motivo, acaba aprendendo o que é exigido. Infelizmente, uma geração de engenheiros de software aprendeu essa lição
A pressão para gerar impacto ou melhorar métricas duvidosas nunca acaba e, enquanto isso, a dívida técnica se acumula. A incerteza sobre reorganizações e demissões também está sempre presente, e a ansiedade em relação ao próximo ciclo de avaliação é grande. Depois de alguns anos, parece que o dinheiro é a principal motivação. Só que não quero uma promoção, porque não quero mais estresse, e provavelmente seria muito difícil ganhar mais em outro lugar, então quero ficar nesta empresa pelo máximo de tempo possível
A psicologia humana não funciona assim. Você acaba competindo com as pessoas ao seu redor, e é difícil ser feliz quando só você fica para trás enquanto elas são promovidas
Ficar por muito tempo em um nível abaixo de staff podia contar negativamente, e, se você não fosse promovido, poderia entrar em um plano de melhoria de desempenho por não atender às expectativas declaradas. O Google acabou removendo essa formulação, porque aprendeu que, em uma empresa de 100 mil pessoas, não há lugares suficientes na pirâmide, e que você acaba perdendo pessoas que não fazem autopromoção, mas mantêm o sistema funcionando. Se bem me lembro, em 2018 eles ainda não sabiam disso
Sou o autor. Fico feliz que este texto tenha voltado a aparecer
Posso responder a qualquer pergunta que tiverem sobre ele
Pelo que parece, você observou a correnteza e escolheu o fluxo que parecia melhor, mas muitas vezes há outras opções. Construir uma barragem, isto é, mudar o terreno. Tentar mudar o negócio de uma forma que ninguém quis ou conseguiu fazer. Olhando para trás, fui mais feliz e bem-sucedido quando pude dizer ao meu chefe o que eu faria, em vez de esperar que ele me desse um trabalho interessante e impactante. Quando essa opção não aparece, talvez seja hora de ir embora, mas muitas vezes vale a pena tentar antes. Às vezes tive de empurrar trabalhos desagradáveis para conquistar o direito de criar meu próprio destino, mas, quando a estrutura de gestão e a confiança se estabeleciam, eu podia usar esse capital para propor algo grande, novo e interessante. Sempre me surpreende ver a ousadia ser recompensada. Na semana passada mesmo, um colega tirou sangue de pedra em forma de financiamento com uma proposta ambiciosa e controversa, e nesta semana virou líder técnico de uma nova equipe. Sempre que me sinto travado, abro um documento em branco e começo a martelar um novo design. Nesse momento não penso em promoção, mas, no fim, isso acabou levando a alguma promoção ou a uma oportunidade maior em algum lugar
Fiquei curioso para saber se você está trabalhando em um novo projeto. Vi o texto sobre fuzzing de parsers de PDF, mas talvez eu não tenha visto, ou tenha perdido, o contexto sobre ele estar relacionado a um novo projeto
https://mtlynch.io/i-sold-tinypilot/
Obrigado por escrever publicamente e documentar sua jornada; certamente não fui o único a se beneficiar. Além disso, toda vez que vejo seu nome de usuário, sempre leio como Mount Lynch
A conclusão que tirei deste texto é como uma estrutura dependente de um comitê de promoção pode ser desumana
Entendo que o Google tenha criado esse sistema porque queria construir uma cultura centrada em engenharia. A intenção provavelmente era fazer com que um excelente trabalho de engenharia fosse reconhecido mesmo que um gerente não o reconhecesse. Mas, quanto mais difícil é quantificar o trabalho, como melhorias culturais, menos esse tipo de comitê parece capaz de reconhecer corretamente uma ótima engenharia. A vida melhora quando você encontra alguém — cliente ou líder — que reconhece o valor que você traz e demonstra esse reconhecimento em decisões de promoção. Um comitê sem rosto, dependente de pacotes, é estruturalmente incapaz de criar as relações nas quais o reconhecimento verdadeiro surge. Se a liderança não me reconhece em uma empresa, por que eu deveria insistir em ficar? Basta encontrar um lugar que reconheça. Se o Google não aprender que não consegue evitar perder bons talentos por má gestão ou processos ruins, a perda é deles. É só aproveitar avaliações de desempenho razoavelmente boas e planejar a saída aos poucos. A vida é curta demais para trabalhar em uma organização que impede ativamente a formação de relações profissionais autênticas e solidárias
Para muita gente, promoção é como ganhar uma competição de comer torta em que o prêmio é mais torta. Reconheça que os seus interesses e os do empregador só se alinham de forma frouxa, e que não há problema em se recusar a jogar o jogo do jeito que a empresa quer
Promoções à parte, quero fazer um trabalho que me dê motivação intrínseca — ou seja, algo significativo, inspirador e no qual eu consiga mergulhar — e ganhar apenas o suficiente para me sustentar e poupar de forma razoável.
O problema são três coisas. Muitas empresas pagam tão mal que é preciso ser promovido para conseguir economizar um pouco; o próprio trabalho significativo é quase um unicórnio; e o mais irritante é que, nas empresas dos EUA, até trabalhadores que desempenham seu papel de forma estável e consistentemente boa acabam inevitavelmente pressionados a “crescer” e “desenvolver a carreira”, ou são chamados de “ficando para trás”. Entregar desempenho excelente de forma consistente em um determinado nível pode não ser estagnação, mas estabilidade intencional. Crescimento infinito no contexto individual — ou ao menos agitação infinita — é uma insanidade incompreensível das empresas americanas.
Achei marcante a frase do autor: “Para continuar avançando na carreira, eu precisava de projetos com escopo maior e de colaboração com mais equipes parceiras. Mas isso significava que o projeto poderia fracassar por muito mais fatores fora do meu controle, e que meses ou anos da minha vida poderiam ser desperdiçados”.
Ao olhar para trás e refletir, acho que dá para reconhecer que o sucesso de uma startup também depende de mais de 100 fatores fora do controle. Não é tempo de vida desperdiçado. É aprender como o mundo funciona.
Para uma startup de alto crescimento financiada por venture capital, talvez várias estrelas precisem se alinhar para que ela dê certo. Mas, em um negócio bootstrapado, basicamente há uma única coisa necessária para o sucesso: adequação produto-mercado. Se você cria um produto que as pessoas querem, mesmo cometendo muitos outros erros, em geral tem boas chances de dar certo. Quando comecei a TinyPilot, eu não sabia nada de hardware nem de vender produtos físicos, e cometi inúmeros erros. Mas encontramos um produto pelo qual as pessoas estavam dispostas a pagar e uma boa forma de colocá-lo na frente dos clientes, então a empresa funcionou. Houve coisas que fizemos bem, mas no primeiro ano a sensação era, em grande parte, de que a receita crescia sozinha e eu tentava acompanhar. Ainda é preciso sorte para encontrar adequação produto-mercado, porque muitas ideias que parecem plausíveis fracassam. Mesmo assim, não é esperar que várias coisas deem sorte ao mesmo tempo; basta ter sorte uma vez.
Mais um daqueles infames textos de 2018 do tipo “por que saí do Google”.
E esses textos sempre começam dizendo que os engenheiros do Google são as pessoas mais inteligentes do mundo. Gente realmente doutrinada.
Eu também estou pensando em sair do Google por isso. Fico sentado em reuniões, tentando empurrar para outros o trabalho que precisa ser feito, com quase nenhum interesse em jogar esse jogo, enquanto no meu projeto há centenas de pequenas tarefas que eu preciso concluir.
Se eu mudar de emprego, posso ganhar US$ 50 mil a US$ 100 mil a mais por ano. A próxima empresa vai realmente valorizar minha experiência, embora tecnicamente essa experiência seja muito mais útil ao Google.
Hoje trabalho de forma mais rápida e eficaz, e ganho mais, em uma empresa pequena com um projeto focado, em vez de uma empresa de 100 mil pessoas que tenta fazer de tudo.
A estrutura era: “O gerente não promove você?” “Não. Gerentes do Google não podem promover seus subordinados diretos. Nem sequer têm direito a voto. Em vez disso, as decisões de promoção são tomadas por um pequeno comitê de engenheiros de software de nível superior e gerentes que estão conhecendo você pela primeira vez naquele dia”.
Pelo que sei, depois de 2022 isso parece ter mudado para um modelo em que o gerente tem o único voto.
A promoção ainda vai para o comitê de promoção. Só que agora tentam colocar o comitê mais próximo da organização, a ponto de talvez já ter ouvido falar do candidato, e incluir na reunião avaliadores com alto contexto que não sejam o gerente. Um ponto que vem do sistema anterior, e que textos assim às vezes deixam passar, é que em cada nível há expectativas explícitas sobre as atividades que se confia que uma pessoa daquele nível execute de forma independente. A decisão de promoção não é uma recompensa por ter feito bem o trabalho atual, mas uma decisão sobre se a pessoa demonstrou suficientemente que consegue fazer o trabalho do próximo nível. Quando alguém fica muito tempo em um nível, normalmente é porque não demonstrou sinais do próximo nível. Claro, pode parecer injusto quando a equipe não oferece oportunidades suficientes para mostrar sinais do próximo nível, ou quando o impacto de um projeto leva anos para ser avaliado e o trabalho não é reconhecido até que o impacto operacional seja medido. Ainda assim, muitas vezes não é tão arbitrário quanto parece.
Como muda todo ano, não vou julgar o Google de 2024 pela minha experiência pessoal, mas em um dos anos em que estive lá, meu gerente mal sabia onde ficava minha mesa. Meus pacotes de promoção para L5 e L6 foram avaliados por comitês de pares, e nem sei se eles olharam a avaliação do gerente. Quando participei de um comitê de promoção para L5, também não demos muito peso à avaliação do gerente. Na época, isso fazia sentido, porque os gerentes eram bastante distantes das áreas que justificavam uma promoção para L5.
Mas isso não é um mistério; no fim das contas, a responsabilidade de criar um pacote forte que deixe claro por que o candidato deve ser promovido é do gerente. A própria tentativa de promoção é o voto do gerente e, depois disso, tudo depende de quão fortemente ele defende a promoção do candidato. Vejo isso como a única forma de garantir consistência entre promoções.