Pensamento de grupo: 4 sinais que 'time muito unido' decide pior (de Challenger a Project Aristotle)

Em 2015, o Google publicou o resultado do Project Aristotle. Dois anos de estudo, 180 times (115 de engenharia, 65 de vendas), 250 atributos medidos (re:Work, 2015). O fator mais forte dos times de alta performance foi segurança psicológica, não capacidade dos membros nem antiguidade do grupo.

Muito time brasileiro leu “segurança psicológica” como “união”. São conceitos opostos. “Time muito unido” é precisamente a condição de risco que Irving Janis descreveu em 1972 em Victims of Groupthink: coesão forte + fontes externas cortadas + líder apoiando uma direção = decisão pior. O Challenger explodiu dentro desse padrão. A Baía dos Porcos também. E, mais perto, a reunião de arquitetura da semana passada no seu time provavelmente também.

Este post destila os 4 sinais mais frequentes em time de engenharia, mostra por que o Challenger virou o caso canônico, e separa a reforma que a NASA realmente adotou dos mitos que circulam.

Ignorância pluralística é um fenômeno próximo mas diferente — está em outro artigo. Lá o problema é “cada um acha que é o único”. Aqui o problema é “o grupo pressiona quem discorda”. Mecanismos opostos, resultado parecido.

O que Janis chamou de pensamento de grupo em 1972

Irving Janis era psicólogo social em Yale. Em Victims of Groupthink (1972) ele analisou decisões de política externa dos EUA que correram mal — notadamente a invasão da Baía dos Porcos (1961) e a resposta ao ataque em Pearl Harbor (1941) — e contrastou com decisões que correram bem sob o mesmo estilo de grupo, especialmente o manejo da Crise dos Mísseis de Cuba (1962), em que o grupo de aconselhamento do Kennedy evitou o padrão depois do fracasso da Baía dos Porcos.

Da análise saíram 8 sintomas em 3 grupos:

• Superestimativa: ilusão de invulnerabilidade, crença na moralidade do grupo.
• Fechamento: racionalização coletiva, estereotipação de quem está fora.
• Pressão por uniformidade: autocensura, ilusão de unanimidade, pressão direta sobre dissidentes, mindguards autoapontados (membros que filtram informação dissonante antes dela chegar ao grupo).

A tese de fundo: coesão suprime divergência. O grupo passa a valorizar manter o acordo acima de examinar os dados. E quanto mais o grupo se vê como “nós contra o resto”, mais o padrão trava.

Por que o Challenger virou o caso canônico

28 de janeiro de 1986. 73 segundos após o lançamento, o ônibus espacial Challenger se desintegra sobre o Atlântico. Sete pessoas a bordo.

A noite anterior tinha uma teleconferência (27 de janeiro, por volta das 20h45 EST) entre engenheiros da Morton Thiokol — fornecedora dos propulsores sólidos — e gerência da NASA. Roger Boisjoly, Allan McDonald e outros engenheiros da Thiokol recomendaram adiar o lançamento: os anéis de vedação (O-rings) perdiam elasticidade abaixo de 11°C e a temperatura prevista para a manhã estava em torno de -3°C (horário de lançamento), com mínima noturna próxima de -8°C. Era fora da janela de dados que a Thiokol tinha (Rogers Commission Report, Vol. I, Ch. 5).

Vice-presidentes da Thiokol reverteram a posição depois de pressão da NASA (“quando é que vocês acham que a Thiokol vai aprovar algum lançamento, em abril?”, famosa fala do gerente de nível III). McDonald se recusou a assinar a aprovação; um VP assinou no lugar. Simultaneamente, engenheiros da Rockwell International em Downey, Califórnia, tinham uma preocupação separada sobre gelo na plataforma — mas essa posição nunca chegou nitidamente à cadeia de decisão de lançamento.

A Rogers Commission (relatório de junho de 1986) catalogou a falha de comunicação. Richard Feynman, nomeado membro da comissão em fevereiro de 1986, escreveu o Apêndice F documentando o descompasso de estimativa de risco: engenheiros estimavam probabilidade de falha catastrófica em torno de 1 em 100 lançamentos; a gerência operava com cerca de 1 em 100.000. Três ordens de grandeza de distância. Esse descompasso foi medido pela comissão depois do acidente, não observado por Feynman antes dele.

O interessante não é que “a NASA era desorganizada”. A NASA do Challenger era um grupo altamente coeso, com décadas de sucessos, confiante na própria competência. Exatamente o perfil de risco do Janis.

4 sinais em time de engenharia

Os 4 abaixo são a destilação prática dos 8 sintomas de Janis para o contexto de time técnico.

Sinal 1: “Nenhuma objeção” virou padrão

Seis reuniões consecutivas de arquitetura aprovaram propostas sem ressalva. Em time real de 8 pessoas, com níveis diferentes de senioridade e background, isso não acontece naturalmente. Alguma coisa está filtrando a discordância antes dela chegar à reunião.

Teste prático: puxe o histórico de uma proposta grande e procure por ”++” ou “LGTM” no PR correspondente. Se todo mundo aprovou sem nenhuma linha de pergunta técnica, provavelmente a conversa real aconteceu em DM, ou não aconteceu.

Isso é a ilusão de unanimidade do Janis. Confirmação sem ressalva lida como consenso quando é só silêncio.

Sinal 2: Discordante é deslocado, não refutado (mindguards)

A objeção técnica não ganha resposta técnica. Vira “fulana é sempre contra tudo”, “ciclano gosta de criar atrito”, “beltrano não entende a prioridade do negócio”. A discordância é tratada como um traço de personalidade do dissidente, não como um dado sobre a proposta.

Esse é o mindguard operando. Alguém — às vezes auto-apontado, sem combinação explícita — se posiciona entre a informação dissonante e o grupo, filtrando ou enquadrando a discordância como ruído. No Challenger, parte do que travou a objeção da Thiokol foi exatamente esse enquadramento: a preocupação técnica virou “a Thiokol está sendo conservadora de novo”.

Sinal 3: “Revisão externa não precisa”

Pedido de auditoria, de segunda opinião, de pentest externo vira atrito. “A gente já conhece esse sistema melhor que qualquer consultor.” “Vai só atrasar o roadmap.” “Esse tipo de bug não acontece na nossa stack.”

É a racionalização coletiva ligada à estereotipação do que está fora: o externo é visto como menos competente ou menos engajado por default. Em time de engenharia o sinal específico é a resistência a trazer alguém de outro time, outro departamento ou um consultor para a mesa de decisão arquitetural.

A reforma pós-Challenger (próxima seção) é exatamente sobre criar canal de revisão independente. Não por acaso.

Sinal 4: Sensação de invencibilidade

“A gente nunca cai em produção.” “Nosso disaster recovery é bem desenhado, não precisa testar.” “Esse padrão de deploy funciona há 4 anos.”

É a ilusão de invulnerabilidade do Janis. No Challenger, a gerência operava com estimativa de ~1 falha a cada 100.000 lançamentos; engenheiros da Thiokol trabalhavam com ~1 em 100 (Feynman, Apêndice F ao Relatório Rogers, 1986). Em time de engenharia, o sintoma aparece quando o exercício de game-day, chaos engineering ou revisão de postmortem é adiado por “não ter sido necessário até agora”.

Teste prático: pergunte quando foi o último incidente real em produção. Se a resposta for “>1 ano” e o time nunca rodou um exercício controlado de falha nesse período, a invulnerabilidade é modelo, não dado.

O que o Project Aristotle encontrou — e a parte que muita gente leu errado

O Project Aristotle rodou entre 2012 e 2014 em 180 times do Google (115 de engenharia, 65 de vendas), medindo 250 atributos. Dos 5 fatores que explicavam performance de time, segurança psicológica era o mais forte e sustentava os outros 4 (dependability, structure/clarity, meaning, impact). A publicação em re:Work saiu em 2015.

O termo em si não é do Google. Amy Edmondson cunhou em 1999, num artigo no Administrative Science Quarterly estudando 51 times de uma fábrica. Definição: estado em que membros acreditam que correr riscos interpessoais é seguro — perguntar, reportar erro, discordar, pedir ajuda — sem punição social.

Leitura errada frequente, em português e em outras línguas: “segurança psicológica = ambiente confortável sem conflito”. A própria Edmondson, em The Fearless Organization (2019), insiste no contrário: segurança psicológica e exigência de padrão alto são eixos independentes. Time só confortável vira zona de conforto improdutiva. Time só exigente vira ansiedade e rotatividade. O ponto é o quadrante “franco + exigente”, em que apontar problema técnico é esperado e feedback duro circula.

União sem franqueza é a condição exata do pensamento de grupo que Janis descreveu. “Time unido que concorda sempre” não é o resultado do Project Aristotle, é o antipadrão que o Project Aristotle ajuda a diagnosticar.

A reforma que a NASA realmente adotou — e os mitos

Aqui o solo é escorregadio porque virou mito reciclado em palestra corporativa. Separando o que é verificável do que é folclore:

O que o Relatório Rogers recomendou (Recomendação IX, junho de 1986): estabelecer um Office of Safety, Reliability, and Quality Assurance (SRQA) com Associate Administrator reportando diretamente ao Administrador da NASA, com autoridade sobre segurança, confiabilidade e QA em toda a agência, independente das demais funções e programas (Rogers Commission Report, Recomendações).

O que a NASA fez em 8 de julho de 1986: anunciou a nomeação de George Rodney como o primeiro Associate Administrator do SRQA (NASA Actions to Implement Rogers Commission Recommendations).

O que a NASA não fez: a autoridade direta sobre todas as operações de segurança não se materializou. Os centros de voo humano mantiveram cada um sua própria organização de segurança reportando ao diretor do centro, não ao SRQA. O Columbia Accident Investigation Board voltou a apontar essa lacuna estrutural em 2003, 17 anos depois.

O que não aconteceu: a NASA não “institucionalizou pre-mortem” nem “devil’s advocate rotativo” depois do Challenger. A técnica de pre-mortem foi formalizada por Gary Klein num artigo da Harvard Business Review em 2007, 21 anos depois do Challenger. A base acadêmica anterior (Mitchell, Russo e Pennington, 1989, sobre prospective hindsight) também é posterior ao acidente. Qualquer post que diga “a NASA já fazia pre-mortem antes de 1986” está errado em pelo menos duas datas.

Para o seu time, a lição verificável é mais magra do que o mito, mas mais útil: a revisão independente só funciona quando é independente de verdade — autoridade separada, canal próprio de escalação, não a mesma hierarquia pintada de outra cor. A implementação parcial do SRQA mostra o que acontece quando o rótulo muda mas a cadeia de reporte não.

Como quebrar o padrão no seu time

Janis já tinha listado antídotos em 1972. Nenhum deles exige um orçamento, uma consultoria externa ou um Chief Something Officer:

1. Dissidente externo convidado. Alguém de fora do time (outro time, outro departamento, um consultor pontual) entra na reunião de decisão com a tarefa explícita de atacar a proposta. Papel nomeado, não implícito. Janis chamava de devil’s advocate — útil manter o nome em inglês para o time entender que é função, não personalidade.
2. Subgrupos revisando a mesma decisão em paralelo. Antes da reunião unificada, 2 ou 3 pequenos grupos avaliam a proposta de forma independente. Convergência é sinal; divergência é dado valioso que teria sido suprimido no formato grande.
3. Líder fala por último. Em time de engenharia, isso é o staff ou o tech lead na code review decidindo depois do júnior ler, não antes. Opinião da liderança ancora o resto do grupo e produz unanimidade falsa.
4. Second-chance meeting. Depois da decisão aparentemente tomada, uma segunda reunião curta onde cada pessoa é convidada a trazer dúvidas residuais. Janis descreveu em 1972; funciona porque legitima trazer objeção depois, em vez de “você teve sua chance na reunião anterior”. No GitHub flow, a cultura de “approving um PR não encerra discussão, follow-ups são bem-vindos” é a versão de código do mesmo mecanismo.

Pre-mortem (Klein, HBR 2007) encaixa como quinta ferramenta: antes de uma decisão arriscada, o time imagina que a decisão falhou em 6 meses e lista as causas. Útil, mas é adição de 2007, não “coisa da NASA pós-Challenger”.

A combinação mais frequente em time pequeno (3 a 8 pessoas): dissidente externo + líder fala por último + second-chance meeting uma semana depois. Custa 40 minutos a mais no total e desarma a maior parte dos 4 sinais.

Fechando

“Time muito unido” não é elogio neutro. É descrição de uma condição em que o grupo tende a decidir pior do que decidiria com um grau salutar de discórdia. Project Aristotle, Edmondson e um século de pesquisa social falam da mesma coisa por caminhos diferentes: a franqueza, não a união, é o que separa times que decidem bem de times que explodem no 73º segundo.

Se o seu time reconhece 2 ou mais dos 4 sinais acima, o próximo passo não é dissolver o time. É inserir uma das 4 ou 5 ferramentas da seção anterior na próxima decisão não trivial. A primeira vez vai ser estranha. A terceira vai parecer natural. A décima vai ser invisível, no sentido bom: discordância vira parte do processo em vez de evento.

Leituras relacionadas

• Ignorância pluralística: 3 sinais no seu time — primo próximo mas diferente, outro mecanismo falho em time coeso.
• Code review vira briga: 5 vieses psicológicos — vieses individuais que amplificam o padrão de grupo.

Pensamento de grupo é parte do capítulo 13 de Engineer Psychology Tricks, que cataloga outros 20+ padrões psicológicos em time de engenharia.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews