A decisão foi tomada numa thread. Aí ela sumiu.

Duas pessoas discutem por nove mensagens numa thread de chat. Alguém propõe um número. Alguém rebate. Uma terceira pessoa diz “beleza, vamos fazer isso” com um joinha. A decisão está tomada. Dinheiro real ou uma promessa real agora pende dela. Aí a thread rola, o canal segue em frente, e uma semana depois o spec ainda diz o número antigo, porque ninguém voltou para mudar.

Agora a empresa tem duas respostas para a mesma pergunta. O doc diz uma coisa. A thread, se você conseguir achá-la, diz outra. E a pessoa que tem que agir sobre a decisão escolhe qualquer uma que por acaso tenha visto.

Uma decisão é tomada onde a conversa acontece, e registrada, se é que é, em outro lugar. Esse gap é onde empresas esquecem o que já decidiram.

A decisão e o registro vivem em dois lugares diferentes

Aqui está a coisa que ninguém projetou de propósito mas toda empresa roda mesmo assim.

Decisões são tomadas em conversa. São tomadas numa thread de chat às 16h, nos últimos cinco minutos de uma call, numa resposta a uma resposta que três pessoas viram. Isso não é uma falha de disciplina, é só onde humanos decidem coisas. O discutir, o trade-off, o momento em que alguém diz “ok, faz”, tudo isso é verbal e rápido e vive num fluxo de mensagens.

Registros vivem em outro lugar inteiramente. O spec, o doc, o board do projeto, a página de wiki. Lento, estruturado, deliberado. Construído para ser lido depois por alguém que não estava lá.

Os dois são conectados por exatamente uma coisa: um humano lembrando de andar a decisão do lugar onde ela foi tomada para o lugar onde ela deveria ser guardada. E esse andar é o passo mais pulado em qualquer empresa, porque no momento em que a decisão é tomada, ela não parece por fazer. Ela parece terminada. Todo mundo na thread concorda. Por que você pararia o momentum para ir atualizar um documento?

Então você não atualiza. E o registro silenciosamente fica obsoleto no instante em que a decisão é tomada.

A correção ingênua: escrever docs melhores. Ela falha do mesmo jeito.

A resposta óbvia é disciplina. Escreva um log de decisões. Faça as pessoas atualizarem o doc. Adicione um passo ao processo: toda decisão é registrada.

Ela falha por uma razão que não tem nada a ver com quão boas suas pessoas são. O passo de registrar acontece depois da decisão e em outro lugar que não onde a decisão foi tomada. Você está pedindo a um humano cansado, na ferramenta errada, para re-derivar o que acabou de ser acordado e transcrevê-lo num lugar estruturado. Isso é um segundo trabalho, feito no pior momento, sem recompensa imediata. A decisão já parece feita. A transcrição é puro imposto.

E mesmo quando alguém o faz, o link sumiu. O doc agora diz “decidimos X.” Ele não diz quem decidiu, quando, por quê, ou o que rejeitamos. Seis semanas depois alguém lê “decidimos X,” discorda, e não tem como saber se X foi um trade-off cuidadoso ou um erro de digitação. Então eles relitigam. A decisão é tomada uma segunda vez, possivelmente diferente, e agora você tem três registros que discordam.

A correção ingênua trata o esquecer como um problema de força de vontade. Não é. É um problema de localização. O registro está no lugar errado para ser confiável.

Uma decisão registrada em outro lugar que não onde foi tomada é uma decisão esperando para ser esquecida.

A correção não é tentar mais no andar. É deletar o andar.

Capture a decisão onde ela é tomada, não onde ela é arquivada

A ideia-chave é simples. Se decisões são tomadas em conversa, então conversa é onde elas têm que ser capturadas. Não transcritas depois. Capturadas ali, conforme acontece, por algo que esteve na sala o tempo todo.

Vale explicar por que isso muda o problema completamente.

Um company brain, um sistema que lê a conversa conforme ela flui, não precisa de um humano para andar nada para lugar nenhum, porque ele nunca saiu da sala. Quando a thread chega a “ok, vamos fazer isso,” o brain já tem as nove mensagens de contexto que a produziram. Ele viu o número proposto, o rebate, o trade-off, o momento do acordo. Ele pode capturar tudo isso como um único fato estruturado: isto foi decidido, nesta data, nesta thread, com esta razão, e aqui está a opção que rejeitamos.

A decisão e seu registro se tornam o mesmo evento em vez de dois eventos com uma ponte humana frágil entre eles.

