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.

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.

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.

operador deveria escalar.

Não escala.

Buraco.

gerente deveria interromper mudança.

Não interrompe.

Buraco.

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

“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.

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.

Translate

sexta-feira, 11 de novembro de 2011