Armadilhas Comuns do Gerente de Engenharia (E Como Parar de Cair Nelas)

É domingo à noite. Você está revisando um PR que seu staff engineer abriu na sexta porque ninguém mais "tinha o contexto." Seu documento de 1:1 com seu subordinado mais sênior tem os mesmos três pontos que tinha há seis semanas. Você não faz uma retro desde a reorganização. Você se diz que é um gestor de coaching. Sua equipe te descreveria como "simpático, mas ausente."

Este guia preenche essa lacuna.

Já fui o mau EM em cada uma dessas histórias. Não vou moralizar. Vou nomear o padrão, te dar o número que quantifica o dano e te dizer exatamente o que fazer esta semana. Você pode ler Lara Hogan, Will Larson e Camille Fournier o ano todo, mas até metabolizar o conselho em comportamento mudado em uma terça de manhã, sua equipe ainda está sofrendo a versão de você que não leu nada disso.

Por Que Isso Importa Agora

EMs do primeiro ano são avaliados em duas coisas: resultado da equipe e retenção de talentos. A maioria erra na retenção porque os modos de falha são invisíveis até alguém pedir demissão. Nesse ponto já é um backfill de 3 meses, uma adaptação de 6 meses e aproximadamente R$ 1M a R$ 1,5M em custo total por saída quando você soma o salário carregado do engenheiro, as taxas de recrutamento e o arrasto de adaptação que pesa sobre a equipe que ficou para trás.

Duas saídas lamentáveis em um ano apagam a maior parte do ganho de produtividade que você entregou. E você não pode gerenciar o que não vê, então o primeiro trabalho é nomear os padrões. Aqui estão os sete que aparecem com mais frequência em EMs de 6 a 18 meses.

Armadilha 1: Programar em Vez de Fazer Coaching

Sintoma. Você está fechando 3 a 8 PRs seus por semana. Se diz que está "desbloqueando a equipe." Na verdade está evitando o trabalho mais difícil e lento de decidir qual pessoa na equipe deve crescer para aquele pedaço do código.

Número real. Cada hora que você passa programando é cerca de 1,5 a 2 horas de coaching da equipe perdidas, porque coaching é orientado a interrupções e você agora está de cabeça baixa e indisponível. Para uma equipe de seis, são cerca de 10 horas de coaching perdidas por semana. Em um trimestre, você subtraiu cerca de 130 horas, ou um sprint completo de desenvolvimento sênior, do crescimento dos seus subordinados.

Solução. Limite sua contribuição como IC a 10% da semana. Bloqueie na agenda, rotule como "tempo de IC" e quando o tempo acabar, acabou. Passe a próxima tarefa do tipo "vou fazer esse rapidinho" para o subordinado cuja área de crescimento ela toca, e diga por que está passando: "Esse é o tipo de trabalho que te leva ao nível sênior. Quero que você seja o dono, e quero revisar o design antes de você começar." Essa última frase é a diferença entre uma transferência e um despejo.

Armadilha 2: Pulando o 1:1 Difícil

Sintoma. Seu 1:1 semanal com o sênior que entrega mas é tóxico na revisão de código continua "ficando sem tempo" antes de você levantar o comportamento. Três meses depois, duas pessoas da equipe estão entrevistando em outro lugar.

Número real. Tempo médio de permanência de um engenheiro que tem um colega que considera tóxico e um gestor que não abordou isso: 8 a 11 meses. Tempo médio de permanência de um engenheiro cujo gestor nomeou o comportamento dentro das primeiras quatro semanas: mais de 2,5 anos. A diferença é um custo completo de backfill por ano de omissão, mais o imposto cultural sobre o restante da equipe que assistiu você não agir.

Solução. Se você está evitando um tópico por duas semanas ou mais, o próximo 1:1 começa com ele. Sem preâmbulos, sem "como foi seu fim de semana." Roteiro: "Quero usar os primeiros 15 minutos para uma conversa difícil sobre como a revisão de código está indo. Ouvi X de dois colegas. Me explique sua perspectiva." Não suavize a abertura. Suavize a escuta. O motivo mais comum pelo qual essa conversa vai mal não é ter dito a coisa errada. É ter dito a coisa certa por 30 segundos e depois passado os próximos 14 minutos se desculpando por isso.

Armadilha 3: Depender Demais de Métricas de Velocidade de Entrega

Sintoma. Você cita story points em skip-levels. Comemorou um aumento de 20% na velocidade de entrega no último trimestre que veio de um sênior reestimando o backlog, não de nenhuma mudança na vazão real. Quando perguntado como a equipe está indo, "a velocidade de entrega está em alta" é a primeira coisa que sai da sua boca.

Número real. Aproximadamente 70% das mudanças de velocidade de entrega em um determinado trimestre são desvio de estimativa, não mudança real de produtividade. Equipes que gerenciam pela velocidade de entrega veem a taxa de falhas em mudanças do DORA subir 15 a 25% dentro de dois trimestres, porque cortam profundidade de testes e rigor de revisão para manter o número de pontos bonito. Você otimizou para o dashboard e danificou o sistema por baixo.

Solução. Substitua a velocidade de entrega no seu relatório semanal por três números: frequência de implantação, taxa de falhas em mudanças e tempo de recuperação. Se sua organização não os rastreia, instrumente você mesmo em uma planilha por um trimestre. Leva cerca de 90 minutos para configurar e 10 minutos por semana para manter. Leve o DORA ao seu skip-level e explique por que está abandonando os pontos. Na primeira vez que fizer isso, seu skip-level vai te respeitar mais, não menos. Pare de citar pontos.

Armadilha 4: Subcomunicar Critérios de Promoção

Sintoma. Você tem um subordinado que "parece próximo" do nível sênior e outro que "ainda não chegou lá." Se alguém pedisse para você escrever a diferença entre eles em 90 segundos, você não conseguiria. Você falaria em "presença" e "responsabilidade" e "julgamento" e a sala assentiria educadamente.

Número real. Os resultados de promoção se correlacionam em cerca de 0,4 com critérios documentados e em cerca de 0,7 com a confiança do gestor e viés de recência quando os critérios não estão escritos. A diferença aparece na calibração como "confio na sua avaliação", que é como os mais barulhentos são promovidos e os quietos ficam estagnados. O custo cai sobre a equipe cerca de 18 meses depois, quando o IC mais forte, que foi preterido sem uma razão clara, vai para uma empresa que deu uma explicação.

Solução. Esta semana, escreva um documento de uma página "como é o nível Staff nesta equipe." Três seções: escopo, impacto, comportamentos. Coloque 4 a 6 exemplos concretos em cada uma, retirados de pessoas que você promoveria amanhã. Compartilhe com cada subordinado no próximo 1:1, não em um e-mail vago de "aqui está o doc, me avise se tiver perguntas." Caminhe por ele. Pergunte onde eles acham que estão. Use o mesmo documento na calibração. Atualize trimestralmente. O documento não é o objetivo; a conversa que ele força é o objetivo.

Armadilha 5: Proteger a Equipe do Contexto (Mal Feito)

Sintoma. Você "protege a equipe da política" não dizendo que o projeto está em risco, que o quadro de pessoal está congelado ou que o cliente odeia a v1. Eles descobrem por um canal do Slack duas semanas depois, muitas vezes por alguém que nem trabalha na sua equipe. Aí te perguntam sobre isso e você diz algo como "Sim, ia falar sobre isso."

Número real. Engenheiros que se sentem mal informados pontuam 30 a 40 pontos mais baixo em pesquisas de engajamento do que colegas que se sentem super informados. O engajamento no quartil inferior prevê rotatividade dentro de 12 meses em 2 a 3 vezes a taxa base. Tradução: a proteção errada custa aproximadamente um em cada quatro subordinados por ano, e os quatro que saem são os que têm opções.

Solução. Compartilhe por padrão. O teste não é "isso vai estressá-los", é "eu gostaria de saber isso se fosse eles." Faça um standup de contexto semanal de 15 minutos: o que mudou no nível de liderança, o que ainda é incerto, o que devem ignorar. Se algo for genuinamente sensível demais, diga "há uma coisa que ainda não posso compartilhar, aqui está quando espero poder." Essa frase compra mais confiança do que qualquer eufemismo. Engenheiros conseguem distinguir um gestor que os protege de um que se protege.

Armadilha 6: Não Fazer Retros (Ou Fazer Retros de Mentira)

Sintoma. A última retro foi há 11 semanas. Ou você faz retros, mas as ações nunca ganham responsáveis ou datas, então os mesmos três problemas aparecem em toda retro para sempre. Alguém menciona que os deploys ainda são dolorosos. Todo mundo acena. Nada acontece. Na próxima retro, alguém menciona que os deploys ainda são dolorosos. Todo mundo acena.

Número real. Equipes que fazem retros reais, com responsáveis nomeados, datas e acompanhamento na próxima retro, entregam cerca de 25% mais trimestres sem incidentes do que equipes que não as fazem. Equipes que fazem retros de mentira pontuam igual a equipes que não fazem nenhuma, o que significa que o ritual sem o ciclo de feedback é ativamente pior do que nada. Você ensinou à equipe que levantar problemas não os resolve, o que é uma lição muito mais difícil de desfazer do que começar do zero.