Agora compare os modos de falha. O doc ingênuo diz “decidimos X” sem proveniência, então é relitigado. A decisão capturada diz “decidimos X na terça, por causa de Y, tendo considerado e rejeitado Z, aqui está a thread.” Quando alguém quer reabri-la, não está discutindo no escuro. Está discutindo com o raciocínio de fato, na frente, com a alternativa rejeitada já nomeada. Metade da relitigação nunca acontece, porque a resposta para “espera, por que fizemos isso?” já está anexada à decisão.

Esse é o movimento inteiro. Pare de pedir a humanos para copiar decisões num sistema de registro. Faça o sistema de registro estar presente no momento da decisão.

A contradição é o alarme, não o constrangimento

Há uma segunda falha que a abordagem ingênua nem consegue ver: a própria contradição.

Quando a thread diz uma coisa e o doc diz outra, ninguém percebe até morder. Alguém age sobre o doc. Outra pessoa age sobre a thread. Os dois colidem a jusante, um número errado é enviado, uma promessa é feita que o time já tinha voltado atrás, duas pessoas aparecem com dois planos diferentes. A contradição existiu por semanas. Ela só viveu em lugar nenhum que pudesse vê-la.

A correção ingênua não consegue pegar isso porque os dois registros não sabem um do outro. O doc não faz ideia de que uma thread discorda dele. A thread rolou para longe e esqueceu que algum dia disse alguma coisa.

Um brain que capturou ambos consegue. No momento em que uma nova decisão numa thread contradiz uma registrada, isso não é uma inconsistência constrangedora a ser silenciosamente enterrada, é um sinal que vale revelar. Atenção: esta thread acabou de decidir algo que contradiz o que o spec diz. Um desses está obsoleto. Qual vence? A contradição se torna uma pergunta que você consegue responder de propósito, na terça, em vez de uma colisão que você descobre na sexta quando já foi enviada.

Essa é a parte que as pessoas subestimam. O valor não é só que decisões são registradas. É que desacordos entre registros são pegos, porque pela primeira vez, os registros vivem num lugar só que pode compará-los.

O que você ganha quando decisões param de evaporar

Junte as peças e o formato fica claro.

Decisões são capturadas onde são tomadas, não andadas à mão para um doc que fica obsoleto. Cada uma carrega sua razão e sua alternativa rejeitada, então sobrevive à pergunta “por que fizemos isso?” sem ser relitigada do zero. E quando dois registros discordam, o desacordo surge como uma pergunta cedo em vez de uma colisão tarde.

Nada disso requer que alguém seja mais disciplinado. Requer que o sistema de registro pare de ser um lugar separado que você tem que lembrar de visitar, e comece a estar presente na conversa onde o decidir de fato acontece. A disciplina se move para fora do humano e para dentro da estrutura, que é o único lugar onde disciplina sobrevive a uma semana corrida.

A virada: uma empresa que não consegue esquecer o que decidiu

Aqui está a parte que não é sobre software.

O custo de uma decisão esquecida raramente é a decisão em si. É a segunda reunião para tomá-la de novo. É o novo contratado que lê o doc obsoleto e constrói a coisa errada de boa fé. É o founder que tem que ser o índice humano de toda escolha que a empresa já fez, porque as escolhas vivem em uma centena de threads que só ele lembra de ter estado. A memória de uma empresa sobre as próprias decisões acaba armazenada nas poucas pessoas que estiveram presentes para elas, e no dia em que uma dessas pessoas está ocupada, ou de férias, ou foi embora, essa memória vai com ela.

Esse é o imposto real. Não os minutos gastos atualizando um doc. A erosão lenta onde uma empresa continua re-decidindo coisas que já resolveu, porque não tem jeito confiável de saber o que resolveu ou por quê. Cada re-decisão é horas que poderiam ter ido para as decisões que você ainda não tomou, as que só um humano deveria tomar.

Uma empresa que lembra o que decidiu, e por quê, e o que recusou, consegue gastar seu julgamento em novas perguntas em vez de antigas. Essa é a diferença entre um time que compõe e um time que continua pagando o mesmo imposto terça após terça.

---

É isso que estamos construindo na Apollo, não um lugar melhor para arquivar decisões depois do fato, mas um company brain que está presente onde o decidir acontece, para que o registro e a decisão sejam uma coisa só em vez de duas. Se você já achou uma thread que contradiz o seu próprio spec e não conseguiu lembrar qual estava certa, você já sabe em qual a sua empresa esteve confiando: qualquer uma que você por acaso viu primeiro.