O Tech Lead como gestor do conhecimento

Imagine que o desenvolvedor mais experiente do time entre de férias. Na primeira semana, surge um problema em uma integração importante e ninguém sabe exatamente como ela funciona. A documentação está desatualizada, algumas decisões arquiteturais nunca foram registradas e os outros desenvolvedores evitam modificar determinados módulos porque desconhecem as consequências.

Depois de algumas tentativas, alguém sugere mandar uma mensagem para o colega que está de férias. Afinal, ele provavelmente resolveria o problema em poucos minutos.

Essa situação é mais comum do que deveria e revela uma fragilidade importante: quando o funcionamento de um sistema depende do conhecimento de uma única pessoa, temos um risco técnico e organizacional que precisa ser tratado.

Em equipes de engenharia, conhecimento não se resume a entender linguagens, frameworks ou ferramentas. Também envolve compreender regras de negócio, decisões arquiteturais, integrações, processos operacionais e, principalmente, os motivos pelos quais determinadas soluções foram escolhidas.

Parte desse conhecimento está no código, mas muita coisa permanece nas conversas, nas experiências individuais e na memória de quem participou da construção do sistema. Para um Tech Lead, ajudar a organizar e distribuir essas informações é tão importante quanto garantir a qualidade das implementações.

O problema não é ter especialistas, mas depender exclusivamente deles

Toda equipe possui profissionais com conhecimentos mais aprofundados em determinadas áreas. Alguém conhece melhor o banco de dados, outro domina a infraestrutura e existe aquela pessoa que entende uma integração legada que ninguém mais tem coragem de modificar.

Essa especialização é natural e pode ser bastante positiva. O problema aparece quando o conhecimento deixa de ser uma competência individual e passa a representar uma dependência obrigatória para o funcionamento do time.

Um conceito utilizado para avaliar esse risco é o bus factor, que representa, de maneira simplificada, quantas pessoas precisariam ficar indisponíveis para que determinado projeto ou atividade fosse seriamente comprometido.

Se apenas um desenvolvedor consegue realizar o deploy de uma aplicação, investigar um problema crítico ou modificar um módulo importante, temos um ponto único de falha. Não importa se essa pessoa é extremamente competente. A equipe continua vulnerável à sua ausência.

O objetivo não é fazer com que todos conheçam profundamente todas as partes do sistema. Isso seria pouco realista e provavelmente ineficiente. O que precisamos é garantir que o conhecimento essencial esteja acessível e que exista mais de uma pessoa capaz de executar atividades críticas.

Na prática, o primeiro passo pode ser bastante simples: identificar quais componentes, processos ou decisões dependem exclusivamente de alguém. Uma conversa com o time costuma revelar essas situações rapidamente.

Se a resposta para uma pergunta importante for sempre “só fulano sabe”, provavelmente encontramos um bom candidato para uma iniciativa de compartilhamento de conhecimento.

Documentar não significa escrever tudo

Quando falamos em gestão do conhecimento, a primeira solução que costuma aparecer é criar documentação. E, naturalmente, ela faz parte do processo. Mas existe uma diferença entre produzir documentos e construir uma base de conhecimento realmente útil. Uma documentação extensa, desatualizada e difícil de consultar pode acabar sendo tão pouco útil quanto a ausência completa de registros.

Imagine um projeto que possui dezenas de páginas descrevendo sua arquitetura, mas nenhuma delas explica como configurar o ambiente, executar os testes ou investigar os problemas mais frequentes. Talvez exista bastante conteúdo, mas ele não responde às perguntas que as pessoas realmente precisam fazer.

Por isso, antes de documentar, vale considerar quais informações são necessárias para desenvolver, operar e evoluir o sistema com segurança. Alguns registros costumam oferecer bastante valor:

