Um engenheiro sênior fez entregas regulares por sete meses, participando das reuniões e respondendo aos PRs (pull requests) dentro do SLA do time. Numa segunda-feira mandou carta de demissão com dois dias de aviso e pediu férias acumuladas pra cobrir o restante. A liderança reagiu instantaneamente, pedindo uma reunião para tentar convencê-lo a ficar; proposta prontamente recusada. Quando fui chamado para reconstruir o histórico com a tech lead, o padrão estava escondido bem debaixo do nariz. Os comentários dos PRs vinham encurtando ao longo de quatro meses, e a participação em discussões de arquitetura havia caído a quase zero. As mensagens no canal do squad migraram de respostas substantivas pra frases curtas e, por fim, emojis de confirmação. O colapso não foi súbito, mas o reconhecimento pela liderança foi.
Na classificação do CID-11, o código QD85 é rotulado como "burnout", um fenômeno ocupacional resultante de um estresse crônico não gerenciado, caracterizado pela exaustão energética, pelo distanciamento mental e pela redução da eficácia profissional. A OMS é explícita em afirmar que não se trata de uma condição médica. Essa distinção importa porque desloca o problema do campo clínico pro campo ocupacional: o burnout de um engenheiro é um sinal sobre o sistema de trabalho, não um diagnóstico sobre o indivíduo. O Engineering Leadership Report 2025 da LeadDev, plataforma de conteúdo pra liderança de engenharia, registrou 22% dos respondentes em nível crítico de burnout e 24% em nível moderado. Pouco menos da metade operava em nível crítico ou moderado.
Essa leitura ganhou peso institucional no Brasil. Desde 26 de maio de 2026, a NR-1 passou a exigir que as empresas incluam os fatores de riscos psicossociais relacionados ao trabalho no inventário do PGR, e o que antes era orientação virou passível de autuação. Não me cabe a leitura jurídica da norma, e não é esse o ponto. O ponto é que a obrigação formal apenas codifica o que a boa liderança técnica já deveria fazer: tratar o burnout como risco do sistema de trabalho, mensurável e gerenciável, e não como fragilidade individual. Para o líder de engenharia, isso significa que a detecção deixa de ser um gesto voluntário e vira uma responsabilidade organizacional.
O sinal precoce mais confiável no ambiente técnico que eu costumo procurar é a degradação da densidade textual nos artefatos assíncronos. Um engenheiro que antes abria PRs com descrição longa, contexto, justificativa e que passa a abrir PRs com uma linha e link pro ticket, está produzindo um forte sinal de redução do engajamento cognitivo. O mesmo vale pra revisão de código: a queda do comentário substantivo pro aprovado com emoji, sustentada por semanas, precede de forma consistente a conversa de demissão. Esse sinal é rastreável em qualquer time que use git e trabalhe com pull-requests, mesmo sem qualquer instrumentação adicional. Entretanto, em tempo de IA, a liderança pode simplesmente instruir um modelo para analisar o histórico de interações do time com frequência mensal e, em minutos, identificar a mudança antes que ela se consolide.
Quando o engenheiro passa a entregar estritamente o que foi pedido e nada além, o sistema está sinalizando uma contração do escopo voluntário. Engenheiros engajados tendem a pegar trabalho adjacente ao atribuído, como corrigir o bug encontrado no caminho ou abrir discussão sobre débito técnico que atrapalhou a implementação. O desaparecimento desse comportamento marca uma perda do investimento afetivo no código, no produto e no time. Como a entrega continua, uma liderança que mede apenas throughput não consegue enxergar o problema. Mas aos poucos a engenharia passa a operar em um modo estritamente contratual. Um modo com prazo de validade curto.
Como estes episódios raramente são isolados, fui buscar os git logs de um engenheiro que tinha pedido demissão no mês anterior e encontrei mais de 60 dias em que seus commits foram concentrados entre 22h00 e 01h00. Antes disso ele comitava em horário comercial. Esse deslocamento do ritmo de commits tem duas manifestações opostas que apontam pro mesmo problema: a jornada noturna sustentada, onde o engenheiro tenta compensar exaustão com mais horas e acelera a degradação, e o espaçamento durante o dia com janelas longas de inatividade, onde a concentração contínua já não se sustenta. Nos dois casos o padrão aparece antes do burnout ser verbalizado. Um git log filtrado por autor e hora do dia, revisado mensalmente, custa cinco minutos e revela o que nenhuma 1:1 vai revelar.
A retração da voz em espaços síncronos pode ser mais difícil de rastrear, mas é igualmente reveladora. O engenheiro que participava de discussões com opinião fundamentada e que passa a concordar com o consenso sem articular sua posição está economizando energia cognitiva que antes investia por conta própria. No time remoto a câmera desligada e o modo ouvinte permanente mascaram a retração. No presencial ela aparece como redução da interação lateral, aquela conversa no corredor que alimenta decisões informais. Gestores raramente percebem porque estão ocupados medindo presença, e não participação.
A pergunta operacional que a liderança técnica precisa responder com frequência mensal não é se o engenheiro está bem, porque a resposta a essa pergunta numa 1:1 é quase sempre calibrada pra se proteger. A pergunta é se os artefatos do trabalho dele mudaram de caráter nos últimos trinta ou sessenta dias. A resposta está nos dados que o time já produz. O custo da detecção é baixo. O custo de não detectar é o turnover de seis a nove meses de salário por pessoa perdida (estimativa SHRM pra empregado médio, com faixas ainda maiores pra engenheiros seniores), somado ao impacto no restante do time que observou o colega entrar em colapso sem que ninguém reagisse a tempo.