Conversas de Promoção e Desempenho que os Engenheiros Respeitam

Um engenheiro sênior em um time com o qual trabalhei pediu demissão na semana seguinte à avaliação com "supera as expectativas." Não por causa da nota. Porque o dossiê de promoção foi rejeitado na calibração dois dias depois, e ninguém (nem o gerente de engenharia, nem o skip-level) havia alertado que era uma aposta arriscada. Ele passou dezoito meses ouvindo "você está arrasando." A história que contou para a rede de contatos ao sair era simples: meu gerente ou não sabia, ou sabia e não me contou. As duas versões são ruins para a reputação da empresa.

Os ciclos semestrais comprimem seis meses de sinais não ditos em uma conversa de 45 minutos. O que você não anotou não aconteceu. O que você não nomeou em maio não pode contar em outubro só porque você se lembrou durante a preparação da calibração. Este playbook é para gerentes de engenharia que querem que seus engenheiros saiam de toda avaliação capazes de prever o resultado por si mesmos, a partir de artefatos já documentados.

Critérios de promoção como uma lista de evidências, não de opiniões

A forma mais rápida de perder a confiança de um engenheiro é defender uma decisão de promoção com adjetivos. "Forte liderança técnica." "Grande impacto entre times." "Senso de responsabilidade excepcional." Nenhuma dessas palavras significa nada para um engenheiro segurando um dossiê rejeitado. Ele quer o artefato.

Conduza promoções com uma rubrica de quatro colunas vinculada ao trabalho entregue:

Note o que não está na rubrica: impressões subjetivas, senioridade por tempo de casa, "parecia um Staff engineer na sala." É assim que você perde um argumento de calibração. As colunas acima são como você ganha um.

Quando você se sentar para escrever um dossiê, a pergunta deixa de ser "a Priya está pronta para Staff?" e passa a ser "a Priya tem três design docs adotados em toda a área, dois serviços de sua responsabilidade de ponta a ponta e um trimestre de desbloqueio de no mínimo cinco engenheiros?" Se ela tem dois design docs, você não está pronto para submetê-la. Se ela tem quatro e coordenou o gerenciamento de incidentes em um P0, você tem um caso.

Mostre o critério com exemplos nomeados. "Em nível Staff, esperamos trabalhos como o RFC de reescrita de pagamentos do Marco ou o framework de retry budget da Lin." Níveis genéricos em uma wiki não são evidências. Dossiês reais que foram aprovados são.

O artigo complementar a este é a job description de Staff Software Engineer. A linguagem de escopo, impacto e alavancagem na sua rubrica de promoção deve espelhar essa JD palavra por palavra. Se sua rubrica diz "conduz decisões de arquitetura" mas sua JD diz "é responsável pelo design de sistemas com múltiplos serviços," seus engenheiros estão se calibrando em relação a dois critérios diferentes.

O plano de visibilidade de 6 meses

O motivo pelo qual a maioria dos dossiês de promoção falha não é que o engenheiro não cresceu. É que ninguém soube que ele cresceu. Um candidato a Staff que entregou um ótimo trabalho em três tickets internos que ninguém fora do time consegue nomear é um candidato cujo dossiê vai ser eliminado na calibração. Visibilidade é uma entrega.

No mês 1 de cada semiciclo, sente-se com cada engenheiro que é candidato a promoção nos próximos 12 meses e escreva juntos um plano de visibilidade de 6 meses. Quatro artefatos, assinados e datados:

1. Um projeto desafiador com um sponsor executivo nomeado e uma superfície de entrega visível (mais sobre a armadilha abaixo).
2. Um artefato entre times: um RFC consumido por outro time, uma integração que outro gerente de engenharia consegue nomear, uma migração que fechou um ticket de dívida técnica em duas áreas distintas.
3. Um resultado de mentoria: um júnior que é promovido, um novo contratado que se integra em 30 dias em vez de 90, um processo de contratação que ele liderou.
4. Um design doc escrito que sobrevive à revisão e é citado por alguém fora do time imediato em até 6 meses.

