Seus Primeiros 30/60/90 Dias como Novo Gerente de Engenharia

Três semanas atrás você era um IC sênior. Hoje seu calendário tem 14 horas de reuniões, 26 horas de "tempo aberto" e uma mensagem no Slack do seu skip-level dizendo "me avisa se quiser tomar um café esta semana." Você ainda tem acesso a merge. Você ainda sabe exatamente qual arquivo abrir para corrigir o bug que acabou de acionar o engenheiro de on-call. E é aí que está a armadilha.

A maioria dos novos gerentes de engenharia recorre ao código porque é mais seguro do que fazer coaching. O ticket no Jira tem uma definição de pronto. O 1:1 com o staff engineer que está discretamente procurando outro emprego, não tem. Então o novo EM entrega uma feature na segunda semana, se sente produtivo e fracassa no trabalho de verdade por seis meses, até que o skip-level pergunta por que a velocidade de entrega do time não se moveu e duas pessoas pediram demissão.

Se você ainda mede sua semana em PRs aprovados, você aceitou o título sem aceitar o trabalho.

Por que os 30/60/90 Importam

A janela em que o time forma uma opinião sobre você é estreita. No dia 45 eles já decidiram se você é um gerente que ainda faz de conta que é IC, ou um IC que está de fato se tornando gerente. Eles percebem quais reuniões você cancela, quais 1:1s você remarca, o que você diz quando aparece. Eles não te contam o que decidiram. Eles apenas começam a ajustar o comportamento em torno disso.

O plano abaixo foi estruturado para forçar o segundo resultado. Cada bloco de 30 dias tem três a cinco entregas concretas, e todas elas são algo que você não pode fazer dentro do IDE.

Dias 1 a 30: Ouça, Audite, Apareça

O primeiro mês é de coleta de informações. Você vai querer consertar as coisas. Não conserte. Você ainda não sabe o que está realmente quebrado em comparação com o que apenas parece quebrado visto do seu lugar antigo.

10 reuniões individuais com subordinados diretos nas primeiras duas semanas

Se você tem oito subordinados diretos, isso é roughly uma reunião individual por dia durante duas semanas mais algumas reuniões de acompanhamento de 30 minutos. As mesmas três perguntas em todas:

1. Qual é a melhor coisa sobre trabalhar aqui agora?
2. Qual é a pior?
3. Se você fosse eu, o que mudaria nos primeiros 90 dias?

Anote à mão. Não tente resolver problemas durante a reunião. O maior erro que os novos gerentes de engenharia cometem nas primeiras reuniões individuais é ouvir uma reclamação e se comprometer a resolvê-la na hora, depois consertando a coisa errada ou quebrando a promessa três semanas mais tarde. "Me conta mais" e "Quero pensar sobre isso" são frases completas.

Ao final da segunda semana você terá de 30 a 50 observações distintas. Padrões vão emergir. Três subordinados diretos vão mencionar a mesma coisa quebrada com palavras diferentes. Esse é o seu mapa.

Audite a velocidade de entrega do time e o rodízio de plantão

Puxe os últimos 8 sprints. Você procura duas coisas:

• Tendência de vazão. Os story points concluídos por sprint estão estáveis, subindo ou caindo? Se estão caindo, quando começou? Vincule a eventos: uma reorganização, uma mudança de escopo, alguém saindo de licença.
• Distribuição do on-call. Puxe os logs de acionamentos e conte os incidentes por engenheiro no último trimestre. Se três pessoas estão carregando 70% dos acionamentos, você tem um problema de equidade e um risco de esgotamento, e você não sabia disso na semana passada porque ninguém reclamou em voz alta o suficiente.

Documente o que encontrar. Não corrija ainda. A auditoria é uma linha de base que você vai usar nos dias 31 a 60 quando conduzir seu primeiro retro.

Participe de 5 reuniões multifuncionais

Planejamento de produto. Revisão de design. Sales enablement (sim, vendas, porque seu time provavelmente entrega features que o time de AE precisa demonstrar). Sincronização de escalações de suporte. A reunião semanal que seu skip-level conduz com seus pares em outra área.

Você não está lá para falar. Você está lá para entender como seu time parece de fora. O gerente de produto que elogia seu time no standup pode revirar os olhos ao falar deles na reunião de planejamento multifuncional. O líder de suporte pode mencionar três escalações de clientes sobre as quais você nunca ouviu falar. A reputação do seu time vive em salas para as quais você não era convidado antes.

Anote nessas reuniões especificamente sobre seu time. Traga as observações de volta para seus subordinados diretos nas reuniões individuais sem citar quem disse o quê.

ZERO commits de código

Regra rígida. Se um bug crítico precisar das suas mãos, faça pair programming com um engenheiro e deixe que ele faça o merge.

Cada commit que você entrega no mês um é um sinal para o time de que o trabalho antigo ainda está disponível para você. Eles vão contornar você para entregar mais rápido. Vão parar de trazer os problemas humanos complicados porque percebem que você prefere estar no código. Você vai se sentir produtivo e vai estar se enganando.

