Liderança

Entre Indicadores e a Realidade: métricas não mudam resultados, só comportamentos

Malba Tahan, em “O Homem que Calculava”, narra uma história que deveria ser leitura obrigatória em toda reunião de resultados corporativos. Três irmãos herdam trinta e cinco camelos de seu pai, com a seguinte determinação: o mais velho receberia metade, o do meio um terço, e o mais novo um nono. A disputa se instala imediatamente, pois nenhuma dessas divisões resulta em números inteiros. Metade de trinta e cinco é dezessete e meio. Um terço é onze vírgula sessenta e seis. Um nono é três vírgula oitenta e nove. Camelos não se dividem em frações.

Os irmãos tentaram resolver o problema da forma mais intuitiva: arredondando. O mais velho reivindicava dezoito, já que dezessete e meio deveria subir. O do meio queria doze, pelo mesmo raciocínio. O mais novo exigia quatro. Somados, trinta e quatro. Sobrava um camelo e ninguém cedia. A briga não era sobre ganância; era sobre a incapacidade de perceber que a conta original simplesmente não fechava. Eles estavam tentando resolver um problema que não tinha solução nos termos em que foi proposto.

Beremiz, o calculista, observa a disputa e oferece uma solução engenhosa. Empresta seu próprio camelo, totalizando trinta e seis. Distribui então dezoito ao primeiro, doze ao segundo e quatro ao terceiro. Os irmãos conferem: dezoito é mais que dezessete e meio, doze é mais que onze vírgula sessenta e seis, quatro é mais que três vírgula oitenta e nove. Todos ganharam mais do que a fração original prometia. Satisfeitos, agradecem e partem. Beremiz recupera os dois camelos restantes: o seu e mais um de lucro.

A elegância da solução esconde uma verdade incômoda: a conta original era impossível. Meio mais um terço mais um nono soma dezessete dezoito avos, não um inteiro. Faltava um dezoito avos para completar a herança. Os irmãos estavam brigando por algo que, matematicamente, não existia como proposto. Cada um achou que ganhou mais porque comparou com a fração impossível, não com o total real. Beremiz não os enganou; apenas foi o único que entendeu o que os números realmente diziam. A diferença entre ele e os irmãos não era moral. Era epistemológica.

Essa parábola atravessa séculos e chega intacta às salas de reunião contemporâneas. Quantas decisões são tomadas sobre frações que não somam um inteiro? Quantos indicadores são apresentados como verdades absolutas por quem não compreende sua natureza fragmentária? A ignorância matemática dos três irmãos não os tornava desonestos. Tornava-os vulneráveis. E vulnerabilidade, quando exposta ao medo de parecer incompetente, frequentemente se traveste de certeza.

A Verdade Que Mente Sem Mentir

Em 1988, a agência W/Brasil criou um comercial para a Folha de S.Paulo que se tornaria referência mundial em publicidade. O texto começava narrando os feitos de um líder político. Este homem, dizia o locutor, pegou uma nação destruída e recuperou sua economia. Devolveu o orgulho a seu povo. Reduziu a inflação de um milhão por cento para vinte e cinco por cento ao ano. Criou uma das maiores montadoras de automóveis do mundo. Construiu autoestradas que se tornariam modelo de engenharia. Reduziu o desemprego de seis milhões de pessoas para duzentas mil.

O espectador acompanhava a narrativa com admiração crescente. Que líder extraordinário. Que realizações impressionantes. Os números eram precisos, verificáveis, historicamente documentados. Nenhuma informação era falsa. A conclusão parecia inevitável: este homem merecia reconhecimento, talvez até reverência. A propaganda construía, fato após fato, a imagem de um estadista competente e visionário.

Então vinha a revelação. O líder era Adolf Hitler. E a conclusão do comercial era cortante: é possível contar um monte de mentiras dizendo só a verdade. Por isso é preciso tomar muito cuidado com a informação. O comercial, escrito por Nizan Guanaes sob direção de Washington Olivetto, ganhou o Leão de Ouro no Festival de Cannes e em 2000 foi eleito um dos cem melhores comerciais de todos os tempos.

Cada fato apresentado era verificável. Nenhum número foi inventado. A mentira residia no que não foi dito: o contexto, as consequências, o custo humano. Wittgenstein argumentava que a linguagem é uma imagem da realidade, mas toda imagem pressupõe um enquadramento. O que fica de fora do quadro não deixa de existir; apenas deixa de ser visto. E quem controla o enquadramento controla a narrativa.

