Um Dia na Vida do Gerente de Engenharia: O Que a Descrição de Cargo Não Conta

São 8h47. Seu engenheiro de plantão recebeu um alerta às 3h14 sobre uma réplica do Postgres que se recuperou sozinha às 3h22, o que significa que ela dormiu oito minutos em vez do resto da noite. Seu skip-level quer uma atualização do roteiro até o meio-dia e você ainda não abriu o Notion. Você tem um 1:1 com um IC sênior em 13 minutos para o qual não se preparou, e o recrutador que te colocou nesse cargo seis meses atrás descreveu tudo como "liderar uma equipe de alta performance."

Essa frase é verdadeira da mesma forma que "toco um restaurante" é verdadeira quando você está, na prática, fazendo inventário às 23h e pedindo desculpas a um cliente fiel por um pedido errado. É o título. O trabalho é tudo que está por baixo.

É assim que o dia realmente parece para um gerente de engenharia com 5 a 12 subordinados em uma empresa de B2B SaaS. Horários reais, interrupções reais, trocas reais. Se você é IC e está pesando a mudança, leia isso e pergunte a si mesmo se parece um trabalho que você faria por anos. Se você já é EM e sente que está falhando porque seu dia não é nada mais que interrupções, leia isso e reconheça que você não está falhando. Você está fazendo o trabalho.

8h00: Preparação para Standup, Triagem no Slack e PagerDuty

Antes da equipe se conectar, você faz o trabalho que ninguém vê.

Abra o PagerDuty. Leia os incidentes da noite passada. Quem foi acionado, o que disparou, foi real ou foi o mesmo alerta instável que você sinalizou para limpeza três sprints atrás? Se foi real, seu engenheiro de plantão precisa de cobertura hoje; diga a ele pelo Slack para pular o standup e dormir mais 90 minutos. Se foi ruído, isso é um ticket para quem cuida de observabilidade. De qualquer forma, decida antes do standup para poder absorver a interrupção em vez de deixar a equipe sentir o impacto.

Depois, Slack. Você tem 47 não lidas em seis canais. Você não está lendo pelo conteúdo. Está varrendo por duas coisas: quem está bloqueado e quem está frustrado. Engenheiros bloqueados precisam de um caminho aberto até as 10h ou perdem metade do dia. Engenheiros frustrados em threads públicas precisam de um DM, não de uma resposta pública, e o DM provavelmente precisa acontecer esta manhã.

Abra o Linear. Ou o Jira. Seja qual for o que sua equipe usa, a pergunta é a mesma: quais tickets estão presos em revisão, quais estão bloqueados em uma dependência fora da equipe e quais parecem "em andamento" mas não se moveram em quatro dias? Esta última categoria é a perigosa. Um engenheiro que não moveu um ticket em quatro dias está ou bloqueado e não vai dizer, trabalhando em algo que não te contou, ou silenciosamente olhando outros empregos. Você precisa saber qual deles até sexta.

Você não escreveu código em três semanas. Costumava fazer essa parte do dia com um café e um compilador. Agora faz com um café e contexto de sete pessoas carregado na cabeça. A mudança de "eu escrevo código" para "eu abro caminho para 7 pessoas que escrevem código" é a primeira coisa sobre a qual ninguém te avisa, e é a parte que a maioria dos ex-ICs lamenta silenciosamente nos primeiros seis meses.

9h00: O 1:1 Para o Qual Você Não Se Preparou

O 1:1 é seus 30 minutos de maior alavancagem da semana, e é a primeira coisa sacrificada quando o sprint planning se estende. Hoje é com Maya, uma engenheira backend sênior. Ela está aqui há três anos. Foi ela quem fez sua última grande migração. E há duas semanas seu LinkedIn mudou silenciosamente de "aberto a oportunidades: não" para "aberto a oportunidades: sim."

Você não começa com isso. Começa com: "Como você está nessa semana?" E então fica quieto.

Um 1:1 real não é uma atualização de status. Atualizações de status acontecem no Linear e no standup. O 1:1 é para tudo que não cabe em um ticket: o feedback que ela tem guardado, a decisão de arquitetura com a qual discorda, o fato de que seu gestor (você) não pressionou o suficiente quando produto cortou o redesenho dela pela metade. Seu trabalho é criar segurança para dizer a coisa difícil, e depois agir sobre o que ela diz.

Às 9h18, o PagerDuty dispara. Não é o serviço da sua equipe, mas está próximo o suficiente para o Slack acender. Você dá uma olhada no celular. Maya vê você olhar. Aqui está o roteiro que funciona:

"Não é nosso, mas o Slack vai ficar barulhento. Me dê 20 segundos para silenciá-lo, e depois continuamos. Seu tempo é mais importante do que aquele thread."

Aí você realmente o silencia. Você não fica meio ouvindo pelos próximos 12 minutos enquanto seus olhos rastreiam notificações do Slack. O 1:1 recebe sua atenção total ou você o cancela. Não existe meio-termo. O meio-termo é como engenheiros seniores aprendem que seu gestor não está realmente presente, e é assim que o LinkedIn de Maya muda de "sim" para "acabei de aceitar uma proposta."

10h30: Revisão de PR, Mas Não Por Correção

Você abre o GitHub. Ou GitLab. Há 14 PRs abertos em sua equipe. Você não os está revisando por correção. Seu staff engineer revisa por correção, e ela é melhor nisso do que você agora.

Você está revisando pelo fluxo.

Quem está esperando mais de 48 horas por uma revisão? Esse engenheiro está perdendo o ritmo e provavelmente mudando de contexto para outra coisa, o que significa que quando a revisão finalmente chegar, ele vai precisar de uma hora para recuperar o contexto. Encontre o revisor, descubra por que está preso, desbloqueie.

Quais dois PRs estão tocando o mesmo arquivo? É um conflito de merge no caminho, e um desses engenheiros vai perder uma manhã com um rebase. Coloque-os em uma chamada de 10 minutos agora.

Qual PR tem seis rodadas de comentários de nitpick em uma mudança de 40 linhas? É um engenheiro sênior sendo excessivamente cuidadoso com um júnior, e isso está corroendo a confiança em ambas as direções. Você não comenta na thread. Você manda DM para o sênior: "Ei, a mudança está ótima. Aprove e vamos em frente." Essa é a decisão que ninguém mais vai tomar, porque ninguém mais tem autoridade para isso.

O GitHub é uma ferramenta de código para seus engenheiros. Para você, é uma superfície de gestão, um painel em tempo real de onde a atenção está presa, onde a colaboração gera atrito e onde a velocidade de entrega da equipe está vazando por gargalos de revisão. Chame isso de imposto da fila de PR. Cada PR parado mais de dois dias tem juros compostos em foco perdido, e você é a única pessoa cujo trabalho é notar.

11h15: Sprint Planning, Depois a Interrupção

Você está há 15 minutos refinando o board do Linear do próximo sprint com seu tech lead. Está pressionando de volta em uma história que diz "investigar migração de provedor de autenticação" porque isso não é uma história, é um trimestre de trabalho disfarçado de uma tarde de terça-feira.

Slack: "oi, tem 2 min para uma pergunta rápida?" Do VP de Produto.

Nunca são dois minutos. Nunca é uma pergunta. A "pergunta rápida" é "estamos adiantando o lançamento da funcionalidade de IA em três semanas, o que sua equipe consegue realisticamente entregar até lá?" Responder isso exige que você saiba a capacidade da equipe, os compromissos do sprint atual, a dívida técnica que está bloqueando a funcionalidade de IA, o PTO do engenheiro sênior no mês que vem e a realidade política de que dizer "não, não conseguimos" é uma frase que define carreira e você só pode usar algumas vezes por ano.

Você atende a chamada. Não dá a resposta na chamada. Diz: "Deixa eu ver as dependências e volto com um número real até as 16h." Depois volta ao sprint planning às 11h38 com seu tech lead, que ficou educadamente olhando para a tela por 23 minutos.