A primeira vez que disse a um engenheiro sênior que faria pair programming com ele em uma migração difícil, mas que não ia fazer o push do commit, ele ficou incomodado por uns dez minutos e depois visivelmente mais tranquilo pelo resto do trimestre. Ele não queria eu digitando no repositório dele. Ele queria eu pensando em tudo o mais.

Dias 31 a 60: Conduza Uma Coisa, Corrija Uma Coisa, Diga Uma Coisa Difícil

O segundo mês é quando você passa de receber informações para gerar resultados. Três entregas, todas pequenas o suficiente para realmente concluir em 30 dias.

Conduza 1 retrospectiva

A primeira como facilitador, não como participante. Use os dados da auditoria de velocidade de entrega. O formato não importa muito (comece-pare-continue, bravo-triste-alegre, o que seu time usa). O que importa é que você traga à tona um padrão desconfortável e deixe a sala absorver isso.

Por exemplo: "Estamos fechando tickets, mas reabrindo 22% deles dentro de dois sprints. O que está acontecendo?" Depois fique em silêncio. Os primeiros 90 segundos serão silenciosos ou cheios de desvios. Aguarde. Os engenheiros vão eventualmente dizer coisas verdadeiras se você não preencher o silêncio com a sua própria teoria.

A primeira vez que conduzi um retro como gerente, falei por 18 dos 30 minutos. Essa foi a lição. Seu trabalho em um retro é perguntar, resumir e atribuir um ou dois encaminhamentos. Não conduzir a conversa.

Corrija 1 processo quebrado

A coisa mais simples que os subordinados diretos reclamaram nas reuniões individuais e que você consegue corrigir em duas semanas. Não a grande reformulação do desenho organizacional. A coisa que tem incomodado todo mundo há meses e que ninguém tem sido sênior o suficiente ou organizado o suficiente para simplesmente eliminar.

Exemplos reais que funcionaram:

• Standup que durava 45 minutos: reduzido para 15, formato mudado para assíncrono como padrão com uma sincronização ao vivo de 10 minutos apenas quando existem bloqueios.
• SLA de revisão de PR de três dias, frequentemente descumprido: publicado um documento de expectativas de uma página, adicionado um bot de lembrete no Slack, nomeado um revisor reserva por área.
• Passagem de on-call sem runbook escrito: exigida uma reunião de passagem de 20 minutos ao final de cada rodízio, com anotações em um documento compartilhado.

Escolha uma. Entregue a correção. Diga ao time que os ouviu. O ponto não é a melhoria do processo (embora seja bem-vinda). O ponto é que eles queriam ver se você realmente ouve, e a resposta agora é sim.

Faça 1 conversa difícil de feedback

Aquela que você tem evitado.

O engenheiro sênior que é brilhante mas atropela os júniores na revisão de código. O nível médio que continua perdendo estimativas por um fator de 3. O tech lead que está desengajado e o time está discretamente trabalhando ao redor dele.

Escreva o roteiro antes da reunião. Use a estrutura situação-comportamento-impacto-pedido:

• Situação: "Na revisão de design de ontem, quando a Priya propôs a abordagem baseada em fila..."
• Comportamento: "...você a interrompeu duas vezes e depois disse que o design 'não funcionaria' sem explicar o motivo."
• Impacto: "Dois outros engenheiros me disseram que não levam ideias iniciais para o canal do time mais, porque esperam ser rebatidos. Estamos perdendo contribuições de que precisamos."
• Pedido: "Preciso que você deixe as pessoas terminarem o raciocínio, e se discordar, faça uma pergunta antes de rebater. Você consegue fazer isso?"

Ensaie em voz alta. Entregue em uma reunião individual, nunca em grupo. Permita o silêncio depois. A conversa vai parecer terrível enquanto você a tem e visivelmente mais fácil da segunda vez em diante. Essa é a conversa que prova para você mesmo que você consegue fazer o trabalho.

Dias 61 a 90: Seja Dono dos Resultados, Planeje o Futuro

O terceiro mês é quando você para de ser "o novo gerente de engenharia" e começa a ser "o gerente de engenharia." Três entregas, todas visíveis para o seu skip-level.

Seja dono de um OKR do time

Não "apoiar a iniciativa de plataforma." Um resultado específico e mensurável pelo qual você será avaliado no final do trimestre.

Ruim: "Melhorar a experiência do desenvolvedor." Bom: "Reduzir o tempo mediano de revisão de PR de 38 horas para 12 horas até o final do Q3, medido via o Dashboard de métricas existente do GitHub."

Escreva. Obtenha a aprovação do seu skip-level. Diga ao time que é seu, não deles. Você vai defender o número, eles vão fazer o trabalho. Essa distinção importa porque o time assistiu a muitos gerentes empurrarem um OKR no prato deles e depois desaparecerem quando os números escorregaram.

Apresente um relatório de 90 dias ao seu skip-level

No máximo três slides. A estrutura que funciona:

