 |
| Bellacosa Mainframe e o self serving bias |
☕ Um Café no Bellacosa Mainframe
Self-Serving Bias: Doctor Who, COBOL e o Dia em que o Sucesso Foi Nosso — Mas o Fracasso Era Sempre de Outra Pessoa
Uma viagem pela TARDIS dos incidentes para entender por que atribuímos sucessos à nossa competência e fracassos ao contexto, aos outros ou ao azar — e como isso pode impedir equipes inteiras de aprender
09:14.
Segunda-feira.
Reunião operacional.
Café quente.
Dashboard verde.
Na tela:
CHANGE SUCCESS RATE: 100%
INCIDENTS: 0
CUSTOMER IMPACT: 0
O gerente sorri.
— Excelente trabalho da equipe.
O arquiteto concorda.
— O planejamento foi muito bom.
O especialista acrescenta:
— Nossa experiência fez a diferença.
Nosso jovem programador COBOL anota mentalmente:
RESULTADO BOM
=
COMPETÊNCIA NOSSA
Até aí, tudo bem.
Uma semana depois.
Mesma sala.
Mesmo café.
Mas o dashboard agora parece ter sido decorado por um Dalek deprimido.
CHANGE FAILED
CUSTOMER IMPACT: 27%
ROLLBACK: 48 MIN
SEV-1
O gerente pergunta:
— O que aconteceu?
O arquiteto responde:
— O fornecedor atrasou uma dependência.
O especialista:
— A janela era curta demais.
Operações:
— A rede também oscilou.
Desenvolvimento:
— O ambiente de homologação não era igual ao de produção.
Nosso jovem programador olha para todos.
— E nossa decisão de fazer GO mesmo sabendo disso?
Silêncio.
— Isso também entrou na causa?
O gerente responde:
— Bem... as circunstâncias estavam muito desfavoráveis.
Interessante.
Na semana anterior:
resultado bom.
Mérito interno.
Agora:
resultado ruim.
Circunstâncias externas.
Nosso jovem começa a enxergar o padrão.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para o relatório da semana anterior.
Depois para o atual.
— Então quando funcionou foi competência de vocês?
— Sim.
— E quando falhou foi culpa das condições?
O gerente hesita.
— Basicamente.
O Doctor sorri.
— Fascinante.
— O quê?
— Vocês aparentemente controlam todos os sucessos...
Pausa.
— e nenhum dos fracassos.
Bem-vindo ao:
Self-Serving Bias
Ou:
Viés de Autoconveniência
A tendência de atribuir nossos sucessos principalmente às nossas capacidades, decisões e esforços, enquanto explicamos nossos fracassos por fatores externos, circunstâncias adversas, azar ou erros de outras pessoas.
Em linguagem Bellacosa:
“Quando funciona, fui eu. Quando quebra, foi o universo.”
🌀 Nossa TARDIS dos incidentes já está virando um catálogo cognitivo
Até aqui encontramos:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos aquilo que confirma nossas crenças.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — grupos inteligentes podem errar juntos.
Authority Gradient — hierarquia pode transformar dúvida em silêncio.
Plan Continuation Bias — continuamos mesmo quando o plano perdeu sentido.
Alarm Fatigue — excesso de alertas vira ruído.
Automation Bias — confiamos demais na máquina.
Drift Into Failure — sistemas derivam lentamente para a borda.
Diffusion of Responsibility — todos veem e ninguém assume.
Normalcy Bias — esperamos que tudo volte ao normal.
Survivorship Bias — estudamos quem sobreviveu.
Base Rate Neglect — ignoramos frequências reais.
Availability Heuristic — o memorável parece mais provável.
Outcome Bias — um bom resultado pode mascarar uma decisão ruim.
Overconfidence Bias — acreditamos saber mais do que realmente sabemos.
Planning Fallacy — subestimamos tempo, esforço e complexidade.
Sunk Cost Fallacy — investimentos passados prendem decisões futuras.
Status Quo Bias — o atual parece naturalmente mais seguro.
Present Bias — o conforto imediato ganha prioridade.
Optimism Bias — acreditamos que o resultado será favorável para nós.
Action Bias — agir parece melhor que observar.
Omission Bias — não agir pode parecer menos culpável.
Loss Aversion — perder dói mais do que ganhar alegra.
Framing Effect — a forma de apresentar muda a percepção.
Recency Bias — o último evento recebe peso demais.
Representativeness Heuristic — “parece X” vira “deve ser X”.
Narrative Bias — uma boa história parece mais verdadeira do que deveria.
Fundamental Attribution Error — culpamos características pessoais dos outros e subestimamos o contexto.
Agora viramos o espelho.
Porque o cérebro costuma fazer algo curioso:
com os outros, personalidade.
conosco, circunstância.
E quando o resultado é bom:
mérito nosso.
🧠 O que é Self-Serving Bias?
Imagine duas provas.
Na primeira:
você tira 10.
Explicação:
“Estudei muito.”
Na segunda:
você tira 4.
Explicação:
“A prova estava mal feita.”
Talvez ambas as explicações sejam verdadeiras.
Mas existe uma tendência humana de organizar a causalidade de maneira favorável à nossa própria imagem.
Sucesso:
EU
↓
COMPETÊNCIA
↓
RESULTADO
Fracasso:
MUNDO
↓
AZAR / CONTEXTO / OUTROS
↓
RESULTADO
O problema não é autoestima.
O problema é aprendizado.
Porque se eu sou sempre causa dos sucessos e nunca participo dos fracassos...
não existe feedback capaz de me corrigir.
☕ Bellacosa Mainframe: o deploy perfeito
Deploy funciona.
Gerente:
— Excelente preparação.
Equipe:
— Testamos tudo.
Ótimo.
Mas talvez:
volume real tenha sido menor;
dependência externa tenha ficado estável;
ninguém encontrou o caso-limite;
rollback não tenha sido necessário.
Parte do sucesso pode vir de competência.
Parte pode vir de condições favoráveis.
Uma organização madura pergunta:
“O que fizemos bem e onde também tivemos sorte?”
🧠 Outcome Bias entra imediatamente
No capítulo de Outcome Bias vimos:
resultado bom pode fazer decisão parecer boa.
Self-Serving Bias acrescenta:
resultado bom também pode fazer a pessoa acreditar:
“Foi porque eu sou bom.”
Agora sorte vira competência percebida.
Próxima mudança:
mais confiança.
Overconfidence Bias agradece.
🧠 Self-Serving Bias + Overconfidence
A sequência pode ser:
DECISÃO ARRISCADA
↓
RESULTADO BOM
↓
“EU SABIA”
↓
SELF-SERVING BIAS
↓
“EU SOU BOM NISSO”
↓
OVERCONFIDENCE
↓
RISCO MAIOR
Até um dia não funcionar.
Depois:
“Foi o fornecedor.”
Círculo perfeito.
👻 Easter Egg nº 1 — o Doctor salvou o universo sozinho
Companion:
— Doctor, salvamos o planeta.
Doctor:
— Naturalmente.
— Nós?
— Bem... principalmente eu.
TARDIS range ao fundo.
Companion:
— E quando quase explodimos a Lua?
Doctor:
— Circunstâncias extraordinárias.
Pausa.
— Ah.
Self-Serving Bias sobrevive até a viagens temporais.
🧠 Fundamental Attribution Error versus Self-Serving Bias
Esses dois capítulos conversam lindamente.
Fundamental Attribution Error
Quando outra pessoa erra:
“Ela é descuidada.”
Self-Serving Bias
Quando eu erro:
“A situação estava impossível.”
Agora inverta o resultado.
Quando outra pessoa acerta:
“Teve sorte.”
Quando eu acerto:
“Competência.”
Essa assimetria pode destruir equipes.
☕ O DBA e o programador
DBA ajusta índice.
Sistema melhora.
DBA:
— Foi meu tuning.
Programador:
— A carga também caiu naquele horário.
Semana seguinte.
DBA ajusta índice.
Sistema piora.
DBA:
— A aplicação está fazendo SQL ruim.
Talvez.
Mas perceba a conveniência causal.
🧠 Atribuição assimétrica
Podemos brincar:
MEU SUCESSO
= SKILL
MEU FRACASSO
= CONTEXTO
SEU SUCESSO
= SORTE
SEU FRACASSO
= SKILL ISSUE
Talvez seja o algoritmo social mais antigo do planeta.
👥 Self-Serving Bias coletivo
Não acontece só em indivíduos.
Equipes inteiras fazem isso.
Aplicação:
“Nossa mudança estava correta; problema foi infraestrutura.”
Infra:
“Infra estava saudável; aplicação saturou.”
Banco:
“Db2 respondeu dentro do esperado; SQL veio ruim.”
Rede:
“Pacotes estavam normais; aplicação tinha timeout baixo.”
Agora todos estão certos...
e produção continua quebrada.
🧠 Organizational Self-Serving Bias
Empresas também fazem.
Projeto bem-sucedido:
“Nossa estratégia.”
Fracasso:
“Mercado mudou.”
Pode ser verdade.
Mas se toda vitória é interna e toda derrota é externa:
o modelo de aprendizado está quebrado.
🧠 Narrative Bias fornece a história conveniente
Narrative Bias monta a história.
Self-Serving Bias escolhe a versão que protege nossa autoimagem.
Sucesso:
“Planejamos perfeitamente.”
Fracasso:
“O fornecedor nos surpreendeu.”
Mesmo conjunto de fatores pode ser narrado de forma diferente.
🖼️ Framing Effect entra junto
Relatório de sucesso:
“Equipe entregou sob condições complexas.”
Relatório de fracasso:
“Dependência externa inviabilizou entrega.”
Agora compare:
talvez ambos tivessem:
equipe;
contexto;
dependências;
sorte.
O frame muda conforme o resultado.
🎯 Pergunta Bellacosa nº 1
Depois de um sucesso:
“Que fatores externos favoráveis ajudaram?”
Essa pergunta combate Self-Serving Bias.
🎯 Pergunta Bellacosa nº 2
Depois de um fracasso:
“Que decisões nossas aumentaram o risco?”
Essa é ainda mais importante.
🧠 Não transforme isso em autoflagelação
Cuidado.
O objetivo não é:
“Tudo é culpa nossa.”
Isso seria outro erro.
Às vezes:
fornecedor falhou.
Rede caiu.
Evento externo foi realmente determinante.
A meta é:
simetria de análise.
Use a mesma régua para sucesso e fracasso.
☕ O mesmo tribunal
Sucesso:
o que controlávamos?
o que não controlávamos?
Fracasso:
o que controlávamos?
o que não controlávamos?
Agora temos comparabilidade.
🧠 Locus of Control
Existe um conceito relacionado:
locus of control.
De forma simplificada, pessoas podem perceber resultados como mais ligados a:
fatores internos;
fatores externos.
Self-Serving Bias não é simplesmente ter locus interno ou externo.
É ajustar convenientemente a atribuição dependendo do resultado.
🧠 “Eu controlo quando dá certo”
Esse é o truque.
Não é:
“Eu sempre controlo.”
Nem:
“Nunca controlo.”
É:
“Eu controlo os bons resultados.”
Muito confortável.
Pouco científico.
💻 COBOL iniciante: compilou de primeira
Você escreve programa.
Compila.
Executa.
Tudo certo.
Pensa:
“Dominei.”
Depois segundo exercício falha.
Pensa:
“Esse compilador é chato.”
Bem-vindo à profissão.
Humildade operacional começa quando fazemos pergunta:
“O que eu fiz certo na primeira e errado na segunda?”
🧠 Error messages não têm ego
Compiler:
IGYPS2121-S
Ele não liga para sua autoestima.
Isso é ótimo.
Ferramentas determinísticas são excelentes professores.
☕ O COBOL não aceita argumento político
PIC está errado.
Está errado.
Não importa:
cargo;
badge;
experiência.
Talvez uma das virtudes do computador seja:
não participar do Self-Serving Bias humano.
Ainda.
🧠 Success Attribution
Quando algo dá certo, pergunte:
o processo funcionou?
a hipótese estava correta?
houve intervenção não planejada?
o volume foi favorável?
algum risco simplesmente não se materializou?
Isso evita confundir:
competência
com:
sorte.
🎲 Luck Analysis
Uma prática interessante:
depois de sucesso importante, registre:
onde tivemos sorte?
Exemplo:
SUCCESS:
Deploy completed.
LUCK:
- partner traffic 30% below forecast
- rollback not required
- senior DBA happened to be online
Agora sucesso continua sucesso.
Mas sem virar mito.
🧠 Near Misses revelam sorte
Mudança deu certo.
Mas:
disco ficou em 98%.
Manual fix foi necessário.
Pessoa específica estava disponível.
Esses near misses mostram:
resultado bom não significa controle total.
🧠 Survivorship Bias
Os sucessos são visíveis.
Os fracassos eliminados do processo podem desaparecer.
Self-Serving Bias aprende com os sobreviventes:
“Nosso método funciona.”
Talvez porque casos ruins foram cancelados ou escondidos.
☕ O projeto vencedor da apresentação
Slide:
“Entrega concluída em prazo recorde.”
Não mostra:
três projetos cancelados.
Survivorship + Self-Serving.
PowerPoint fica lindo.
Aprendizado, nem tanto.
🧠 Recency Bias
Acertamos os últimos três incidentes.
Equipe:
“Estamos muito bons.”
Talvez.
Ou sequência curta.
Recency Bias amplifica percepção de competência.
🔥 Hot Hand novamente
O analista acertou três RCAs.
Quarto:
todos acreditam.
Ele também.
Self-Serving Bias reforça:
“Meu feeling é excelente.”
Overconfidence aparece.
🧠 Confirmation Bias protege a autoimagem
Se acredito que sou excelente em diagnóstico:
lembro acertos.
Esqueço hipóteses erradas.
Quando erro:
encontro explicação externa.
A crença nunca sofre.
Confirmation Bias trabalha como advogado do ego.
🧠 Selective Memory
Nosso cérebro não mantém logs como SMF.
Ainda bem e infelizmente.
Podemos lembrar:
os dias em que salvamos produção.
Menos:
as vezes em que a primeira hipótese estava errada.
Por isso decision journals ajudam.
☕ SMF da autoestima
Talvez precisemos de:
USER.BELLACOSA.SMF.EGO
Registre:
hipótese inicial;
resultado;
confiança.
Depois consulte antes de declarar:
“Eu sempre acerto.”
📝 Decision Journal novamente
Antes:
HYPOTHESIS:
DB2
CONFIDENCE:
85%
Depois:
ROOT CAUSE:
API externa
Guarde.
Não para humilhar.
Para calibrar.
🧠 Hindsight Bias tenta apagar o erro
Depois de descobrir API:
“Eu já desconfiava.”
Decision log:
“DB2 85%.”
Obrigado, documento.
Self-Serving Bias e Hindsight Bias odeiam registros contemporâneos.
🧠 Planning Fallacy
Projeto atrasa.
Equipe diz:
“Cliente mudou escopo.”
Verdade talvez.
Mas quanto atraso veio também de:
estimativa agressiva?
dependências esquecidas?
otimismo?
Self-Serving Bias pode impedir calibrar planejamento.
📊 Decompose variance
Em vez de:
“atrasou por causa do cliente.”
Tente:
DELAY: 6 weeks
CLIENT CHANGE: 2 weeks
TEST UNDERESTIMATE: 2 weeks
ENVIRONMENT: 1 week
INTERNAL REWORK: 1 week
Agora o mundo continua culpado por parte.
E nós também aprendemos.
🧠 Sunk Cost
Projeto ruim.
Equipe que o propôs quer defender.
Se cancelar:
parece admitir erro.
Self-Serving Bias cria história:
“A estratégia continua correta; execução externa falhou.”
Talvez.
Mas talvez estratégia também precise revisão.
🧠 Escalation of Commitment
Quanto mais identidade investimos:
mais difícil admitir participação no fracasso.
Self-Serving Bias protege decisão passada.
Sunk Cost protege investimento.
Resultado:
mais investimento.
☕ “A ideia era boa, execução foi ruim”
Frase clássica.
Às vezes absolutamente correta.
Mas se toda ideia fracassada tem execução ruim...
talvez precisemos revisar critério de “boa ideia”.
🧠 Strategy-execution gap pode virar lixeira causal
Executivos:
estratégia estava certa.
Operação:
plano era impossível.
Cada nível protege a própria parte.
Organização não aprende.
👥 Groupthink e Self-Serving Bias coletivo
Equipe aprovou decisão em consenso.
Fracassa.
Agora todos dizem:
“Não havia alternativa.”
Talvez houvesse.
Mas admitir isso ameaça identidade coletiva.
Groupthink pode continuar depois da decisão.
🧠 Group-serving Bias
Existe também fenômeno relacionado em que favorecemos nosso grupo nas atribuições.
“Nossa equipe fez certo.”
“A outra equipe causou.”
Isso é especialmente importante em silos.
☕ Aplicação versus infraestrutura: Guerra dos Cem Anos
Aplicação:
“É rede.”
Rede:
“É aplicação.”
Db2:
“É SQL.”
Middleware:
“É consumer.”
Todo incidente começa uma assembleia da ONU.
Se cada silo preserva sua autoimagem, RCA vira negociação diplomática.
🧠 Shared Metrics ajudam
Use:
end-to-end latency;
transaction trace;
correlation ID.
Quando todos olham mesma cadeia:
menos espaço para defesa tribal.
📊 Data beats departmental ego
Não elimina política.
Mas ajuda.
🧠 Fundamental Attribution Error + Self-Serving Bias
Agora conseguimos ver a simetria:
Outro time falha:
“Eles são ruins.”
Nosso time falha:
“Contexto ruim.”
Outro time acerta:
“Tiveram sorte.”
Nosso time acerta:
“Competência.”
Se isso não for combatido:
cooperação morre.
🎯 Pergunta Bellacosa nº 3
“Se outra equipe tivesse tomado exatamente esta decisão, julgaríamos da mesma forma?”
Excelente teste.
🧠 Role Reversal Test
Pegue sua explicação.
Troque:
“nós”
por:
“eles”.
Ainda parece justa?
Se não:
Self-Serving Bias pode estar presente.
☕ O teste do espelho
Nosso deploy funcionou:
“Planejamento.”
Deploy deles funcionou:
“Sorte.”
Espelho.
Corrija.
🧠 Blameless Postmortem precisa incluir autoatribuição honesta
Não basta evitar culpar pessoa.
Também precisamos evitar:
autoabsolvição coletiva.
Blameless significa:
sem caça às bruxas.
Não:
sem responsabilidade.
🧠 Accountability madura
Pode dizer:
“Fornecedor falhou na entrega e nossa decisão de não ter fallback aumentou o impacto.”
Essa frase é poderosa.
Reconhece externo.
Reconhece interno.
Sem teatro.
☕ “E” em vez de “ou”
Não:
foi fornecedor OU nós.
Talvez:
fornecedor falhou E nós não tínhamos redundância.
Sistemas complexos adoram “e”.
🧀 Swiss Cheese novamente
Evento externo atravessa barreiras internas.
Se fornecedor falha:
isso é trigger.
Mas:
por que impacto virou SEV-1?
Talvez arquitetura permitiu propagação.
Self-Serving Bias quer parar no fornecedor.
Swiss Cheese pergunta pelas defesas.
🔐 Cybersecurity
Empresa sofre phishing.
Organização:
“Usuário clicou.”
Fundamental Attribution Error.
Usuário:
“Filtro deveria ter bloqueado.”
Self-Serving Bias.
Security:
“Treinamos todo mundo.”
Talvez todos estejam parcialmente certos.
Precisamos cadeia inteira.
🧠 Multi-party accountability
Incidentes frequentemente têm:
trigger externo;
erro humano;
controle ausente;
decisão interna.
Não procure absolvição.
Procure distribuição causal.
🤖 IA e Self-Serving Bias
Agora fica divertido.
Equipe usa IA.
Resultado bom:
“Nossa estratégia de IA foi excelente.”
Resultado ruim:
“O modelo alucinou.”
Pergunta:
como foi o prompt?
Havia validação?
HITL?
Dados?
Guardrails?
A IA pode virar novo bode expiatório.
🧠 Automation Bias de ida e volta
Quando IA acerta:
“Ferramenta maravilhosa.”
Quando erra:
“IA não presta.”
Ou:
usuário aceita resposta errada:
“Foi a IA.”
Mas quem decidiu delegar?
Self-Serving Bias pode terceirizar responsabilidade para automação.
☕ “A IA fez”
Uma frase que ouviremos cada vez mais.
Mas sistemas sociotécnicos precisam perguntar:
quem definiu objetivo?
quem aprovou autonomia?
quais controles?
qual validação?
quem tinha authority?
A IA é componente.
Não explicação total.
🧠 Vendor Blame
Fornecedor é alvo confortável.
Especialmente em cloud e SaaS.
“Foi AWS.”
Talvez.
Mas:
multi-region existia?
retry correto?
circuit breaker?
RTO?
A arquitetura assumia disponibilidade total?
Novamente:
trigger externo + exposição interna.
🧠 Force Majeure mental
Às vezes qualquer coisa fora da equipe vira:
“imprevisível.”
Mas talvez fosse risco conhecido.
Self-Serving Bias transforma previsível não mitigado em azar.
🎯 Pergunta Bellacosa nº 4
“Chamamos isso de azar antes ou só depois que aconteceu?”
Boa.
🧠 Optimism Bias antes, Self-Serving depois
Antes:
“Fornecedor não deve cair.”
Optimism Bias.
Depois cai:
“Ninguém poderia prever.”
Self-Serving Bias.
Mas talvez SLA e histórico mostrassem.
Decision journal novamente.
🧠 Normalcy Bias
Sistema sempre recuperou.
Não criamos redundância.
Falha maior.
Depois:
“evento excepcional.”
Talvez.
Mas Normalcy Bias influenciou preparação.
Self-Serving Bias apaga nossa participação.
🌀 Drift Into Failure
Margem cai.
Organização não age.
Depois incidente.
Relatório:
“pico extraordinário de carga.”
Sim.
Mas por que um pico razoável derrubou?
Drift criou fragilidade.
Self-Serving Bias prefere evento externo.
🧠 Present Bias
Adiamos manutenção.
Falha.
“Hardware envelheceu inesperadamente.”
Talvez envelhecimento seja a coisa menos inesperada do universo.
Present Bias participou.
Self-Serving reescreve.
☕ Disco velho fica velho
Surpresa limitada.
🧠 Loss Aversion
Não quisemos substituir sistema porque risco de mudança.
Depois falha.
“Tecnologia antiga nos traiu.”
Talvez.
Mas decidimos mantê-la.
A decisão também pertence à história.
📚 A linguagem do post-mortem importa
Compare:
“Fornecedor causou indisponibilidade.”
versus:
“A falha do fornecedor iniciou o evento; ausência de fallback interno permitiu impacto de 47 minutos.”
A segunda é muito mais útil.
🧠 Trigger versus Root Cause
Talvez “root cause” singular seja inadequada em muitos casos.
Separe:
trigger;
contributors;
amplifiers;
failed controls.
Assim evitamos usar trigger externo como absolvição.
☕ O raio não explica a casa sem para-raios
Caiu raio.
Sim.
Mas por que queimou tudo?
Pergunta de engenharia.
🧠 Success Postmortem novamente
Uma arma poderosíssima contra Self-Serving Bias:
estude sucessos.
Pergunte:
onde tivemos competência?
onde tivemos sorte?
que controles funcionaram?
que near miss ocorreu?
que condição favorável não controlávamos?
Isso calibra autoestima operacional.
🏆 Pre-mortem de sucesso
Não só:
“por que falhamos?”
Também:
“por que funcionou?”
Talvez descobrimos que:
uma pessoa específica salvou manualmente.
Isso revela fragilidade escondida.
🧠 Luck-adjusted learning
Ideia Bellacosa:
aprendizado ajustado pela sorte.
Decisão boa + resultado ruim:
pode continuar sendo decisão boa.
Decisão ruim + resultado bom:
continua ruim.
Self-Serving Bias não gosta disso.
Mas Outcome Bias já nos ensinou.
📊 Matriz decisão x resultado
RESULTADO BOM RESULTADO RUIM
DECISÃO BOA competência azar possível
+ contexto
DECISÃO RUIM sorte falha esperável
Essa matriz deveria existir em War Rooms.
🧠 Judge process, not ego
Avalie:
o processo decisório.
Não:
se gostamos do resultado.
Nem:
se protege nossa autoestima.
💻 Code review e Self-Serving Bias
Meu bug:
requisito estava ambíguo.
Bug do colega:
faltou atenção.
Faça teste do espelho.
Talvez ambos tenham contexto.
Talvez ambos tenham responsabilidade.
🧠 Pair review
Se revisão revela que três pessoas interpretaram requisito errado:
não é apenas programador.
É ambiguidade sistêmica.
☕ Comentário COBOL imortal
* THIS CODE IS CORRECT.
* INPUT DATA IS WRONG.
Talvez o primeiro Self-Serving Bias executável.
🧠 Logs podem carregar culpa embutida
Mensagem:
INVALID USER INPUT
Talvez input só seja “inválido” porque interface aceitou algo ambíguo.
Naming também cria atribuição.
🔍 Observability neutra
Prefira:
VALUE OUTSIDE ACCEPTED RANGE
em vez de:
USER ERROR
Fato antes de julgamento.
👥 Performance Reviews e Self-Serving Bias
Gestor:
projeto bom:
“minha liderança.”
Ruim:
“equipe não entregou.”
Esse viés pode ser tóxico.
Líder maduro tende a fazer quase o contrário:
dar crédito coletivo;
assumir responsabilidade pela parte que controla.
Não por teatro.
Por alinhamento de accountability.
🧠 Liderança e causalidade
Um líder não controla tudo.
Mas controla:
prioridades;
recursos;
processos;
incentivos.
Se esses contribuíram:
precisa entrar no post-mortem.
☕ O chefe que só aparece no slide verde
Indicador verde:
foto no LinkedIn.
Incidente:
“vamos verificar com a equipe técnica.”
Self-Serving Bias corporativo em alta definição.
🧠 Incentivos podem reforçar
Se bônus depende de sucesso:
pessoas têm incentivo para:
atribuir sucesso a si;
fracasso a fatores externos.
Então não é apenas psicologia.
É desenho organizacional.
📈 KPI Attribution Gaming
Projeto não bate meta.
Explicação:
mercado.
Bate:
execução.
Se ninguém audita atribuições:
métrica vira storytelling.
🧠 Forecast Accountability
Antes:
registre premissas.
Depois:
compare.
Isso reduz reescrita conveniente.
📝 Assumption Log
ASSUMPTION:
Partner availability >= 99.9%
OWNER:
Architecture
MITIGATION:
None
RATIONALE:
Historical stability
Se parceiro cai:
não podemos dizer:
“imprevisível.”
A premissa estava documentada.
🧠 Precommitment de responsabilidade
Antes da decisão:
“Se X falhar, nossa arquitetura suporta?”
Isso impede terceirizar causalidade depois.
🎯 Pergunta Bellacosa nº 5
“O que afirmaríamos sobre esta decisão se o resultado tivesse sido o oposto?”
Fantástica.
Se resposta muda totalmente:
Outcome + Self-Serving podem estar ativos.
🧪 Counterfactual Attribution
Mudança funcionou.
Pergunte:
“Se tivesse falhado com os mesmos sinais, o que culparíamos?”
Talvez revele incoerência.
🧠 Role + Outcome Swap
Outra técnica:
troque:
equipe;
resultado.
Se julgamento muda:
há viés.
📋 Checklist anti-Self-Serving Bias
[ ] Estou atribuindo sucesso a mim e fracasso ao contexto?
[ ] Usei a mesma régua para nossa equipe e outras?
[ ] Que fatores externos ajudaram no sucesso?
[ ] Que decisões internas contribuíram para o fracasso?
[ ] Estamos chamando risco conhecido de azar?
[ ] O resultado está influenciando demais a avaliação da decisão?
[ ] Registramos nossas premissas antes?
[ ] Houve near miss no sucesso?
[ ] Estamos culpando fornecedor para encerrar investigação?
[ ] Que barreiras internas poderiam ter limitado o impacto?
[ ] Se outra equipe tivesse feito isso, julgaríamos igual?
[ ] Estamos protegendo reputação ou buscando aprendizado?
[ ] Nossa narrativa mudaria se o resultado fosse oposto?
[ ] O que estava sob nosso controle?
🧪 Como combater Self-Serving Bias — passo a passo
Passo 1 — Faça attribution symmetry
A mesma análise para sucesso e fracasso.
Passo 2 — Separe controlável de não controlável
Lista explícita.
Passo 3 — Registre decisões antes do resultado
Decision journal.
Passo 4 — Faça success reviews
Não só post-mortems de falha.
Passo 5 — Procure sorte nos sucessos
Sem vergonha.
Passo 6 — Procure contribuição interna nos fracassos
Mesmo com trigger externo.
Passo 7 — Use role reversal
Troque “nós” por “eles”.
Passo 8 — Evite linguagem absoluta
“Foi o fornecedor.”
Melhor:
“Fornecedor iniciou; arquitetura amplificou.”
Passo 9 — Revise incentivos
Eles premiam autojustificação?
Passo 10 — Recompense aprendizado honesto
Não apenas narrativa bonita.
🧠 Psychological Safety
Se admitir erro destrói carreira:
Self-Serving Bias vira estratégia de sobrevivência.
As pessoas racionalmente protegem a própria imagem.
Então cultura precisa permitir:
“Nossa decisão contribuiu.”
Sem execução pública.
☕ Uma equipe que não pode admitir erro não consegue calibrar nada
Ela só consegue:
justificar.
🧠 Blameless + accountable novamente
Uma cultura saudável diz:
“Vamos entender sem humilhar.”
E também:
“Vamos reconhecer nossa parte.”
As duas coisas podem coexistir.
🧠 Ego preservation
Self-Serving Bias protege autoestima.
Isso é humano.
Mas engenharia exige mecanismos externos porque não podemos pedir:
“Não tenha ego.”
Melhor:
logs;
decision journals;
metrics;
reviews.
Processo ajuda cérebro.
💾 External Memory
SMF não se ofende.
Git não esquece.
Change ticket não reescreve sozinho.
Use registros.
Eles funcionam como memória menos conveniente.
☕ Git blame, ironicamente
O nome “blame” é quase uma provocação perfeita.
Mas um git blame mostra:
quem alterou linha.
Não:
por que sistema falhou.
Contexto continua necessário.
🧠 Evidence beats autobiography
História que contamos sobre nós mesmos:
“somos excelentes em incident response.”
Dados:
MTTR.
recorrência.
near misses.
qualidade do RCA.
Compare.
📊 Calibration Metrics
Podemos medir:
previsão versus resultado;
estimativa versus real;
hipótese inicial versus RCA.
Isso ajuda reduzir narrativa autoindulgente.
🧠 Learning Organization
Uma organização que aprende consegue dizer:
“Fizemos várias coisas certas e uma escolha ruim.”
Ou:
“A decisão foi boa, mas o resultado foi ruim.”
Nuance.
Sem isso:
só existem heróis e vítimas.
👻 Easter Egg nº 2 — Os Daleks também têm Self-Serving Bias
Dalek:
— VICTORY IS DALEK SUPERIORITY.
Doctor:
— E quando perdem?
Dalek:
— TEMPORAL ANOMALY.
Doctor:
— Naturalmente.
Talvez os Daleks inventaram gestão executiva antes da humanidade.
🧠 Self-Serving Bias em retrospectiva Agile
Sprint boa:
equipe performou.
Sprint ruim:
dependências externas.
Talvez.
Mas se “dependência externa” aparece toda sprint:
já virou parte do sistema.
Não é externa à realidade operacional.
☕ Se acontece todo mês, já mora aqui
Uma regra Bellacosa.
🧠 Planning Fallacy novamente
Se fornecedor costuma atrasar:
inclua.
Não diga toda vez:
“evento extraordinário.”
Base Rate.
Planning.
Self-Serving.
Três capítulos num Gantt chart.
🧠 Risk Register contra conveniência
Risco conhecido antes.
Materializa depois.
Não é exatamente surpresa.
Se não mitigamos:
isso pertence à decisão.
🧠 Black Swan abuse
Nem todo evento ruim é Black Swan.
Às vezes é apenas:
cisne normal que ninguém queria colocar no slide.
Self-Serving Bias adora chamar previsível de excepcional.
☕ O “evento sem precedentes” que aconteceu três vezes
Histórico:
2026:
“Evento sem precedentes.”
Talvez a palavra “precedente” esteja em manutenção.
🧠 Base Rate Neglect novamente
Se queda de fornecedor ocorre 2x/ano:
não é impossível.
Arquitetura precisa decidir como lidar.
🧠 Self-Serving Bias + Omission Bias
Não fizemos patch.
Ataque ocorre.
“A ameaça evoluiu.”
Talvez.
Mas decisão de adiar patch também conta.
Omission Bias remove ação.
Self-Serving remove responsabilidade.
🧠 Self-Serving Bias + Action Bias
Restartamos sem evidência.
Funcionou.
“Boa resposta.”
Não funcionou.
“Sistema estava muito degradado.”
Mesmo comando.
Resultado mudou julgamento.
Outcome Bias + Self-Serving.
🧠 Framing Success
Até palavras importam.
Sucesso:
“entrega.”
Fracasso:
“aprendizado.”
Às vezes “aprendizado” vira eufemismo para evitar responsabilidade.
Aprendizado é ótimo.
Mas primeiro descreva fato.
☕ Nem todo incêndio precisa virar “oportunidade de aprendizado” antes de apagar
Às vezes pode chamar de incêndio.
Depois aprende.
🧠 RCA sem autoproteção
Uma estrutura boa:
WHAT HAPPENED?
WHAT WAS UNDER OUR CONTROL?
WHAT WAS OUTSIDE OUR CONTROL?
WHAT DID WE ASSUME?
WHAT DID WE DO WELL?
WHAT SHOULD WE CHANGE?
WHERE DID LUCK MATTER?
Simples.
Muito poderosa.
🧬 Regeneração organizacional
Uma organização madura contra Self-Serving Bias:
registra decisões antes do resultado;
faz success reviews;
procura sorte em vitórias;
procura responsabilidade controlável em derrotas;
usa a mesma régua entre equipes;
evita atribuições mono-causais;
documenta premissas;
analisa risco conhecido;
reduz incentivos defensivos;
e mantém segurança psicológica para admitir erro.
Principalmente:
ela aprende a dizer duas frases que parecem simples, mas são raras:
“Isso deu certo, mas nem tudo foi mérito nosso.”
e:
“Isso deu errado, e nem tudo foi culpa dos outros.”
Aí começa aprendizado de verdade.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Self-Serving Bias é a tendência de atribuir sucessos à própria competência e fracassos a fatores externos.
Ele protege autoestima, mas pode destruir calibração.
Fundamental Attribution Error e Self-Serving Bias usam réguas diferentes para nós e para os outros.
Outcome Bias transforma sucesso em prova de competência mesmo quando houve sorte.
Overconfidence pode nascer de sucessos mal atribuídos.
Narrative Bias constrói histórias convenientes para explicar resultados.
Framing pode transformar contribuição interna em detalhe e fator externo em protagonista.
Trigger externo não elimina fragilidade interna.
Success reviews são tão importantes quanto post-mortems.
Decision journals dificultam reescrever nossas crenças depois do resultado.
Role reversal ajuda a detectar assimetria de julgamento.
E principalmente:
Se toda vitória prova que somos bons e toda derrota prova que o mundo é injusto, não construímos experiência — construímos uma autobiografia.
🕰️ De volta à reunião
Semana anterior:
SUCCESS
Equipe:
— Excelente planejamento.
Semana atual:
SEV-1
Equipe:
— Fornecedor.
Nosso jovem abre uma tabela.
FATORES EXTERNOS
- partner delay
- network fluctuation
Depois:
FATORES INTERNOS
- GO despite partner uncertainty
- rollback not fully tested
- no fallback path
- window too tight
O gerente observa.
— Então foi culpa nossa?
Nosso programador responde:
— Não foi isso que eu disse.
— Então foi do fornecedor?
— Também não é suficiente.
O Doctor sorri.
— Ah. O maravilhoso mundo onde duas coisas podem ser verdade ao mesmo tempo.
O jovem continua:
— O fornecedor iniciou a degradação.
Pausa.
— Nós decidimos operar sem proteção suficiente contra essa possibilidade.
Agora há aprendizado.
Sem autoflagelação.
Sem absolvição.
Sem vilão de desenho animado.
Embora um Dalek provavelmente melhorasse a apresentação.
🔧 Na mudança seguinte
Checklist:
PARTNER HEALTH:
VALIDATED
FALLBACK:
AVAILABLE
ROLLBACK:
TESTED
STOP TRIGGER:
DEFINED
Deploy funciona.
Desta vez ninguém diz apenas:
“Somos excelentes.”
O gerente pergunta:
— Onde tivemos sorte?
Equipe responde:
— Volume ficou 15% abaixo do pico.
— E o que controlamos bem?
— Fallback testado.
— Near miss?
— Uma conexão quase saturou.
Registram.
Melhoram.
Isso é maturidade.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(SELF-SERVING)
Dentro:
IF RESULT = 'SUCCESS'
PERFORM FIND-EXTERNAL-HELP
PERFORM FIND-LUCK
END-IF.
IF RESULT = 'FAILURE'
PERFORM FIND-OUR-CONTRIBUTION
END-IF.
IF EXPLANATION = 'THEIR-FAULT'
PERFORM ROLE-REVERSAL-TEST
END-IF.
Comentário:
* SUCCESS HAS MANY PARENTS.
* FAILURE ALSO DOES.
Outro:
* LUCK IS NOT A COMPETENCY BADGE.
Outro:
* ACCOUNTABILITY IS NOT SELF-BLAME.
E naturalmente:
* DALEKS CALL VICTORY "SUPERIORITY"
* AND DEFEAT "TEMPORAL INTERFERENCE".
Nosso jovem fecha o membro.
Horas depois alguém pergunta:
— Como você resolveu aquele incidente tão rápido?
Ele quase responde:
“Experiência.”
Mas para.
— Eu reconheci o padrão.
— Então foi você.
— Em parte.
— Em parte?
— O log estava excelente, o DBA já tinha coletado dump e o problema apareceu exatamente numa área que eu conheço.
O colega ri.
— Está ficando modesto.
Ele responde:
— Não.
Pausa.
— Estou tentando manter o RCA da minha própria cabeça atualizado.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica:
Aceitar mérito sem ignorar a sorte e aceitar responsabilidade sem carregar o universo inteiro: essa é uma forma muito mais útil de competência.
☕🌀
Next stop: Actor-Observer Bias — quando explicamos nosso próprio erro pelo contexto, mas observamos o erro alheio e enxergamos personalidade, descuido e incompetência. Parece familiar? Deve. É o espelho ainda mais detalhado do Fundamental Attribution Error.
Sem comentários:
Enviar um comentário