Bellacosa Mainframe em overconfidence bias

☕ Um Café no Bellacosa Mainframe

Overconfidence Bias: Doctor Who, COBOL e o Dia em que o Especialista Tinha Certeza Demais

Uma viagem pela TARDIS dos incidentes para entender por que experiência, sucesso passado e conhecimento técnico podem transformar confiança em cegueira operacional

02:08.

War Room.

Café forte.

Mudança crítica.

O gerente pergunta:

— Temos risco?

O especialista mais experiente da sala responde sem hesitar:

— Não.

Nosso programador COBOL iniciante olha para ele.

Trinta anos de mainframe.

Db2.

CICS.

JCL.

VSAM.

COBOL.

SMP/E.

Production support.

Milhares de mudanças.

Centenas de incidentes.

O homem provavelmente já viu coisas que fariam um microserviço pedir aposentadoria.

O jovem pergunta:

— Nenhum risco?

O especialista sorri.

— Já fiz isso dezenas de vezes.

O gerente relaxa.

A mudança segue.

02:17.

Primeiro warning.

WARNING
BATCH ELAPSED ABOVE EXPECTED

O especialista olha.

— Normal.

02:23.

QUEUE DEPTH: +140%

— Efeito transitório.

02:31.

DB2 LOCK WAIT: +320%

O iniciante pergunta:

— Devemos parar?

O especialista responde:

— Confia em mim.

Essa frase muda o clima da sala.

Porque confiança é confortável.

Certeza mais ainda.

02:39.

TRANSACTION FAILURE RATE: 8%

O especialista ainda insiste:

— Vai estabilizar.

VWORP.

A TARDIS materializa-se ao lado do console.

A porta abre.

O Doctor sai.

Olha para os gráficos.

Olha para o especialista.

E pergunta:

— Quanto você acha que sabe sobre o que vai acontecer nos próximos dez minutos?

O especialista cruza os braços.

— O suficiente.

O Doctor sorri.

— Ah.

Pausa.

— Essa é exatamente a resposta que me preocupa.

Bem-vindo ao:

Overconfidence Bias

Ou:

Viés de Excesso de Confiança

A tendência de superestimar a precisão do próprio conhecimento, julgamento, previsão ou controle sobre os acontecimentos.

🌀 Onde estamos na nossa jornada?

Nossa TARDIS já encontrou uma bela coleção de monstros cognitivos e organizacionais.

Swiss Cheese Model mostrou como várias barreiras podem falhar.

Normalization of Deviance mostrou como desvios viram rotina.

Hindsight Bias mostrou como o passado parece óbvio depois.

Confirmation Bias mostrou como procuramos aquilo que confirma nossas crenças.

Anchoring Bias mostrou como a primeira explicação prende a investigação.

Groupthink mostrou como grupos inteligentes podem errar juntos.

Authority Gradient mostrou como hierarquia pode silenciar informação importante.

Plan Continuation Bias mostrou como continuamos planos que já deveriam ser revistos.

Alarm Fatigue mostrou como excesso de sinais destrói atenção.

Automation Bias mostrou como confiamos demais em sistemas automáticos.

Drift Into Failure mostrou como sistemas derivam lentamente para a borda.

Diffusion of Responsibility mostrou como todos podem ver e ninguém agir.

Normalcy Bias mostrou como esperamos que tudo volte ao normal.

Survivorship Bias mostrou como estudamos apenas os sobreviventes.

Base Rate Neglect mostrou como esquecemos a frequência real dos eventos.

Availability Heuristic mostrou como memória fácil parece probabilidade.

Outcome Bias mostrou como confundimos resultado com qualidade da decisão.

Agora surge um viés capaz de alimentar quase todos os anteriores:

certeza demais.

🧠 O que é Overconfidence Bias?

Overconfidence Bias é a tendência de acreditar que nossas estimativas, previsões, julgamentos ou habilidades são mais precisos do que realmente são.

Em forma simples:

O QUE EU SEI
   <
O QUE EU ACHO QUE SEI

Essa diferença é perigosa.

Especialmente em sistemas complexos.

Porque quanto maior a confiança subjetiva, menor pode ser a disposição para:

verificar;
ouvir;
testar;
pedir ajuda;
considerar alternativas;
revisar o plano.

☕ Bellacosa Mainframe: o veterano que já viu tudo

Experiência é valiosa.

Extremamente valiosa.

Um profissional com décadas de produção reconhece padrões que um iniciante não reconhece.

Isso ajuda.

Mas existe uma armadilha:

“Já vi isso antes.”

pode virar:

“Sei exatamente o que está acontecendo.”

E essas frases não são equivalentes.

Talvez o sistema de 2026 tenha:

mais integrações;

mais volume;

mais dependências;

mais automação;

mais camadas;

mais fornecedores.

A aparência pode ser familiar.

O mecanismo pode ser novo.

🧠 Experiência não elimina incerteza

Essa é uma regra importante:

Experiência reduz ignorância. Não elimina incerteza.

Sistemas complexos possuem interações emergentes.

Mesmo especialista excelente pode errar.

Aliás, especialistas muito bons às vezes conseguem construir justificativas extremamente sofisticadas para uma hipótese errada.

Isso é uma forma elegante de permanecer enganado.

👻 Easter Egg nº 1 — “Eu sei exatamente o que estou fazendo”

Imagine Doctor Who.

Companion:

— Você sabe exatamente o que está fazendo?

Doctor:

— Absolutamente.

Pausa.

Olha para o console.

— Mais ou menos.

Esse “mais ou menos” é saudável.

Porque inteligência real precisa conviver com incerteza.

📏 Calibration

Uma ideia central aqui é:

calibração.

Se alguém diz:

“Tenho 90% de certeza.”

em muitas situações semelhantes, algo próximo de 90% deveria estar correto.

Se acerta 60%:

está overconfident.

Se acerta 98%:

talvez esteja underconfident.

Calibração significa alinhar confiança subjetiva com desempenho real.

📊 Exemplo simples

Analista registra 100 previsões.

Em todas escreve:

CONFIDENCE: 90%

Depois:

CORRETAS: 61
ERRADAS: 39

Temos um problema.

Não necessariamente técnico.

Cognitivo.

A confiança está mal calibrada.

🧠 O perigo do “tenho certeza”

Durante incidente:

“Tenho certeza que é Db2.”

Pergunta útil:

“Quanto de certeza?”

Se resposta:

“100%.”

Cuidado.

Sistemas complexos raramente oferecem 100%.

Uma hipótese mais saudável:

“Db2 é minha hipótese principal, algo como 70%, porque A, B e C.”

Agora podemos atualizar.

🔎 Confidence range

Ao invés de:

ROOT CAUSE: DB2

use:

HYPOTHESIS: DB2
CONFIDENCE: 65%
EVIDENCE:
- lock wait elevated
- same timeline
CONTRARY:
- one affected path bypasses DB2

Muito melhor.

Certeza virou algo examinável.

⚓ Overconfidence + Anchoring

Especialista fala:

“É storage.”

Todos acreditam.

A hipótese vira âncora.

Quanto maior a confiança da fala, maior o poder de ancoragem.

Tom confiante pode influenciar tanto quanto evidência.

Isso é importante:

convicção não é dado.

🔎 Overconfidence + Confirmation Bias

A pessoa já está convencida.

Agora começa a procurar provas.

Quanto maior a confiança inicial, menor disposição para reconhecer evidência contrária.

Confirmation Bias vira guarda-costas da certeza.

👥 Overconfidence + Groupthink

O especialista mais respeitado fala com total certeza.

Grupo:

— Se ele está tão seguro...

Convergência.

Agora ninguém quer parecer a única pessoa insegura.

Groupthink cresce.

🪜 Overconfidence + Authority Gradient

Especialista sênior:

— Não precisamos rollback.

Júnior:

— Mas...

— Já fiz isso cem vezes.

Fim.

A confiança do sênior amplifica a distância hierárquica.

Authority Gradient transforma certeza individual em silêncio coletivo.

▶️ Overconfidence + Plan Continuation Bias

Plano começa a dar sinais ruins.

Líder confiante:

“Está sob controle.”

Continua.

Depois:

“Mais cinco minutos.”

Continua.

Overconfidence reduz percepção de necessidade de parar.

🔔 Overconfidence + Alarm Fatigue

Operador experiente diz:

“Esse alerta é lixo.”

Talvez esteja certo.

Mas certeza excessiva pode impedir perceber que hoje a assinatura mudou.

Familiaridade + confiança = perigo.

🤖 Automation Bias e confiança delegada

Às vezes excesso de confiança não está na pessoa.

Está na ferramenta.

Dashboard:

CONFIDENCE: 98%

Usuário transfere certeza para máquina.

Mas quem validou essa calibração?

Overconfidence pode ser automatizado.

🌀 Drift Into Failure

Esse encaixe é fantástico.

Uma organização vive anos sem grande incidente.

Começa a acreditar:

“Nós dominamos isso.”

Margem cai.

Exceções crescem.

Mas sucesso histórico produz confiança.

Agora Overconfidence acelera o drift.

🧠 Outcome Bias alimenta Overconfidence

Esse é o ponto central da sequência.

Decisão arriscada dá certo.

Outcome Bias:

foi uma boa decisão.

Repete.

Dá certo.

A pessoa começa:

“Sou muito bom nisso.”

Agora:

Outcome Bias virou Overconfidence Bias.

Sorte histórica foi convertida em autoestima preditiva.

🎰 Streaks e falsa competência

Imagine dez mudanças arriscadas.

Todas funcionam.

A pessoa conclui:

“Eu sei exatamente até onde podemos ir.”

Talvez.

Ou talvez tenha experimentado uma sequência favorável.

Em sistemas probabilísticos, sucesso repetido não elimina risco residual.

🧠 Gambler’s illusion corporativa

Existe uma tentação:

“Nunca falhou antes.”

Logo:

“não vai falhar agora.”

Isso não é exatamente Overconfidence apenas.

Mas muitas vezes aparece junto.

Histórico positivo cria sensação de controle.

🎯 Illusion of Control

Outro conceito relacionado:

Illusion of Control.

Tendência de acreditar que controlamos mais um resultado do que realmente controlamos.

Exemplo:

“Se der problema, eu resolvo.”

Talvez.

Mas e se:

rollback quebrar;

dado corromper;

dependência externa cair?

A capacidade de reação também possui limites.

☕ Bellacosa Mainframe: “Se der problema, voltamos”

Essa frase parece ótima.

Pergunta:

rollback foi testado?

— Não.

Então:

“Se der problema, voltamos”

não é plano.

É esperança com verbo técnico.

Overconfidence adora planos não testados.

🧪 Teste a confiança

Sempre que alguém disser:

“Isso é tranquilo.”

Pergunte:

“O que poderia tornar isso não tranquilo?”

Se pessoa não consegue citar nada:

talvez esteja overconfident.

Especialista maduro normalmente conhece falhas possíveis.

🧠 Conhecimento verdadeiro inclui limites

Pessoa superficial:

“Sei.”

Pessoa experiente:

“Sei, mas depende.”

Pessoa realmente madura:

“Sei bastante nesta área; nesta parte aqui tenho baixa confiança.”

Isso é força.

Não fraqueza.

🧠 Dunning-Kruger — cuidado com simplificações

Overconfidence é frequentemente confundido com o chamado efeito Dunning-Kruger.

Mas não são simplesmente sinônimos.

O ponto útil aqui é:

pessoas podem ter dificuldade de avaliar a própria competência em determinados contextos.

Porém Overconfidence também aparece em especialistas.

Não é apenas problema de iniciantes.

👨‍💻 O iniciante pode ser excessivamente confiante

Programador aprende COBOL básico.

Consegue:

MOVE.

IF.

PERFORM.

Arquivo sequencial.

Pensa:

“COBOL é simples.”

Depois encontra:

REDEFINES;

COMP-3;

OCCURS DEPENDING ON;

CICS;

Db2;

VSAM;

EBCDIC;

copybooks gigantes.

Humildade chega.

Normal.

🧙 O especialista também pode ser

Trinta anos de experiência.

Já resolveu milhares de incidentes.

Isso pode criar:

