Postmortem blameless é teatro: 3 sinais no squad

“Fazemos postmortem blameless aqui.” É a frase mais citada em conversa de engenharia dos últimos anos, e também a mais desconectada da cultura real em que é dita. O postmortem acontece, a palavra “blameless” aparece no documento, e no mês seguinte o mesmo tipo de bug volta. Não porque o processo está quebrado. Porque ninguém tinha incentivo para avisar antes.

Amy Edmondson definiu segurança psicológica em 1999 como o estado em que o membro do time acredita que correr riscos interpessoais — perguntar, reportar erro, discordar, pedir ajuda — não resulta em punição ou humilhação. Em 2015, o Project Aristotle do Google analisou mais de 180 times e encontrou que o fator mais comum nos times de alto desempenho não era nem capacidade técnica, nem remuneração. Era segurança psicológica. E a parte difícil de aceitar é esta: declarar que a cultura é blameless não cria segurança psicológica. Ela aparece só quando o comportamento do líder bate com a declaração, incidente após incidente.

O custo invisível: o bug fica escondido

Edmondson identificou que em time sem segurança psicológica, o bug não é discutido, ele é corrigido em silêncio. Ou pior: a descoberta é atrasada até que o blast radius apareça em outro lugar. O postmortem que você acaba de rodar só cobre os bugs que não deu para esconder. Os bugs que couberam no silêncio nunca entraram na pauta.

Isso é diferente de “o time é descuidado”. É um incentivo bem calibrado. Se reportar erro derruba a avaliação de desempenho, a resposta racional do engenheiro é não reportar. O postmortem blameless pede o oposto desse incentivo, mas sem mudar o incentivo, só pede.

3 sinais de que a segurança psicológica quebrou (ninguém vai te avisar)

Os três sinais abaixo saem do capítulo que escrevi sobre o tema para o livro Truques Psicológicos do Engenheiro. Nenhum deles aparece em retrospectiva, porque todos os três operam no espaço do que não é dito.

Sinal 1: Pergunta reprimida

Membros param de perguntar o que não sabem. O medo específico é “vão achar que eu não sei nem isso”. A consequência não é só retrabalho. É que o entendimento compartilhado do sistema diverge silenciosamente entre quem tinha coragem de perguntar no começo e quem não tinha. Depois de 6 meses, você tem dois subgrupos dentro do mesmo time trabalhando em modelos mentais diferentes do mesmo código, e ninguém sabe disso ainda.

O sinal operacional: PR com comentário “só uma dúvida rápida” em que a dúvida é na verdade sobre uma invariante fundamental do sistema, e o autor da PR tratou como se já soubesse. A pergunta chegou tarde demais e envergonhada demais.

Sinal 2: Silêncio na discordância

Ninguém se opõe à direção técnica proposta. Reuniões em que “não há objeção” virou padrão são o sintoma mais citado por Irving Janis quando descreveu o pensamento de grupo em 1972. Janis analisou falhas históricas sob esse quadro: a invasão da Baía dos Porcos e o desastre do Challenger. Nos dois, pessoas na sala sabiam que a direção era problemática e não falaram.

A pressão de conformidade combina com o problema HiPPO (opinião da pessoa mais bem paga vira decisão). Em time coeso onde o líder sinaliza uma direção específica e o release está próximo, os quatro gatilhos de groupthink de Janis ficam todos ativos ao mesmo tempo. “Time unido” não garante boa decisão — pode criar o clima em que é difícil discordar.

Sinal 3: Ignorância pluralística

Todos no time têm o mesmo descontentamento sobre uma situação, mas cada um acha “só eu penso assim”. Hora extra naturalizada (“todo mundo faz, então eu também preciso”). Dívida técnica largada (“se ninguém aponta, talvez seja só impressão minha”). Reunião que virou ritual (“se todo mundo participa, deve ser necessária”). Uma revisão publicada em Frontiers in Social Psychology mostra que esse fenômeno é estudado em contextos sociais há mais de cem anos.

O perigo específico da ignorância pluralística é que, mesmo todos descontentes, ninguém levanta a voz, e a situação não muda. Não existe gatilho interno que a dissolva. Precisa de intervenção externa.

O que funciona (não é doçura, é franqueza)

Edmondson insiste em um ponto que costuma ser mal interpretado: segurança psicológica não é “ambiente em que tudo é permitido”. Segurança psicológica e exigência de padrão alto coexistem. Apontar uma decisão tecnicamente errada continua sendo necessário. Feedback sobre problema de desempenho deve ser entregue. Cumprir prazo e critério de qualidade continua responsabilidade.

A diferença é que esses apontamentos acontecem sem punição informal (humilhação, exclusão social, avaliação enviesada) para quem recebe. Não é “doçura”, é “franqueza”. Não esconder problema, reportar erro, expressar discordância, pedir ajuda — só quando esse ambiente permite franqueza é que o padrão alto se mantém.

Mecanismos operacionais que atacam cada sinal

Três mecanismos sobre os quais a literatura e a prática relatada por engenheiros convergem:

Pesquisa anônima periódica para dissolver ignorância pluralística. Coletar as opiniões anônimas e mostrar o resultado agregado — “olha, 70% do time acha que essa reunião é ritual” — faz o descontentamento virar fato público. Isso não resolve o problema, mas tira ele do espaço do “só eu penso assim”. É um passo necessário.

Líder expõe o próprio ponto fraco primeiro. “Essa área eu não entendo bem, me ensina.” “Semana passada cometi esse erro.” A reciprocidade age aqui — quando o líder mostra fragilidade, o membro consegue mostrar também. Mas só funciona se for genuíno. Fragilidade performada é lida como manipulação em uma iteração.

Hábito de 5 segundos antes de reagir a opinião contrária. Diante de “não concordo com essa decisão”, esperar cinco segundos antes de responder reduz a resposta defensiva reflexa (“não, isso é diferente”). Parece bobo, mas é o único mecanismo que vi mudar o comportamento de líderes que juravam “receber bem feedback” e na prática reagiam defensivamente em 300ms.

Observação de harness: o segundo bug é o diagnóstico

Opero um harness autônomo em mais de 15 domínios há meses. Quando um bug no mesmo lugar aparece pela segunda vez em menos de 60 dias, meu diagnóstico padrão não é mais “melhorar o teste”. É “por que o primeiro postmortem não produziu mudança estrutural?”. E a resposta tipicamente não é técnica. Em agente 24h: segundo incidente, 3 falhas no postmortem descrevi um caso específico em que o segundo incidente só apareceu porque o agente acumulou estado por tempo suficiente — algo que o primeiro postmortem, feito sobre 24h de execução, não tinha como ver.

A analogia com times humanos é direta. Postmortem blameless funciona quando o custo esperado de reportar a causa real é menor que o benefício esperado. Se a cultura inverte essa conta — mesmo que só uma vez, mesmo que informalmente — o postmortem continua acontecendo, continua tendo a palavra “blameless” no documento, e continua produzindo zero mudança estrutural. É teatro.

A regra que uso agora, tanto para agentes quanto para times humanos: trate o primeiro incidente como ponto de dados. Trate o segundo incidente do mesmo tipo como ponto de dados sobre a cultura, não sobre o sistema.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews