O erro de processamento havia afetado seiscentas e doze contas. O CEO sabia disso no final do primeiro dia. No final do segundo dia o CEO também sabia o seguinte: que o erro havia se originado numa atualização de rotina do sistema de faturamento, que a atualização havia sido testada de acordo com o protocolo acordado, que os testes não haviam detectado o erro porque a combinação específica de tipos de conta afetados não estava incluída nos casos de teste, e que os casos de teste haviam sido projetados pelo fornecedor usando documentação fornecida durante a fase de transferência de conhecimento. O CEO perguntou a Joel sobre os casos de teste. Joel trouxe o framework de teste original que a empresa havia usado antes da transição e o comparou com a versão do fornecedor. A diferença não era dramática. Era o tipo de diferença que só é visível para alguém que sabe por que o framework original foi construído da forma como foi construído, ou seja, alguém que estava presente para o incidente específico, dezoito meses antes da transição, que havia causado que o framework original incluísse a combinação específica de tipos de conta que a versão do fornecedor não incluía. "Este caso de teste existe em nosso framework original por causa de algo que aconteceu antes de você chegar," disse Joel. "Um erro de faturamento, menor do que este, que afetou um subconjunto de contas com uma combinação específica de configurações legadas. O incidente foi resolvido e depois o framework foi atualizado para incluir essa combinação de tipo de conta em todos os futuros testes do sistema de faturamento. A atualização estava documentada no próprio framework de teste. Mas a razão da atualização, o incidente que a produziu, não estava documentada. Era memória institucional." "E a equipe do fornecedor?" disse o CEO. "A equipe do fornecedor revisou a documentação durante a fase de transferência de conhecimento," disse Joel. "Viram os casos de teste. Não viram a razão para este específico. Quando construíram seu próprio framework fizeram um julgamento razoável sobre quais casos de teste incluir com base na documentação. Este não entrou em sua versão porque sem o contexto parecia um caso extremo em vez de uma lição aprendida." "Isso está documentado em algum lugar?" disse o CEO. "Nos arquivos de Sandra," disse Joel. "Ela mantinha registros de incidentes desde o início. Detalhados. Foram incluídos nos materiais de transferência de conhecimento." "E a equipe de Diane?" disse o CEO. "Os recebeu," disse Joel. "Os revisou. Não tinha Sandra para explicá-los. E não sabia o que perguntar." "Porque não sabiam o que não sabiam," disse o CEO. "Correto," disse Joel.

Esta é a forma específica como o conhecimento deixa uma organização. Não pela saída dramática. Não pela carta de demissão ou pela festa de aposentadoria ou pelo anúncio de reestruturação. Pela acumulação silenciosa de contexto não documentado que existe apenas na compreensão das pessoas que estavam presentes quando o contexto foi criado, e que desaparece, de forma incremental e invisível, toda vez que uma dessas pessoas sai sem transmiti-lo. Os cadernos verdes haviam sido a tentativa de Maya de desacelerar esse processo. De tornar visível o invisível. De criar um registro não apenas do que era o conhecimento mas de por que existia e o que o havia produzido e o que aconteceria se não fosse aplicado. Maya havia entendido, instintivamente, que conhecimento sem contexto é informação, e informação sem contexto é dado, e dado sem contexto é ruído, e que a diferença entre uma organização que aprende com sua experiência e uma organização que continua repetindo os mesmos erros é quase inteiramente determinada por quanto do contexto sobrevive às transições. Os cadernos verdes haviam sobrevivido à transição. Estavam num armário na área de suporte. O que não havia sobrevivido era Maya. Do lado do fornecedor, Gil havia identificado a lacuna no caso de teste três semanas antes de o erro de processamento ocorrer. Não a havia identificado especificamente como uma lacuna no caso de teste. A havia identificado como um padrão nas ligações que sua equipe estava recebendo, um subconjunto de tipos de conta que estavam produzindo vias de resolução incomuns que o roteiro não cobria completamente e que seus agentes estavam tratando através da improvisação em vez de através do processo definido. Havia levantado isso com seu gerente. Seu gerente havia dito que era uma questão para a equipe operacional do cliente. Gil escreveu em suas próprias notas. Escrevia coisas num pequeno caderno marrom com páginas quadriculadas que guardava na gaveta esquerda de sua mesa. O atual era o nono. Escreveu: combinação de tipo de conta, interação de configurações legadas, via de resolução pouco clara, risco potencial de erro. Sublinhou risco potencial de erro e desenhou uma pequena seta apontando para a margem esquerda, onde escreveu: escalar. Escalou. A escalada foi para Jonathan. Jonathan a encaminhou para o contato de conta do cliente. O contato de conta a registrou como uma consulta de processo. A consulta de processo ficou na fila. Três semanas depois, o erro de processamento ocorreu. Gil leu o relatório do incidente e encontrou a combinação de tipo de conta no terceiro parágrafo. Havia escalado. A escalada havia sido processada corretamente e ficado na fila. A fila não havia sido revisada antes de a atualização ser enviada. A atualização havia produzido o erro. Havia feito tudo o que a estrutura lhe permitia fazer. A estrutura não havia sido construída para detectar o que ele havia visto.

