Existe uma verdade desconfortável que ninguém gosta de admitir: os tipos de pessoas que escolhem passar a vida resolvendo problemas através de código geralmente são as mesmas que prefeririam enfrentar um deadlock de banco de dados a ter uma conversa sobre como estão se sentindo.
Quando você passa anos aprendendo a pensar em termos de arquiteturas, complexidade algorítmica e otimização de performance, falar sobre "sentimentos" e "empatia" soa como... impreciso, subjetivo e impossível de mensurar.
Em 2012, o Google decidiu resolver esse problema da única forma que sabia: com dados.
O problema que ninguém queria admitir
Em 2012, o Google tinha um problema, não um problema técnico, não um problema de escala, mas um problema humano: eles não conseguiam entender por que algumas equipes entregavam resultados consistentemente extraordinários enquanto outras, compostas por pessoas igualmente talentosas lutavam.
E isso incomodava profundamente.
Porque o Google é uma empresa que foi fundada na premissa de que dados e análise podem resolver qualquer problema. Eles mediram tudo: quantas vezes as pessoas iam ao banheiro, com quem almoçavam, quanto tempo passavam em reuniões, quantos e-mails mandavam e etc.
Gastaram milhões de dólares em estudos. Reuniram alguns dos melhores estatísticos, psicólogos organizacionais e sociólogos.
Criaram o Projeto Aristóteles para estudar 180 equipes diferentes ao longo de três anos.
E sabe o que descobriram no início?
Nada.
Não importava se as equipes eram compostas por amigos ou estranhos, não importava se todos eram extrovertidos ou introvertidos, não importava o background educacional... Não importava a senioridade.
"Nós olhamos 180 equipes," disse Abeer Dubey, um dos gestores do projeto, "tínhamos um monte de dados, mas não havia nada que mostrasse que uma mistura específica de tipos de personalidade ou habilidades fazia diferença."
A parte do "quem" da equação parecia não importar.
E isso era um problema existencial para uma empresa que acredita religiosamente em otimização baseada em dados.
A virada (que não era sobre dados)
A resposta veio de um lugar inesperado: pesquisas acadêmicas sobre "normas de grupo" e um conceito que soava perigosamente soft para engenheiros do Vale do Silício: segurança psicológica.
Amy Edmondson, professora da Harvard Business School, define como "uma crença compartilhada pelos membros de que a equipe é segura para assumir riscos interpessoais."
Em português claro: a sensação de que você pode ser você mesmo, admitir que não sabe algo, discordar do arquiteto sênior, compartilhar uma ideia maluca, sem ser humilhado, rejeitado ou punido.
Quando os pesquisadores do Projeto Aristóteles encontraram esse conceito nas revistas acadêmicas, eles finalmente tinham uma hipótese que fazia sentido com os dados que estavam vendo.
Equipes que performavam bem tinham duas características mensuráveis:
Primeiro: Igualdade na distribuição de turnos na conversação. Todo mundo falava aproximadamente a mesma quantidade ao longo do tempo.
Segundo: Alta sensibilidade social. As pessoas conseguiam identificar quando alguém estava desconfortável, mesmo que não verbalizasse.
Mas aqui estava o problema: como você vende isso para engenheiros?
Como você diz para pessoas que escolheram carreiras onde conseguem resolver problemas complexos sem precisar lidar com ambiguidade emocional que agora elas precisam... se importar com como os outros estão se sentindo?
A solução foi "Googletizada"
Eles transformaram empatia em métrica.
Criaram pesquisas, escalas, questionários, correlações estatísticas e gráficos mostrando que equipes com maior segurança psicológica tinham 27% menos erros de código, que times onde todos falavam tinham 35% mais inovações e que sensibilidade emocional correlacionava com menor tempo de debugging.
"Googlers amam dados," disse Abeer Dubey, um dos gestores do projeto. "Ao colocar coisas como empatia e sensibilidade em gráficos e relatórios de dados, isso faz com que fique mais fácil conversar sobre. É mais fácil falar sobre nossos sentimentos quando podemos apontar para um número."
Isso soa cínico quando você coloca dessa forma, mas era exatamente o que precisava acontecer.
Porque o que o Google entendeu é que para mudar cultura em um ambiente técnico, você precisa falar a língua daquele ambiente e a língua de engenheiros é dados, métricas, evidência empírica.
A jornada de Julia Rozovsky: do problema à solução
Julia Rozovsky era uma das pesquisadoras principais do Projeto Aristóteles, mas antes de trabalhar no Google, ela havia vivido na pele exatamente o problema que estava tentando resolver.
Em Yale, cursando MBA, ela foi colocada em um grupo de estudos cuidadosamente montado pela escola, todos eram inteligentes, ambiciosos, tinham backgrounds similares, na teoria, deveria funcionar perfeitamente.
Na prática, foi um pesadelo.
"Eu sempre sentia como se tivesse que provar a mim mesma," ela relatou. Quando o grupo se reunia, havia disputas constantes por liderança, pessoas interrompiam umas às outras e havia sempre tensão sobre quem estava no comando.
Ao mesmo tempo, Rozovsky participava de outra equipe, um grupo voluntário de competição de cases de negócios e esse time tinha uma mistura aleatória: um ex oficial do exército, um pesquisador, um diretor de ONG e um conselheiro de refugiados.
E funcionava perfeitamente.
Eles mandavam e-mails com piadas bobas, gastavam os primeiros 10 minutos de reuniões só batendo papo, quando faziam brainstorming "tínhamos muitas ideias loucas" ela disse, "Ninguém se preocupava se o resto do time ia nos julgar".
Rozovsky ficou obcecada com essa diferença. Por que dois grupos com ela como denominador comum tinham dinâmicas tão opostas?
Anos depois, quando já trabalhava no Google liderando o Projeto Aristóteles, ela finalmente encontrou a resposta nos dados: segurança psicológica.
O grupo de estudos tinha normas que puniam vulnerabilidade. O time de competição tinha normas que a encorajavam. Simples assim. E devastadoramente difícil de mudar.
Como transformar descoberta em mudança
O desafio que Rozovsky e a equipe do Projeto Aristóteles enfrentavam era brutal: eles tinham identificado que segurança psicológica era o fator crítico, mas como você implementa isso em uma organização de 50.000 engenheiros?
Você não pode simplesmente mandar um e-mail dizendo "sejam mais vulneráveis uns com os outros."
A solução que encontraram foi brilhante em sua simplicidade: criar permissão estrutural através de dados.
Eles começaram a compartilhar as descobertas com grupos selecionados de gestores, não com workshops de inteligência emocional, não com consultores falando sobre feelings, mas com pesquisas, questionários e correlações estatísticas.
"Googlers amam dados" disse Abeer Dubey, gestor do projeto. "Ao colocar coisas como empatia e sensibilidade em gráficos e relatórios de dados, isso faz com que fique mais fácil conversar sobre."
Os gestores recebiam pesquisas para avaliar suas equipes, métricas sobre distribuição de participação em reuniões, scores de sensibilidade social e correlações entre esses fatores e performance de entrega.
E então, armados com dados, eles podiam ter conversas que antes eram impossíveis.
Um gestor poderia olhar para os resultados e ver: "apenas 2 pessoas falaram 73% do tempo nas últimas 10 reuniões", outro poderia ver: "seu time tem score de segurança psicológica no percentil 15."
Não eram julgamentos morais, eram fatos mensuráveis que apontavam para oportunidades de melhoria.
E para engenheiros, essa diferença é tudo.
O paradoxo dos milhões de dólares
Tem algo profundamente irônico na história do Projeto Aristóteles.
O Google gastou milhões de dólares e três anos para provar cientificamente algo que qualquer professor de MBA ou terapeuta organizacional poderia ter dito de graça: times funcionam melhor quando as pessoas confiam umas nas outras.
"Somente ter dados que provam às pessoas que compensa prestar atenção a essas coisas é o passo mais importante para fazê-las prestarem atenção de verdade," disse Rozovsky, "Não subestime o poder de dar às pessoas uma plataforma e linguagem operacional comum."
Mas esse é exatamente o ponto.
Em culturas técnicas, em ambientes onde "otimização" é a palavra sagrada, você não pode simplesmente aparecer e dizer "sejam mais empáticos.", isso não funciona, soa como julgamento moral, como fraqueza, como algo que vai atrapalhar a "real" entrega de valor.
Você precisa provar, com dados, com correlações, com gráficos e tabelas e análise estatística.
E então, só então, você ganha permissão para falar sobre coisas que realmente importam: como as pessoas estão se sentindo, se confiam umas nas outras, se conseguem ser vulneráveis.
O Google não descobriu nada novo, eles legitimaram conhecimento antigo traduzindo-o para uma linguagem que engenheiros podiam aceitar.
E isso, paradoxalmente, era exatamente o que precisava acontecer.
Aqui está a parte mais reveladora da história do Projeto Aristóteles.
A Google passou anos evitando conversas sobre "como você está se sentindo" com seus times porque não era mensurável, não movia métricas e era "soft."
Eles focavam em otimização: melhores processos, melhores ferramentas, melhores arquiteturas e conseguiam resultados razoáveis.
Mas quando finalmente começaram a prestar atenção nas coisas "soft", modelar vulnerabilidade, criar espaço para que as pessoas admitissem que não sabiam coisas, intervir quando alguém monopolizava conversas, os resultados melhoraram dramaticamente.
Não porque tinham descoberto algo novo, mas porque finalmente tinham dado permissão para a organização se importar com a coisa certa.
O custo oculto da obsessão por otimização é que ela faz organizações ignorarem as variáveis mais importantes. Porque essas variáveis são difíceis de medir, porque são ambíguas, porque envolvem emoções.
E especialmente em ambientes técnicos, onde muitos escolhem essas carreiras especificamente porque preferem a clareza de código à ambiguidade de humanos, é muito fácil racionalizar essa ignorância.
"Não é meu trabalho ser terapeuta" a lógica diz, "Meu trabalho é entregar software"
Mas organizações não entregam software. Pessoas entregam software.
E pessoas que não confiam umas nas outras, que têm medo de parecer incompetentes, que escondem problemas, que guardam conhecimento como moeda de troca, entregam software pior.
Ou entregam por menos tempo antes de pedir demissão.
O que o Projeto Aristóteles revelou sobre medição
Os pesquisadores do Projeto Aristóteles descobriram que avaliar se um time está saudável requer olhar além de velocity ou quantidade de bugs em produção.
Eles começaram a observar:
Como erros são tratados. Quando alguém introduz um bug, é uma oportunidade de aprendizado ou uma chance de humilhação? O time faz post-mortem sem culpa ou vira caça às bruxas?
Como discordâncias acontecem. Quando alguém discorda do arquiteto sênior, o que acontece? A ideia é explorada ou é descartada? A pessoa que discordou é vista como colaboradora ou como problemática?
O que acontece com perguntas. Quando um desenvolvedor júnior faz uma pergunta "básica", como o time reage? Com paciência ou com irritação velada?
Quem fala nas reuniões. É sempre as mesmas 2~3 pessoas ou há rotatividade? Quando alguém novo tenta contribuir, eles conseguem terminar suas frases?
E a descoberta surpreendente foi que essas coisas são mensuráveis.
Não da forma precisa que engenheiros gostariam. Não com a clareza de "função X tem complexidade O(n²)." Mas mensuráveis o suficiente para tomar decisões.
É possível contar quantas vezes cada pessoa fala numa reunião, é possível medir tempo médio entre alguém fazer uma pergunta e receber resposta útil, é possível "trackear" quantas pessoas saem de uma retrospectiva sem ter dito nada.
O Google não inventou nada novo, eles só fizeram o que fazem melhor: pegaram conhecimento que existia há décadas em psicologia organizacional e traduziram para a linguagem que engenheiros entendem.
E funcionou.
Não porque engenheiros são menos capazes de empatia do que outras pessoas. Mas porque em culturas técnicas, organizações precisam de permissão para se importar com coisas que não parecem "técnicas."
E dados fornecem essa permissão.
A lição mais ampla
O Projeto Aristóteles tem uma lição que vai muito além de gestão de equipes de tecnologia.
Quando você quer mudar comportamentos em qualquer cultura, você precisa falar a língua daquela cultura.
Para médicos, você precisa de estudos clínicos, para advogados, você precisa de precedentes, para engenheiros, você precisa de dados.
Não porque essas pessoas são incapazes de agir sem "prova", mas porque em suas culturas profissionais, certas formas de argumentação têm mais peso, mais legitimidade.
E se você quer que mudanças realmente aconteçam, você precisa respeitar isso ao invés de lutar contra.
O Google poderia ter simplesmente mandado seus gestores fazerem workshops de inteligência emocional. Poderiam ter contratado consultores para falar sobre vulnerabilidade e confiança.
Nada disso teria funcionado.
O que funcionou foi dar às pessoas dados que validavam o que no fundo elas provavelmente já sabiam: que times onde as pessoas confiam umas nas outras performam melhor.
E ao fazer isso, o Google não só melhorou suas próprias equipes. Eles criaram um framework que outras empresas de tecnologia puderam usar. Eles legitimaram conversas sobre empatia e vulnerabilidade em um setor que tradicionalmente as via como fraqueza.
Isso é transformação cultural de verdade.
A transformação cultural que o Google provou ser possível
Existem coisas que não podem ser otimizadas.
Experiências emocionais, conversas difíceis e discussões sobre quem queremos ser, como nossos colegas nos fazem sentir.
Essas coisas resistem à otimização porque são inerentemente humanas.
E talvez o insight mais importante do Projeto Aristóteles não seja sobre o que eles descobriram sobre equipes, mas sobre o que eles descobriram sobre mudança cultural.
Às vezes, para fazer organizações prestarem atenção no que importa, você precisa dar a elas permissão para se importar.
E em culturas técnicas, essa permissão vem embrulhada em dados, em correlações estatísticas, em gráficos que mostram que empatia não é oposta à performance, ela é o que possibilita performance sustentável.
Pode chamar isso de manipulação, Pode chamar de comunicação efetiva ou pode chamar de tradução cultural.
O Google chama de finalmente prestar atenção na coisa certa.
