| Bellacosa Mainframe e o normalcy bias |
☕ Um Café no Bellacosa Mainframe
Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Dando Errado — Mas Todo Mundo Achou que Ia Passar
Uma viagem pela TARDIS dos incidentes para entender por que, diante de sinais anormais, nosso cérebro insiste em acreditar que o mundo continuará funcionando como sempre funcionou
09:04.
Segunda-feira.
Café quente.
Mainframe acordado.
Usuários trabalhando.
Tudo normal.
Então aparece:
WARNING
PAYMENT RESPONSE TIME ABOVE BASELINE
O operador olha.
— Deve ser pico de volume.
09:11.
QUEUE DEPTH +40%
— Segunda-feira.
09:18.
TIMEOUT RATE +180%
— Deve estabilizar.
09:26.
Primeiras reclamações.
— Usuário sempre reclama antes de a coisa ficar normal.
09:34.
FAILED TRANSACTIONS: 417
O gerente pergunta:
— Precisamos abrir incidente?
Alguém responde:
— Vamos esperar mais dez minutos.
09:41.
Mais falhas.
09:46.
Mais reclamações.
09:49.
O sistema não está estabilizando.
Mas a mente coletiva ainda trabalha com uma convicção silenciosa:
“Provavelmente vai voltar ao normal.”
VWORP.
VWORP.
VWORP.
A TARDIS surge no corredor.
A porta abre.
O Doctor sai.
Olha para o painel.
Depois para os operadores.
— Há quanto tempo isso está piorando?
— Quarenta minutos.
— E o que vocês estão esperando?
— Que normalize.
O Doctor inclina a cabeça.
— Com base em quê?
Silêncio.
— Bem... normalmente normaliza.
Ele olha novamente para o gráfico.
— Ah.
Pausa.
— Então vocês estão usando o fato de ontem ter terminado bem como evidência de que hoje também terminará?
Mais silêncio.
— Isso é encantador.
Outra pausa.
— E profundamente perigoso.
Bem-vindo ao:
Normalcy Bias
Ou:
Viés de Normalidade
A tendência de subestimar sinais de perigo e assumir que, mesmo diante de eventos anormais, a situação provavelmente continuará parecida com aquilo que conhecemos.
🌀 Nossa TARDIS já viu muita coisa
Até aqui encontramos:
Swiss Cheese Model — várias defesas imperfeitas podem falhar juntas.
Normalization of Deviance — desvios podem virar rotina.
Hindsight Bias — depois do evento tudo parece óbvio.
Confirmation Bias — buscamos o que confirma nossas crenças.
Anchoring Bias — a primeira explicação pesa demais.
Groupthink — grupos convergem cedo demais.
Authority Gradient — hierarquia pode silenciar quem percebe risco.
Plan Continuation Bias — continuamos planos que já deveriam ser revistos.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais na máquina.
Drift Into Failure — pequenas decisões e perda de margem levam o sistema para a borda.
Diffusion of Responsibility — todo mundo vê e ninguém assume.
Agora o problema é diferente:
o perigo está visível, mas não parece real o bastante.
🧠 O que é Normalcy Bias?
Normalcy Bias é a tendência de acreditar que as coisas continuarão aproximadamente como sempre foram, mesmo quando surgem evidências de mudança séria.
O cérebro trabalha com modelos.
Ele aprende:
segunda-feira tem pico.
fila cresce.
depois cai.
Então, quando vê outra fila crescendo, tenta encaixar no padrão conhecido.
Isso é útil.
Sem esse mecanismo ficaríamos em pânico a cada pequena variação.
Mas em uma emergência real, essa mesma tendência pode atrasar resposta.
Representando:
SINAL ANORMAL
↓
“ISSO JÁ ACONTECEU”
↓
“DEVE PASSAR”
↓
ESPERA
↓
SINAL PIORA
↓
“AINDA DEVE PASSAR”
↓
ATRASO NA REAÇÃO
☕ Bellacosa Mainframe: “isso acontece no fechamento”
Imagine:
CPU: 91%
Operador:
— No fechamento sempre sobe.
Depois:
CPU: 95%
QUEUE: +120%
— Ainda dentro do esperado.
Depois:
CPU: 97%
QUEUE: +300%
TIMEOUTS: 870
— Deve ser o volume.
Talvez seja.
Mas a pergunta correta é:
“Em que ponto deixamos de estar dentro do comportamento conhecido?”
Normalcy Bias prospera quando não existe esse ponto definido.
📈 Baseline novamente salva o dia
Se você apenas pensa:
“isso costuma acontecer”
fica sujeito à memória.
Melhor:
BASELINE DE SEGUNDA-FEIRA
CPU normal: 72–84%
Queue normal: até 2.500
Timeout normal: < 20/min
Hoje:
CPU: 96%
Queue: 18.000
Timeout: 310/min
Agora fica difícil dizer:
“segunda-feira normal.”
Dados ajudam a quebrar o viés de normalidade.
🧠 “Já aconteceu antes” pode significar duas coisas
Frase:
“Já aconteceu antes.”
Pode significar:
conhecemos esse comportamento e sabemos por que é seguro;
ou:
sobrevivemos a ele antes e estamos presumindo que sobreviveremos novamente.
Essas coisas não são iguais.
A segunda se conecta diretamente com:
Normalization of Deviance.
🧩 Normalcy Bias versus Normalization of Deviance
Os nomes parecem parentes.
São.
Mas não são a mesma coisa.
Normalization of Deviance
O desvio se torna aceito ao longo do tempo.
“Esse warning é normal.”
Normalcy Bias
Diante de uma situação potencialmente grave, presumimos que ela não será tão grave e que a rotina continuará.
“Isso deve melhorar sozinho.”
Uma fala sobre:
o que aceitamos como normal.
A outra:
o que esperamos que continue normal.
As duas juntas podem ser perigosíssimas.
🚨 Exemplo
Warning diário.
Normalizamos.
Um dia o warning aparece com intensidade muito maior.
Normalcy Bias:
“É aquele warning de sempre.”
Mas não é mais o mesmo comportamento.
A familiaridade mascara mudança de escala.
👻 Easter Egg nº 1 — “Sempre volta”
Imagine uma estação espacial.
Luzes piscando.
Um técnico diz:
— A energia sempre volta.
Doctor:
— E voltou?
— Nas outras vezes.
— E desta?
— Ainda não.
— Então talvez devêssemos parar de usar as outras vezes como plano de recuperação.
Essa frase vale para produção.
🧠 Por que fazemos isso?
Porque admitir que existe emergência é caro.
Psicologicamente.
Organizacionalmente.
Operacionalmente.
Se dissermos:
“Temos incidente”
precisamos:
abrir War Room;
escalar;
interromper mudança;
avisar negócio;
talvez chamar diretor;
talvez perder SLA.
Esperar é mais confortável.
Talvez resolva sozinho.
Então Normalcy Bias pode ser reforçado por incentivos.
💰 Declarar incidente tem custo social
Imagine uma cultura onde abrir Severity 1 gera:
reuniões;
relatórios;
cobrança;
culpa;
PowerPoint para diretoria.
O que acontece?
Pessoas retardam declaração.
Não necessariamente conscientemente.
Pensam:
“Vamos esperar mais cinco minutos.”
Isso é perigoso.
A cultura tornou reconhecimento da realidade caro.
🚦 Better safe than embarrassed
Uma organização madura prefere:
falso positivo controlado;
a incidente reconhecido tarde.
Se alguém declara incidente e depois descobre que era menor:
ótimo.
Se for ridicularizado:
da próxima vez esperará.
Normalcy Bias ganha ajuda da cultura.
🧀 Swiss Cheese + Normalcy Bias
Imagine barreira:
detecção humana.
O alerta aparece.
Mas humano pensa:
“não é grave.”
Mais um buraco.
Depois barreira:
escalation.
Não escalamos porque:
“vai passar.”
Outro buraco.
Depois:
rollback.
Não rollbackamos porque:
“ainda deve estabilizar.”
Terceiro buraco.
O queijo vai alinhando.
🌀 Drift Into Failure prepara o terreno
Durante anos:
mais volume;
menos margem;
mais warning.
A operação vai se adaptando.
Então chega o dia em que sistema cruza a fronteira.
Mas todos ainda possuem modelo mental antigo:
“ele sempre aguenta.”
Isso é Normalcy Bias sustentado por memória histórica.
O sistema mudou.
O modelo mental não.
🧠 Model Drift humano
Falamos de drift em sistemas.
Mas também existe drift entre:
realidade;
modelo mental.
Exemplo:
2021:
batch aguenta 20 milhões.
2026:
processa 80 milhões.
Operador ainda pensa:
“Esse job é muito robusto.”
Talvez fosse.
Sob condições antigas.
🤖 Automation Bias piora
Dashboard:
OVERALL: GREEN
Usuários reclamam.
Normalcy Bias:
“provavelmente ruído.”
Automation Bias:
“o painel diz verde.”
Agora os dois se reforçam.
A realidade perde votação.
🔔 Alarm Fatigue também ajuda
Se alertas aparecem constantemente:
novo alerta grave parece só mais um.
Normalcy Bias diz:
“igual aos anteriores.”
Alarm Fatigue diz:
“não quero olhar.”
Excelente combinação.
👥 Groupthink cria normalidade coletiva
Uma pessoa diz:
— Não parece grave.
Outra:
— Concordo.
Terceira:
— Já vimos antes.
Agora o grupo constrói uma narrativa:
“está tudo sob controle.”
A pessoa mais preocupada começa a duvidar.
Groupthink transforma Normalcy Bias individual em percepção coletiva.
🪜 Authority Gradient silencia o desconfortável
Júnior:
— Isso está pior que o normal.
Sênior:
— Relaxa. Já vi isso várias vezes.
O júnior se cala.
Talvez esteja certo.
Authority Gradient protege o modelo mental antigo.
▶️ Plan Continuation Bias
Mudança em andamento.
Métricas pioram.
Equipe:
— Deve estabilizar depois do próximo passo.
Continua.
Normalcy Bias:
isso ainda não é emergência.
Plan Continuation Bias:
não pare.
E lá vamos nós.
👥 Diffusion of Responsibility
Todo mundo observa.
Ninguém declara incidente porque presume que:
se fosse realmente grave, alguém já teria declarado.
Perfeito.
Agora a ausência de ação das outras pessoas vira evidência de normalidade.
Esse mecanismo é assustadoramente elegante.
🧠 Social Proof em crise
Humano observa os outros.
Se ninguém corre:
talvez não haja fogo.
Isso é útil em situações ambíguas.
Mas se todos estão olhando uns para os outros:
o grupo inteiro pode ficar parado.
🔥 “Se fosse grave, alguém faria alguma coisa”
Essa frase deveria disparar alerta mental.
Porque talvez todas as pessoas estejam usando exatamente o mesmo raciocínio.
🏢 O caso do cheiro de queimado
Imagine data center.
Alguém sente cheiro de queimado.
Olha para outros.
Ninguém parece preocupado.
Pensa:
ar-condicionado.
Outro também sente.
Vê primeiro calmo.
Pensa:
deve ser normal.
Todos detectaram.
Nenhum validou.
Essa é uma versão perfeita.
💻 No COBOL: retorno estranho
Programa normalmente retorna:
REJECTS: 10–30
Hoje:
REJECTS: 490
Operador:
— Final de mês.
Depois:
REJECTS: 1.870
— Volume alto.
Pergunta:
qual limite separa explicação razoável de racionalização?
Precisa existir.
🚨 Thresholds de reconhecimento
Além de thresholds técnicos, precisamos de thresholds de decisão.
Exemplo:
IF REJECT RATE > 1%
DECLARE DEGRADED
IF > 3%
OPEN INCIDENT
IF > 5%
STOP PROCESSING
Agora a mente não negocia infinitamente.
🧠 Precommitment retorna
Antes da crise:
definimos:
se X ocorrer, agimos.
Durante:
menos espaço para:
“vamos esperar.”
Precommitment combate Normalcy Bias.
🛑 Trigger Action Response Plan
Uma abordagem poderosa:
TRIGGER:
Queue > 10k por 5 min
ACTION:
abrir incidente
TRIGGER:
Timeout > 5%
ACTION:
HOLD mudança
TRIGGER:
Reconciliação != 0
ACTION:
STOP
O gatilho conecta diretamente a ação.
Reduz ambiguidade.
🧠 Não espere certeza absoluta
Outra armadilha.
Pessoas esperam:
“prova de desastre.”
Mas segurança trabalha com evidência suficiente.
Se esperar certeza total:
talvez já seja tarde.
A pergunta é:
“qual nível de incerteza aceitamos antes de agir?”
📊 Confidence Thresholds
Exemplo:
não sabemos causa.
Mas sabemos:
impacto subindo;
tendência negativa;
margem caindo.
Já pode ser suficiente para:
abrir incidente.
Você não precisa saber causa raiz para reconhecer emergência.
🔥 Incidente primeiro, explicação depois
Às vezes pessoas pensam:
“Não podemos declarar incidente porque ainda não sabemos a causa.”
Errado.
Incidente é sobre impacto e risco.
Causa vem depois.
Se prédio está queimando, não precisamos saber origem do fogo antes de evacuar.
☕ Bellacosa Mainframe: RC=00 e negócio quebrado
Job:
RC=0000
Tudo normal?
Talvez.
Mas reconciliação:
EXPECTED: 3.450.000
POSTED: 3.210.000
Normalcy Bias:
“talvez atraso de atualização.”
Investigue.
RC=00 só fala sobre o que o programa considerou sucesso.
Não sobre o universo.
🧠 Technical Normal vs Business Abnormal
Essa distinção é muito importante.
Infra:
normal.
Negócio:
anormal.
Se você escuta apenas infraestrutura, pode ignorar clientes.
Sempre valide impacto ponta a ponta.
📞 Usuário pode ser o primeiro sensor
Usuário reclama.
Dashboard verde.
Não presuma:
usuário está errado.
Ele pode estar enxergando uma camada não monitorada.
Normalcy Bias adora desqualificar sinal externo porque não cabe no painel.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Deve normalizar.”
Pergunte:
“Qual evidência mostra tendência de normalização?”
Se resposta:
“normalmente acontece”
temos memória.
Não evidência atual.
🎯 Pergunta Bellacosa nº 2
Outra:
“Qual comportamento distinguiria ‘pico normal’ de ‘incidente começando’?”
Defina.
🎯 Pergunta Bellacosa nº 3
Outra:
“Quanto tempo estamos dispostos a esperar antes de agir?”
Sem isso:
espera vira infinita.
🎯 Pergunta Bellacosa nº 4
E:
“Se isso piorar duas vezes, nossa decisão muda?”
Planeje antes.
🧪 Passo a passo para combater Normalcy Bias
Passo 1 — Tenha baseline objetivo
Não dependa de sensação.
Passo 2 — Defina triggers claros
Quando deixa de ser normal?
Passo 3 — Diferencie variação de tendência
Um pico isolado pode ser ruído.
Três métricas piorando juntas contam história.
Passo 4 — Defina tempo de observação
“Esperar” precisa ter relógio.
Exemplo:
OBSERVE FOR 5 MIN
THEN REASSESS
Não:
“vamos vendo.”
Passo 5 — Use escalonamento progressivo
Warning.
Degraded.
Incident.
Critical.
Passo 6 — Permita declaração precoce
Sem punição social.
Passo 7 — Use fresh eyes
Pessoa nova pode perceber que o “normal” já mudou.
Passo 8 — Compare com cenários históricos corretos
Não apenas:
“já aconteceu.”
Pergunte:
“nas mesmas condições?”
Passo 9 — Registre decisões
Por que optamos por esperar?
Qual sinal mudaria isso?
Passo 10 — Faça retrospectiva sobre atrasos de reconhecimento
Não apenas causa raiz.
Pergunte:
quando tivemos informação suficiente para perceber que era incidente?
🕰️ Time to Declare
Podemos medir:
MTTD.
MTTR.
Mas também:
Time to Declare
Quanto tempo entre sinais suficientes e declaração formal?
Exemplo:
09:10 primeiro sinal forte
09:47 incidente declarado
37 minutos.
Talvez recuperação tenha levado 20.
Então maior problema foi reconhecimento tardio.
🧠 Recognition Latency
Atraso cognitivo importa.
Sistema pode detectar às 09:10.
Humano reconhecer às 09:40.
Organização agir às 09:50.
Três tempos diferentes.
📊 Timeline cognitiva novamente
09:04 metric abnormal
09:11 queue growing
09:18 timeouts
09:26 users report
09:34 failures
09:49 incident declared
Pergunte:
em qual ponto já tínhamos evidência suficiente?
Isso produz aprendizado.
🧠 Hindsight Bias cuidado!
Depois:
— Era claramente incidente às 09:11.
Talvez.
Ou talvez não.
Não use futuro para julgar.
Mas podemos perguntar:
quais critérios teriam permitido reconhecer antes?
Isso transforma retrospectiva em engenharia.
🏥 Normalcy Bias fora da TI
Esse viés aparece em desastres naturais, emergências e situações em que pessoas demoram a reagir porque eventos extremos parecem improváveis.
É justamente por isso que alertas públicos precisam ser:
claros;
acionáveis;
específicos.
“Pode haver risco” é diferente de:
“Evacue agora.”
Em TI também.
🚨 Mensagens vagas alimentam viés
WARNING:
SYSTEM MAY BE DEGRADED
Pessoa:
— Talvez não.
Melhor:
PAYMENT FAILURE RATE 12%
NORMAL < 0.2%
IMPACT CONFIRMED
OPEN INCIDENT NOW
Ação clara.
🧠 Linguagem importa
Evite:
“parece alguma instabilidade.”
Se dados mostram:
35% das transações falhando,
diga isso.
Eufemismo pode reforçar Normalcy Bias.
🏢 Cultura do “não dramatiza”
Algumas equipes valorizam calma.
Ótimo.
Mas calma não significa minimizar.
Você pode dizer:
“Temos impacto crítico confirmado”
sem pânico.
Precisão não é dramatização.
🧯 British calm versus denial
Aqui nosso humor britânico fica perfeito.
Existem duas atitudes:
Calma britânica:
“O prédio está pegando fogo. Vamos evacuar de forma ordenada.”
Normalcy Bias:
“Há apenas uma quantidade incomum de fumaça. Talvez seja o chá.”
Não confunda compostura com negação.
👻 Easter Egg nº 2 — chá e Daleks
Companion:
— Doctor, há Daleks na recepção.
— Quantos?
— Quatorze.
— E o segurança?
— Disse que provavelmente é uma convenção.
Doctor:
— Normalcy Bias.
— O quê?
— Depois explico. Corra.
🔁 Continuous Reassessment
Uma prática central:
reavalie.
Se decidiu:
esperar cinco minutos,
depois de cinco:
nova decisão.
Não deixe decisão temporária virar permanente.
⏰ Timer explícito
Use:
DECISION:
Observe.
EXPIRES:
09:30.
Às 09:30:
decida novamente.
Isso impede inércia.
🧠 “No decision” é uma decisão
Esperar também é ação.
Ela possui risco.
Pergunte:
qual é o custo de esperar?
Às vezes esperar é correto.
Mas deve ser escolha consciente.
📉 Cost of Delay
Se fila cresce 1.000/minuto:
esperar 10 minutos:
+10.000 backlog.
O tempo possui custo mensurável.
Isso ajuda a combater:
“vamos esperar mais.”
💻 COBOL e batches
Batch começa atrasar.
Ainda dentro da janela.
Normalcy Bias:
dá tempo.
Mas calcule:
ritmo atual.
tempo restante.
volume restante.
Agora talvez descubra matematicamente que não dá.
Projeção supera esperança.
📈 Forecast operacional
Em vez de:
“ainda está rodando.”
Use:
CURRENT RATE: 20k/min
REMAINING: 2M
ESTIMATED END: 05:12
SLA: 04:00
Agora futuro provável fica visível.
🤖 IA pode ajudar — e atrapalhar
IA pode detectar anomalias.
Ótimo.
Mas Automation Bias:
IA diz normal.
Ou Normalcy Bias:
IA não sinalizou, então não é incidente.
Use IA como mais uma fonte.
Não substituto de realidade.
🔍 Anomaly Detection não é oráculo
Se modelo treinou com histórico onde sistema já estava degradando, pode considerar degradação “normal”.
Interessante, não?
O modelo também pode normalizar desvio estatisticamente.
Por isso baseline precisa ser saudável, não apenas frequente.
🧠 “Normal” estatístico versus “normal” seguro
Esse é um ponto magnífico.
Se sistema vive 95% do tempo com warning:
estatisticamente:
warning é normal.
Operacionalmente:
talvez seja péssimo.
Não confunda frequência com segurança.
🧬 Regeneração organizacional
Como uma organização se regenera depois de identificar Normalcy Bias?
Ela:
define baseline;
define gatilhos;
mede tempo de reconhecimento;
treina escalonamento;
reduz custo social de declarar incidentes;
usa dados objetivos;
cria temporizadores;
faz reavaliação periódica;
valoriza sinais externos;
e ensina:
“Familiar não significa seguro.”
📋 Checklist anti-Normalcy Bias
Quando algo parece estranho:
[ ] Isso está realmente dentro do baseline?
[ ] A tendência está melhorando ou piorando?
[ ] Estamos usando memória ou dados?
[ ] Condições são iguais às vezes anteriores?
[ ] Existe impacto confirmado?
[ ] Quanto custa esperar?
[ ] Qual é nosso trigger de incidente?
[ ] Quando reavaliamos?
[ ] Alguém está minimizando sem evidência?
[ ] O silêncio do grupo está sendo tratado como prova?
[ ] Se isso dobrar, o que faremos?
[ ] Já deveríamos estar agindo?
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Normalcy Bias é a tendência de presumir que a realidade continuará parecida com o normal conhecido, mesmo diante de sinais anormais.
“Já aconteceu antes” não prova que a situação atual seja segura.
Familiaridade pode atrasar reconhecimento de emergência.
Baseline objetivo é melhor que memória.
Esperar precisa ter prazo e critério.
Não é necessário conhecer causa raiz para declarar incidente.
Automation Bias e Alarm Fatigue podem reforçar Normalcy Bias.
Groupthink e Authority Gradient podem transformar minimização individual em consenso.
Normalization of Deviance muda o que chamamos de normal.
Drift Into Failure muda o sistema enquanto nosso modelo mental permanece antigo.
E principalmente:
O fato de o mundo ter voltado ao normal ontem não obriga o mundo a repetir a gentileza hoje.
🕰️ De volta às 09:04
A TARDIS retorna.
Primeiro alerta:
PAYMENT RESPONSE TIME ABOVE BASELINE
Operador:
— Deve ser pico.
Nosso programador responde:
— Pode ser. Vamos comparar com baseline.
09:08.
Fila 60% acima do normal.
09:10.
Timeout 4%.
Trigger definido:
TIMEOUT > 3%
FOR 3 MIN
→ DECLARE DEGRADED
09:13.
Ainda 4,5%.
Ele diz:
— Estamos em degraded.
O gerente pergunta:
— Já?
— Sim. O critério foi definido antes.
09:16.
Impacto aumenta.
Trigger:
FAILURE RATE > 5%
→ OPEN INCIDENT
Incidente aberto.
Owner atribuído.
MQ investigado.
Consumer degradado.
09:24.
Causa encontrada.
09:29.
Serviço restaurado.
Backlog controlado.
Nenhuma crise de duas horas.
O gerente pergunta:
— Não abrimos cedo demais?
Nosso programador olha para o gráfico.
— Talvez.
— E isso não é ruim?
O Doctor responde antes dele:
— Comparado a quê?
Silêncio.
— Ao privilégio de descobrir tarde demais que deveriam ter aberto antes?
O gerente sorri.
— Justo.
🥚 Easter Egg final
Horas depois surge:
BELLACOSA.BIAS(NORMAL)
Dentro:
IF CURRENT-STATE NOT = BASELINE
PERFORM INVESTIGATE
END-IF.
IF ONLY-REASON-TO-WAIT =
'IT-USUALLY-GETS-BETTER'
PERFORM SET-TIMER
END-IF.
IF IMPACT-CONFIRMED
PERFORM ACT
END-IF.
Comentário:
* FAMILIAR IS NOT THE SAME AS SAFE.
Outro:
* HOPE IS NOT A MONITORING STRATEGY.
E, naturalmente:
* BAD WOLF LEFT BEFORE THE ALARM.
Nosso jovem fecha o membro.
Pouco depois alguém diz:
— Esse erro costuma sumir sozinho.
Ele responde:
— Ótimo.
— Ótimo?
— Sim. Então sabemos o que esperar.
Abre um timer.
— Se não sumir em cinco minutos, sabemos que não estamos mais no caso normal.
Essa resposta é simples.
Mas representa uma mudança profunda.
Ele não rejeitou experiência.
Transformou experiência em critério testável.
Não entrou em pânico.
Também não negou realidade.
Em algum lugar:
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro permanece uma frase:
Calma é observar os fatos sem pânico. Normalcy Bias é observar os fatos e esperar que eles parem de ser fatos.
☕🌀
Next stop: Survivorship Bias — quando estudamos apenas os sistemas, projetos e equipes que sobreviveram e esquecemos de perguntar quantos fizeram exatamente a mesma coisa e desapareceram no caminho.