O CEO ligou para Maya. Não para pedir que voltasse. Ainda não. Para fazer uma pergunta. "O erro de processamento," disse o CEO. "A atualização do sistema de faturamento. Os casos de teste." "Fiquei sabendo," disse Maya. "Dom me mandou uma mensagem." "Joel identificou a lacuna. O framework do fornecedor estava faltando um caso de teste que existia no nosso por causa de um incidente de dezoito meses atrás. O incidente estava nos arquivos de Sandra. O contexto não." "Sei a qual incidente você está se referindo," disse Maya. "Achei que saberia," disse o CEO. "Foi antes do meu tempo aqui mas Sandra me contou sobre ele quando eu estava construindo a base de conhecimento," disse Maya. "Adicionei uma entrada. Pensei ter deixado o contexto claro mas é possível que o tenha deixado claro para alguém que já conhecia a história e não claro para alguém que estava lendo sem esse histórico." "Você pode olhar a entrada e me dizer o que pensa?" disse o CEO. "Sim. Me dê um dia," disse Maya. Ligou de volta na manhã seguinte. "A entrada descreve o incidente e a lição," disse Maya. "Não descreve por que a lição importa. Alguém lendo-a sem contexto entenderia o que aconteceu e o que foi mudado. Não necessariamente entenderia que o mesmo tipo de falha ocorreria novamente se a mudança não fosse mantida em futuros frameworks de teste. Escrevi para alguém que entendia o sistema. Não para alguém aprendendo o sistema do zero." "Isso é um problema comum com a documentação?" disse o CEO. Maya ficou quieta por um momento. "Sim," disse Maya. "Não porque a documentação é ruim. Porque a documentação é sempre escrita por alguém que já entende a coisa sendo documentada, para alguém que imagina que também entende. A lacuna entre esse leitor imaginado e o leitor real é onde o contexto vive e onde se perde." "Você estaria disposta a fazer isso?" disse o CEO. "Você quer dizer revisar toda a base de conhecimento em busca de lacunas de contexto?" disse Maya. "Sim," disse o CEO. "Isso levaria meses," disse Maya. "Eu sei," disse o CEO. "E a equipe do fornecedor precisaria estar envolvida," disse Maya. "Não faz sentido identificar as lacunas se as pessoas que precisam preenchê-las não fazem parte do processo." "Posso perguntar para onde isso está levando?" disse Maya. "Ainda não estou pronto para responder essa pergunta," disse o CEO. "Mas gostaria de saber que você estaria disposta a fazer parte do que quer que leve." Maya ficou quieta novamente. Por mais tempo desta vez. "Eu gostaria de saber mais antes de me comprometer com qualquer coisa," disse Maya. "É justo," disse o CEO. "Mas sim," disse Maya. "Em princípio. Se levar para algo que acho que vale a pena." "Obrigado Maya," disse o CEO. "Posso perguntar mais uma coisa?" disse Maya. "Sim," disse o CEO. "Você está pensando na base de conhecimento especificamente ou está pensando em tudo?" disse Maya. "Em tudo," disse o CEO. "Bom," disse Maya. Nora estava em tratamento há três meses. Ainda estava vindo. Não todos os dias. Três dias por semana nas semanas em que o tratamento permitia, dois dias nas semanas em que não permitia, e uma vez, no segundo mês, nada por uma semana inteira quando os efeitos colaterais haviam produzido um cansaço que estava além do que a palavra cansaço geralmente descreve. A empresa havia se ajustado ao redor dela sem ser solicitada. Owen havia sido o primeiro a organizar isso. Não como um arranjo formal. Como uma conversa que teve com três pessoas em reuniões breves separadas numa manhã de terça-feira. Não disse a ninguém acima dele que havia feito isso. Não lhe ocorreu reportar. Era uma coisa que precisava ser feita e ele a havia feito. O CEO ficou sabendo por Nora. "Owen organizou," disse Nora. "Não transformou em projeto. Simplesmente fez acontecer." O CEO pensou nisso. Depois foi a Owen. "Soube do que você fez por Nora," disse o CEO. Owen olhou para cima. "É simplesmente o que se faz," disse Owen. O CEO ficou lá por um momento. "É exatamente o que Priya disse," disse o CEO. "O quê?" perguntou Owen. "Nada," disse o CEO. "Obrigado Owen." O CEO pensou: quantas vezes ele fez esse tipo de coisa que ninguém acima dele sabe.