“Meu feeling é suficiente.”

Às vezes é excelente.

Mas precisa continuar aberto a falsificação.

📚 Tacit Knowledge

Especialistas possuem conhecimento tácito.

Difícil de explicar.

Reconhecem padrões.

Isso é real.

Não precisa transformar tudo em checklist.

Mas decisões críticas ainda podem se beneficiar de:

dados;
challenge;
segunda opinião;
critérios.

Experiência e processo não são inimigos.

🔍 Recognition-Primed Decision novamente

No modelo de decisão baseado em reconhecimento, especialistas percebem padrões rapidamente.

Excelente.

Mas uma defesa útil é:

“Que detalhe faria este caso não ser aquele padrão?”

Isso reduz excesso de confiança sem desperdiçar expertise.

🧪 Premortem

Já vimos essa técnica.

Ela é excelente contra Overconfidence.

Antes da mudança:

“Imagine que falhou horrivelmente. O que aconteceu?”

Pessoas são forçadas a produzir modos de falha.

Isso quebra a fantasia:

“Tudo vai dar certo.”

🧠 Prospective Hindsight

Premortem usa uma forma de retrospectiva imaginada.

Você se coloca no futuro onde falhou.

Agora pergunta:

“Por quê?”

Isso ajuda a encontrar riscos ignorados pela confiança.

📋 Checklist de confiança

Antes de mudança crítica:

[ ] Quais são nossas principais premissas?

[ ] Qual delas pode estar errada?

[ ] Que dado não temos?

[ ] Qual é nossa confiança real?

[ ] Existe evidência contrária?

[ ] Quem discorda?

[ ] Qual é nosso rollback?

[ ] Foi testado?

[ ] O que faria STOP?

[ ] Estamos confiando em experiência ou evidência atual?

📊 Confidence intervals no espírito

Você não precisa calcular intervalo estatístico formal para toda decisão.

Mas pense:

“Minha estimativa é 20 minutos.”

Talvez seja:

20 ± 15.

Isso muda planejamento.

Overconfidence costuma produzir estimativas estreitas demais.

⏱️ Planning Fallacy

Existe outro viés relacionado:

Planning Fallacy.

Subestimamos:

tempo;

custo;

complexidade.

Porque confiamos demais em cenários ideais.

Exemplo:

— Mudança leva 30 minutos.

Realidade:

2h45.

Esse merece episódio próprio.

☕ “Só meia hora”

Frase corporativa famosa.

“Só muda um parâmetro.”

“Só um copybook.”

“Só um campo.”

“Só um restart.”

O mainframe sabe que “só” costuma ser palavra com tendências terroristas.

🧠 Complexity blindness

Overconfidence pode levar a subestimar dependências.

Você conhece muito bem seu componente.

Mas não necessariamente:

sistema inteiro.

Isso se conecta à racionalidade local do Drift Into Failure.

🕸️ Local expertise ≠ global certainty

DBA conhece Db2.

Sysprog conhece z/OS.

Programador conhece aplicação.

Mas incidente atravessa:

MQ;

rede;

API;

cloud;

fornecedor.

A certeza local pode falhar globalmente.

🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Tenho certeza.”

Pergunte:

“Qual evidência faria você mudar de ideia?”

Se resposta:

“Nenhuma.”

Não temos hipótese.

Temos fé.

🎯 Pergunta Bellacosa nº 2

Outra:

“Quanto você apostaria se precisasse colocar um percentual?”

Isso força calibração.

🎯 Pergunta Bellacosa nº 3

Outra:

“Que parte dessa decisão está fora da nossa visibilidade?”

Perfeito para sistemas complexos.

🎯 Pergunta Bellacosa nº 4

“Estamos certos ou apenas acostumados a dar certo?”

Essa deveria ficar na parede da War Room.

🧪 Decision Journal contra Overconfidence

Registre antes:

DECISION:
GO

CONFIDENCE:
80%

EXPECTED:
Batch completes by 02:30

RISKS:
- MQ consumer delay
- DB2 contention

STOP IF:
Queue > 10k

Depois compare.

Se seu 80% falha metade das vezes:

aprenda.

🧠 Calibration curves pessoais

Especialistas poderiam revisar suas previsões.

Exemplo:

Quando disseram 90%:

acertaram 72%.

Quando disseram 70%:

acertaram 68%.

Ótimo insight.

Talvez reduzir confiança declarada.

🎯 Humildade epistemológica

Nome bonito.

Ideia simples:

“Posso estar errado.”

Não significa paralisia.

Você ainda decide.

Mas mantém espaço para atualização.

Esse espaço pode salvar produção.

🏦 Overconfidence em finanças

Trader tem sequência de lucros.

Aumenta posição.

Mais lucro.

Acredita ter habilidade especial.

Depois mercado muda.

Perda enorme.

É um padrão clássico de excesso de confiança.

TI possui sua versão:

deploys arriscados funcionando.

Até não funcionarem.

🔐 Segurança

Especialista diz:

“Ninguém consegue explorar isso.”

Pergunta:

“Testamos?”

— Não.

Então isso é confiança.

Não evidência.

Segurança odeia certezas não testadas.

🤖 IA e overconfidence textual

Modelos podem produzir respostas fluidas e assertivas.

Usuário interpreta:

confiança alta.

Mas fluência e confiança epistemológica não são a mesma coisa.

Uma resposta elegante pode estar errada.

Por isso:

fontes;
testes;
validação;
evidência.

Sempre.

🧠 Human + AI overconfidence loop

Pessoa já acredita em X.

Pergunta à IA de forma enviesada.

IA responde algo compatível.

Pessoa:

“A IA confirmou.”

Agora confiança aumenta.

Confirmation Bias + Automation Bias + Overconfidence.

Combo premium.

🧪 Independent validation

Uma defesa:

não peça apenas para IA:

“Confirme que minha hipótese está certa.”

Pergunte:

“Quais evidências contradizem minha hipótese?”

Ou:

“Que explicações alternativas existem?”

Isso quebra o loop.

📋 Como combater Overconfidence Bias — passo a passo

Passo 1 — Transforme certeza em probabilidade

Não:

“É rede.”

Use:

“Rede é hipótese principal, 60%.”

Passo 2 — Liste o que não sabe

Unknowns.

Visíveis.

Passo 3 — Procure disconfirming evidence

Não só confirmação.

Passo 4 — Use premortem

Imagine falha.

Passo 5 — Peça segunda opinião

Principalmente em ações irreversíveis.

Passo 6 — Registre previsões

Antes do resultado.

Passo 7 — Revise calibração

Periodicamente.

Passo 8 — Use STOP criteria

Não dependa do feeling durante pressão.

Passo 9 — Dê voz ao júnior

Fresh eyes.

Passo 10 — Celebre mudança de opinião baseada em evidência

Isso é maturidade.

🧠 Mudar de ideia não é perder

Essa ideia precisa virar cultura.

Pessoa diz:

— Minha hipótese era Db2.

Novo dado mostra MQ.

— Estava errado. Mudamos para MQ.

Excelente.

Não:

“Como posso reinterpretar o dado para continuar certo?”

A capacidade de abandonar hipótese é competência.

🧯 O ego também é dependência operacional

Se uma investigação depende de alguém preservar reputação:

temos risco.

Cultura precisa permitir:

“Eu errei.”

Sem transformar isso em humilhação.

Isso reduz Overconfidence defensivo.

🧠 Expertise sem ego

Uma das marcas de especialistas excelentes é conseguir dizer:

“Não sei.”

Essa resposta pode parecer menos impressionante.

Mas é muito mais útil que inventar certeza.

☕ O “não sei” operacional

Exemplo:

— É seguro?

Resposta ruim:

“Sim.”

Resposta melhor:

“Não encontrei risco conhecido, mas ainda não validamos rollback.”

A segunda informa.

🧠 Unknown unknowns

Donald Rumsfeld popularizou a expressão “unknown unknowns”, mas a ideia é muito mais ampla:

existem coisas que não sabemos que não sabemos.

Sistemas complexos têm muitas.

Overconfidence ignora esse espaço.

🌌 Doctor Who adora unknown unknowns

Uma porta alienígena.

Doctor:

— Não toque.

Companion:

— Por quê?

— Não sei.

— Então talvez seja segura.

— Essa lógica é fascinante e horrível.

Em produção:

ausência de risco conhecido não é prova de ausência de risco.

🧪 Chaos Engineering como vacina parcial

Uma organização muito confiante pode testar suas crenças deliberadamente.

Exemplo:

falha de node;

latência;

dependência indisponível.

Pergunta:

“O sistema realmente reage como acreditamos?”

Chaos Engineering, quando apropriada e bem controlada, ajuda a confrontar crenças com realidade.

🧠 Game Days

Simulações.

Incident drills.

Rollback drills.

Você descobre:

runbook errado;

telefone desatualizado;

permissão ausente.

Ótimo.

Melhor descobrir durante exercício que durante desastre.

🧯 Teste de restore

“Backup funciona.”

Overconfidence.

Pergunta:

“Restore foi testado?”

Se não:

temos arquivo.

Não garantia de recuperação.

💾 Um backup não testado é fé armazenada em disco

Talvez essa frase mereça o café.

🧠 Overconfidence e documentação

Especialista:

“Não precisa documentar, eu sei.”

Perigoso.

Conhecimento está numa cabeça.

Availability alta para ele.

Zero para próximo turno.

Drift Into Failure agradece.

🪫 Bus Factor

Se uma pessoa for embora e o sistema parar:

risco.

Overconfidence organizacional pode esconder isso:

“Fulano sempre resolve.”

Até não estar disponível.

🧠 Team confidence

Não é apenas indivíduo.

Equipes podem desenvolver excesso de confiança.

“Nossa equipe nunca erra.”

“Nosso mainframe nunca cai.”

“Nosso processo é maduro.”

Essas frases merecem curiosidade.

🏆 Success breeds complacency

Sucesso é maravilhoso.

Mas pode reduzir vigilância.

Outro paradoxo:

quanto melhor história, maior risco de acreditar que controles são desnecessários.

Outcome Bias volta novamente.

🎯 A regra do sucesso desconfiado

Depois de uma operação dar certo:

pergunte:

“Que riscos existiam e não se materializaram?”

Isso mantém aprendizado.

Não precisa transformar sucesso em pessimismo.

Apenas separar:

competência;

controle;

sorte.

🧪 Success post-mortem

Por que não estudar também mudanças bem-sucedidas?

Pergunte:

o que funcionou;
o que quase falhou;
que intervenção manual ocorreu;
que suposição estava errada;
onde tivemos sorte.

Isso reduz Overconfidence.

📊 Near misses invisíveis

Resultado verde.

Mas:

duas retries;

um manual fix;

um DBA interveio;

um alerta foi ignorado.

Talvez a operação “bem-sucedida” carregasse aprendizado.

Registre.

🧠 Overconfidence e Normalcy Bias

“Sempre estabiliza.”

Confiança alta.

Então esperamos.

Até não estabilizar.

Overconfidence fornece força ao Normalcy Bias.

🧠 Overconfidence e Survivorship Bias

“Nosso método funciona.”

Porque estamos olhando para sobreviventes.

Casos fracassados não aparecem.

A confiança cresce sobre amostra incompleta.

🧠 Overconfidence e Base Rate Neglect

Especialista acha que identifica falhas raras “no feeling”.

Mas talvez taxa real seja baixa.

Sem histórico, confiança subjetiva domina.

🧠 Overconfidence e Availability Heuristic

Incidente recente está vivo na memória.

Pessoa lembra bem.

Sente confiança.

“É igual.”

Memória forte produz certeza forte.

📋 Checklist Bellacosa anti-Overconfidence

[ ] Qual é nossa hipótese?

[ ] Qual percentual de confiança?

[ ] O que não sabemos?

[ ] Qual evidência contradiz?

[ ] Quem discorda?

[ ] Que condição faria STOP?

[ ] O rollback está testado?

[ ] Estamos usando histórico real?

[ ] Já tivemos sorte com esse processo antes?

[ ] O sistema mudou desde a última vez?

[ ] Estamos confundindo experiência com infalibilidade?