Esse documento vai para uma pasta compartilhada. Ambos assinam. Agora não há ambiguidade sobre o que o próximo ciclo será avaliado, e o engenheiro pode fazer uma autoavaliação no mês 3 e no mês 5 em vez de descobrir na mesa de calibração.

Se entregar os quatro, o dossiê se escreve sozinho. Se entregar dois dos quatro, ele sabe no mês 4 (não no dia da avaliação) que o dossiê não está pronto, e tem a chance de corrigir o curso ou aceitar um atraso de 6 meses sem que isso pareça uma traição.

A conversa difícil de desempenho: SBI + Pedido + Compromisso

A maioria dos gerentes de engenharia usa o sanduíche. Abre com um elogio, entrega a crítica no meio, fecha com uma mensagem reconfortante. Os engenheiros não ouvem o meio. Eles ouvem "você está indo bem, algumas coisas menores, você está indo bem." Depois ficam surpresos em outubro e contam para os amigos.

Pare com o sanduíche. Use SBI + Pedido + Compromisso. Quatro etapas, sem rodeios.

Situação. O momento, o lugar e o contexto específicos. "Na revisão de redesign do auth-service em 12 de março."

Comportamento. O que a pessoa fez, de forma observável. Não o que você inferiu sobre o estado mental dela. "Você se recusou a responder duas das quatro perguntas dos revisores e disse 'podemos resolver isso depois.'"

Impacto. O que custou para o time ou para o trabalho. "Os revisores me escalaram depois. Atrasamos o lançamento em uma semana para refazer o modelo de ameaças."

Pedido. O que você quer de diferente, especificamente, da próxima vez. "Quando um revisor sinalizou uma questão de segurança em um design doc, preciso que você a responda no documento em até 48 horas, mesmo que a resposta seja 'vamos adiar isso e este é o motivo.'"

Compromisso. Uma data e um ponto de verificação. "Vamos revisitar isso na nossa reunião individual do dia 9 de abril e olhar como foram as próximas duas revisões de design."

Dois roteiros de exemplo que você pode usar diretamente:

Revisões de código bloqueando o time. "No sprint 23, três das suas revisões de código levaram mais de 4 dias para retornar. Uma delas atrasou o lançamento do checkout-revamp por um sprint completo. O time está começando a contornar você, o que significa que você está perdendo contexto sobre a base de código. Preciso que você retorne as revisões em 24 horas ou as redistribua para alguém que possa. Vamos verificar isso na nossa reunião individual do dia 15."

Design docs sem rigor. "Seus dois últimos design docs (a migração de fila e a reescrita do rate-limiter) não tinham seção de modos de falha nem plano de rollback. O comitê de revisão de arquitetura devolveu os dois para uma segunda passagem, o que custou duas semanas para cada. Em nível Staff, design docs precisam ser aprovados na primeira revisão em pelo menos 70% das vezes. Quero que o próximo doc que você escrever inclua uma tabela de modos de falha e uma seção de rollback antes de ir para o comitê. Vamos revisar o próximo doc juntos antes da submissão no dia 22."

Note o que está faltando. Nada de "mas você tem feito um trabalho ótimo em outros aspectos." Essa frase é para o seu próprio conforto, não para o dele. Reserve para o final da reunião se precisar, depois do compromisso.

Sinais de PIP: quando começar, quando não usar

Um plano de melhoria de desempenho (PIP) é uma ferramenta, não uma punição. O maior erro que os gerentes de engenharia cometem é começá-lo tarde demais, geralmente porque ficaram usando o sanduíche por seis meses. O segundo maior erro é iniciá-lo quando o problema real é de adequação ao papel, não de desempenho.

Inicie um PIP quando as três condições forem verdadeiras:

1. O comportamento foi nomeado ao engenheiro por escrito (em anotações de reuniões individuais que ele pode consultar).
2. O comportamento foi repetido ao longo de pelo menos dois ciclos ou dois meses.
3. O comportamento está inalterado após pelo menos duas anotações escritas de reuniões individuais sinalizando-o e pelo menos uma conversa SBI.

Se você não consegue demonstrar as três a partir do seu histórico de reuniões individuais, você não tem um caso de PIP. Você tem uma lacuna de feedback, e o PIP será contestado pelo RH e pelos seus pares gerentes na calibração.

Não use o PIP quando for um problema de adequação ao papel, não de desempenho.

Um "problema de adequação" parece assim: o engenheiro está tecnicamente bem, entrega seu trabalho, mas está desalinhado com o domínio do time (pessoa profundamente de infraestrutura em um time de produto, pessoa profundamente de produto em um time de plataforma) ou com o estágio da empresa (gosta do caos de equipe pequena e foi contratado com 800 pessoas). O engenheiro não está falhando. A posição está errada.

Forçar um PIP em um problema de adequação gera uma saída hostil. O engenheiro reage, tecnicamente se defende, sai de qualquer forma e conta para todos que você tentou gerenciá-lo para fora de forma injusta. Custo: 6 meses de moral do time e sua reputação no mercado mais amplo.

Ofereça uma transição planejada. Direta, respeitosa, com prazo definido. "Acho que você seria mais adequado no time de plataforma. Conversei com a Maria e ela tem uma vaga. Gostaria de apoiar sua transição nas próximas 4 semanas. Se preferir buscar oportunidades externas, posso lhe dar 6 semanas de prazo e uma recomendação sólida." Os engenheiros respeitam isso. Os amigos deles respeitam isso. Seu pipeline de contratação se beneficia.

A árvore de decisão para PIP, simplificada:

Um PIP bem conduzido se resolve em 60 dias, seja por melhoria real ou por uma saída limpa. Se o seu está se arrastando pelo mês 4, você está gerenciando seu próprio desconforto, não o desempenho do engenheiro.

Calibração de promoção com pares gerentes

A calibração é a reunião onde as decisões de promoção são de fato tomadas. O dossiê que você escreveu é o ingresso de entrada. Os 90 minutos em uma sala com 4 a 6 pares gerentes e seu director são onde as dinâmicas de defesa versus contestação decidem o resultado.

Leve um pré-leitura de uma página. Dois dias antes da calibração, envie para seus pares gerentes uma única página por candidato:

• Nome, nível atual, nível alvo
• Os 3 principais artefatos (com links para o design doc, RFC, postmortem de incidente)
• Evidências de escopo, impacto e alavancagem em três bullets curtos cada
• Um parágrafo sobre o contra-argumento mais forte e sua resposta a ele

Esse último ponto é o que separa um gerente que sai com seu engenheiro promovido de um que não sai. Antecipar o argumento do contestador no pré-leitura significa que a resistência na sala é algo que você já abordou por escrito. Se você não antecipar, seu par que está contestando tem a chance de enquadrar o argumento primeiro.

Defenda um caso limítrofe sem vender demais. Limítrofe significa que o engenheiro está no critério em duas das três dimensões e se aproximando na terceira. Não diga "ele é absolutamente Staff." Diga "ele está no critério em escopo e alavancagem, se aproximando em impacto, e este é o trabalho em andamento que fecha a lacuna até o Q3." Esse é o tipo de linguagem que sobrevive ao escrutínio de um director. Vender demais um caso limítrofe destrói sua credibilidade pelos próximos dois ciclos.

Quando um par gerente bloqueia seu engenheiro para proteger o próprio (acontece, especialmente quando as avaliações são ranqueadas por posição relativa ou o orçamento é limitado), não reaja na sala. Você vai perder, e vai desgastar o relacionamento. Em vez disso, leve para fora. "Quero entender melhor sua preocupação com o critério de design doc da Priya. Podemos revisar juntos os três RFCs dela esta semana?" Nove em dez vezes, a resistência se dissolve quando você tira a conversa da mesa de calibração.

A armadilha do "projeto desafiador"

Metade dos dossiês de promoção que vi serem rejeitados foi por causa de um projeto desafiador que nunca ia gerar trabalho visível. O padrão é sempre o mesmo. O gerente atribui um projeto que soa ótimo no papel. O engenheiro passa 4 meses nele. O projeto é desprioritizado, o escopo é cortado ou o sponsor executivo muda de time. O engenheiro não entrega nada externamente visível. A sala de calibração pergunta "o que a Priya fez neste semestre?" O gerente não tem nada para apontar.

Valide o escopo desafiador antes de atribuir. Três verificações, todas obrigatórias:

1. Orçamento real. Há uma linha de orçamento ou uma alocação de quadro de pessoal, não um "vamos resolver isso depois." Se o financeiro não consegue nomear, não existe.
2. Sponsor executivo nomeado. Um Director ou VP específico que disse, por escrito ou em uma reunião gravada: "esta é uma das minhas 3 principais prioridades neste semestre." Não um CC em um e-mail de lançamento. Uma declaração explícita.
3. Superfície de entrega visível. Um usuário, cliente ou time interno que vai usar o resultado e pode confirmar que chegou. Se as únicas pessoas que vão ver são o próprio time do engenheiro, é um projeto normal, não desafiador.

Se qualquer uma das três estiver faltando, o projeto é uma armadilha para a carreira. Questione, mesmo que o engenheiro esteja animado. "Adoro essa ideia. Antes de atribuí-la como seu projeto desafiador, preciso saber quem é o sponsor executivo e qual usuário vai utilizá-la. Sem essas duas informações, você vai gastar 4 meses em algo que não ajuda o seu dossiê." Os bons engenheiros agradecem no mês 5. Os ótimos agradecem no mês 1.

Cadência do documento de crescimento escrito

Um documento. O mesmo documento. Permanece por toda a trajetória do engenheiro no seu time. Não três documentos separados em três lugares diferentes.

Três cadências alimentam esse documento:

A atualização mensal em bullets é a mais subestimada. Cinco minutos. O engenheiro escreve o que entregou, o que o bloqueou, o que aprendeu e o que está pedindo de você. Você lê antes da próxima reunião individual e responde por escrito. Seis meses depois, quando a preparação da calibração começa, você tem 6 meses de bullets que se comprimem no dossiê formal sem nenhum esforço heroico de memória.

A grande regra: o engenheiro consegue ler sua própria trajetória a qualquer momento. Se ele perguntar "onde estou?", a resposta é "abra o documento, role até a última revisão trimestral, você pode ver exatamente onde está." Sem surpresas. Sem "deixa eu agendar um tempo para conversarmos." O documento é a resposta.

Também é assim que você se recupera quando um engenheiro muda de time ou você sai da empresa. O próximo gerente herda um documento real. Não um histórico de mensagens no Slack.

Erros comuns a evitar

• Guardar o feedback real para o dia da avaliação. Se seu engenheiro está ouvindo pela primeira vez em outubro, você falhou em maio.
• Promover com base em potencial em vez de evidências. Potencial é no que você aposta na contratação, não na promoção. Promoção se baseia em artefatos entregues.
• Linguagem vaga que o engenheiro traduz como "sem problemas." "Adoraria ver um pouco mais de capricho nos seus design docs" não é feedback. É uma dica que é ignorada. Use SBI.
• Calibrar sem artefatos na sala. Se você não consegue vincular o design doc, você não tem argumento.
• Confundir horas trabalhadas com impacto entregue. Um engenheiro de 60 horas que entregou duas features não supera um de 40 horas que entregou quatro.

Medindo o sucesso

Você saberá que este playbook está funcionando quando:

• Zero engenheiros são surpreendidos pela nota do dia de avaliação, porque estiveram lendo o mesmo documento de crescimento que você.
• Os dossiês de promoção são aprovados na primeira rodada de calibração em 70% das vezes, porque você parou de submeter casos limítrofes como apostas arriscadas.
• Os PIPs se resolvem em 60 dias (seja por melhoria real ou por uma transição limpa) em vez de se arrastarem pelo mês 6 e contaminarem o time.
• Os engenheiros conseguem citar de memória os critérios do próximo nível, porque você escreveu a rubrica e a revisou sobre um artefato real.

O critério é simples. O engenheiro segurando um dossiê rejeitado deve conseguir apontar para os critérios, apontar para o seu trabalho e concordar com a lacuna. Se não conseguir, o fracasso foi seu, não dele.

Saiba Mais

• Job Description de Staff Software Engineer
• Conduzindo 1:1s com Engenheiros que Geram Movimento
• Contratando Engenheiros Seniores que Ficam
• 1:1s com Skip-Level que Revelam a Verdade