 |
| Bellacosa Mainframe e o moral hazard |
☕ Um Café no Bellacosa Mainframe
Moral Hazard: Doctor Who, COBOL e o Dia em que Alguém Assumiu o Risco — Porque Outro Time Pagaria a Conta
Uma viagem pela TARDIS dos incidentes para entender como seguros, contratos, SLAs, terceirização, automações e separação entre decisão e consequência podem incentivar comportamentos mais arriscados em sistemas críticos
08:37.
Segunda-feira.
War Room ainda vazia.
Café recém-passado.
Produção normal.
Na tela, uma proposta de mudança:
CHANGE:
BATCH PAYMENT ENGINE
SCOPE:
14 PROGRAMS
6 COPYBOOKS
3 DB2 TABLES
2 MQ FLOWS
WINDOW:
2 HOURS
Nosso jovem programador COBOL olha.
— Isso tudo em duas horas?
O gerente responde:
— Sim.
— Parece apertado.
— Se atrasar, operações segura.
— E se quebrar?
— Infra faz rollback.
— E se perdermos dados?
— O time de reconciliação corrige.
— E se o fornecedor não responder?
— Temos SLA.
Nosso jovem fica alguns segundos em silêncio.
Interessante.
Para cada risco:
alguém tinha uma resposta.
Mas quase sempre:
a resposta era outra pessoa.
O gerente continua:
— Vamos fazer Big Bang. É mais rápido.
O programador pergunta:
— Quem decidiu isso?
— Nós.
— E quem fica de plantão se der problema?
— Operações.
— Quem reconcilia?
— Financeiro.
— Quem responde ao cliente?
— Atendimento.
— Quem paga penalidade?
— A empresa.
Silêncio.
— Então...
Pausa.
— quem está assumindo o risco?
O gerente olha.
— Nós estamos decidindo.
— Eu sei.
— Então?
— Decidir e carregar a consequência são a mesma coisa?
Antes que alguém responda:
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para o change.
Depois para a lista de times envolvidos.
— Quem escolheu o Big Bang?
— Gestão de projeto.
— Quem fará recuperação se falhar?
— Operações.
— Quem trabalhará madrugada adentro?
— Operações e desenvolvimento.
— Quem recebe bônus se entregar antes?
Silêncio.
— Gestão do projeto.
O Doctor sorri.
— Ah.
— O quê?
— Vocês criaram um sistema em que uma pessoa recebe parte do benefício da decisão...
Pausa.
— enquanto outras pessoas recebem parte maior do prejuízo se a decisão der errado.
Bem-vindo ao:
Moral Hazard
Ou:
Risco Moral
Um conceito econômico e comportamental que aparece quando alguém toma decisões de risco sabendo que não suportará integralmente as consequências negativas dessas decisões.
Em linguagem Bellacosa:
“Se eu ganho quando dá certo e outra pessoa paga boa parte da conta quando dá errado, meu incentivo para ser cauteloso diminui.”
🧠 Moral Hazard não significa “pessoa imoral”
Primeiro cuidado.
O nome pode confundir.
“Moral Hazard” não significa necessariamente:
fraude;
má-fé;
falta de caráter.
Pode existir mesmo quando ninguém está conscientemente tentando prejudicar alguém.
O problema é:
estrutura de incentivos.
Se benefício e consequência estão separados:
o comportamento pode mudar.
Isso é profundamente importante em:
seguros;
finanças;
outsourcing;
cloud;
DevOps;
projetos;
SRE;
segurança;
incidentes.
E naturalmente:
mainframe.
☕ O exemplo clássico do seguro
Imagine que você possui seguro completo para um carro.
Se qualquer dano for integralmente pago por outra entidade, talvez exista menos incentivo econômico para evitar alguns riscos.
Isso não significa que todo segurado vai dirigir perigosamente.
Significa que:
a proteção contra perdas pode alterar incentivos.
Por isso seguros possuem:
franquia;
limites;
condições.
Eles tentam manter:
skin in the game.
Ou seja:
alguma parte da consequência continua com quem toma a decisão.
🧠 Risk Compensation versus Moral Hazard
Eles se parecem.
Mas não são iguais.
Risk Compensation
“Estou mais protegido, então posso me sentir confortável assumindo mais risco.”
Pode acontecer mesmo quando eu continuo pagando as consequências.
Moral Hazard
“Parte importante das consequências cairá sobre outra pessoa, então meu incentivo para reduzir risco diminui.”
A diferença principal é:
quem paga a conta.
☕ Exemplo Bellacosa
Risk Compensation
Equipe recebe rollback automático.
Passa a deployar mais.
Ela ainda sofre os incidentes.
Moral Hazard
Projeto decide acelerar deploy.
Se der certo:
projeto bate prazo.
Se falhar:
operações passa a madrugada corrigindo.
Agora temos:
assimetria de recompensa e consequência.
👻 Easter Egg nº 1 — O botão do Companion
Companion:
— Doctor, posso apertar aquele botão?
Doctor:
— Não.
— Por quê?
— Pode destruir o sistema de contenção.
— E quem conserta?
— Eu.
— Ah.
Ela começa a estender o dedo.
Doctor:
— E é exatamente por isso que você não vai apertar.
Às vezes a melhor governança começa quando quem aperta o botão conhece o custo de apertá-lo.
🧠 Principal-Agent Problem
Moral Hazard aparece frequentemente dentro de um problema maior:
principal-agent problem.
Uma pessoa ou organização — o principal — delega alguma atividade para outra — o agente.
Mas:
os incentivos não são perfeitamente alinhados.
Exemplo:
empresa contrata fornecedor.
Fornecedor recebe por:
entregar mudança.
Empresa suporta:
risco operacional.
Se contrato recompensa:
velocidade,
mas não penaliza adequadamente:
incidentes,
o fornecedor pode racionalmente priorizar:
velocidade.
Não porque seja “malvado”.
Porque:
o sistema de incentivos está ensinando isso.
☕ Outsourcing mainframe
Fornecedor tem KPI:
DELIVERIES / MONTH
Equipe interna mede:
AVAILABILITY
INCIDENTS
DATA INTEGRITY
Fornecedor quer:
entregar.
Operação quer:
não quebrar.
Conflito estrutural.
Se change falha:
fornecedor talvez recebe ticket.
Operação recebe:
telefone às 03:00.
Quem sente mais risco?
Operação.
Quem decidiu escopo?
Talvez fornecedor/projeto.
Moral Hazard possível.
🧠 KPI cria comportamento
Se premiamos:
quantidade de releases,
podemos ter:
mais releases.
Se quem gera releases não sofre custo completo de incidentes:
atenção.
Goodhart entra discretamente.
🧠 Moral Hazard + Goodhart's Law
Métrica:
“entregar projeto no prazo.”
Equipe corta:
testes.
Documentação.
Rollback rehearsal.
Entrega no prazo.
KPI:
verde.
Três semanas depois:
produção quebra.
Quem absorve?
Operação.
Agora a métrica ficou verde...
e o sistema ficou vermelho.
☕ A entrega terminou no Go-Live?
Para projeto:
sim.
Para operações:
talvez tenha começado ali.
Essa diferença é enorme.
🧠 Definition of Done
Uma defesa simples contra Moral Hazard:
Definition of Done precisa incluir consequências operacionais.
Não apenas:
código entregue.
Mas:
testes completos;
observabilidade;
runbook;
rollback;
suporte;
documentação;
reconciliação.
Agora benefício e responsabilidade ficam mais próximos.
🧠 “Você constrói, você opera”
A filosofia:
You Build It, You Run It
pode reduzir Moral Hazard porque quem cria também participa da operação.
Não é solução universal.
Mas o princípio é poderoso:
aproxime decisão e consequência.
Quando desenvolvedor sente incidente:
passa a considerar:
logging;
recovery;
monitoring
durante o desenvolvimento.
☕ O código muda depois da primeira madrugada de plantão
Curiosamente.
Depois de um SEV-1 às 03:00:
aquele DISPLAY adicional começa a parecer muito barato.
🧠 Skin in the Game
Expressão útil.
Quem toma risco deveria ter:
alguma exposição ao resultado.
Não punição.
Exposição informacional e operacional.
Exemplo:
arquiteto aprova desenho.
Participa da revisão do incidente.
Projeto entrega.
Continua responsável pelo hypercare.
Fornecedor implanta.
SLA inclui qualidade pós-produção.
Isso reduz distância entre:
decisão
e:
efeito.
🧠 Moral Hazard + Self-Serving Bias
Se dá certo:
“Projeto entregou.”
Se dá errado:
“Operações não estabilizou.”
Self-Serving Bias protege quem recebeu benefício.
Moral Hazard protege estruturalmente porque custo ficou em outro lugar.
Combinação ruim.
🧠 Fundamental Attribution Error
Projeto envia mudança arriscada.
Operação executa.
Falha.
Relatório:
“Operador executou procedimento incorretamente.”
Mas:
por que arquitetura exigia manobra manual sob pressão?
Moral Hazard pode terminar em:
culpa na ponta.
☕ Quem tem a agulha?
A velha regra operacional volta.
Decisão precisa ter:
owner.
Aprovação.
Registro.
Quando incidente ocorre:
não pode desaparecer a cadeia decisória.
🧠 Authority Gradient
Chefe:
— Faça hoje.
Operador:
— Risco está alto.
Chefe:
— Assumo.
Mas depois...
incidente.
Quem está na timeline?
Operador que apertou Enter.
Authority Gradient + Moral Hazard.
Quem dá ordem pode estar distante da consequência imediata.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Pode fazer.”
Pergunte:
“Quem é o risk owner dessa decisão?”
Não apenas:
quem executa.
🧠 Execution Owner ≠ Risk Owner
Muito importante.
EXECUTOR:
Operations
DECISION OWNER:
Project Manager
RISK OWNER:
Business Service Owner
Agora a organização sabe:
quem tomou decisão;
quem executou;
quem aceitou risco.
🧠 Omission Bias
Às vezes ninguém quer explicitamente assumir risco.
Então decisão fica difusa.
“Vamos seguir.”
Quem decidiu?
Todo mundo.
Logo:
ninguém.
Diffusion of Responsibility aparece.
Moral Hazard institucional.
🧠 Diffusion of Responsibility + Moral Hazard
Se custo será dividido entre:
cinco departamentos,
cada um sente apenas parte.
Então ninguém possui incentivo forte suficiente para prevenir.
Tragedy of the commons começa a aparecer.
☕ Shared platform
Time A consome CPU.
Custo geral pago por infraestrutura.
Então A não otimiza.
Time B faz igual.
Time C também.
Resultado:
capacity problem.
Quem paga?
Empresa inteira.
Isso é um terreno fértil para Moral Hazard.
🧠 FinOps e Moral Hazard
Cloud oferece exemplo perfeito.
Desenvolvedor cria:
máquina enorme.
Benefício:
performance.
Conta:
centro de custo central.
Se equipe não vê custo:
incentivo para otimização diminui.
Showback e chargeback tentam alinhar:
consumo
e:
consequência econômica.
☕ CPU “grátis”
Nada é tão caro quanto recurso que alguém acredita ser grátis.
🧠 Mainframe MIPS/MSU
Mesmo lógica.
Se aplicação consome:
muito CPU
mas custo é abstrato e pago centralmente:
equipe pode não sentir incentivo econômico para otimizar.
Isso não significa:
culpar aplicação.
Significa:
dar visibilidade.
📊 Showback
TEAM A:
CPU CONSUMPTION: X
STORAGE: Y
BATCH WINDOW IMPACT: Z
Não precisa cobrar diretamente.
Só tornar custo visível já muda comportamento.
🧠 Moral Hazard em capacity
Equipe pede:
mais capacidade.
Se é grátis para ela:
por que otimizar primeiro?
Arquiteto:
— Precisamos de 4x mais CPU.
Sysprog:
— Vocês revisaram SQL?
— Não.
— Por quê?
— Upgrade é mais rápido.
Quem paga hardware?
Outro orçamento.
Incentivo desalinhado.
🧠 Moral Hazard + Risk Compensation
Agora combinamos.
Novo seguro:
rollback.
Risk Compensation:
mais risco.
Se incidente for suportado por outro time:
Moral Hazard:
mais incentivo ainda para aumentar risco.
☕ O deploy ousado
Dev:
“Se der problema, operações volta.”
Operations:
“E se o rollback falhar?”
Dev:
“Vocês têm DR.”
Maravilhoso.
Toda camada de proteção vira justificativa para alguém aumentar exposição.
🧠 Swiss Cheese e propriedade das fatias
Um detalhe interessante:
cada time controla uma fatia.
Dev:
teste.
Ops:
rollback.
Security:
controle.
DBA:
recovery.
Se cada um pensa:
“a próxima fatia segura”,
os buracos podem se alinhar.
Moral Hazard pode enfraquecer responsabilidade local.
🧠 Defense in Depth não significa:
“Posso relaxar porque existe outra defesa.”
Significa:
cada camada deve cumprir sua função independentemente.
☕ Cinto + airbag + freio
Não significa:
pode dirigir olhando o celular.
As camadas somam.
Não se substituem emocionalmente.
🧠 Moral Hazard em segurança
Usuário pensa:
“Security tem antivírus.”
Então:
menos cuidado.
Equipe pensa:
“Tem cyber insurance.”
Então:
menos investimento.
Gestor pensa:
“Fornecedor é responsável.”
Então:
menos verificação.
Todas podem ser formas de desalinhamento.
🔐 Cyber Insurance
Seguro pode reduzir impacto financeiro.
Mas talvez não cubra:
reputação;
dados;
operação.
Mesmo economicamente:
franquias;
exclusões.
Não é transferência total de risco.
🧠 Risk Transfer não é Risk Elimination
Você compra seguro.
Risco financeiro parcialmente transferido.
Mas:
incidente continua existindo.
Cliente continua impactado.
Dados continuam vazados.
Logo:
RISK TRANSFER
≠
RISK REMOVAL
☕ “Tem SLA”
Outra frase mágica.
Fornecedor falha.
Você recebe crédito.
Ótimo.
Cliente?
Ainda ficou sem serviço.
SLA transfere parte do custo.
Não restaura disponibilidade retroativamente.
🧠 SLA Credits
Se fornecedor cai 8 horas:
você ganha desconto.
Financeiro sorri.
Operação não.
O crédito pode ser:
insignificante diante do impacto.
Moral Hazard pode surgir se fornecedor sabe:
penalidade máxima
é pequena.
🧠 Contract Design
Contrato precisa alinhar:
incentivos.
Não apenas:
penalidade.
Pode incluir:
availability;
quality;
security;
recovery.
Mas cuidado com métricas demais.
Goodhart continua.
☕ Contrato perfeito também não existe
Se você tentar escrever toda possibilidade:
Need for Control reaparece com 700 páginas.
Balance.
🧠 Moral Hazard no modelo “fixed price”
Projeto fornecedor recebe valor fixo.
Quanto menos gastar:
maior margem.
Empresa quer:
qualidade.
Fornecedor pode ter incentivo para:
reduzir custo.
Isso é normal em contratos.
O design precisa:
aceitação;
quality gates;
SLA.
Não confiar em bondade.
Nem assumir maldade.
Desenhe incentivos.
🧠 Incentive-Compatible Systems
Economia gosta dessa ideia:
criar regras em que agir de forma desejável também seja racional para quem decide.
Em operação:
não dependa de:
heroísmo.
Crie incentivos em que:
qualidade;
segurança;
custo
façam parte da decisão.
☕ Não peça “ownership”
Enquanto recompensa apenas:
velocidade.
Pessoas aprendem pelo bônus.
Não pelo pôster.
🧠 Moral Hazard + Planning Fallacy
Projeto promete:
6 meses.
Se atrasar:
equipe de sustentação recebe pressão.
Quem fez estimativa já pode estar em outro projeto.
Agora custo do otimismo é transferido.
Isso incentiva estimativas agressivas.
📅 Bid otimista
Fornecedor promete:
4 meses.
Ganha contrato.
Depois:
change requests.
Extensões.
Quem paga?
Cliente.
Se penalidade inicial é pequena:
incentivo para bid agressivo.
Um problema clássico de contratos.
🧠 Winner's Curse pode aparecer
Outro conceito interessante:
em licitações, quem faz a estimativa mais otimista pode ganhar.
Depois descobre:
subestimou.
Não é exatamente Moral Hazard.
Mas contratos podem criar ambiente onde:
o vencedor é quem aceita mais risco.
Se parte desse risco será renegociada depois:
Moral Hazard aumenta.
☕ “Ganha primeiro, negocia depois”
Estratégia conhecida.
Nem sempre saudável.
🧠 Moral Hazard em projetos internos
Não precisa fornecedor.
Time de transformação:
recebe bônus por:
migração concluída.
Time legado:
absorve:
incidentes.
Agora incentivo:
migrar rápido.
Não necessariamente:
operar bem.
Inclua:
post-go-live KPIs.
🧠 Hypercare
Manter projeto responsável por algumas semanas após Go-Live:
excelente.
Agora quem tomou decisões sente:
efeitos operacionais.
Isso alinha.
☕ Projeto não termina no HASP395
Acabou o job.
Mas negócio continua.
Boa analogia.
🧠 Moral Hazard e turnover
Pessoa toma decisão de longo prazo.
Vai embora antes da consequência.
Não podemos impedir carreira.
Mas arquitetura precisa:
documentação;
decision records.
Senão:
benefício agora.
Dívida para quem fica.
🧠 Technical Debt como Moral Hazard
Equipe entrega feature rápido.
Recebe crédito.
Debt vai para:
futuro.
Talvez outra equipe.
Isso é um tipo de externalização de custo.
☕ “Depois a gente refatora”
“Depois” normalmente é um time sem nome.
🧠 Present Bias + Moral Hazard
Benefício:
agora.
Custo:
depois.
E talvez para:
outro.
Essa combinação é poderosíssima.
Present Bias já favorece curto prazo.
Moral Hazard reduz peso do custo futuro.
🧠 Sunk Cost
Depois dívida cresce.
Ninguém quer reescrever.
Agora Status Quo.
Os vieses começam a formar uma guilda.
🧠 Externalities
Moral Hazard conversa com:
externalidades.
Uma decisão produz custo para terceiros.
Exemplo:
aplicação dispara consultas pesadas.
Time ganha:
feature.
Db2 sofre:
CPU.
Outros sistemas recebem:
latência.
A aplicação não vê integralmente custo.
☕ “Na minha aplicação está rápido”
Parabéns.
Você terceirizou lentidão para o banco.
Local Optimization encontra Moral Hazard.
🧠 End-to-End Metrics
Antídoto:
medir:
impacto sistêmico.
Não apenas:
métrica local.
Se time é avaliado por:
latência ponta-a-ponta
e:
custo,
incentivo melhora.
🧠 WLM e prioridades
Todo mundo quer:
service class alta.
Se custo de prioridade for coletivo:
cada time pede prioridade máxima.
Se todos são prioridade 1:
ninguém é.
Moral Hazard de recursos compartilhados.
☕ “Meu job é crítico”
Claro.
Todo job é crítico quando perguntamos ao owner.
Por isso precisamos:
governança.
🧠 Tragedy of the Commons
Recursos compartilhados:
CPU;
I/O;
storage;
rede.
Cada time maximiza seu uso.
Custo distribuído.
Resultado:
degradação coletiva.
Não é exatamente Moral Hazard em todos os casos, mas é parente próximo.
🧠 Moral Hazard em War Room
Incident Commander decide:
restart agressivo.
Se der certo:
MTTR cai.
Se der errado:
evidência desaparece;
RCA sofre.
Talvez commander seja medido apenas por:
restore time.
Agora incentivo favorece:
ação rápida.
Action Bias + Moral Hazard.
☕ Métrica de MTTR sozinha
Pode ensinar:
“recupere rápido.”
Mesmo que destrua evidência.
Talvez adicione:
quality of recovery;
recurrence.
🧠 Balanced Metrics
Use:
MTTR.
Repeat Incident Rate.
Data Integrity.
Customer Impact.
Agora incentivo menos unilateral.
🧠 Moral Hazard e bônus
Se bônus depende:
apenas de uptime,
equipe pode:
não registrar incidentes.
Goodhart.
Se depende:
zero security findings,
pode esconder.
Precisamos métricas que:
não tornem verdade inimiga da recompensa.
☕ Se reportar problema reduz bônus...
adivinhe o que acontece com observabilidade.
🧠 Psychological Safety
Se quem admite risco perde:
status,
risco será escondido.
Moral Hazard pode existir na direção oposta:
gestor recebe benefício por dashboard verde
e custo de esconder risco recai no futuro.
🧠 Narrative Bias
Depois do incidente:
“Ninguém poderia prever.”
Mas decision log mostra:
dois engenheiros alertaram.
Agora narrativa tenta externalizar custo.
Decision records combatem.
🎯 Pergunta Bellacosa nº 2
“Quem recebe o benefício se der certo e quem suporta o custo se der errado?”
Talvez a melhor pergunta do capítulo.
Desenhe.
📊 Incentive Map
DECISION:
Big Bang deployment
BENEFIT:
Project — deadline achieved
COST IF FAILURE:
Operations — overtime
Business — lost revenue
Customer — service outage
Support — complaints
Agora Moral Hazard fica visível.
🧠 Risk Ownership Matrix
Outra ferramenta:
RISK:
Data corruption
DECISION OWNER:
Project
RISK OWNER:
Business
EXECUTOR:
Operations
MITIGATION OWNER:
DBA
Muito melhor que:
“todos responsáveis.”
☕ Quando todos são responsáveis...
o alerta já sabe como termina.
Diffusion of Responsibility.
🧠 RACI
RACI pode ajudar:
Responsible.
Accountable.
Consulted.
Informed.
Mas só se realmente usado.
Uma planilha com 300 linhas pode virar Control Theater.
Use de forma pragmática.
🧠 Accountability
A palavra chave.
Moral Hazard diminui quando:
quem decide também responde:
por qualidade;
por custo;
por impacto.
Não no sentido punitivo.
No sentido:
decisão não termina quando benefício foi capturado.
🧠 Accountability ≠ Blame
Precisamos repetir.
Se toda accountability vira punição:
pessoas evitam decidir.
Authority e Omission Bias.
Queremos:
ownership do resultado.
Não caça às bruxas.
☕ Skin in the game sem pele arrancada
Talvez a formulação Bellacosa.
🧠 Moral Hazard em IA
Agora fica especialmente interessante.
Equipe usa agente.
Agente toma ação.
Algo quebra.
Humano diz:
“Foi a IA.”
Fornecedor:
“Usuário aprovou.”
Gestão:
“Ferramenta estava homologada.”
Responsabilidade pulveriza.
Perfeito terreno para Moral Hazard.
🤖 AI Vendor
Fornecedor vende:
automação de mudança.
Benefício:
mais volume.
Se incidente:
cliente suporta.
Contrato talvez limite responsabilidade.
Incentivo precisa ser avaliado.
🧠 AI Agent Permissions
Se agente possui:
DELETE;
DEPLOY;
PAYMENT,
quem assume risco?
Designer?
Owner?
Operator?
Business?
Defina antes.
Não depois do incidente.
🧠 Human-in-the-loop como liability theater
HITL pode virar:
“Humano aprovou, então culpa dele.”
Mas se humano recebeu:
200 approvals;
3 segundos cada;
sem contexto,
isso não é controle real.
É transferência de responsabilidade.
Moral Hazard institucional.
☕ A aprovação humana pode virar para-raios jurídico
Se design é ruim.
Precisamos evitar.
🧠 Meaningful Human Control
Humano precisa:
entender;
ter tempo;
poder rejeitar;
possuir informação.
Se não:
approval é decorativo.
🎯 Pergunta Bellacosa nº 3
“O humano realmente controla a decisão ou apenas assina a responsabilidade?”
Fortíssima.
🧠 Moral Hazard + Automation Bias
Ferramenta recomenda.
Humano confia.
Se errado:
“Modelo falhou.”
Mas a organização escolheu:
delegar.
Precisamos ownership sistêmico.
🧠 Insurers, vendors, cloud providers
Ter contrato não significa:
ter transferido todas as consequências.
Você pode terceirizar:
infraestrutura.
Não:
responsabilidade final perante o cliente.
Muito importante.
☕ “Está na cloud” não significa “é problema da cloud”
Shared Responsibility Model deveria estar tatuado em alguns projetos.
Metaforicamente.
🧠 Shared Responsibility
Cloud provider:
hardware.
Você:
configuração.
IAM.
Dados.
Aplicação.
Se breach:
“a AWS deveria impedir” não basta.
Moral Hazard pode aparecer quando empresa interpreta outsourcing como:
outsourcing de responsabilidade.
🧠 Outsourcing Risk
Você terceiriza:
execução.
Não necessariamente:
accountability.
Contrato ajuda.
Governança continua.
☕ Você pode terceirizar o datacenter
Não pode terceirizar a reputação perante seu cliente.
🧠 Moral Hazard em change windows
Projeto não precisa ficar de plantão.
Então agenda:
mudança sexta 23h.
Ops sofre.
Solução:
quem pede mudança participa do plantão.
Agora decisão sobre horário muda magicamente.
Skin in the game.
😄 Sexta-feira 23h
Antes:
“Melhor janela.”
Depois que project manager precisa ficar:
“Talvez terça 20h seja melhor.”
Incentivos são professores excelentes.
🧠 On-call rotation
Desenvolvedor entra no on-call.
Observabilidade melhora.
Código fica mais recuperável.
Por quê?
Porque consequência ficou próxima.
Não é punição.
É feedback.
🧠 Moral Hazard + Feedback Loops
Quando quem decide recebe feedback tarde ou nunca:
aprendizado fraco.
Aproxime:
feedback.
Isso reduz:
Moral Hazard
e:
Outcome Bias.
🧠 Feedback delay
Feature lançada.
Erro operacional aparece meses depois.
Equipe original já esqueceu.
Decision logs ajudam.
Post-implementation review também.
☕ “Depois do Go-Live”
Deveria existir formalmente.
Não só bolo e foto.
🧠 Post-Implementation Review
30 dias depois:
incidentes?
performance?
cost?
manual work?
customer impact?
Agora projeto recebe:
consequência real.
🧠 Moral Hazard e budget silos
Time A economiza:
R$100k.
Decisão aumenta custo de infra:
R$500k.
A economiza.
Empresa perde.
Local incentives.
FinOps tenta combater.
☕ Economia local, prejuízo global
Clássico.
🧠 Total Cost of Ownership
Use TCO.
Não apenas:
project cost.
Inclua:
run;
support;
licenses;
capacity;
incidents.
Isso reduz externalização.
🧠 Build vs Run
Projeto barato.
Operação caríssima.
Se procurement olha apenas:
CAPEX,
Moral Hazard na seleção.
Inclua:
OPEX.
🧠 Vendor lock-in
Fornecedor oferece:
entrada barata.
Saída cara.
Benefício inicial.
Custo futuro:
cliente.
Contrato precisa enxergar ciclo.
☕ O almoço “grátis”
Normalmente chega com fatura em outra sprint.
🧠 Moral Hazard e Sunk Cost
Depois de entrar:
custo de sair alto.
Agora fornecedor pode ter poder.
Não é automaticamente Moral Hazard, mas incentivos mudam.
Governança precisa observar.
🧠 Procurement e SLA
Procurement negocia:
preço baixo.
Operação recebe:
serviço ruim.
Procurement KPI:
verde.
Operação:
vermelho.
Separação de benefício e consequência.
🎯 Pergunta Bellacosa nº 4
“A métrica de sucesso de quem decide inclui o custo operacional gerado depois?”
Excelente.
🧠 Moral Hazard na arquitetura
Arquiteto escolhe:
tecnologia complexa.
Projeto fica moderno.
Depois suporte:
escasso.
Arquiteto muda de iniciativa.
Ops fica.
Inclua:
operability review.
🧠 Operational Readiness Review
Antes de produção:
quem suporta?
skill existe?
tooling?
backup?
recovery?
monitoring?
cost?
Arquitetura não termina no diagrama.
☕ Caixa bonita com setas não atende pager
Muito menos às 03:00.
🧠 Runbook as Contract
Um bom runbook declara:
quem faz o quê.
Isso reduz:
“achei que o outro time faria.”
🧠 Moral Hazard + Diffusion
Quanto mais dependências:
mais fácil externalizar.
“DBA resolve.”
“Security verifica.”
“Ops monitora.”
No fim:
ninguém é dono do sistema inteiro.
Service ownership ajuda.
🧠 Product / Service Ownership
Uma pessoa ou equipe precisa olhar:
end-to-end.
Não executar tudo.
Mas possuir:
accountability do serviço.
Isso internaliza parte dos custos.
☕ Dono do serviço
Não significa:
faz tudo.
Significa:
não pode dizer “não é meu problema” para cada seta do diagrama.
🧠 Moral Hazard em bancos
Crédito é exemplo clássico.
Quem origina empréstimo pode receber benefício imediato.
Se risco for vendido ou transferido:
pode diminuir incentivo para avaliar cuidadosamente.
Esse tipo de desalinhamento ficou famoso em discussões sobre crises financeiras.
A estrutura importa:
origination versus retention of risk.
🧠 Analogia mainframe
Equipe cria transação.
Outro time processa.
Outro reconcilia.
Outro suporta.
Se criador não absorve custo:
pode gerar complexidade sem sentir.
Service costing ajuda.
☕ Cada interface “gratuita”
Custa:
monitoramento;
teste;
suporte;
incident response.
Torne visível.
🧠 Moral Hazard e observabilidade
Se incident cost é invisível para projeto:
ele não entra na decisão.
Então crie:
cost of incident.
Horas.
clientes.
receita.
Agora feedback econômico.
📊 Incident Cost Allocation
Não necessariamente cobrança financeira.
Mas:
INCIDENT:
4h outage
ENGINEERING HOURS:
96
CUSTOMER IMPACT:
X
REVENUE IMPACT:
Y
Mostre.
Incentivos ficam mais realistas.
🧠 Decision Journals
Antes:
“Big Bang é aceitável porque rollback é sólido.”
Depois:
falha.
Não deixe reescrever:
“Ninguém sabia.”
Registro ajuda accountability.
🧠 Hindsight Bias
Cuidado inverso.
Não julgue decisão apenas pelo resultado.
Se risco era conscientemente aceito e processo foi bom:
resultado ruim não prova irresponsabilidade.
Outcome Bias.
Moral Hazard exige analisar:
incentivo antes.
☕ Uma decisão pode ser arriscada sem ser irresponsável
Se:
risk owner sabe;
benefício justifica;
controles existem.
Muito importante.
🧠 Moral Hazard não é “qualquer risco tomado”
É:
risco incentivado pela separação entre decisão e consequência.
Essa definição evita banalização.
🧠 Risk Appetite
Se business aceita:
10% de risco
por benefício X,
e business também absorve consequência:
não é necessariamente Moral Hazard.
É decisão de risco.
🧠 Moral Hazard aparece quando:
benefício privado/local;
custo coletivo/externo.
Simplificando:
UPSIDE:
ME
DOWNSIDE:
US
☕ A versão corporativa
“Meu bônus, nosso incidente.”
Magnífico e terrível.
🧠 Moral Hazard em liderança
Líder promete prazo impossível.
Se sucesso:
reconhecimento.
Se falha:
equipe “não entregou”.
Incentivo claro.
Por isso metas precisam:
accountability bidirecional.
🧠 Psychological Contract
Se líderes sempre externalizam custo:
equipes deixam de confiar.
Então Moral Hazard também destrói:
cultura.
🧠 Burnout externality
Prazo agressivo.
Gestão recebe entrega.
Equipe paga:
horas;
burnout.
Se custo humano não entra:
decisão parece barata.
☕ Toda estimativa tem alguém dormindo atrás dela
Às vezes literalmente.
🧠 Sustainable Pace
Não é luxo.
É internalizar custo.
Se entrega depende:
sempre de horas extras,
TCO está sendo escondido.
🧠 Moral Hazard + Present Bias
Ganho trimestral.
Custo em seis meses.
Executivo talvez já seja medido por:
trimestre.
Incentivo estrutural para:
curto prazo.
Governança precisa:
métricas de longo prazo.
📈 Long-term KPIs
Reliability.
Debt.
Retention.
Customer trust.
Não apenas:
delivery.
🧠 Moral Hazard em segurança de acesso
Gestor pede:
acesso amplo.
Benefício:
velocidade.
Security assume:
risco.
Se gestor não sente consequência de breach:
pode pedir acesso excessivo.
Least privilege reduz isso por arquitetura.
🔐 Guardrails
Em vez de:
“por favor, peça só o necessário.”
Sistema limita.
Porque incentivo humano pode ser:
“me dê tudo para não depender de ninguém.”
☕ SPECIAL no RACF para resolver ticket pequeno
Talvez um pouco exagerado.
Só um pouco.
🧠 Strong Controls versus incentives
Quando Moral Hazard é forte:
não dependa só de:
boas intenções.
Use:
limits;
audit;
approvals;
segregation of duties.
Mas proporcionalmente.
Need for Control continua espreitando.
🧠 Moral Hazard + Need for Control
Descobrimos incentivos ruins.
Resposta:
40 approvals.
Cuidado.
A solução ideal é:
alinhar incentivos e usar guardrails fortes onde necessário.
Não burocracia infinita.
🧠 Incentive alignment > paperwork
Se fornecedor ganha mais quando:
qualidade melhora,
melhor.
Se só adicionarmos:
relatórios,
talvez não mude comportamento.
🎯 Pergunta Bellacosa nº 5
“O comportamento arriscado é racional dentro dos incentivos que nós mesmos criamos?”
Fantástica.
Se sim:
não adianta palestra.
Mude sistema.
🧠 “Treinamento” como solução preguiçosa
Equipe sempre pula etapa porque:
prazo impossível.
Empresa:
“Treinamento de compliance.”
Nada muda.
Porque incentivo continua.
Moral Hazard não é resolvido por PowerPoint.
☕ Incentivo vence cartaz motivacional por nocaute técnico
Quase sempre.
🧠 Mechanism Design
Termo econômico mais avançado:
projetar regras e incentivos para induzir resultados desejáveis.
Em TI:
se você quer:
qualidade,
inclua qualidade no sucesso.
Se quer:
operabilidade,
faça equipe participar do run.
Se quer:
custo eficiente,
mostre custo.
🧠 Error Budgets
SRE outra vez.
Equipe pode inovar.
Mas se reliability cai:
budget acaba.
Agora quem gera risco também encontra limite.
Excelente alinhamento.
☕ Você pode gastar risco
Mas a conta aparece.
Isso é bonito.
🧠 Chargeback / Showback
Uso de recurso fica visível.
Não necessariamente para punir.
Mas para internalizar:
consequência.
🧠 On-call ownership
Mesmo princípio.
Construiu?
Receba feedback.
Isso muda decisões de design.
🧠 Shared KPIs
Dev + Ops:
mesmo SLO.
Agora:
não existe benefício de entregar feature derrubando reliability.
Objetivo compartilhado reduz conflito.
☕ DevOps no sentido profundo
Não é só:
pipeline.
É:
reduzir fronteiras onde um time captura benefício e outro absorve consequência.
Isso encaixa perfeitamente com Moral Hazard.
🧠 Silo incentives
Dev:
delivery.
Ops:
stability.
Security:
zero findings.
Business:
revenue.
Cada silo pode otimizar localmente.
Service-level objectives ajudam criar:
visão comum.
🧠 Moral Hazard e Zero-Risk Bias
Curioso.
Security pode exigir:
zero risco
porque custo da fricção cai no Dev.
Dev pode exigir:
velocidade
porque custo do incidente cai no Ops.
Cada time otimiza:
o que recebe benefício.
Sistema inteiro sofre.
☕ Todo departamento consegue produzir uma solução perfeita
Para o próprio dashboard.
🧠 End-to-End Governance
Pergunte:
como decisão afeta:
cliente;
infra;
security;
support;
finance.
Multi-perspective review.
📋 Checklist anti-Moral Hazard
[ ] Quem toma a decisão?
[ ] Quem recebe o benefício se der certo?
[ ] Quem paga o custo se der errado?
[ ] Esses grupos são os mesmos?
[ ] O executor está assumindo risco decidido por outra pessoa?
[ ] O risk owner está explícito?
[ ] Existe incentivo para aumentar risco?
[ ] O contrato recompensa qualidade, não apenas volume?
[ ] O projeto continua responsável após Go-Live?
[ ] O custo operacional entra na decisão?
[ ] O serviço possui owner end-to-end?
[ ] Existe shared KPI entre Dev, Ops e negócio?
[ ] Estamos usando seguro, SLA ou rollback como licença para assumir risco?
[ ] O humano realmente decide ou só assina?
[ ] Há externalidades para outros times?
🧪 Como combater Moral Hazard — passo a passo
Passo 1 — Mapeie benefício e consequência
Quem ganha?
Quem perde?
Passo 2 — Identifique o risk owner
Nome explícito.
Passo 3 — Aproxime decisão e operação
Hypercare.
On-call.
Passo 4 — Ajuste métricas
Não recompense só velocidade.
Passo 5 — Mostre custos ocultos
Incident hours.
Capacity.
Support.
Passo 6 — Crie shared KPIs
Reliability + delivery.
Passo 7 — Use guardrails técnicos
Least privilege.
Canary.
Passo 8 — Melhore contratos
Alinhe qualidade e resultado.
Passo 9 — Faça post-implementation review
Não encerre projeto no deploy.
Passo 10 — Revise incentivos após incidentes
Pergunte:
o comportamento era previsível dadas as regras?
🧠 O teste do contador de consequências
Uma técnica Bellacosa.
Antes da decisão:
IF SUCCESS:
Who benefits?
IF FAILURE:
Who works overnight?
Who loses money?
Who gets blamed?
Who pays?
Se respostas forem completamente diferentes:
investigue Moral Hazard.
☕ O teste das 03:00
Pergunta simples:
“Quem estará acordado às três da manhã se isso der errado?”
Depois:
“Essa pessoa participou da decisão?”
Se não:
há algo para revisar.
🧠 Moral Hazard e incident ownership
Mudança pedida por:
Business.
Aprovada por:
Project.
Executada por:
Ops.
Falha.
Todos precisam:
participar do post-mortem.
Não apenas Ops.
🧠 Postmortem attendance as feedback
Quem toma risco deveria ver:
consequência.
Isso ajusta modelo mental.
☕ Uma hora de RCA pode economizar muita confiança gratuita
Especialmente depois de sucesso fácil.
🧠 Moral Hazard e Near Misses
Se consequências negativas não materializam:
incentivos ruins podem permanecer invisíveis.
Near miss é oportunidade.
Pergunte:
quem teria pago?
Antes que aconteça.
🧠 Pre-mortem
Imagine falha.
Quem sofre?
Agora externalidades aparecem.
Muito útil.
🎯 Pergunta Bellacosa nº 6
“Se essa decisão desse errado amanhã, alguém que está aprovando hoje mudaria de opinião se tivesse que suportar pessoalmente o custo operacional?”
Excelente teste.
🧠 Moral Hazard na IA generativa
Programador gera código.
Se quebrar:
reviewer pega.
Então pode revisar menos o próprio output.
Copilot aumenta produtividade.
Mas talvez também:
externalize validation.
Reviewer vira filtro.
Moral Hazard micro.
☕ “O code review pega”
Frase perigosa.
Reviewer é barreira.
Não substituto para responsabilidade autoral.
🧠 CI/CD
Testes automáticos pegam.
Então:
menos teste local.
Talvez racional.
Mas se pipeline fica caro e falha mais:
o custo foi transferido.
Observe.
🧠 Quality at Source
Lean gosta de ideia:
qualidade onde trabalho ocorre.
Não empurre defeito para:
QA.
QA não deveria ser:
departamento de encontrar aquilo que Dev decidiu não verificar.
☕ QA não é lavanderia de bug
A camiseta está quase pronta.
🧠 Moral Hazard e handoffs
Toda fronteira organizacional pode:
externalizar custo.
Dev → QA.
QA → Ops.
Ops → Support.
Support → Customer.
Quanto mais handoffs:
mais risco de:
“problema do próximo.”
🧠 Flow Ownership
Mapeie cadeia.
Defeito gerado aqui.
Descoberto ali.
Quanto custa?
Shift-left tenta aproximar detecção da origem.
Além de técnica:
é alinhamento de incentivo.
🧠 Cost of Late Defect
Bug encontrado:
na IDE:
barato.
em teste:
mais caro.
em produção:
caríssimo.
Se criador não vê custo tardio:
Moral Hazard.
Feedback rápido ajuda.
☕ Compilador é um ótimo cobrador instantâneo
Erro na linha.
Pagamento imediato.
Por isso aprendemos.
🧠 COBOL e return codes
Programa devolve:
RC.
Chamador precisa:
tratar.
Não empurre erro silenciosamente.
Um RC=00 falso é quase:
Moral Hazard codificado.
Você captura benefício:
“job verde.”
Próximo step recebe:
dados errados.
💻 Exemplo
Ruim:
IF FILE-STATUS NOT = '00'
DISPLAY 'ERRO'
MOVE 0 TO RETURN-CODE
END-IF
Operação vê:
sucesso.
Erro vai adiante.
Melhor:
IF FILE-STATUS NOT = '00'
DISPLAY 'ERRO'
MOVE 12 TO RETURN-CODE
END-IF
Agora consequência volta para:
quem precisa decidir.
🧠 Greenwashing operacional
Job verde.
Negócio vermelho.
Se time é medido por:
RC=00,
pode haver incentivo para:
suprimir falhas.
Não faça.
☕ $HASP395 ... CC 0000
Não é absolvição espiritual.
Dados precisam estar corretos.
🧠 Error Handling and accountability
Erro precisa chegar:
ao lugar correto.
Não ser:
absorvido silenciosamente
para manter dashboard bonito.
🧠 Moral Hazard + Normalization of Deviance
Equipe empurra problema downstream.
Funciona.
Repete.
Outro time corrige manualmente.
Agora workaround vira serviço invisível.
Origem não sente custo.
Perfeito Moral Hazard.
☕ Maria corrige toda manhã
Enquanto sistema oficial acredita:
“processamento automático.”
Maria é arquitetura.
Mas não aparece no diagrama.
🧠 Manual Reconciliation
Se downstream sempre conserta:
upstream pode relaxar.
Então contabilize:
rework.
Mostre para origem.
📊 Rework Metrics
SOURCE SYSTEM A:
Errors generated: 400/month
Manual correction: 70h
Agora custo deixa de ser invisível.
🧠 Moral Hazard e observabilidade organizacional
Não basta monitorar CPU.
Monitore:
externalized work.
Incidents created by change.
Support tickets.
Rework.
Isso revela incentivos ruins.
🧠 Blame is not incentive alignment
Você pode culpar time.
Nada muda.
Se métrica e orçamento continuam iguais:
comportamento racional persiste.
Mude estrutura.
☕ Se sistema recompensa errado
não espere comportamento certo por patriotismo corporativo.
🧠 Leadership lesson
Uma boa pergunta de liderança:
“Que comportamento nosso sistema de metas está incentivando?”
Não:
“Por que as pessoas fazem isso?”
Isso conecta:
Moral Hazard;
Fundamental Attribution Error;
Actor-Observer Bias.
🧠 People respond to systems
Não deterministicamente.
Mas incentivos importam.
A melhor cultura não depende de:
santos.
Depende de:
regras razoáveis.
🧠 Ethics matters too
Claro.
Moral Hazard não elimina ética individual.
Uma pessoa pode agir corretamente mesmo com incentivo ruim.
Mas engenharia organizacional não deve depender:
exclusivamente
de heroísmo moral.
☕ Sistemas críticos gostam de pessoas boas
Mas preferem pessoas boas com bons controles.
🧠 Moral Hazard e Resilience
Resiliência pode paradoxalmente criar Moral Hazard.
Se Ops sempre salva:
projetos começam a confiar:
“Ops dá jeito.”
O heroísmo operacional vira seguro gratuito.
Perigoso.
🧠 Hero Culture
Operações salva.
Recebe aplauso.
Mas sistema nunca melhora.
Por quê?
Porque capacidade heroica absorve custo.
Deixe custo ficar visível.
☕ O sysprog que salva tudo
Pode estar involuntariamente subsidiando processo ruim.
Essa dói.
🧠 Remove hidden subsidies
Não pare de ajudar.
Mas registre:
quantas intervenções.
Quanto esforço.
Mostre.
Agora investimento em prevenção ganha business case.
🧠 Moral Hazard e staffing
Equipe pequena absorve tudo.
Outros times assumem:
“eles resolvem.”
Até turnover.
Agora risco explode.
Bus Factor.
🧠 Skills as Shared Risk
Se só uma pessoa sabe:
custo da dependência deve aparecer.
Não deixe:
“tem fulano”
virar mitigação permanente.
☕ “Fala com João”
Não é arquitetura HA.
🧠 Moral Hazard e decision rights
Quem possui direito de decisão deve possuir:
accountability proporcional.
Se não:
risco desalinhado.
🧠 RAPID / DACI
Frameworks de decisão podem ajudar.
Não precisamos decorar siglas.
Princípio:
quem decide precisa estar claro.
E:
quem aceita risco precisa estar claro.
🧠 Stop-the-Line Authority
Qualquer pessoa detecta risco crítico:
pode parar.
Isso reduz Moral Hazard hierárquico.
Porque executor não precisa aceitar risco imposto sem voz.
☕ Toyota encontra TARDIS
Puxou Andon.
Parou linha.
Doctor aprovaria.
🧠 Psychological Safety again
Se júnior diz:
“isso é arriscado”
e é ignorado,
risk owner precisa estar explícito.
Caso contrário:
decisão vira:
“todo mundo concordou.”
Groupthink.
📋 Bellacosa Moral Hazard Decision Card
DECISION:
________________________
UPSIDE:
________________________
WHO RECEIVES UPSIDE?
________________________
DOWNSIDE:
________________________
WHO BEARS DOWNSIDE?
________________________
RISK OWNER:
________________________
EXECUTOR:
________________________
ROLLBACK OWNER:
________________________
Simples.
Poderoso.
🧠 Accountability Triangle
Podemos imaginar:
DECISION
/\
/ \
BENEFIT — CONSEQUENCE
Quanto mais afastados:
mais Moral Hazard possível.
🧠 Alinhe o triângulo
Quem decide:
entende benefício.
Entende consequência.
Participa da revisão.
Isso melhora decisões.
☕ Decisão sem consequência é teoria
Consequência sem poder de decisão é ressentimento.
Excelente.
🧠 Governance madura
Boa governança tenta evitar:
dois extremos.
Extremo 1
Ninguém pode decidir.
Need for Control.
Extremo 2
Quem decide nunca paga consequência.
Moral Hazard.
O equilíbrio:
autonomia com accountability.
🧠 Guardrails + Ownership
Permita:
decidir dentro de limites.
Mas resultado:
continua pertencendo ao serviço.
Essa talvez seja uma das melhores formas.
🧠 Product Teams
Equipes end-to-end reduzem:
handoffs.
Externalidades.
Não eliminam.
Mas diminuem fronteira Dev/Ops.
☕ “Não é meu problema”
Quanto menos vezes essa frase cabe na arquitetura:
melhor.
🧠 Moral Hazard + Zero-Risk Bias + Risk Compensation
Nosso trio recente:
Zero-Risk Bias
“Quero eliminar risco.”
Risk Compensation
“Agora estou protegido, posso arriscar mais.”
Moral Hazard
“E parte do custo nem será meu.”
Agora imagine:
rollback;
seguro;
SLA;
Ops heroico.
Pode surgir:
overconfidence institucional.
🧠 Illusion of Control entra novamente
“Se falhar, temos mecanismos.”
Talvez.
Mas:
quem paga cada falha?
E:
quantas falhas estamos dispostos a gerar?
🧠 Risk Budget com Owner
Erro budget é útil porque:
permite risco.
Mas deixa:
limite visível.
Se time consome:
para.
Isso internaliza.
☕ O risco finalmente recebeu extrato bancário
Bonito.
🧠 Moral Hazard e regulatory bailout
Em finanças, Moral Hazard é frequentemente discutido quando instituições acreditam que poderão ser resgatadas se decisões arriscadas produzirem perdas sistêmicas.
A lógica:
se upside fica com a instituição
e downside extremo pode ser socializado,
incentivo pode mudar.
No mainframe corporativo:
escala menor.
Mas estrutura parecida:
benefício local, custo coletivo.
🧠 “Too Important to Fail”
Sistema crítico.
Todos sabem:
se falhar, organização inteira mobiliza.
Então projeto pode inconscientemente pensar:
“Alguém resolverá.”
Quanto mais crítico:
mais recursos de salvamento.
Paradoxalmente:
pode aumentar tolerância a risco.
☕ O sistema VIP
Sempre tem vinte especialistas disponíveis.
Então ninguém investe em automatizar recuperação.
Até um dia:
não estão.
🧠 Heroic Backstop
Especialista veterano vira:
seguro informal.
Novatos arriscam mais porque:
“se der ruim, chama ele.”
Risk Compensation + Moral Hazard.
Treinamento precisa:
usar mentor,
não depender dele como airbag humano.
🧠 Controlled Escalation
Escalar é certo.
Mas preserve:
responsabilidade por aprender.
Depois:
review.
Não apenas:
“o sênior resolveu.”
🎯 Pergunta Bellacosa nº 7
“Estamos tratando a competência de alguém como uma proteção gratuita que nos permite manter um processo ruim?”
Excelente.
🧠 Moral Hazard e root cause
RCA deveria perguntar:
“Que incentivos tornaram esta decisão razoável?”
Não apenas:
“quem errou?”
Se time sempre faz change grande porque:
só mudanças grandes recebem atenção executiva,
incentivo estranho.
🧠 Organizational Economics
Todo processo tem:
economia.
Tempo.
Status.
Bônus.
Fricção.
Pessoas respondem.
Mainframe não existe fora da organização.
☕ O JCL roda em z/OS
Mas a decisão de rodá-lo roda em seres humanos.
🧠 Step-by-step anti-Moral Hazard em uma War Room
Antes da mudança
Defina:
owner.
Risco.
Conseqüência.
Durante
Executor pode parar.
Depois
Owner participa do resultado.
Após incidente
Revise incentivos.
Simples.
🧪 Exemplo completo
Mudança:
DB2 schema.
Benefício:
projeto entrega.
Risco:
rollback difícil.
Decisão anterior:
projeto decide.
Ops executa.
Melhoria:
DECISION OWNER:
Application Service Owner
RISK ACCEPTANCE:
Business
EXECUTION:
DBA
HYPERCARE:
Dev + DBA + Ops
SUCCESS KPI:
Business + Reliability
Agora:
benefício e consequence closer.
🧠 Moral Hazard não desaparece
Nenhum desenho alinha tudo perfeitamente.
Mas podemos:
reduzir.
Dar visibilidade.
Criar accountability.
☕ Zero Moral Hazard
Cuidado.
Zero-Risk Bias está ouvindo.
🧠 Curiosidade: o termo
A expressão “moral hazard” vem de longa tradição em seguros e economia.
Historicamente, havia preocupação de que proteção contra perdas pudesse alterar comportamento.
Com o tempo, o conceito se tornou central em:
economia da informação;
contratos;
finanças.
Hoje é útil para pensar qualquer situação onde:
a exposição à consequência muda os incentivos de quem toma risco.
Inclusive nossa querida War Room.
🧠 Information Asymmetry
Outro ingrediente:
quem toma decisão pode saber mais sobre:
risco
do que quem paga.
Exemplo:
fornecedor conhece limitação.
Cliente não.
Se contrato não exige transparência:
Moral Hazard aumenta.
☕ O famoso:
“Isso nunca aconteceu.”
Pergunta:
“Nos testes de vocês?”
Informação importa.
🧠 Observability between organizations
SLA sem telemetria compartilhada:
disputa.
Fornecedor:
“não foi conosco.”
Cliente:
“foi.”
Shared metrics ajudam.
🧠 Moral Hazard e black boxes
Quanto menos visível processo do fornecedor:
mais difícil alinhar.
Contratos precisam:
auditability.
Mas sem virar Need for Control infinito.
🧠 Trust but verify
De novo:
confiança.
Auditabilidade.
Incentivos.
Três elementos.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Moral Hazard ocorre quando quem assume um risco não suporta integralmente suas consequências.
Não significa necessariamente falta de ética; frequentemente é um problema de desenho de incentivos.
Risk Compensation fala da mudança de comportamento quando percebemos mais proteção; Moral Hazard acrescenta a questão de quem paga o downside.
Benefício local e custo coletivo são um sinal clássico.
SLAs, seguros, rollback, fornecedores e times de suporte não eliminam risco; podem transferir parte da consequência.
Outsourcing de execução não é outsourcing automático de accountability.
Projetos deveriam continuar ligados ao resultado após o Go-Live.
Shared KPIs entre Dev, Ops e negócio ajudam a reduzir externalização de custos.
On-call, hypercare, showback e post-implementation reviews aproximam decisão e consequência.
HITL pode virar teatro de responsabilidade se o humano não tiver tempo, informação ou poder real para decidir.
Accountability não é culpa.
E principalmente:
se quem decide recebe a recompensa e quem executa, suporta ou corrige recebe a maior parte do prejuízo, não espere que palestras sobre responsabilidade consertem o problema — mude os incentivos.
🕰️ De volta às 08:37
O gerente ainda quer:
Big Bang.
Nosso jovem pergunta:
— Se fizermos, quem fica no hypercare?
— Operações.
— Só?
— Bem...
— Quem definiu o escopo?
— Projeto.
— Então projeto fica também?
Silêncio.
O Doctor olha para o gerente.
— É uma excelente pergunta.
O gerente pensa.
— Tudo bem. Projeto fica.
— E quem aprova risco?
— Business owner.
— E rollback?
— DBA e aplicação juntos.
— Agora podemos fazer Big Bang?
Nosso jovem responde:
— Agora podemos discutir Big Bang com as pessoas que realmente carregarão o resultado.
Isso muda a conversa.
🔧 A decisão muda
Depois de revisar:
impacto;
rollback;
staffing,
decidem:
não fazer Big Bang.
Dividem:
3 waves.
Canary.
Hypercare conjunto.
Por quê?
Curiosamente:
quando as pessoas que capturavam o benefício também começaram a enxergar e carregar o custo...
o apetite por risco mudou.
Não precisou sermão.
Só:
incentivo alinhado.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(MORAL-HAZARD)
Dentro:
IF DECISION-OWNER NOT = RISK-OWNER
PERFORM CHECK-INCENTIVES
END-IF.
IF BENEFIT-GOES-LOCAL
AND COST-GOES-GLOBAL
PERFORM ALIGN-ACCOUNTABILITY
END-IF.
IF SOMEONE-SAYS
'OPS-WILL-FIX-IT'
PERFORM INVITE-THEM-TO-HYPERCARE
END-IF.
Comentário:
* MY UPSIDE.
* YOUR DOWNSIDE.
* BAD DESIGN.
Outro:
* OUTSOURCING
* DOES NOT DELETE
* ACCOUNTABILITY.
Outro:
* SLA CREDIT
* DOES NOT RESTORE
* LOST TIME.
Mais um:
* WHO DECIDES?
* WHO PAYS?
E naturalmente:
* DALEKS PREFER
* OTHER SPECIES
* TO PAY THE DOWNSIDE.
Nosso jovem fecha o membro.
Horas depois alguém propõe:
— Podemos cortar os testes finais. Se der problema, QA pega.
Ele responde:
— Talvez QA pegue.
— Então?
— Quem ganha o prazo economizado?
— Nós.
— E quem recebe o retrabalho?
Silêncio.
— QA.
— Então antes de cortar...
Pausa.
— vamos descobrir se estamos realmente removendo trabalho ou apenas mandando nossa conta para o próximo time.
A mudança continua.
Os testes também.
Mais tarde, outra automação permite remover parte deles com segurança.
Desta vez:
dados justificam.
Não terceirização silenciosa de risco.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
Uma organização aprende de verdade quando quem escolhe o risco não consegue simplesmente despachar a consequência para outra fila.
E talvez Moral Hazard possa ser resumido em uma pergunta muito simples:
“Se você tivesse que pagar integralmente a conta dessa decisão, ainda escolheria a mesma coisa?”
Se a resposta mudar...
há algo importante escondido no desenho do sistema.
☕🌀
Next stop: Principal-Agent Problem — quando quem toma uma decisão em nome da organização possui objetivos, informações e incentivos diferentes daqueles de quem realmente depende do resultado.