Este fenômeno não requer maldade para prosperar. Basta medo. Basta insegurança. Basta a pressão de parecer competente em um ambiente que pune a imperfeição. Quando o erro é tratado como sentença e não como dado, as pessoas naturalmente começam a editar a realidade. Não porque sejam más, mas porque são humanas. E humanos sob ameaça tendem a proteger a própria imagem antes de proteger a verdade. O problema não está na pessoa; está no sistema que a treinou para temer a transparência.

A Transparência Que Revela

Há uma ironia que a experiência ensina e que a intuição frequentemente resiste: um KPI ruim é mais valioso que um KPI bom. O indicador positivo confirma o que já se sabe; o negativo revela o que ainda não se aprendeu. Um sistema que apresenta apenas métricas saudáveis é um sistema que esconde suas fragilidades, ou pior, que não sabe onde elas estão. A transparência verdadeira não é a exibição orgulhosa dos acertos; é a exposição corajosa dos erros.

Considere um cenário comum em equipes de desenvolvimento: o tempo médio de resposta de uma API está dentro do SLO estabelecido. Os dashboards estão verdes, os relatórios estão positivos, todos comemoram. Mas ninguém olhou o percentil noventa e nove. Ninguém percebeu que um em cada cem usuários espera quinze segundos por uma resposta. A média mascara o sofrimento da cauda. O KPI bom escondeu o problema real. Se houvesse um indicador vermelho, alguém teria investigado. Como estava verde, ninguém perguntou.

O mesmo acontece com métricas de disponibilidade que ignoram a degradação parcial. O sistema está tecnicamente no ar, então o SLI de uptime está verde. Mas metade das funcionalidades retorna erro. A métrica diz que está tudo bem; a experiência do usuário diz que não está. Esse descompasso entre o que medimos e o que importa é sintoma de métricas mal desenhadas, não de sistemas mal operados. O problema não é o time que monitora; é o indicador que não captura a realidade relevante.

Donald Knuth, um dos pais da ciência da computação, alertava que otimização prematura é a raiz de todo mal. Mas existe um mal ainda mais insidioso: a otimização da aparência. Quando a métrica se torna o objetivo em vez de ser o sintoma, o sistema começa a otimizar para parecer bem em vez de ser bem. É a Lei de Goodhart em ação: quando uma medida se torna meta, ela deixa de ser boa medida. A métrica fraca é um presente. Ela aponta exatamente onde o conhecimento falta, onde o processo falha, onde o comportamento precisa mudar. Tratar a métrica fraca como ameaça e tentar eliminá-la, em vez de eliminar o problema que ela revela, é confundir o termômetro com a febre.

O Método do Médico

Um médico não cura. Esta afirmação soa contraintuitiva, mas expressa uma verdade fundamental sobre sistemas complexos. O médico observa parâmetros, formula hipóteses, administra intervenções e monitora resultados. Ele não controla diretamente a cura; controla as condições que permitem ao corpo curar-se. A diferença é crucial. O médico trabalha com indicadores: temperatura, pressão, frequência cardíaca, resultados de exames. Ele usa conhecimento técnico para interpretar o que esses números significam e quais comportamentos do sistema precisam ser modificados.

Quando um paciente apresenta febre persistente, o médico não declara fracasso pessoal. Ele investiga. Testa hipóteses. Ajusta a medicação. Observa novamente. A febre que não cede não é evidência de incompetência médica; é informação diagnóstica. Ela diz que a intervenção atual não está funcionando e que outra abordagem é necessária. O médico competente não esconde a febre do prontuário para parecer competente. Ele a registra, analisa e usa como guia para a próxima decisão.

Sistemas de software operam sob a mesma lógica. Um SLI de latência elevada não é fracasso da equipe de engenharia; é informação sobre o estado do sistema. Mas aqui começam as nuances que a pressa frequentemente ignora. Às vezes o problema é o código. Às vezes é a infraestrutura subdimensionada. Às vezes é a arquitetura que foi projetada para um cenário diferente do atual. Muitos sistemas nascem como projetos para resolver uma tarefa específica e depois são forçados a se comportar como plataformas que precisam evoluir. A solução pontual vira sistema crítico sem ter sido desenhada para isso.