• README e instruções de ambiente: como executar a aplicação, configurar dependências e rodar os testes.
• Visão arquitetural: principais componentes, responsabilidades e integrações.
• ADRs (Architecture Decision Records): decisões técnicas relevantes, alternativas consideradas e justificativas.
• Runbooks: procedimentos para investigar incidentes, executar operações e recuperar serviços.
• Regras de negócio importantes: comportamentos e restrições que não ficam evidentes apenas pela leitura do código.

Esses documentos não precisam ser longos. Um ADR, por exemplo, pode ocupar uma única página e ainda assim preservar informações fundamentais sobre uma decisão arquitetural. O mais importante é que a documentação seja fácil de encontrar, esteja próxima do trabalho e possa ser atualizada quando o sistema mudar.

Também precisamos evitar a ideia de que documentar é uma atividade realizada apenas depois que tudo está pronto. Quando uma decisão relevante é tomada ou um problema complexo é resolvido, aquele pode ser o melhor momento para registrar o aprendizado, enquanto o contexto ainda está disponível.

O código também precisa compartilhar conhecimento

Nem todo conhecimento precisa estar em documentos externos. Parte importante dele pode ser transmitida pela própria estrutura do software.

Nomes claros, responsabilidades bem definidas, testes automatizados e organização consistente ajudam outros desenvolvedores a compreender como o sistema funciona e quais comportamentos precisam ser preservados.

Imagine duas implementações que executam a mesma regra de negócio. A primeira possui métodos com nomes genéricos, condições difíceis de interpretar e dependências pouco evidentes. A segunda organiza as responsabilidades de maneira compreensível, utiliza nomes relacionados ao domínio e possui testes que demonstram os principais cenários.

Mesmo sem consultar documentação adicional, provavelmente será mais fácil compreender e modificar a segunda implementação. Isso não significa que código bem escrito elimina a necessidade de documentação. Existem decisões que não podem ser compreendidas apenas observando o resultado final. O código mostra como uma solução foi implementada, mas nem sempre explica por que determinada alternativa foi escolhida ou quais restrições influenciaram a decisão.

É justamente essa combinação que torna a gestão do conhecimento mais eficiente: utilizar o código para comunicar o funcionamento do sistema e registros complementares para preservar informações que não estão evidentes na implementação.

Compartilhar conhecimento precisa fazer parte do trabalho

Uma das maneiras mais eficientes de distribuir conhecimento é criar oportunidades para que diferentes pessoas participem de atividades que normalmente ficam concentradas em poucos profissionais.

Imagine que apenas um desenvolvedor conheça profundamente o processo de deploy. Podemos pedir que ele escreva um documento explicando cada etapa, mas também podemos convidar outra pessoa para acompanhar a execução, realizar o procedimento com supervisão e validar se as instruções realmente são suficientes. Essa segunda abordagem permite identificar informações que o especialista considera óbvias, mas que não estão claras para quem está aprendendo.

O mesmo princípio pode ser aplicado a outras atividades. Pair programming ajuda a compartilhar raciocínio durante a implementação. Code reviews permitem discutir decisões e conhecer partes diferentes do sistema. Investigações conjuntas de incidentes ajudam a distribuir conhecimento operacional, enquanto apresentações técnicas curtas podem compartilhar aprendizados relevantes sem exigir treinamentos extensos.

Também podemos trabalhar com uma rotação gradual de responsabilidades. Se sempre a mesma pessoa investiga problemas no banco de dados, talvez seja interessante envolver outros desenvolvedores nessas análises. Se apenas o Tech Lead participa das decisões arquiteturais, podemos criar oportunidades para que outros profissionais conduzam discussões e apresentem propostas.

O cuidado está em não transformar o compartilhamento de conhecimento em uma sobrecarga adicional. Essas atividades precisam fazer parte do planejamento, especialmente quando envolvem componentes críticos ou competências que exigem tempo para serem desenvolvidas.

Compartilhar conhecimento não é simplesmente pedir que alguém explique o que sabe. É criar condições para que outras pessoas consigam utilizar esse conhecimento com autonomia.

Decisões técnicas também precisam de memória

