Postmortem blameless: 1 contraexemplo apaga

Declarar postmortem blameless na wiki do squad leva uma tarde. Manter a cultura blameless no dia em que o incidente foi feio, o deploy era do estagiário, e o cliente ligou, leva anos. E um único deslize do líder pode apagar meses de trabalho.

Essa é a parte que a maior parte dos textos sobre “cultura blameless” não conta. A literatura acadêmica conta — está em Edmondson (1999), no Project Aristotle (2015) do Google e em Janis (1972) — mas chega nos times como slogan. “Aqui a gente faz postmortem blameless.” Ponto. O resto é tratado como natural, e não é.

O conceito, rápido: segurança psicológica não é “gentileza”

Amy Edmondson, da Harvard Business School, definiu segurança psicológica em 1999 como “a crença compartilhada de que o time é seguro para correr riscos interpessoais”. Correr risco interpessoal quer dizer coisas banais do dia a dia: perguntar, discordar, reportar erro, pedir ajuda. Coisas que, num time sem segurança psicológica, saem caras.

A própria Edmondson insiste num ponto que sempre some em resumo: segurança psicológica não é o oposto de exigência. É o oposto de medo. Um time com segurança psicológica continua tendo meta apertada, feedback direto e critério técnico. A diferença é que, quando alguém ergue a mão para dizer “esse deploy está errado”, ninguém é humilhado por isso.

Em 2015, o Google publicou o Project Aristotle. Analisaram 180 times e o fator mais correlacionado com time de alto desempenho não era QI médio, nem senioridade, nem remuneração. Era segurança psicológica. Isso virou a citação favorita de slide de RH por motivo bom: o dado é sólido e confrontável.

E aí entra a parte do postmortem.

Blameless: o teste prático da cultura, não o nome da reunião

Postmortem blameless é a prática-símbolo da segurança psicológica em engenharia. Quando ocorre um incidente, o foco vai para “o que aconteceu” e “como evitar” — não para “de quem é a culpa”.

O ponto é que a cultura blameless não funciona só por declaração. Só quando o líder, na prática, mantém o comportamento de não culpar quem causou o incidente é que o time começa a acreditar “realmente não culpam aqui”.

Um único contraexemplo faz a confiança recuar muito.

Essa frase parece exagero retórico. Não é. Ela reflete um fenômeno da literatura de segurança psicológica que costuma chamar de negativity bias em contexto de confiança organizacional: evidência negativa pesa mais que evidência positiva na atualização de crença sobre “esse ambiente é seguro?”. Meses de postmortem blameless bem conduzidos somam-se devagar. Uma reunião em que o líder, cansado, diz “mas por que você mergeou isso sem rodar os testes?” apaga de uma vez.

Isso tem consequência operacional específica, e é por isso que vale levar a sério:

• O próximo incidente tende a ter menos detalhe no postmortem. Gente não conta o que não precisa contar.
• Quem causou o próximo bug tende a demorar mais para avisar. Minutos viram horas, horas viram manhãs.
• Análise de causa raiz fica mais rasa. “Foi um erro de digitação” vira versão oficial de “faltava checagem no pipeline”.

Em três meses dá para desfazer o estrago, se o líder assumir publicamente que errou naquele momento. Em um ano, talvez. Sem reconhecimento, o time aprende outra regra: aqui faz blameless quando dá. O que, para efeito prático, é o mesmo que não fazer.

Isto não é pensamento de grupo (Janis) nem ignorância pluralística

Vale separar três fenômenos que às vezes aparecem no mesmo texto e são distintos.

Pensamento de grupo (Janis, 1972, estudando falhas como a invasão da Baía dos Porcos; o próprio Janis aplicou o framework ao Challenger em 1991) é o que acontece em time muito coeso: pensamento crítico é suprimido para preservar consenso. A doença aqui é concordar demais.

Ignorância pluralística é quando todo mundo tem a mesma crítica em silêncio, cada um achando “sou só eu que penso isso”. A doença aqui é a sala inteira acreditar numa minoria imaginária.

Falha da cultura blameless por contraexemplo é outra coisa: o time tinha segurança psicológica, tinha postmortem blameless funcionando, e a confiança foi retirada por uma ação concreta e observável do líder. A doença aqui é um sinal emitido ao time — “nesse tipo de erro, culpa-se” — e o aprendizado é rápido.

As três se cruzam em time de engenharia real, mas a intervenção para cada uma é diferente. Para pensamento de grupo, traga ponto de vista externo. Para ignorância pluralística, faça pesquisa anônima. Para blameless quebrado, o líder precisa reconhecer publicamente o deslize — não “em 1-a-1 com quem foi culpado”, na reunião do time inteiro, onde a culpa foi expressa. Se o deslize foi público, a correção precisa ser pública.

O que fazer na prática

Três coisas que valem gastar energia para quem quer blameless que dure meses, não semanas:

Enxergar o contraexemplo como evento crítico, não como “exceção”. No dia seguinte a um deploy ruim, a cabeça do líder está cheia de prazo, cliente, custo. É exatamente aí que a palavra “você” na frase errada vira o contraexemplo. Pré-escreva o que se vai dizer no próximo postmortem difícil. Parece exagero. É mais barato que refazer a cultura.

Separar análise técnica de responsabilidade administrativa. Blameless não quer dizer “ninguém responde por nada”. Quer dizer que o postmortem é para aprender sobre o sistema, e qualquer consequência de desempenho vai em outra conversa, com outro ritmo. Misturar os dois na mesma reunião é a receita para blameless virar teatro.

Publicar a correção quando houver deslize. “Semana passada no postmortem eu culpei Fulana, errei, me desculpo publicamente”. Essa frase, em reunião do time, recupera credibilidade mais do que seis postmortems impecáveis depois. O custo é constrangimento pessoal do líder. O retorno é o time lembrar que o compromisso com a cultura inclui o próprio líder.

Nada disso requer ferramenta. Requer memória — do líder, sobre o que foi dito, e do time, sobre o que foi feito. O contraexemplo fica na memória do time por tempo desproporcional. Vale lembrar antes, não depois.

---

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