O conhecimento que partiu não estava apenas na documentação. Isso era o que o CEO estava começando a entender nas semanas após o erro de processamento, sentando com o problema da forma como o CEO havia aprendido, cedo numa carreira que havia incluído muitos problemas que pareciam simples e não eram, a sentar com os problemas antes de decidir o que fazer com eles. A documentação era a parte visível. Os cadernos verdes. Os registros de incidentes. Os frameworks de teste. Os artigos de conhecimento do produto. A parte invisível era mais difícil. A parte invisível era o conhecimento que nunca havia estado em nenhum documento. O conhecimento de Priya sobre quando ficar numa ligação e quando um cliente precisava de algo além do que o roteiro podia oferecer. O conhecimento de Sandra sobre quais agentes estavam prontos para mais responsabilidade. O conhecimento de Maya sobre por que a base de conhecimento estava organizada da forma como estava. O conhecimento de Owen sobre quando uma equipe precisava ser organizada antes de a necessidade ser visível em qualquer relatório. Nada disso havia estado em nenhum documento. Tudo havia partido, ou estava partindo, ou estava presente e invisível, que era seu próprio tipo de perda. O CEO pensou na teoria de Joel sobre dois tipos de distância. A parte na documentação que você podia ver, identificar e abordar. A parte que havia vivido em Priya e Sandra e Maya você não podia ver, não conseguia identificar completamente e não conseguia abordar completamente, não de onde a empresa estava agora. Só podia reconstruí-la. E reconstruí-la exigia as condições que a haviam produzido em primeiro lugar. A sala. A proximidade. A experiência acumulada de pessoas que estavam presentes para as coisas que produziam o conhecimento e que ficavam tempo suficiente para passá-lo adiante para as pessoas que vinham depois delas. O CEO sentou com essa compreensão por vários dias. Sem agir sobre ela. Ainda não. Depois de vários dias a compreensão estava suficientemente clara. O CEO convocou uma reunião com Joel. Não uma reunião formal. Uma conversa na sala de reuniões com a lousa e as quatro cadeiras. "Quero conversar sobre o que voltar realmente significaria," disse o CEO. "Em termos de?" disse Joel. "Em termos do que exigiria," disse o CEO. "O conselho. O contrato. O cronograma. As pessoas." "Você tomou a decisão," disse Joel. "Estou tomando agora," disse o CEO. "Enquanto conversamos. Quero entender o que exige antes de terminar de tomá-la." "Exige encerrar o contrato com o fornecedor," disse Joel. "Haverá penalidades. Posso olhar para as cláusulas de saída mas devemos assumir que é caro." "Eu sei," disse o CEO. "Exige reconstruir a função de suporte internamente," disse Joel. "Isso significa contratar. Treinar. Reconstruir a base de conhecimento a um estado onde possa realmente apoiar a equipe. Isso leva tempo. Provavelmente um ano para chegar a um estado funcional. Dois anos para chegar onde estávamos antes." "Dois anos," disse o CEO. "No mínimo," disse Joel. "E as pessoas?" disse o CEO. "Essa é a pergunta mais difícil," disse Joel. "Algumas delas voltarão," disse Joel. "Não todas. Maya pode. Sandra pode. As outras, as que aceitaram a indenização ou as posições com o fornecedor, algumas terão seguido em frente de formas que são reais e não podem ser facilmente revertidas. E Priya." "Priya," disse o CEO. "Priya está numa pequena empresa fazendo exatamente o que deve estar fazendo," disse Joel. "Não sei se voltaria." "Gostaria de perguntar a ela," disse o CEO. "Achei que diria isso," disse Joel. "O que mais?" disse o CEO. "O conselho," disse Joel. "Marcus vai querer entender o caso financeiro. As penalidades por sair do contrato com o fornecedor mais o custo de reconstruir internamente mais o período de transição onde você está rodando duas operações simultaneamente ou rodando uma operação abaixo do padrão anterior. Esse é um número significativo." "Eu sei," disse o CEO. "Você vai precisar de um número diferente para colocar contra ele," disse Joel. "Elena," disse o CEO. "O erro de processamento. A tendência de churn. As seiscentas e doze contas. A distância entre três vírgula seis e quatro vírgula dois numa escala de cinco pontos e o que essa distância custa em valor de vida do cliente ao longo de três anos." "Esse é o caso," disse Joel. "Você consegue construí-lo?" disse o CEO. "Sim," disse Joel. "Levará duas semanas para fazer direito." "Faça direito," disse o CEO. "E enquanto eu o construo?" disse Joel. "Vou ligar para algumas pessoas," disse o CEO.

Fim do Capítulo 10

Pensamento do autor:

Você está pensando na base de conhecimento especificamente ou está pensando em tudo disse Maya. Em tudo disse o CEO. Fiquei satisfeito que alguém finalmente perguntou.

Aqui Está O Que Está Quebrado. O CEO. O Conhecimento Que Partiu.

MarvinPro | Março 2026

marvinpro.com

Pense Simples.