Tem um tipo de corte em TI que dói mais porque ele vem com uma sensação muito específica de distorção: o projeto desandou lá em cima, as decisões ruins ficaram anos sem correção, mas quem sai pela porta é justamente quem passou esse tempo segurando a operação.
Foi esse o gatilho de um relato publicado no Hacker News no fim de semana. Segundo o autor do post, a parceira dele passou 15 anos em uma big tech, saiu de IC para gestão, liderava mais de 30 pessoas e quase não conseguia usar férias porque estava sempre trabalhando. Ainda assim, acabou demitida depois de semanas conduzindo cortes no próprio time — cortes que, no relato, nasceram de erros acumulados em níveis acima dela, não da qualidade do trabalho que ela e o time vinham entregando.
O detalhe que mais pesa no caso não é só a demissão. É o padrão. A equipe toda vai embora, o estrago fica evidente, mas a figura apontada como origem do caos continua de pé. Para quem já passou por empresa grande, isso tem cara de déjà vu.
O caso não viralizou porque é raro. Viralizou porque é reconhecível
Nos comentários, a discussão foi menos sobre uma empresa específica e mais sobre uma mecânica corporativa que muita gente em tecnologia sente na pele. Um dos leitores resumiu o problema dizendo que certos gestores são ótimos em manage up: sabem vender narrativa para cima, mesmo quando atrapalham tudo para baixo. Outro lembrou que grandes empresas não funcionam como meritocracia limpa; funcionam também por proximidade com poder, timing, política interna e proteção mútua.
Isso explica por que tanta gente boa entra em modo exaustão antes de perceber o risco. Quem está perto da entrega tende a acreditar que resultado técnico, resiliência e esforço vão ser suficientes para protegê-lo. Só que, em várias estruturas, o jogo não é decidido só onde a entrega acontece. Ele também é decidido onde a história do fracasso é recontada.
E aí mora uma crueldade bem conhecida em TI: quando a empresa precisa mostrar reação rápida, é mais fácil cortar headcount visível do que admitir anos de direção ruim, incentivo torto ou liderança blindada.
Quando a falha vira caça ao culpado, a empresa aprende menos e corta pior
Esse ponto conversa direto com uma lição clássica de engenharia de confiabilidade. No SRE Workbook do Google, a defesa de postmortem sem culpa parte de uma ideia simples: focar em quem errou costuma deixar o sistema mais fraco, não mais forte.
O livro bate em alguns pontos que servem muito além de incidentes técnicos:
- o foco útil é entender o que permitiu a falha, não só quem estava na cadeira quando ela apareceu;
- culpa pública empurra times para comportamento defensivo, silêncio e aversão a risco;
- ação de verdade melhora processo, automação, prioridade e desenho organizacional — não só o discurso sobre “mais atenção da próxima vez”.
Traduzindo para o mundo do trabalho: quando uma área começa a tropeçar por meses e a única resposta no fim é trocar a linha de frente, a empresa pode até cortar custo no trimestre, mas continua sem mexer na engrenagem que produziu o problema.
Por que isso aparece tanto em tecnologia?
Porque TI costuma concentrar três ingredientes perigosos ao mesmo tempo:
- complexidade suficiente para esconder causa real: quando tudo depende de produto, orçamento, plataforma, people e prazo, dá para empurrar culpa para vários lados;
- times que seguram muito no braço: profissionais bons tapam buraco, absorvem retrabalho e mantêm a casa em pé por tempo demais;
- métrica ruim de curto prazo: parece mais objetivo cortar um time inteiro do que admitir que a tese do projeto, da liderança ou da reorganização estava errada.
É por isso que tantos relatos parecidos aparecem em fóruns abertos. Não é só sobre injustiça emocional. É sobre estrutura. Em muita operação, quem carrega a execução vira amortecedor. E amortecedor bom tem um problema: ele mascara o tamanho real da batida.
Os sinais que costumam aparecer antes do corte
Nenhum checklist prevê tudo, mas alguns padrões merecem atenção quando começam a virar rotina:
- mudança de direção toda semana sem fechamento claro do que morreu e do que continua;
- liderança cobrando velocidade sem priorização real;
- decisão errada recorrente sempre tratada como “ajuste de contexto”;
- gente muito boa acumulando função para compensar falha estrutural;
- cortes fatiados, comunicados em ondas, para diluir a percepção do tamanho do rombo.
Quando isso se junta, o risco não é só burnout. É virar a camada sacrificável de um problema que nasceu muito acima da sua alçada.
O que dá para fazer do lado de cá
Não existe blindagem perfeita, mas existem algumas leituras úteis:
- registre contexto: entregas, alertas levantados, decisões contestadas e mudanças de rumo importam mais do que memória oral quando a história começa a ser reescrita;
- observe quem some e quem se fortalece depois de erro grande: isso revela mais sobre a política interna do que qualquer discurso de cultura;
- não confunda ser indispensável com estar protegido: muita gente só descobre essa diferença tarde demais;
- mantenha opcionalidade viva: currículo, rede, portfólio e conversa de mercado continuam sendo defesa prática, não paranoia.
É duro, mas real: em empresa saudável, postmortem melhora sistema. Em empresa doente, postmortem vira teatro e o corte desce para quem ainda estava tentando segurar a parede.
O caso do Hacker News bateu justamente por isso. Não parece exceção. Parece padrão demais.
