 |
| 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.
VWORP.
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
E:
“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:
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.
VWORP.
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.
VWORP.
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”.