Essa dívida de concepção se manifesta nos indicadores. A latência sobe porque não foram previstos mecanismos de cache. A disponibilidade cai porque não há redundância. O tempo de recuperação é alto porque não existe automação de failover. Nenhum desses problemas é culpa do desenvolvedor que está de plantão quando o incidente acontece. São consequências de decisões tomadas antes, frequentemente sob pressão de prazo, quando alguém decidiu que mecanismos de resiliência poderiam esperar. A métrica ruim de hoje é o eco da decisão apressada de ontem.

A resposta madura é investigar: o problema está no código, na infraestrutura, na rede, no banco de dados, na arquitetura original? Quais comportamentos precisamos modificar? Que conhecimento está faltando? A resposta inadequada é esconder, justificar ou redefinir o indicador para que o problema desapareça do relatório enquanto continua existindo no sistema. O engenheiro que age assim é como o médico que apaga a febre do prontuário e declara o paciente curado.

As Métricas DORA e a Tentação do Atalho

O programa DORA, conduzido pelo Google Cloud, passou mais de uma década pesquisando o que diferencia times de alta performance em engenharia de software. O resultado são quatro métricas que se tornaram referência: frequência de deploy, lead time para mudanças, taxa de falha de mudanças e tempo de recuperação de serviço. As duas primeiras medem velocidade; as duas últimas medem estabilidade. Times de elite conseguem ser rápidos e estáveis simultaneamente. Não sacrificam uma pela outra.

A pesquisa mostra que times que se destacam nessas métricas têm duas vezes mais chance de atingir ou exceder os objetivos organizacionais. A tentação imediata é transformar as métricas DORA em metas. Se times de elite fazem deploy múltiplas vezes por dia, vamos exigir que nosso time faça deploy múltiplas vezes por dia. Se times de elite têm taxa de falha abaixo de quinze por cento, vamos estabelecer quinze por cento como meta. O problema é que isso inverte a causalidade.

Times de elite não são de elite porque têm boas métricas DORA. Eles têm boas métricas DORA porque desenvolveram práticas, conhecimentos e comportamentos que naturalmente produzem esses resultados. Deploys frequentes são consequência de pipelines automatizados, testes confiáveis, arquitetura desacoplada e cultura de pequenas mudanças incrementais. Exigir a métrica sem construir as condições é como exigir que alguém corra uma maratona sem treinar. A pessoa pode até tentar, mas o resultado será lesão, não performance.

Quando uma organização olha suas métricas DORA e descobre que está no nível baixo ou médio, a pergunta produtiva não é “como subimos esses números?”. É “que conhecimentos e comportamentos precisamos desenvolver para que esses números subam naturalmente?”. A diferença parece sutil, mas é fundamental. A primeira pergunta leva a atalhos: deploys forçados que aumentam a frequência mas também aumentam a taxa de falha, testes removidos para reduzir o lead time, incidentes subnotificados para melhorar o tempo de recuperação. A segunda pergunta leva a aprendizado: investimento em automação, capacitação em testes, refatoração de arquitetura, melhoria de observabilidade.

O relatório DORA de 2022 parou de identificar times “elite” porque a análise estatística mostrou apenas três clusters distintos. Mas a lição permanece: métricas são sintomas de capacidades. Melhorar o sintoma sem desenvolver a capacidade é cosmético. Desenvolver a capacidade melhora o sintoma como efeito colateral.

O Error Budget: Licença Para Aprender

O conceito de error budget, popularizado pelo time de Site Reliability Engineering do Google, representa uma das inversões mais elegantes do pensamento sobre confiabilidade. A lógica tradicional diz: maximize a disponibilidade, minimize os erros, busque a perfeição. A lógica do error budget diz: defina quanto erro é aceitável e use essa margem para inovar. Se o SLO estabelece noventa e nove vírgula nove por cento de disponibilidade, isso significa que existe zero vírgula um por cento de indisponibilidade permitida. E indisponibilidade permitida é sinônimo de espaço para experimentar.

O livro “Site Reliability Engineering”, publicado pelo Google em 2016, documenta essa filosofia com clareza. Os autores explicam que o error budget é a ferramenta que o SRE usa para equilibrar a confiabilidade do serviço com o ritmo de inovação. Mudanças são a maior fonte de instabilidade, representando aproximadamente setenta por cento das interrupções, e o trabalho de desenvolvimento para novas funcionalidades compete com o trabalho de desenvolvimento para estabilidade. O error budget remove a política dessas negociações. Se há orçamento disponível, pode-se lançar. Se o orçamento estourou, para-se e conserta. A métrica objetiva substitui a disputa subjetiva. Não é punição; é informação.

Essa abordagem transforma fundamentalmente a relação com a falha. Em um ambiente tradicional, qualquer erro é evidência de incompetência. Em um ambiente com error budget, o erro é custo de aprendizado, desde que esteja dentro do orçamento. John Boyd, estrategista militar cujas ideias influenciaram profundamente os métodos ágeis, argumentava que a vitória pertence a quem aprende mais rápido. O ciclo OODA, observar, orientar, decidir, agir, pressupõe que a velocidade de aprendizado supera a velocidade de execução. O error budget operacionaliza essa filosofia: falhe rápido, aprenda rápido, corrija rápido, dentro de limites acordados.

A implicação organizacional é profunda. Se o time tem error budget disponível e não está usando, pode estar sendo conservador demais. Pode estar deixando de experimentar, de inovar, de aprender. Disponibilidade excessiva não é virtude; é desperdício de oportunidade. Essa inversão de perspectiva só faz sentido em ambientes onde a falha não é punida. Se usar o error budget significa arriscar a carreira, ninguém vai usá-lo. O orçamento vai existir no papel e morrer na prática.

O Conflito das Metas Contraditórias

Um dos sintomas mais claros de disfunção organizacional é a proliferação de metas que se contradizem. Maximize a velocidade de entrega. Maximize a qualidade do código. Minimize o custo operacional. Maximize a satisfação do cliente. Cada uma dessas metas, isoladamente, parece razoável. Juntas, formam um sistema de incentivos impossível. O time que tenta atender todas simultaneamente acaba não atendendo nenhuma, ou pior, otimiza para aquela que será cobrada mais ruidosamente, independente de ser a mais importante.

Considere um exemplo concreto. Uma organização estabelece como meta reduzir o lead time de deploy de duas semanas para dois dias. Simultaneamente, estabelece como meta reduzir a taxa de incidentes em produção em cinquenta por cento. E ainda adiciona uma meta de reduzir o custo de infraestrutura em trinta por cento. Cada meta faz sentido individualmente. Mas como elas interagem?

Reduzir o lead time exige automação de testes e pipelines. Automação exige investimento inicial, que aumenta custo no curto prazo. Deploys mais frequentes significam mais mudanças em produção, que aumentam a probabilidade de incidentes, pelo menos até que a automação esteja madura. Reduzir custo de infraestrutura pode significar menos ambientes de teste, que reduz a capacidade de validar mudanças antes de produção. A meta de velocidade compete com a meta de estabilidade, que compete com a meta de custo. O time está em xeque.

A física ensina que sistemas com restrições contraditórias entram em estados de tensão. A engenharia de software não é diferente. Quando o KPI de velocidade compete com o KPI de qualidade, o desenvolvedor precisa escolher qual vai sacrificar. Se o ambiente pune a escolha errada mas não oferece critério para a escolha certa, o resultado é paralisia ou aleatoriedade. Estabelecer metas contraditórias sem explicitar as prioridades não é desafiar o time; é confundi-lo. E confusão não produz alta performance.

O problema se agrava quando as metas são definidas por pessoas que não entendem suas interdependências técnicas. Reduzir o tempo de deploy sem aumentar a automação de testes é receita para incidentes. Aumentar a cobertura de código sem critério de qualidade dos testes é receita para falsa segurança. Exigir zero downtime sem investir em redundância é receita para heroísmo insustentável. Cada métrica existe em relação com outras. Ignorar essas relações é como ajustar a pressão arterial sem considerar a frequência cardíaca: você pode matar o paciente tentando curar um sintoma.

A solução não é ter menos metas; é ter metas conscientes. Isso significa entender os trade-offs, explicitar as prioridades e aceitar que otimizar uma dimensão frequentemente significa desotimizar outra. Significa também revisar metas quando as condições mudam, em vez de mantê-las por inércia. Uma meta que fazia sentido no trimestre passado pode ser contraproducente hoje. A rigidez que parece disciplina é frequentemente apenas falta de atenção.

Parecer Bom Versus Ser Bom

Existe uma diferença fundamental entre parecer bom e ser bom que ambientes de medo sistematicamente obscurecem. Parecer bom é otimizar a apresentação. Ser bom é otimizar o sistema. Parecer bom é escolher o ângulo favorável da fotografia. Ser bom é melhorar o que a fotografia revela. Ser bom é também ser transparente com os problemas, admitir metas não atingidas, e trabalhar consistentemente no sistema para resultados de longo prazo. A distinção parece óbvia, mas a pressão por resultados de curto prazo a dissolve com notável eficiência.

Jeff Bezos construiu a Amazon sobre essa distinção. Em sua carta aos acionistas de 1997, ele declarou que decisões seriam tomadas com foco no longo prazo e na liderança de mercado, não na lucratividade de curto prazo ou nas reações de Wall Street. Em 2000, quando as ações da Amazon caíram oitenta por cento, ele não mudou a estratégia para parecer melhor no trimestre seguinte. Manteve o investimento em infraestrutura porque acreditava que quinze por cento do comércio eventualmente seria online, numa época em que era menos de um por cento. Em 2012, após o maior prejuízo da empresa em uma década, escreveu aos acionistas que no longo prazo os interesses dos clientes e dos acionistas se alinham. Quem quisesse retorno imediato deveria investir em outro lugar.

Considere agora a métrica de cobertura de testes. Um time sob pressão pode elevar a cobertura de sessenta para noventa por cento em uma sprint. Os dashboards ficam verdes, os relatórios impressionam, todos comemoram. Mas se esses testes foram escritos apenas para cobrir linhas, sem testar comportamentos relevantes, a cobertura subiu e a qualidade não. O sistema parece mais seguro e não está. A métrica melhorou e o produto não. Isso é parecer bom.

Ser bom seria diferente. Seria reconhecer que cobertura de testes não se adiciona à força, mas se cultiva através de práticas. Times que desenvolvem orientados a testes naturalmente produzem código testável e testes significativos. A cobertura é consequência, não objetivo. Forçar a métrica sem mudar a prática é como forçar a colheita sem preparar o solo.

Uma abordagem mais saudável que metas agressivas de cobertura é a regra do escoteiro aplicada ao código: deixe o acampamento mais limpo do que encontrou. Toda vez que um desenvolvedor toca em um trecho de código, adiciona uma camada de teste ao que modificou. Não é uma meta arbitrária de noventa por cento até o fim do trimestre. É uma prática incremental que melhora a base gradualmente, onde ela está sendo efetivamente trabalhada. O código mais tocado fica mais testado. O código esquecido permanece como está até ser tocado. A cobertura sobe como efeito colateral de um comportamento sustentável.

A armadilha se fecha quando o ambiente não distingue entre os dois. Se a métrica é o único critério de avaliação, otimizar a métrica é racional, mesmo que não otimize o sistema. A Lei de Goodhart não é uma curiosidade acadêmica; é uma força organizacional. Quando a cobertura de testes vira meta, a cobertura deixa de medir qualidade. Quando o número de deploys vira meta, o número deixa de medir velocidade. Quando qualquer indicador vira meta, ele captura a atenção e perde o significado.

A Tirania do Fracasso

Em ambientes onde o medo impera, não atingir uma meta significa fracasso pessoal. Não há espaço para perguntar por quê. Não há interesse em investigar o que faltou. A meta não atingida é evidência de incompetência, e incompetência é punida. Esse ciclo fecha-se rapidamente em um sistema onde ninguém admite dificuldade, ninguém pede ajuda, ninguém revela a métrica real. Todos parecem bem. Ninguém está bem.

O problema com essa abordagem é que ela confunde resultado com capacidade. Uma meta não atingida pode significar que o time é incapaz. Pode também significar que a meta era irreal, que as condições mudaram, que dependências falharam, que o conhecimento necessário não existia, que as ferramentas eram inadequadas, que o prazo era insuficiente. Cada uma dessas causas requer uma resposta diferente. Punir uniformemente todas elas como “fracasso” é como dar o mesmo remédio para todas as doenças: ocasionalmente funciona, geralmente não, e às vezes mata.

A alternativa é tratar a meta não atingida como dado, não como sentença. Perguntar: o que esse resultado revela sobre o sistema? Que conhecimento faltou? Que comportamento precisa mudar? Que condição externa interferiu? Que dependência falhou? Essas perguntas não absolvem ninguém de responsabilidade; elas direcionam a responsabilidade para onde ela pode produzir mudança. Culpar sem diagnosticar é satisfatório emocionalmente e inútil praticamente. Diagnosticar sem culpar é desconfortável emocionalmente e produtivo praticamente.

A diferença entre essas duas abordagens é a diferença entre organizações que aprendem e organizações que repetem. A organização que pune o fracasso ensina as pessoas a esconderem problemas. A organização que investiga o fracasso ensina as pessoas a revelarem problemas. E só se pode resolver o que se consegue ver.

A Diferença de Segundos

A alta performance mora em margens estreitas. A diferença entre o velocista medalhista e o eliminado nas semifinais é centésimos de segundo. A diferença entre o sistema que aguenta o pico de Black Friday e o que cai é milissegundos de latência. A diferença entre o deploy que passa e o que falha é uma linha de código. Essa proximidade entre sucesso e fracasso significa que melhorias incrementais exigem esforço exponencial.

Reduzir a latência de duzentos para cem milissegundos pode ser questão de cache bem implementado. Reduzir de cem para cinquenta exige repensar arquitetura. Reduzir de cinquenta para vinte e cinco pode requerer mudança de linguagem de programação, infraestrutura dedicada, algoritmos especializados. Cada ganho marginal custa mais que o anterior. Quem não entende essa dinâmica estabelece metas lineares para sistemas não-lineares, e depois busca culpados quando a realidade física não coopera.

Gene Amdahl formalizou isso na lei que leva seu nome: o ganho máximo de otimização é limitado pela fração não otimizável. Se noventa por cento do tempo é paralelizável e dez por cento não é, nenhuma quantidade de processadores reduzirá o tempo total abaixo daqueles dez por cento. A implicação para métricas é direta: existem limites físicos, matemáticos e arquiteturais para qualquer indicador. Metas que ignoram esses limites não são ambiciosas; são fantasiosas. E perseguir fantasia não é ambição; é desperdício de energia em algo que não pode existir.

Isso não significa que metas agressivas são ruins. Significa que metas agressivas precisam ser informadas pelos limites do sistema. Exigir latência de um milissegundo de uma arquitetura que faz dez chamadas de rede síncronas não é desafio; é impossibilidade. Exigir zero incidentes de um sistema que processa milhões de transações não é excelência; é negação da estatística. A meta ambiciosa e possível energiza. A meta ambiciosa e impossível desmotiva. Distinguir entre as duas exige conhecimento técnico que nem sempre está presente onde as metas são definidas.

O Conhecimento Que Falta

Aristóteles distinguia entre ignorância vencível e invencível. A primeira pode ser superada com estudo; a segunda é limitação intrínseca. O problema com métricas nas organizações raramente é ignorância invencível. É preguiça epistemológica disfarçada de pragmatismo. Ninguém nasce sabendo interpretar um gráfico de latência no percentil noventa e nove ou calcular o error budget de um trimestre. Mas qualquer pessoa pode aprender, desde que reconheça que não sabe.

O drama começa quando o reconhecimento da ignorância é punido. Quando admitir “não entendi esse indicador” significa ser visto como incompetente, as pessoas param de perguntar. Quando questionar a metodologia de um KPI é interpretado como insubordinação, as pessoas param de questionar. Deming, o pai do controle estatístico de qualidade, alertava que o medo é o maior inimigo da melhoria. Ele não falava de covardia individual; falava de ambientes que transformam a curiosidade em risco.

A consequência é previsível: pessoas que não entendem o que medem passam a medir o que entendem. Ou pior: passam a apresentar o que convém. Não por desonestidade congênita, mas por sobrevivência institucional. Um ambiente que exige certezas de quem deveria estar aprendendo cria um incentivo perverso para a simulação de competência. E simulação de competência é apenas outro nome para incompetência sustentada.

O Medo Que Corrompe

Existe uma diferença crucial entre agir de má-fé e agir sob coerção ambiental. A má-fé pressupõe intenção deliberada de enganar. A coerção ambiental produz o mesmo resultado através de incentivos distorcidos. Quando o ambiente pune a verdade inconveniente, a mentira conveniente se torna estratégia de sobrevivência. Não é preciso ser vilão para editar relatórios. Basta estar em um lugar onde relatórios honestos encerram carreiras.

Hannah Arendt cunhou o termo “banalidade do mal” para descrever como pessoas comuns podem perpetrar atos terríveis quando inseridas em sistemas que normalizam o inaceitável. Guardadas as devidas proporções, organizações que institucionalizam o medo produzem sua própria banalidade: a banalidade da mentira. Indicadores adulterados, contextos omitidos, narrativas construídas para proteger reputações. Nenhum desses atos nasce necessariamente de perversidade individual. Podem nascer de um sistema que tornou a verdade perigosa.

O mais difícil de identificar é que muitas pessoas sequer percebem o que estão fazendo. Convenceram-se de que otimizar a apresentação é parte do trabalho. Que destacar o positivo e minimizar o negativo é “comunicação estratégica”. Que omitir contexto é “ser objetivo”. A racionalização é tão completa que a distorção se traveste de profissionalismo. Kierkegaard observava que a forma mais perigosa de desespero é aquela em que a pessoa nem sabe que está desesperada. Analogamente, a forma mais perigosa de distorção organizacional é aquela em que nem quem distorce percebe que está distorcendo.

Ambientes Que Usam Falhas Para Crescer

A Toyota construiu um dos sistemas de produção mais admirados do mundo sobre um princípio contraintuitivo: não ter problemas é um problema. Se ninguém está relatando falhas, ou as pessoas não entendem o processo, ou não se sentem seguras para revelar a verdade. Os líderes da Toyota trabalham ativamente para criar segurança psicológica suficiente para que problemas e erros venham à tona. Só assim podem ser resolvidos.

Um exemplo concreto é a história da minivan. A primeira tentativa da Toyota no mercado americano, a Previa de 1991, fracassou. Entre outros problemas, tinha apenas dois porta-copos, insuficiente para o consumidor americano. Em vez de abandonar o segmento ou culpar a equipe, a Toyota investigou, aprendeu e ajustou. A segunda geração, a Sienna, veio com quatorze porta-copos. A empresa continuou iterando e, em 2019, ultrapassou a Honda como a minivan mais vendida nos Estados Unidos.

O mecanismo que sustenta esse comportamento é cultural, não processual. Qualquer funcionário na linha de produção da Toyota tem autoridade para parar a linha inteira se identificar um problema de qualidade. Isso seria impensável em ambientes onde parar a produção significa punição. Na Toyota, significa responsabilidade. O princípio, chamado jidoka, coloca qualidade acima de velocidade. E funciona porque o ambiente torna seguro exercê-lo.

Os números confirmam a cultura. Funcionários da Toyota geram mais de um milhão de ideias de melhoria de processo por ano. O dado mais impressionante é que noventa por cento dessas ideias são implementadas. Isso não acontece por acaso. Acontece porque a organização criou um ambiente onde sugerir melhoria não é arriscado, mas esperado. Onde revelar um problema é contribuição, não insubordinação.

A Coragem da Verdade Completa

No fim, métricas são apenas números. Não mentem nem dizem a verdade. Quem faz isso são as pessoas que as interpretam e apresentam. E essas pessoas estão inseridas em contextos que as moldam. Um ambiente que pune o erro produz pessoas que escondem erros. Um ambiente que premia a aparência produz pessoas que cuidam da aparência. Um ambiente que valoriza o aprendizado produz pessoas que aprendem.

Um time é uma unidade. Quando um desenvolvedor esquece de tratar um caso de borda e isso causa um incidente em produção, não foi o desenvolvedor que errou sozinho. O processo de code review deveria ter identificado. Os testes automatizados deveriam ter capturado. O ambiente de homologação deveria ter revelado. Cada camada de validação que falhou é tão responsável quanto o código original. E acima de todas essas camadas está a liderança que desenhou, ou deixou de desenhar, esse processo.

Peter Drucker dizia que a maior parte do que chamamos de gerenciamento consiste em dificultar o trabalho das pessoas. A frase é provocativa, mas carrega uma verdade. Quando o líder escolhe um bode expiatório, ele resolve o problema do dia e perpetua o problema do sistema. Quando ele investiga o processo, capacita o time, fortalece as camadas de validação, ele resolve o sistema e previne o problema de amanhã. Escolher o bode expiatório é fácil. Capacitar o time é o trabalho real da liderança.

Coragem e responsabilidade andam juntas. A coragem de mostrar o número feio precisa vir acompanhada da responsabilidade de fazer algo a respeito. Transparência sem ação é apenas confissão. Mas transparência com ação é fundação de confiança. Em um ambiente seguro, revelar um problema não é admitir fraqueza; é pedir apoio. E apoio só pode ser dado a quem pede. O time que esconde seus problemas fica sozinho com eles.

A responsabilidade também implica distinguir entre o que é treinável e o que não é. Falta de conhecimento técnico se resolve com capacitação. Falta de experiência se resolve com mentoria e prática. Falta de habilidade se resolve com tempo e exercício. Essas são deficiências treináveis. O que não é treinável é caráter: a disposição para aprender, a honestidade para admitir erro, a humildade para pedir ajuda. Quando alguém com conhecimento e capacidade escolhe distorcer, omitir ou manipular, o problema não é de treinamento. É de adequação.

A verdade completa exige mais que boa intenção. Exige ambiente seguro, conhecimento técnico, maturidade emocional e coragem. Coragem de admitir que não sabe. Coragem de mostrar o número feio. Coragem de perguntar o que precisa mudar. Bertrand Russell dizia que o problema do mundo é que os tolos são cheios de certezas e os inteligentes cheios de dúvidas. A maturidade organizacional começa quando a dúvida deixa de ser fraqueza e passa a ser método.

A Fotografia Que Importa

Os três irmãos da história de Malba Tahan não eram desonestos. Eram ignorantes. E sua ignorância os fazia lutar por algo que não existia nos termos em que foi proposto. Beremiz não os enganou; revelou que já estavam enganados. A diferença entre ele e os irmãos não era moral. Era epistemológica. Ele sabia ler os números. Eles só sabiam brigar por eles.

As organizações estão cheias de trinta e cinco camelos. Metas que somam mais de cem por cento do tempo disponível. KPIs que medem a mesma coisa de formas contraditórias. Indicadores que capturam o conveniente e ignoram o relevante. Verdades parciais apresentadas como retratos completos. E muitas pessoas de boa-fé, genuinamente tentando fazer o certo, perpetuando erros porque ninguém as ensinou a fazer a conta.

O ponto central não é que existem pessoas más manipulando números. É que números sem compreensão de sua natureza são perigosos. Uma métrica é uma abstração da realidade, não a realidade. Ela captura algumas dimensões e ignora outras. Ela reflete escolhas de quem a desenhou. Usá-la bem exige entender essas escolhas e suas implicações. Usá-la mal exige apenas copiá-la de um template e cobrar resultado.

Uma cultura de aprendizado contínuo usa métricas a seu favor. Não como tribunal que julga, mas como espelho que revela. A métrica ruim não é inimiga; é professora. Ela diz onde o conhecimento falta, onde o comportamento precisa mudar, onde o processo precisa evoluir. A transformação não acontece por decreto. Acontece quando as pessoas desenvolvem novos comportamentos, e novos comportamentos exigem energia: energia para aprender, para praticar, para errar, para corrigir, para tentar de novo.

A métrica poética cobra sua fatura. A fotografia adulterada revela seu filtro. A verdade incompleta encontra seu contexto. E quando isso acontece, e sempre acontece, não há apresentação em PowerPoint que salve. O que salva é ter aprendido antes. Ter perguntado antes. Ter encarado a foto feia e entendido que ela não estava ali para julgar, mas para ensinar.

A maturidade da verdade não é um destino; é uma prática. Diária, desconfortável e insubstituível. Como diria Popper, podemos não saber se estamos certos, mas sempre podemos descobrir se estamos errados. A única condição é querer saber.

Referências

Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.
Tahan, M. (1949). O Homem que Calculava. Record.
Deming, W. E. (1986). Out of the Crisis. MIT Press.
Popper, K. (1959). The Logic of Scientific Discovery. Routledge.
Arendt, H. (1963). Eichmann in Jerusalem: A Report on the Banality of Evil. Viking Press.
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer. McGraw-Hill.
Bezos, J. (1997-2020). Cartas aos Acionistas da Amazon. Amazon.
Google SRE. (n.d.). Error Budget Policy. https://sre.google/workbook/error-budget-policy/
DORA. (2022). State of DevOps Report. Google Cloud.