O custo oculto do conhecimento tribal

O conhecimento tribal é o entendimento informal e não documentado de como as coisas funcionam, que existe apenas na cabeça das pessoas que estão presentes há tempo suficiente para adquiri-lo. Por que o sistema de faturamento lida com reembolsos da maneira que lida. Com quem falar sobre a API legada. O que aconteceu durante o incidente em março que moldou a configuração atual de alertas. Quais valores de configuração são estruturais e quais são seguros para alterar.

Em uma equipe pequena, o conhecimento tribal é eficiente. Todos se conhecem, o contexto é compartilhado por proximidade e conversas diárias, e a sobrecarga de uma documentação formal na verdade atrasaria mais as coisas do que ajudaria. A tribo é pequena o suficiente para que o conhecimento circule naturalmente.

O problema é que o conhecimento tribal não escala, e o ponto em que ele deixa de escalar geralmente chega antes que a equipe perceba.

A quebra de escala

A quebra normalmente acontece entre dez e vinte engenheiros. Abaixo de dez, a maioria dos engenheiros tem um modelo mental razoável de todo o sistema e sabe a quem perguntar sobre qualquer componente específico. Acima de vinte, o sistema cresceu além da compreensão de qualquer indivíduo, a equipe inclui pessoas que entraram recentemente a ponto de não terem o contexto histórico, e os engenheiros que detêm o conhecimento tribal ficam cada vez mais divididos entre seu próprio trabalho e o fardo crescente de responder a perguntas.

Os sintomas são reconhecíveis: reuniões que existem principalmente para compartilhar contexto em vez de tomar decisões. Threads do Slack onde metade da discussão serve para reconstruir o histórico antes que a pergunta real possa ser abordada. Integração de novos funcionários que leva meses porque o contratado precisa absorver o contexto por osmose em vez de leitura. Decisões que são rediscutidas porque ninguém se lembra (ou a equipe atual nunca soube) que a mesma questão foi discutida e resolvida seis meses atrás.

Cada um desses sintomas tem um custo, e os custos somam algo muito maior do que a maioria das equipes reconhece, porque cada caso individual parece menor.

Por que isso bloqueia o trabalho assíncrono

O conhecimento tribal é fundamentalmente incompatível com o trabalho assíncrono. Quando o contexto necessário para tomar uma decisão vive na cabeça de alguém, a decisão só pode acontecer quando essa pessoa estiver disponível para compartilhá-lo. Isso força tudo para canais síncronos: reuniões, conversas em tempo real no Slack, toques no ombro.

Em uma equipe distribuída ou híbrida, a incompatibilidade é ainda mais aguda. O engenheiro em um fuso horário diferente que precisa de contexto sobre o sistema de pagamentos tem que esperar até que o engenheiro que detém esse contexto esteja online. A decisão que poderia ter sido tomada de forma assíncrona a partir de um documento acaba bloqueada por um espaço na agenda.

Converter o conhecimento tribal em documentação pesquisável libera a tomada de decisões assíncrona porque o contexto fica disponível para qualquer pessoa, a qualquer momento, sem exigir a presença do detentor do conhecimento. Um engenheiro que pode ler o registro de decisões sobre por que o sistema de pagamentos está estruturado daquela forma não precisa agendar uma reunião para descobrir.

O problema da conversão

O desafio de converter o conhecimento tribal em documentação é que as pessoas que o detêm são tipicamente as mais ocupadas da equipe: os engenheiros seniores e os primeiros funcionários, cujo tempo é o mais valioso e o mais disputado. Pedir para que eles se sentem e escrevam tudo o que sabem é pedir que assumam uma tarefa grande e sem limites definidos, além do trabalho que já realizam.

A documentação autogravável resolve isso ao capturar o conhecimento tribal dos canais onde ele já está sendo compartilhado. Quando um engenheiro sênior explica uma decisão de design no Slack, essa explicação é capturada e estruturada. Quando uma reunião aborda a história por trás da arquitetura atual de um sistema, a discussão se torna parte da documentação. Quando uma descrição de PR explica por que uma abordagem específica foi escolhida, o raciocínio é preservado junto ao código.

O engenheiro sênior não escreve documentos. Ele faz seu trabalho normal, e a documentação surge a partir dele.

Perguntas frequentes

Como identificamos nosso conhecimento tribal? Procure por perguntas que são feitas repetidamente e só podem ser respondidas por pessoas específicas. Procure por threads no Slack onde as primeiras mensagens servem para estabelecer o contexto antes da pergunta real. Procure por reuniões que existem para compartilhar informações em vez de tomar decisões. Todos esses são sintomas de conhecimento que deveria ser documentado, mas não está.

Qual é o conhecimento tribal mais valioso para capturar primeiro? Decisões de arquitetura de sistema (por que as coisas são construídas da forma como são), histórico de incidentes (o que deu errado e o que foi alterado como resultado) e limites de integração (como diferentes serviços se comunicam e por quê). Estas são as áreas onde a falta de contexto causa os erros mais caros.

O conhecimento tribal pode ser totalmente eliminado? Não, e não deveria. Alguns conhecimentos são inerentemente contextuais e se desenvolvem por meio da experiência de maneiras que a documentação não consegue capturar totalmente. O objetivo é reduzir a proporção de conhecimento operacional crítico que existe apenas na cabeça das pessoas, não eliminar completamente a transferência informal de conhecimento.

Leitura recomendada: O fator ônibus, Dívida de documentação, Por que documentos de engenharia importam. Páginas relacionadas: Documentação autogravável, Retenção de conhecimento, Para equipes de engenharia.