Esse é o papel que nenhuma descrição de cargo menciona: tradutor de contexto. Você fica entre a estratégia executiva ("queremos IA no Q3") e a realidade da engenharia ("a migração de autenticação bloqueia isso, e o engenheiro que conhece autenticação está de licença parental"). Você não pode dizer sim para os dois. Seu trabalho é traduzir um no outro de uma forma que não quebre a confiança em nenhuma direção. Algumas semanas você faz isso bem. Algumas semanas faz mal e sua equipe fica desorientada. Os dois são normais.

13h00: A Reunião Consigo Mesmo Que Nunca Acontece

Depois do almoço, sua agenda mostra "FOCO: documento de planejamento Q3." Está lá há três semanas. Move todos os dias.

Esse é o problema da reunião com você mesmo. O trabalho que requer pensamento ininterrupto, seu plano trimestral da equipe, suas avaliações de desempenho, a decisão de arquitetura que seu staff engineer escalou para você na sexta, nunca tem um prazo duro hoje. Por isso sempre perde para o trabalho que tem. O alerta de plantão. O DM no Slack do engenheiro que precisa de cobertura. A "pergunta rápida" do VP.

A maioria dos EMs perde essa batalha. O documento Q3 é escrito às 23h do domingo porque seu diretor precisa dele na segunda de manhã. As avaliações de desempenho são apertadas na semana antes do prazo e se nota.

A solução é sem glamour: bloqueie o tempo de foco na agenda e trate como uma reunião externa. Recuse pedidos sobrepostos. Aceite que algumas semanas você vai perder o bloco para um incêndio real, e tudo bem, mas o padrão tem que ser defendido. Os engenheiros que se tornam Senior EMs e Diretores são os que aprenderam a proteger seu próprio tempo de pensar antes de se tornar uma crise.

15h30: Notion Assíncrono, Não Slack em Tempo Real

No meio da tarde, seu cérebro está exausto. É quando você deveria estar fazendo seu trabalho de menor pensamento e maior volume: escrevendo a documentação que fica no Notion e não muda nada no seu dia mas vai compor ao longo dos próximos dois trimestres.

A atualização do manual da equipe. O runbook de plantão que seu engenheiro pediu há duas semanas. As notas da retrospectiva do último sprint que você prometeu circular. O documento de calibração do ciclo de contratação que seu recrutador está esperando.

Nada disso é urgente. Tudo isso é importante. O efeito composto é que daqui a seis meses, quando você integrar um novo engenheiro, ele vai ler três páginas do Notion e ter um tempo de adaptação de uma semana em vez de fazer as mesmas perguntas ao seu tech lead por um mês. Esse é o alavancagem do trabalho escrito, e é invisível até você parar de fazê-lo e assistir a equipe desacelerar sem que ninguém consiga apontar por quê.

17h00: Trabalho no Dossiê de Promoção

A equipe está saindo. Você abre o Notion. Está escrevendo dois dossiês de promoção (um para um engenheiro indo para Sênior, um para um indo para Staff) e uma auto-avaliação para si mesmo.

Os dossiês de promoção são o trabalho postergado todos os dias até que a temporada de avaliação de desempenho chegue como um caminhão. E os engenheiros que são promovidos são aqueles cujos gestores escreveram o caso ao longo de todo o ciclo, com evidências específicas, não os cujos gestores enfiaram tudo em um fim de semana com linguagem vaga sobre "impacto demonstrado."

Aqui está um trecho de template do Notion que realmente funciona:

## Caso de Promoção: [Nome] → [Nível]

### O que mudou no escopo (últimos 2 trimestres)
- [Projeto específico, conduzido do início ao fim, com resultado mensurável]
- [Colaboração multifuncional específica com resultado nomeado]
- [Momento específico de mentoria com mentee nomeado e resultado]

### Evidências de que o próximo nível já está acontecendo
- [Link para doc de design que escreveu]
- [Link para incidente que liderou]
- [Link para feedback de par ou skip-level]

### Riscos que o painel vai levantar (e respostas)
- [Risco]: [Resposta antecipada]
- [Risco]: [Resposta antecipada]

### Pedidos ao painel
- [O que você precisa que ponderem mais ou menos]

A seção de riscos e respostas é a que a maioria dos gestores pula. É a que vence. Os painéis de promoção são céticos por padrão, e um dossiê que antecipa as objeções deles faz 80% do trabalho antes de abrirem a boca.

Você termina o primeiro dossiê às 17h51. Seu filho tem uma apresentação às 19h. Você vai fazer o segundo dossiê amanhã, exceto que amanhã tem um 1:1 que esqueceu, uma revisão de incidente e um painel de candidato. Então vai fazer na quinta. Talvez.

O Ponto de Inflexão do Crescimento: 5 Engenheiros para 9

Tudo que acabei de descrever funciona com 5 engenheiros. Quebra com 9.

Com 5, você consegue manter todos os PRs na cabeça. Pode ter 1:1 semanal com todos e ainda ter tempo para pensar. Você sabe quem está preso antes de perguntarem, porque consegue ver pela linguagem corporal no standup.

Com 9, não consegue. A matemática não funciona. Nove 1:1s de 30 minutos por semana é 4,5 horas; com preparação e acompanhamento, é um dia inteiro. Os PRs que você costumava dar uma olhada agora precisam de um filtro do tech lead antes de chegarem até você. Os standups param de ser sinal e viram teatro de status porque há vozes demais.

Os sistemas que você ignorou com 5 se tornam inegociáveis com 9: um charter escrito da equipe para que novos integrantes saibam a régua, um rodízio de plantão que não depende da sua memória, um critério de contratação que existe fora da sua cabeça, e 1:1s quinzenais para as pessoas mais seniores porque precisam menos e semanais para as mais novas na equipe ou no nível sênior.

Quando você faz a mudança para quinzenal, alguém se sente negligenciado. Diga o motivo diretamente. "Estou mais sobrecarregado do que estava. Quinzenal é o que consigo manter. Se algo urgente aparecer, meu DM no Slack está aberto e respondo em menos de uma hora." A honestidade compra mais boa vontade do que os 30 minutos perdidos custam.

O Que a Descrição de Cargo Errou

"Liderar uma equipe de alta performance" realmente significa:

• Proteger o foco deles. A maior parte do seu dia é absorver o caos para que eles não precisem.
• Traduzir a ambiguidade. A estratégia executiva é vaga de propósito. Sua equipe precisa de tickets, não de vibes.
• Defender o tempo deles. Dizer não para a "pergunta rápida" do VP faz parte do trabalho, não é desvio dele.
• Escrever o documento que ninguém mais vai escrever. Runbooks, charters, dossiês de promoção, resumos de retro.
• Absorver o estresse para que eles não precisem. Esse é o núcleo sem glamour do papel e a parte que esgota as pessoas.

A descrição de cargo diz "gerar resultados." O dia diz "escreva a página do Notion que significa que a próxima pessoa não vai precisar descobrir isso do zero."

Fechamento

Se tudo neste artigo parece energizante (o 1:1 para o qual você realmente gostaria de ir, o caos que gostaria de traduzir, o lento acúmulo de documentação escrita que ninguém mais vai fazer), você está pronto.

Se parece desgastante (você preferiria entregar código do que absorver reuniões, preferiria resolver problemas técnicos difíceis do que humanos), o plano de carreira IC não é uma rebaixamento. É uma forma diferente de trabalho sênior, e a indústria está finalmente recompensando-o adequadamente. A JD de Staff Software Engineer é o complemento deste artigo por um motivo. Leia os dois. Escolha aquele cujas partes difíceis você está disposto a viver pelos próximos cinco anos.

A resposta certa é aquela em que os dias ruins ainda parecem um trabalho que vale a pena fazer.

Saiba Mais

• JD de Staff Software Engineer (complemento)
• Conduzindo 1:1s Que Engenheiros Não Temem
• A Transição de IC para EM
• Escrevendo Dossiês de Promoção Que Realmente Funcionam