 |
| Bellacosa Mainframe e a omission bias |
☕ Um Café no Bellacosa Mainframe
Omission Bias: Doctor Who, COBOL e o Dia em que Não Fizemos Nada — e Isso Também Foi uma Decisão
Uma viagem pela TARDIS dos incidentes para entender por que deixar acontecer pode parecer menos culpável do que agir, mesmo quando a omissão aumenta o risco
02:18.
Madrugada.
War Room.
Café forte.
Uma mudança crítica está em andamento.
O monitor mostra:
02:18:32
PAYMENT FAILURE RATE: 2.1%
O runbook diz:
IF FAILURE RATE > 2%
FOR 5 MINUTES
THEN
HOLD CHANGE
REASSESS
Nosso jovem programador COBOL olha para o relógio.
02:20.
FAILURE RATE: 2.7%
02:22.
FAILURE RATE: 3.4%
Ele pergunta:
— Vamos interromper?
O gerente hesita.
— Ainda não.
— Mas cruzamos o trigger.
— Eu sei.
— Então?
O gerente olha para a tela.
— Se eu mandar parar e depois descobrirmos que era só um pico, eu causei uma interrupção desnecessária.
O especialista concorda.
— Melhor esperar.
Nosso jovem pensa.
Faz sentido.
Ninguém quer ser a pessoa que:
parou a produção;
abortou a mudança;
derrubou o serviço;
acionou rollback
sem necessidade.
02:25.
FAILURE RATE: 5.8%
O gerente diz:
— Agora já está alto demais para mexer.
Curioso.
Primeiro:
era cedo demais para agir.
Agora:
é tarde demais.
A inação conseguiu criar a própria justificativa.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do console.
A porta abre.
O Doctor sai.
Olha para o gráfico.
Depois para o gerente.
— Por que não interromperam quando o limite foi ultrapassado?
— Eu não queria causar uma indisponibilidade.
O Doctor aponta para:
FAILURE RATE: 5.8%
— E isso foi causado por quem?
— Pela falha.
— Então não conta?
Silêncio.
O Doctor sorri.
— Ah.
Pausa.
— Ações possuem autores. Omissões conseguem vestir-se de destino.
Bem-vindo ao:
Omission Bias
Ou:
Viés da Omissão
A tendência de julgar consequências negativas causadas por uma ação como piores, mais culpáveis ou mais graves do que consequências semelhantes — ou até maiores — causadas por não agir.
Em linguagem Bellacosa:
“Se eu mexer e piorar, foi culpa minha. Se eu não fizer nada e piorar... foi o sistema.”
🌀 O espelho de Action Bias
No episódio anterior vimos:
Action Bias
Pressão aparece.
Queremos agir imediatamente.
Restart.
Kill.
Clear.
Rollback.
Qualquer coisa para reduzir ansiedade.
Omission Bias parece o contrário:
“Melhor não tocar.”
Mas os dois possuem uma raiz parecida:
desconforto com responsabilidade sob incerteza.
No Action Bias:
agir reduz desconforto.
No Omission Bias:
não agir reduz responsabilidade percebida.
Nenhum dos dois pergunta automaticamente:
qual decisão reduz mais risco?
🧠 O que é uma omissão?
Parece simples.
Ação:
fazer algo.
Omissão:
não fazer.
Mas sistemas críticos complicam.
Imagine:
um operador sabe que dataset vai encher.
Pode expandir.
Não expande.
Dataset enche.
A falha não foi “causada” por um comando errado.
Mas havia uma decisão possível.
Não exercida.
A omissão também participou do resultado.
☕ Bellacosa Mainframe: o filesystem em 96%
Segunda-feira:
USS FILESYSTEM: 91%
Terça:
93%
Quarta:
96%
Analista:
— Deveríamos expandir.
Gerente:
— Mexer em filesystem em produção me preocupa.
— Se não mexermos?
— Ainda tem 4%.
Quinta:
98%.
Sexta:
100%.
Serviço para.
Post-mortem:
“Filesystem filled.”
Tecnicamente correto.
Mas incompleto.
A pergunta deveria ser:
“Em que momento sabíamos o suficiente para agir?”
🧠 Omission Bias adora voz passiva
Observe frases:
“O servidor ficou sem espaço.”
“A fila cresceu.”
“A vulnerabilidade permaneceu aberta.”
“O conhecimento se perdeu.”
Tudo soa como fenômeno meteorológico.
Mas talvez alguém tenha decidido:
não aumentar capacidade;
não escalar;
não corrigir;
não documentar.
A linguagem pode esconder agência.
👻 Easter Egg nº 1 — o botão que ninguém apertou
Uma nave espacial está perdendo oxigênio.
Companion:
— Existe um botão para selar o compartimento?
Doctor:
— Sim.
— Por que ninguém apertou?
— Porque selá-lo deixaria duas pessoas presas.
— E não apertar?
— Coloca duzentas em risco.
Silêncio.
— Então não apertar também é uma escolha.
Exatamente.
⚖️ Action versus Omission
Imagine duas decisões:
Cenário A
Você executa failover.
Falha.
Derruba serviço.
Cenário B
Você não executa failover apesar dos sinais.
Servidor primário cai.
Derruba serviço.
Resultado semelhante.
Mas psicologicamente:
A parece:
“Eu fiz.”
B parece:
“Aconteceu.”
Essa diferença influencia decisões.
🧠 Moral Responsibility asymmetry
Pessoas frequentemente sentem maior responsabilidade por danos causados diretamente por uma ação do que por danos produzidos pela inação.
Isso faz algum sentido moralmente em vários contextos.
Mas em engenharia operacional:
se temos responsabilidade explícita de monitorar e responder,
omitir pode ser tão relevante quanto agir.
☕ A famosa frase:
“Eu preferi não mexer.”
Pergunta:
com base em qual análise?
Se:
risco de mudança > risco de permanência,
ótimo.
Se:
“porque ninguém poderia me culpar se eu deixasse como estava”,
temos outro problema.
🪡 A agulha da seringa volta de novo
No mundo corporativo, há um fenômeno que conversa fortemente com Omission Bias:
quem faz mudança deixa rastro.
Change ticket.
Aprovação.
Nome.
Comando.
Timestamp.
Quem não faz nada?
Frequentemente não deixa artefato.
Logo:
ação possui assinatura; inação costuma parecer neutra.
Isso distorce incentivos.
🧠 Status Quo Bias e Omission Bias
São primos muito próximos.
Status Quo Bias:
manter parece natural porque já está assim.
Omission Bias:
mudar parece mais culpável se der errado.
Juntos:
“Melhor deixar como está.”
Mesmo quando:
o status quo está degradando.
🌀 Drift Into Failure agradece
Sistema apresenta pequenos sinais.
Intervir exige:
mudança;
aprovação;
risco.
Não intervir:
nenhum evento imediato.
Então adiamos.
Margem cai.
Mais um pouco.
Mais um pouco.
A omissão se repete.
Drift Into Failure transforma decisões de não agir em trajetória.
🧠 Present Bias também entra
Corrigir agora:
custo.
Não corrigir:
conforto.
Omission Bias reduz responsabilidade percebida.
Present Bias reduz peso do futuro.
A dupla constrói dívida.
🔐 Patch de segurança
Um clássico.
Patch pode causar regressão.
Então:
“Vamos esperar.”
A vulnerabilidade permanece.
Se ataque acontecer:
“Fomos atacados.”
Se patch tivesse causado outage:
“A mudança derrubou produção.”
Percebe a assimetria narrativa?
Isso pode levar organizações a tolerarem riscos invisíveis porque são menos atribuíveis.
🧠 Risk of Action versus Risk of Inaction
Outra vez precisamos de simetria.
PATCH AGORA
-----------
possível regressão
janela
teste
rollback
NÃO PATCH
---------
vulnerabilidade ativa
exploit possível
janela de exposição
compliance
A decisão precisa comparar ambos.
Não apenas:
“patch pode quebrar.”
🧀 Swiss Cheese e omissão
Barreira:
alerta detecta.
Próxima:
operador deveria escalar.
Não escala.
Buraco.
Próxima:
gerente deveria interromper mudança.
Não interrompe.
Buraco.
Próxima:
reconciliação deveria bloquear liberação.
Alguém decide:
“vemos amanhã.”
Buraco.
O acidente não precisa de comando errado.
Pode ser construído por coisas não feitas.
🚨 Near Miss não investigado
Near miss acontece.
Ninguém se machuca.
Resolver estruturalmente exige tempo.
Então:
“Não aconteceu nada.”
Sem ação.
Próximo near miss.
Nada.
Omission Bias + Outcome Bias:
“Fizemos bem em não exagerar.”
Até o dia.
🧠 Outcome Bias legitima omissão
Não fizemos nada.
Tudo acabou bem.
Conclusão:
“Não agir foi correto.”
Talvez.
Ou tivemos sorte.
Outcome Bias transforma omissão sortuda em política.
🧠 Optimism Bias reforça
“Provavelmente não vai piorar.”
Então não fazemos.
Se não piorar:
confiança aumenta.
Se piorar:
“Foi inesperado.”
Omission Bias adora Optimism Bias porque fornece justificativa emocional.
🧠 Normalcy Bias também
Problema aparece.
“Vai normalizar.”
Então não atuamos.
Essa é uma forma de omissão.
Normalcy Bias explica a expectativa.
Omission Bias explica por que permanecer imóvel parece mais aceitável que intervir.
👥 Diffusion of Responsibility
Todos veem.
Ninguém age.
Cada um pensa:
“Se fosse realmente necessário, alguém faria.”
Agora Omission Bias pode existir coletivamente.
O silêncio das outras pessoas legitima a própria inação.
🪜 Authority Gradient
Júnior percebe risco.
Interromper mudança exigiria confrontar sênior.
Então:
não fala.
Depois algo falha.
A omissão não foi falta de conhecimento.
Foi inibição social.
Omission Bias + Authority Gradient.
👥 Groupthink
Sala inteira está confortável.
Uma pessoa pensa:
“Deveríamos parar.”
Mas ninguém fala.
Não levantar objeção parece menos disruptivo que interromper consenso.
O grupo segue.
Às vezes Omission Bias não é operacional.
É verbal.
Não falar também pode ser uma omissão crítica.
🎯 Speak-up as action
Se você percebe:
risco;
dado estranho;
premissa errada,
e não fala,
talvez a barreira humana deixe de funcionar.
Por isso culturas de segurança precisam tornar:
questionar;
escalar;
parar
ações socialmente legítimas.
✈️ Crew Resource Management
Em aviação, estruturas modernas enfatizam comunicação entre tripulantes e capacidade de challenge, porque copiloto silencioso pode não evitar uma decisão ruim.
Em TI:
júnior que viu o problema, mas não falou,
é o equivalente organizacional de um sensor que detectou e não transmitiu.
☕ COBOL iniciante: a dúvida que você não falou
Você vê:
IF WS-AMOUNT > 0
PERFORM PROCESSAR
END-IF
E pensa:
“E se vier negativo?”
Mas o sênior escreveu.
Você fica quieto.
Produção recebe crédito estornado com valor negativo.
Bug.
Depois você diz:
— Eu tinha pensado nisso.
A pergunta não serve depois.
Fale antes.
Com respeito.
Com evidência.
🧠 Hindsight Bias depois pode ser cruel
Após incidente:
“Por que ninguém parou?”
Agora parece óbvio.
Mas antes existiam custos reais:
interromper negócio;
desafiar superior;
causar falso positivo.
Não julgue só retrospectivamente.
Melhore triggers e autoridade de STOP.
🛑 Stop Authority
Uma poderosa defesa:
pessoas precisam saber:
quem pode parar?
Sob quais critérios?
Se tudo depende de coragem individual improvisada,
Omission Bias vence.
Exemplo:
ANY ENGINEER MAY CALL HOLD
IF:
- DATA LOSS SUSPECTED
- FAILURE > 5%
- SECURITY CONTROL FAILED
Agora agir não é insubordinação.
É procedimento.
🧠 Precommitment novamente
Antes:
defina:
se X, faremos Y.
Durante pressão:
menos negociação emocional.
IF RECONCILIATION != ZERO
DO NOT RELEASE
Não:
“Mas talvez amanhã feche.”
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Melhor não mexer.”
Pergunte:
“Qual é o custo de não fazer nada?”
🎯 Pergunta Bellacosa nº 2
Outra:
“Se a situação piorar por termos esperado, consideraremos isso uma decisão?”
Pergunta desconfortável.
Útil.
🎯 Pergunta Bellacosa nº 3
Outra:
“Estamos evitando a ação porque ela é arriscada ou porque nos torna responsáveis?”
Excelente.
🎯 Pergunta Bellacosa nº 4
E:
“Qual evidência faria a inação deixar de ser aceitável?”
Defina trigger.
🧪 Como combater Omission Bias
Passo 1 — Trate “não fazer” como opção explícita
Não default invisível.
Passo 2 — Registre rationale
Por que esperamos?
Passo 3 — Calcule risco da inação
Assim como risco da ação.
Passo 4 — Defina prazo
Não agir até quando?
Passo 5 — Use triggers
Se X acontecer, agiremos.
Passo 6 — Dê autoridade para STOP
Sem medo político.
Passo 7 — Registre decisões de não agir
Audit trail também para WAIT.
Passo 8 — Faça reassessment
Inação temporária não vira eterna.
Passo 9 — Use second pair of eyes
Especialmente em decisões de alto impacto.
Passo 10 — Revise near misses
O que quase aconteceu porque não agimos?
📝 Decision Log de omissão
Muito útil:
02:18
DECISION:
WAIT / NO ACTION
RATIONALE:
Failure 2.1%, trend unclear
REASSESS:
02:23
ACT IF:
Failure > 3%
or data loss confirmed
Agora a inação virou:
decisão;
com prazo;
critério.
Não abandono.
🧠 WAIT pode ser excelente
É importante não cair no oposto.
Às vezes não agir é a decisão correta.
Como vimos em Action Bias.
O sistema está recuperando.
Intervir pioraria.
Então:
WAIT.
Perfeito.
Mas uma boa omissão é:
deliberada, monitorada e revisável.
Não:
“Não quero mexer.”
☕ A diferença entre WAIT e IGNORE
WAIT
----
observa
mede
tem timer
tem trigger
IGNORE
------
torce
Bellacosa Operational English.
🧠 Omission Bias e Action Bias precisam coexistir no treinamento
Duas perguntas:
Antes de agir:
“Precisamos mesmo fazer algo agora?”
Antes de não agir:
“Qual o risco de esperar?”
Essa dupla cria equilíbrio.
⚖️ Decision Symmetry
Uma decisão madura pergunta:
ACTION A
risk
benefit
reversibility
NO ACTION
risk
benefit
time horizon
Inação também precisa passar pelo tribunal.
🔥 Failure to Act
Em incidentes, há momentos em que inação é o principal problema.
Exemplo:
dados corrompendo ativamente.
Esperar mais métricas pode ser irresponsável.
Nesse cenário:
contenção é prioridade.
Action Bias não significa não agir.
Omission Bias não significa sempre agir.
Precisamos de:
proporcionalidade.
🧠 Severity drives urgency
Quanto maior:
impacto;
irreversibilidade;
velocidade de propagação,
menor tempo aceitável para esperar.
Exemplo:
latência leve:
pode observar.
Transferências duplicadas:
pare.
📊 Damage Rate
Uma métrica útil:
quanto dano adicional acontece por minuto?
Se:
zero ou baixo,
há espaço diagnóstico.
Se:
R$ 1 milhão/min,
ação precisa ser rápida.
Agora a urgência tem base.
💻 Batch duplicando registros
Job processa:
100k registros/min.
Descobrimos duplicidade.
Cada minuto:
100 mil novos erros.
Não diga:
“Vamos observar mais 20 minutos.”
Contain.
Mesmo sem root cause.
Porque custo da omissão é enorme.
🔐 Segurança: conta comprometida
Credencial ativa.
Atacante movendo dados.
Você ainda não sabe vetor inicial.
Bloqueia conta?
Provavelmente.
Porque investigação pode continuar depois.
Containment.
Omission Bias aqui seria perigoso.
🧠 Reversibilidade importa novamente
Ações reversíveis podem ser usadas mais cedo.
Exemplo:
bloquear temporariamente.
Ações irreversíveis:
delete.
Mais rigor.
Isso ajuda a equilibrar Action e Omission Bias.
🎛️ Safe Default
Design de sistemas pode ajudar.
Se condição crítica aparece:
qual default?
Continue?
Pare?
Depende.
Em sistemas financeiros:
reconciliação falha talvez deva:
fail closed.
Em disponibilidade:
talvez fail open.
O design precisa antecipar dilema.
🧠 Fail-safe versus fail-operational
Nem sempre segurança significa parar.
Alguns sistemas precisam continuar operando degradados.
Então Omission Bias não é resolvido por:
“sempre interrompa.”
É resolvido por:
critérios pré-definidos.
☕ Mainframe e condição de retorno
COBOL e JCL já nos ensinam isso.
// IF STEP1.RC > 8 THEN
//STOP EXEC PGM=...
Ou:
IF WS-RECON-DIFF NOT = ZERO
MOVE 'N' TO WS-RELEASE
END-IF.
O programa não pensa:
“Talvez dê certo.”
O critério foi definido.
🧠 Governance como memória de decisão
Bom processo remove carga moral do operador.
Ele não precisa decidir sozinho:
“Vou ser o cara que para produção?”
O sistema diz:
“Critério X foi atingido.”
Então HOLD.
Isso reduz Omission Bias causado por medo pessoal.
👥 Psychological Safety
Pessoas precisam conseguir dizer:
“Eu recomendo parar.”
Sem:
ridicularização;
retaliação;
rótulo de alarmista.
Se falar traz custo social alto,
silêncio vira estratégia racional.
E a organização recebe Omission Bias sistêmico.
🧠 Blameless não significa passive
Cultura sem culpa não é:
ninguém decide.
É:
decidimos com clareza;
depois aprendemos sem caça às bruxas.
Isso aumenta willingness to act.
🪜 Escalation Path
Se você não tem autoridade:
escalone.
Não:
“não é comigo.”
Exemplo:
RISK CONFIRMED
↓
ENGINEER
↓
INCIDENT COMMANDER
↓
SERVICE OWNER
Responsabilidade circula.
🧠 Diffusion + Omission
Quando ninguém sabe quem pode decidir,
todo mundo não decide.
Por isso ownership é defesa.
📋 Checklist anti-Omission Bias
[ ] O que acontece se não fizermos nada?
[ ] Esse risco está aumentando?
[ ] A inação é reversível?
[ ] Quanto tempo podemos esperar?
[ ] Existe trigger para agir?
[ ] Quem tem autoridade?
[ ] Estamos evitando culpa ou reduzindo risco?
[ ] Registramos por que decidimos esperar?
[ ] Existe reassessment time?
[ ] Alguém discordou?
[ ] A omissão pode destruir margem?
[ ] O dano cresce por minuto?
[ ] Se o resultado piorar, a inação ainda parecerá razoável?
[ ] Estamos tratando o status quo como neutro?
🧪 Passo a passo Bellacosa
Passo 1 — Nomeie a opção “não agir”
Coloque na tabela.
Passo 2 — Calcule consequência
Hoje.
1h.
1 dia.
1 mês.
Passo 3 — Meça taxa de deterioração
O risco cresce?
Passo 4 — Defina trigger
Objetivo.
Passo 5 — Determine autoridade
Quem pode agir?
Passo 6 — Dê prazo à espera
WAIT até X.
Passo 7 — Preserve evidência
Enquanto espera.
Passo 8 — Reavalie
No relógio.
Passo 9 — Documente
Decisão e contexto.
Passo 10 — Aprenda
A espera foi adequada?
📈 Leading indicators novamente
Omission Bias prospera quando só olhamos resultado final.
Nada caiu.
Então:
“fizemos certo em não agir.”
Mas leading indicators podem mostrar:
margem caindo;
warnings;
retries;
manual interventions.
O sistema talvez esteja pagando pela omissão lentamente.
🌀 Drift de manutenção
Patch adiado.
Capacity adiada.
Refactor adiado.
Treinamento adiado.
Documentação adiada.
Nenhuma omissão individual parece grave.
Juntas:
sistema fragiliza.
Isso é Drift Into Failure construído por decisões negativas:
coisas que não fizemos.
🧠 Absence as causal factor
Em sistemas complexos, causalidade não é só:
“qual componente quebrou?”
Pode incluir:
controle que faltou;
treinamento não feito;
escalation não executada;
barreira não mantida.
Não procure apenas ações erradas.
Procure capacidades ausentes.
🔍 Post-mortem pergunta melhor
Não:
“Quem fez algo errado?”
Mas:
“Que ação esperada não aconteceu, e por quê?”
Isso encontra:
processo;
cultura;
ownership;
incentivo.
🧠 Hindsight Bias cuidado
Depois do desastre:
“Claramente deveriam ter agido.”
Talvez.
Mas reconstruir:
o que sabiam?
quais custos?
quais triggers?
Se não existiam critérios,
melhore sistema.
Não apenas culpe quem hesitou.
☕ O peso político da interrupção
Muitos sistemas têm uma assimetria institucional:
parar serviço exige diretor.
Continuar exige ninguém.
Isso favorece omissão.
Talvez governança precise ser revista.
🧠 Default to Continue
Em mudanças:
default pode ser:
continue até alguém parar.
Talvez para operações críticas melhor:
continue enquanto critérios saudáveis permanecerem.
Quando condição falha:
automatic HOLD.
Isso muda psicologia.
🤖 Automação contra Omission Bias
Automação pode ajudar:
trigger atingiu.
sistema reduz tráfego.
abre ticket.
escalona.
Mas Automation Bias nos lembra:
não delegue cegamente.
Guardrails.
Validação.
🚦 Circuit breaker
Um excelente exemplo tecnológico.
Dependência falha.
Sistema não insiste infinitamente.
Circuit breaker abre.
Isso é design que evita Omission Bias operacional:
não espera humanos decidirem enquanto dano cresce.
🧠 Rate Limiting
Outro.
Se volume anormal cresce:
reduzimos.
Containment automático.
Bom design transforma decisões críticas repetitivas em controle.
👨💻 Dica para COBOL iniciante
Se você percebe comportamento estranho:
não pense:
“Sou júnior, talvez não seja nada.”
Pense:
“Tenho uma observação. Vou comunicar.”
Você não precisa dizer:
“O sistema vai cair.”
Diga:
“Estou vendo X, acima do baseline Y. Pode alguém validar?”
Isso é profissional.
🧠 Comunicação calibrada
Não:
“Acho que é desastre!”
Nem:
silêncio.
Use:
OBSERVAÇÃO:
Reject rate 4x baseline.
CONFIANÇA:
Não sei a causa.
RECOMENDAÇÃO:
Reavaliar antes de liberar.
Excelente.
👻 Easter Egg nº 2 — K-9 e a decisão de não fazer
K-9:
— Danger probability increasing.
Companion:
— Doctor, fazemos alguma coisa?
Doctor:
— Ainda não.
— Omission Bias?
— Não.
— Como sabe?
— Tenho um timer, três thresholds e um plano.
Pausa.
— Ah.
Esperar com critérios é estratégia. Esperar sem critérios é esperança.
📊 A matriz Action/Omission
Podemos criar:
RESULTADO BOM RESULTADO RUIM
AGIR boa intervenção ação causou dano
NÃO AGIR espera correta omissão contribuiu
Outcome Bias tentará julgar só resultado.
Precisamos avaliar processo.
Exatamente como capítulo anterior.
🧠 Omission Bias + Outcome Bias
Não agir.
Tudo fica bem.
“Viu? Fizemos certo.”
Talvez.
Pergunte:
critério era bom?
Não agir.
Tudo piora.
“O sistema falhou.”
Talvez.
Pergunte:
tínhamos oportunidade razoável de conter?
🎯 O teste contrafactual
Pergunte:
“Se outra equipe tivesse tomado a decisão oposta, consideraríamos razoável com os dados daquele momento?”
Ajuda a separar resultado de processo.
🧪 Decision Review cego ao resultado
Mostre:
dados disponíveis;
opções;
riscos.
Não resultado.
Pergunte:
“Você agiria ou esperaria?”
Depois revele.
Excelente contra Outcome + Omission Bias.
🧠 Omission Bias na gestão
Projeto claramente perdeu valor.
Cancelar exige decisão explícita.
Manter:
continua sozinho.
Então ninguém cancela.
Status Quo + Sunk Cost + Omission.
Projetos zumbis existem porque:
ninguém quis ser o autor de sua morte.
💀 Zombie Projects
Orçamento pequeno anual.
Ninguém usa muito.
Ninguém quer cancelar.
Consome:
staff;
licença;
atenção.
Não existe ação ruim visível.
Existe omissão longa.
🧠 Decommissioning as action
Desligar também é responsabilidade.
Se ninguém possui owner para aposentar sistemas,
tudo vive para sempre.
Esse é Omission Bias arquitetural.
📚 Documentação não escrita
Ninguém toma uma decisão explícita:
“Não documentaremos.”
Ela apenas não acontece.
Anos depois:
conhecimento perdido.
Omission Bias pode viver em ausência de tarefas.
🧠 Preventive maintenance
Mesma coisa.
Ninguém diz:
“Queremos risco.”
Apenas priorizam outra coisa toda semana.
No fim:
risco cresceu.
🔥 Cultura de urgência produz omissão preventiva
Urgente vence importante.
Present Bias.
Manutenção perde.
Omission Bias.
Depois incidente.
Action Bias.
O ciclo inteiro da série numa madrugada.
🧬 Regeneração organizacional
Como uma organização combate Omission Bias?
Ela:
trata inação como decisão explícita;
compara risco de agir e esperar;
define triggers;
dá stop authority;
registra WAIT decisions;
cria reassessment timers;
protege speak-up;
mede custo de atraso;
e revisa omissões em post-mortem.
Principalmente:
remove a ilusão de que:
“Não toquei em nada” significa “não tomei nenhuma decisão.”
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Omission Bias é a tendência de considerar danos causados pela ação piores ou mais culpáveis que danos causados pela inação.
Não agir também é uma escolha quando existe oportunidade real de agir.
Status quo não é neutro.
WAIT pode ser uma excelente decisão se tiver evidência, timer e trigger.
IGNORE não é WAIT.
Action Bias e Omission Bias são extremos opostos que precisam ser equilibrados.
Authority Gradient pode transformar percepção em silêncio.
Diffusion of Responsibility pode transformar responsabilidade coletiva em omissão coletiva.
Outcome Bias pode legitimar uma omissão apenas porque tivemos sorte.
Drift Into Failure pode ser construído por centenas de pequenas coisas que ninguém fez.
Stop Authority e precommitment reduzem custo psicológico da ação.
E principalmente:
Não fazer nada pode ser exatamente a coisa certa — mas precisa ser escolhido pelo risco, não pela esperança de que a culpa fique sem dono.
🕰️ De volta às 02:18
A TARDIS retorna.
FAILURE RATE: 2.1%
O runbook:
>2% FOR 5 MIN
→ HOLD
02:20.
2.7%.
02:22.
3.4%.
Nosso programador olha.
— O trigger foi atingido.
O gerente hesita.
— Se pararmos e for só um pico...
O jovem responde:
— Pode ser.
— Então?
— Mas o critério foi definido antes de sabermos o resultado.
Pausa.
— Se acreditamos nele apenas quando sabemos que dará errado, não é controle.
HOLD.
A mudança para.
Fila estabiliza.
Investigam.
Encontram incompatibilidade em uma rotina nova.
Corrigem.
Novo teste.
GO duas horas depois.
Sem escalada.
O gerente pergunta:
— E se tivesse normalizado sozinho?
Nosso programador responde:
— Teríamos feito um HOLD desnecessário.
— Isso não seria ruim?
— Seria custo.
Pausa.
— Mas já decidimos antecipadamente que esse custo era aceitável comparado ao risco de continuar acima do limite.
O Doctor sorri.
— Excelente.
— Você gosta muito dessa palavra.
— Gosto quando humanos param de negociar com regras apenas porque descobriram que podem perder conforto.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(OMISSION)
Dentro:
IF ACTION = 'NONE'
PERFORM CALCULATE-NO-ACTION-RISK
END-IF.
IF DECISION = 'WAIT'
PERFORM SET-REASSESS-TIME
END-IF.
IF SOMEONE-SAYS
'BETTER-NOT-TO-TOUCH'
PERFORM ASK-WHY
END-IF.
Comentário:
* NO COMMAND
* CAN STILL BE A DECISION.
Outro:
* WAIT HAS A TIMER.
* IGNORE HAS AN EXCUSE.
Outro:
* SILENCE IS NOT A CONTROL.
E naturalmente:
* BAD WOLF DID NOTHING.
* THAT WAS THE PROBLEM.
Nosso jovem fecha o membro.
Horas depois:
— Filesystem está em 95%. Quer aumentar?
Ele responde:
— Primeiro tendência.
— Cresce 2% por dia.
— Capacidade disponível?
— Sim.
— Risco de expansão?
— Baixo.
— Risco de esperar?
— Deve encher em dois dias.
Ele sorri.
— Então não fazer nada seria a intervenção mais agressiva.
Mudança aberta.
Expansão controlada.
Nada explode.
Nenhuma War Room.
Nenhum herói.
Nenhum diretor acordado às três da manhã.
Apenas uma falha que não aconteceu.
E talvez essa seja uma das coisas mais difíceis de enxergar em engenharia:
o valor de uma ação preventiva aparece justamente no evento que deixou de existir.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room permanece:
Ação e omissão são duas formas de escolher. O sistema não se importa qual delas parece menos culpável — apenas com as consequências de cada uma.
☕🌀
Next stop: Loss Aversion — quando o medo de perder aquilo que já temos pesa muito mais que a possibilidade de ganhar algo melhor, fazendo equipes aceitarem custos, riscos e arquiteturas ruins apenas para evitar a sensação de perda.