• Slide 1, o que herdei. Linha de base de velocidade de entrega, distribuição do on-call, os três principais riscos que encontrei, os três principais pontos fortes. Duas frases cada.
• Slide 2, o que entreguei. O retro que conduzi, o processo que corrigi, o OKR do qual assumi a responsabilidade. Artefatos concretos que o skip-level pode verificar.
• Slide 3, o que estou pedindo. O plano de contratação para o segundo semestre e a proposta de dívida técnica (próximo item). Pedidos específicos, custos específicos, resultados esperados específicos.

Esse é o artefato que lhe garante um segundo ciclo de 90 dias de confiança. É também o que o seu skip-level vai citar para o chefe dele ao explicar por que te promoveu. Facilite para eles.

Proponha o plano de contratação do H2 e o plano de dívida técnica

Uma vaga aberta com uma JD que você escreveu (vincule o modelo de JD para staff software engineer) e uma lista ranqueada dos 3 principais itens de dívida técnica com estimativas de custo aproximadas.

O plano de contratação deve responder: qual papel, por que esse papel e não outro, o que fica desbloqueado quando a pessoa começa, qual é o trade-off se você não conseguir a vaga. Uma página.

A lista de dívida técnica deve responder, para cada item: o que quebra hoje por causa dela, custo aproximado de engenharia para corrigir (em semanas-pessoa), melhoria esperada (em termos mensuráveis como 30% menos acionamentos, 2 semanas de integração mais rápida, o que fizer sentido). Ranqueie os três. Defenda o ranqueamento quando for questionado.

Submeta. Defenda. Mesmo que você não consiga a vaga ou o orçamento para a dívida técnica, o ato de escrever e defender o plano é o que o move de "novo gerente de engenharia" para "gerente de engenharia com um ponto de vista."

Os Modos de Falha do Mundo Real

Três formas previsíveis de esse plano sair dos trilhos.

O chamado do IC para o código

Quando suas mãos estão com vontade de digitar, isso é abstinência, não fraqueza. Reserve 90 minutos por semana para "tempo de engenharia" (revisão de arquitetura, leitura de PRs sem fazer merge, depurando um problema difícil com um júnior) e chame assim. Não chame de programação. O rótulo importa porque te força a perguntar, toda vez, se o que você está prestes a fazer é mentoria ou fuga.

A crise de identidade "não sou bem um gerente"

Se você ainda está dizendo isso na semana seis, o time já percebeu. Eles ouvem isso como "estou planejando voltar a ser IC no momento em que isso ficar desconfortável," o que os faz menos propensos a trazer as coisas desconfortáveis para você.

Substitua por: "Sou um gerente que costumava entregar código. Agora entrego as pessoas que entregam código." Diga em voz alta da primeira vez que parecer estranho. Na semana dez não vai parecer mais.

A hipercorreção

O gerente de engenharia que lê três livros de gestão na semana um e chega na segunda-feira com um novo framework, um novo ritual e um standup com outro nome. Os subordinados diretos odeiam isso. Eles não pediram um novo sistema operacional. Eles pediram um gerente que ouve.

Ouça primeiro. Mude depois. A auditoria de 30 dias existe exatamente para você não fazer isso.

Templates e Ferramentas que Você Vai Realmente Usar

Quatro artefatos que valem a pena construir uma vez e reutilizar sempre:

• Roteiro de perguntas para o primeiro 1:1. As três perguntas acima, mais três de acompanhamento: "Como é uma ótima semana para você?" "Com quem no time eu deveria garantir passar mais tempo?" "O que eu deveria saber e que ninguém vai me contar?"
• Template de registro de observações de 30 dias. Três colunas: o que ouvi, o que vi, o que ainda não estou mudando e por quê. A terceira coluna é a disciplina.
• Template de relatório de 90 dias. Três slides, estrutura acima, limite rígido de contagem de palavras por slide para você não inflar o conteúdo.
• Roteiro de conversa de feedback difícil. Situação, comportamento, impacto, pedido. Imprima. Preencha antes de cada 1:1 difícil nos primeiros seis meses.

Medindo o Sucesso no Dia 90

Você vai saber que os 90 dias funcionaram se todas as cinco afirmações forem verdadeiras no último dia:

1. Cada subordinado direto teve pelo menos 6 reuniões individuais com você e consegue dizer no que você está trabalhando para ele.
2. A velocidade de entrega do time está medida e com tendência definida. Mesmo que a tendência seja estável, você sabe exatamente por quê.
3. Um processo está visivelmente melhor e o time te dá crédito por isso.
4. Seu skip-level consegue descrever o maior risco do seu time em uma frase porque você o comunicou.
5. Você não fez merge de código em 90 dias e o time está bem.

O último é o teste real. Os 90 dias não são sobre provar que você ainda sabe programar. São sobre provar que você consegue parar.

Saiba Mais

• Conduzindo 1:1s que Seus Subordinados Diretos Esperam Ansiosos
• A Mudança de Fazer para Liderar
• Gerenciando Antigos Colegas
• Template de JD para Staff Software Engineer