[ ] Se estivermos errados, como descobriremos cedo?

🧬 Regeneração organizacional

Como regenerar depois de reconhecer excesso de confiança?

A organização passa a:

registrar previsões;

usar níveis de confiança;

fazer premortems;

criar challenge process;

valorizar segunda opinião;

testar rollback;

executar drills;

preservar unknowns;

revisar near misses;

premiar mudança de opinião baseada em dados.

E principalmente:

ensina líderes e especialistas a dizer:

“Esta é minha melhor hipótese, não uma profecia.”

📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Overconfidence Bias é a tendência de superestimar a precisão do próprio julgamento.

Experiência ajuda, mas não elimina incerteza.

Convicção não é evidência.

Confiança precisa ser calibrada.

Outcome Bias pode transformar sorte em excesso de confiança.

Authority Gradient amplifica a certeza do especialista.

Groupthink pode transformar certeza individual em consenso coletivo.

Plan Continuation Bias fica mais forte quando líderes acreditam controlar a situação.

Premortem, segunda opinião e decision journals ajudam.

Especialistas maduros sabem dizer “não sei”.

E principalmente:

A confiança útil diz “sei o suficiente para decidir”. A confiança perigosa diz “sei tanto que não preciso mais verificar”.

🕰️ De volta às 02:08

A TARDIS retorna.

Mudança prestes a começar.

Gerente:

— Temos risco?

Especialista responde:

— Não.

Nosso programador agora pergunta:

— Zero?

O especialista pensa.

— Bem... não zero.

— Qual sua confiança?

— Talvez 85%.

— E os 15%?

Silêncio.

Abrem a lista.

Rollback ainda não testado.

Uma dependência externa mudou.

Volume maior que no último ciclo.

Agora a equipe possui algo melhor que certeza.

Possui:

um mapa da incerteza.

O gerente pergunta:

— Ainda GO?

Especialista:

— HOLD por quinze minutos. Quero testar o rollback e validar a dependência.

Quinze minutos depois:

descobrem que rollback falharia por falta de permissão.

Corrigem.

GO.

Mudança funciona.

Resultado bom.

Nosso programador pergunta:

— Então você estava certo?

O especialista sorri.

— Sobre qual parte?

Boa resposta.

O Doctor coloca as mãos nos bolsos.

— Agora sim estou começando a gostar desta equipe.

VWORP.

🥚 Easter Egg final

No dia seguinte aparece:

BELLACOSA.BIAS(CONFIDENT)

Dentro:

       IF CONFIDENCE = 100
           PERFORM FIND-WHAT-WE-MISSED
       END-IF.

       IF EXPERIENCE = 'HIGH'
           PERFORM CHECK-CURRENT-DATA
       END-IF.

       IF SOMEONE-SAYS
          'TRUST-ME'
           PERFORM ASK-FOR-EVIDENCE
       END-IF.

Comentário:

* CERTAINTY IS NOT A MONITORING TOOL.

Outro:

* EXPERIENCE SHOULD REDUCE ERROR,
* NOT REDUCE CURIOSITY.

E naturalmente:

* BAD WOLF WAS 99% SURE.

Nosso jovem programador fecha o membro.

Pouco depois alguém pergunta:

— Você sabe resolver esse S0C7?

Ele quase responde:

“Claro.”

Mas para.

Abre o dump.

— Tenho uma hipótese forte.

— Qual?

— Dado inválido.

— Tem certeza?

Ele sorri.

— Ainda não.

E talvez esse “ainda não” seja uma das frases mais inteligentes que um profissional pode carregar para produção.

Porque sistemas críticos não precisam de pessoas inseguras.

Precisam de pessoas confiantes o suficiente para agir...

e humildes o suficiente para verificar.

VWORP.

A TARDIS desaparece.

No quadro fica:

Confiança é combustível. Certeza excessiva é neblina. Use a primeira sem dirigir dentro da segunda.

☕🌀

Next stop: Planning Fallacy — quando todo mundo sabe que projetos parecidos levam seis horas, mas a reunião conclui com absoluta serenidade que “dessa vez fazemos em quarenta minutos”.

Translate

terça-feira, 7 de junho de 2011