Uma situação bastante comum em sistemas que evoluem durante vários anos é encontrar uma implementação aparentemente estranha e não compreender por que ela foi construída daquela maneira.

Talvez exista uma integração com um serviço externo que utiliza um formato de dados incomum. Talvez determinada funcionalidade possua uma restrição que parece desnecessária. Ou talvez a equipe tenha escolhido uma arquitetura mais simples em vez de uma alternativa tecnicamente mais sofisticada. Sem conhecer o contexto, um novo desenvolvedor pode interpretar essas escolhas como erros e tentar corrigi-las.

O problema é que algumas decisões foram tomadas para atender a restrições que continuam existindo, mesmo que não estejam evidentes no código. Os ADRs ajudam a preservar esse histórico. Um registro simples pode apresentar o problema, as alternativas avaliadas, a decisão tomada e suas consequências. Assim, quando alguém questionar determinada escolha, será possível compreender os motivos que a justificaram.

Isso não significa que decisões antigas devam ser mantidas indefinidamente. Pelo contrário, conhecer o contexto original ajuda a identificar quando uma escolha deixou de fazer sentido.

Se uma arquitetura foi definida considerando um volume pequeno de usuários e o sistema agora atende uma demanda muito maior, talvez seja necessário reavaliá-la. Mas essa revisão será mais consistente quando conhecemos as condições que orientaram a decisão anterior. A memória técnica da equipe não deveria depender exclusivamente de quem estava presente na reunião em que tudo foi decidido.

Como começar sem criar mais burocracia

Gestão do conhecimento não precisa começar com a implantação de uma plataforma, a criação de dezenas de documentos ou um grande projeto de documentação.

Uma abordagem mais simples é identificar os riscos mais relevantes e trabalhar gradualmente para reduzi-los. Podemos começar com um pequeno diagnóstico:

A partir dessas respostas, podemos selecionar algumas ações de maior impacto.

Se o deploy depende exclusivamente de alguém, documentar e validar o procedimento com outra pessoa pode ser uma prioridade. Se novos integrantes levam semanas para configurar o ambiente, melhorar o README e automatizar etapas do setup pode trazer resultados imediatos. Se decisões arquiteturais são constantemente rediscutidas, começar a registrar ADRs pode reduzir o retrabalho.

Também vale definir uma responsabilidade simples: quando alguém resolver um problema recorrente ou descobrir uma informação importante, deve avaliar se aquele conhecimento precisa ser registrado ou compartilhado.

O objetivo não é exigir documentação para qualquer atividade, mas evitar que aprendizados relevantes desapareçam depois que a tarefa é concluída.

O conhecimento precisa continuar acessível quando as pessoas não estão

Um Tech Lead que conhece profundamente o sistema pode se tornar uma referência importante para a equipe. Mas, se todas as decisões precisam passar por ele, se apenas ele compreende determinados componentes e se sua ausência paralisa o trabalho, essa experiência também pode estar criando uma dependência perigosa.

Desenvolver autonomia exige compartilhar contexto, distribuir responsabilidades e permitir que outras pessoas participem das decisões. Isso não acontece apenas com documentação, nem apenas com treinamentos. É resultado de práticas incorporadas à rotina de engenharia.

Uma boa maneira de avaliar esse trabalho é observar o que acontece quando alguém experiente não está disponível. O time consegue investigar problemas? As informações necessárias são encontradas com facilidade? Outras pessoas conseguem realizar atividades críticas? As decisões anteriores podem ser compreendidas sem depender da memória de quem participou delas?

Se a resposta para essas perguntas for frequentemente negativa, provavelmente existe espaço para melhorar a maneira como o conhecimento circula pela equipe. No fim das contas, o papel do Tech Lead não é ser a pessoa que sabe tudo sobre o sistema, mas ajudar a construir um time que consiga compreender, manter e evoluir esse sistema sem depender exclusivamente de alguém.

Quanto mais conhecimento compartilhado, menor a dependência de indivíduos e maior a capacidade da equipe de tomar decisões, resolver problemas e continuar evoluindo.