Solução. Cadência: a cada dois sprints, 60 minutos, sem exceções. Formato: quatro colunas (mantido, abandonado, fazendo mais, bloqueado em). Cada ação recebe um nome de responsável e uma data. Acompanhe as ações em um quadro público. Abra a próxima retro revisando as ações anteriores. Se menos de 70% estiverem concluídas, essa é a conversa, e você pula o brainstorming. A equipe vai reclamar na primeira vez. Faça mesmo assim. Dois ciclos depois, eles vão começar a aparecer com ações já nomeadas, porque sabem que você vai verificar.

Armadilha 7: Contratar Devagar Porque Contratar É Difícil

Sintoma. Você tem uma vaga aberta há quatro meses. Entrevistou oito candidatos. Nenhum estava "no nível." Enquanto isso sua equipe está a 80% da capacidade há um trimestre e seu sênior mais forte está fazendo o trabalho de duas pessoas e está começando a parecer cansado nos 1:1s.

Número real. Custo de uma vaga sênior aberta com remuneração típica de SaaS: cerca de R$ 100K a R$ 150K por mês em produção perdida, mais a carga que você está colocando no restante da equipe, o que aumenta o risco de rotatividade deles (veja a Armadilha 5). Uma vaga aberta por quatro meses já custou para a empresa R$ 500K e provavelmente comprou uma saída lamentável por cima. A régua que você está mantendo agora custou mais do que duas contratações mais baratas juntas teriam custado.

Solução. Defina a régua por escrito: três requisitos obrigatórios, três desejáveis. Execute cada ciclo de entrevistas contra esse documento, não contra vibes. Se você rejeitou cinco candidatos seguidos, a régua é o problema, não o mercado. Ou a reduza deliberadamente e diga ao seu skip-level por quê, ou divida a vaga em duas contratações mais baratas que possam crescer para se tornar uma forte. A Descrição de Cargo de Staff Software Engineer é um bom ponto de partida para o que "a régua" parece escrita. Pare de esperar por um unicórnio enquanto sua equipe está se esgotando. O unicórnio não está chegando, e a equipe é o ativo que você realmente tem.

Unindo Tudo: Uma Autoauditoria de 30 Minutos

Marque um timer. Para cada uma das sete armadilhas acima, se puntue de 1 a 5. Seja honesto. Seu skip-level já sabe.

Qualquer coisa com 3 ou menos: escolha uma solução deste guia, coloque na agenda para esta semana e diga a um par EM o que você se comprometeu a fazer para não largar silenciosamente. Não tente corrigir as sete de uma vez. Você vai bater de frente com todas elas. Escolha a pontuação mais baixa, aplique essa solução por duas semanas, depois faça a auditoria novamente.

O motivo pelo qual isso funciona e "serei mais intencional com o coaching" não funciona é que a solução é um bloco na agenda, não uma aspiração. Blocos na agenda sobrevivem às segundas-feiras. Aspirações não.

Como É o Bom Resultado em 90 Dias

Imagem concreta. Se você fez a auditoria esta semana e se comprometeu com uma solução a cada duas semanas, aqui está a equipe que deve ter até agosto:

• Você entrega código menos de 10% da semana e não se sente culpado por isso.
• Você teve pelo menos dois 1:1s difíceis e a equipe ficou melhor com eles, não pior.
• Seu relatório semanal começa com frequência de implantação e taxa de falhas em mudanças, não story points.
• Cada subordinado sabe como é o próximo nível para ele, no papel, e teve pelo menos uma conversa com você sobre onde está em relação a isso.
• A equipe recebe contexto por padrão compartilhado, não protegido por padrão, e seu standup de contexto semanal é um hábito que ninguém questiona.
• As retros seguem uma cadência de dois sprints com um registro de ações fechadas que está mais de 70% dentro do prazo.
• Nenhuma vaga ficou aberta por mais de oito semanas sem uma recalibração de régua por escrito.

Nada disso exige uma transplante de personalidade. Exige decidir que a versão de você que tolera esses padrões é a que sua equipe está pagando, e depois fazer uma mudança de cada vez até que não esteja mais.

Saiba Mais

• Os Primeiros 30/60/90 Dias como Novo EM
• Conduzindo 1:1s com Engenheiros Que Movem as Coisas
• Métricas de EM: Velocidade de Entrega, Qualidade, Retenção, Contratação
• Conversas de Promoção e Desempenho
• Descrição de Cargo de Staff Software Engineer