Existe uma pergunta que todo CTO ou CEO deveria se fazer regularmente, mas que a maioria evita por desconforto: se o seu melhor engenheiro fosse atropelado por um ônibus amanhã, o que aconteceria com a sua operação? Não é uma pergunta morbida. É uma das mais importantes de gestão de risco em tecnologia que existe. Ela tem até nome: bus factor.

O conceito é simples na teoria e devastador na prática. O bus factor de um sistema ou organização é o número mínimo de pessoas que, se removidas subitamente, causariam falha crítica na operação. Bus factor 1 significa que uma única pessoa sabe como aquilo funciona. Se ela sair, adoecer, ou simplesmente pedir demissão na segunda-feira, você tem um problema sério nas mãos.

Em mais de 20 anos atuando em tecnologia, passando por IBM, AWS e atendendo empresas como BTG, B3, XP e Inter, posso afirmar com segurança: a dependência de pessoas-chave é um dos riscos mais subestimados e mais comuns no mercado brasileiro. E, ao contrário do que parece, não é um problema técnico. É um problema de gestão.

Por que o bus factor é tão alto na maioria das empresas

Antes de falar em solução, precisamos entender o diagnóstico. A dependência de pessoas-chave não surge por acidente — ela é, na maioria dos casos, ativamente construída pela cultura da organização.

O primeiro fator é o reconhecimento mal calibrado. Quando uma empresa recompensa o "herói" — aquele que resolve o incidente às 3h da manhã, aquele que é o único que sabe ligar o sistema legado — ela está, inconscientemente, incentivando o hoarding de conhecimento. A pessoa que sabe mais do que todo mundo se torna indispensável, e indispensabilidade vira poder. Por que ela iria ensinar?

O segundo fator é a pressão de entrega. Em ambientes onde o time está sempre correndo atrás do prazo, documentar, mentorar e fazer pair programming parecem luxos. O resultado é que o conhecimento fica concentrado em quem faz, e quem faz nunca tem tempo de transferir o que sabe.

O terceiro fator, mais sutil, é o crescimento rápido sem estrutura. Startups e empresas em expansão acelerada tendem a contratar rápido, mas raramente investem em onboarding profundo ou em criar redundância de conhecimento. A pessoa que construiu o sistema nos primeiros anos vira a única referência para tudo — e esse status cristaliza com o tempo.

O custo real da dependência: além do risco óbvio

A maioria dos gestores reconhece o risco quando a pessoa-chave pede demissão ou fica de licença. Mas o custo da dependência de pessoas-chave começa muito antes disso.

Primeiro, existe o custo de velocidade. Quando só uma pessoa sabe como determinado sistema funciona, qualquer demanda que envolve aquele sistema passa por ela. Isso cria gargalo. O time fica bloqueado esperando disponibilidade de alguém sobrecarregado, e a entrega desacelera. Em empresas de médio porte, não é raro ver times inteiros com capacidade reduzida porque uma ou duas pessoas concentram o conhecimento crítico.

Segundo, existe o custo de negociação. Pessoas que sabem que são insubstituíveis negociam de uma posição de força — e às vezes abusam disso. Salários inflados, recusa de certas tarefas, comportamentos difíceis de gerenciar. A empresa fica refém porque simplesmente não pode perder aquela pessoa naquele momento.

Terceiro, existe o custo de inovação. Sistemas e processos que dependem de uma única pessoa raramente evoluem. A modernização fica travada porque qualquer mudança passa pela disponibilidade e disposição daquela pessoa. Vi organizações no setor financeiro mantendo sistemas dos anos 90 parcialmente porque a única pessoa que entendia a arquitetura não tinha interesse — ou capacidade — de liderar a modernização.

Uma pesquisa da Gartner aponta que empresas com alto bus factor em áreas críticas levam, em média, 3 a 5 vezes mais tempo para recuperar operações após a saída inesperada de um colaborador técnico sênior. No Brasil, onde o mercado de tecnologia tem turnover médio superior a 20% ao ano, isso se traduz em risco operacional real e recorrente.

Como diagnosticar o bus factor da sua organização

Antes de agir, você precisa medir. Aqui estão as perguntas práticas que faço durante consultorias de gestão de risco em tecnologia para mapear o bus factor de uma organização:

  • Quais sistemas ou processos criariam incidente crítico se a pessoa responsável não estivesse disponível por duas semanas?
  • Quem são as pessoas que recebem mais mensagens diretas de emergência no time? Elas concentram conhecimento não documentado.
  • Quais áreas têm documentação técnica atualizada e quais dependem de "perguntar para fulano"?
  • Se você abrisse o repositório de código, quantos módulos críticos têm commits de apenas uma pessoa nos últimos 12 meses?
  • Qual foi o impacto da última vez que alguém de tecnologia ficou de férias por duas semanas sem contato?

Esse diagnóstico frequentemente revela situações que a liderança conhecia intuitivamente mas nunca havia quantificado. Um mapa de dependências — cruzando sistemas críticos com as pessoas que os conhecem profundamente — é o ponto de partida para qualquer plano de resiliência organizacional em tecnologia.

Estratégias práticas para reduzir o bus factor

A boa notícia é que bus factor é um problema solucionável. A má notícia é que não existe solução rápida. Requer consistência, cultura e estrutura. Estas são as abordagens que funcionam na prática:

1. Knowledge sharing estruturado, não voluntário

Esperar que as pessoas compartilhem conhecimento espontaneamente não funciona. O knowledge sharing precisa ser parte formal do processo de trabalho. Isso significa reservar tempo em sprint para documentação, criar rituais de transferência de conhecimento (como "tech talks" semanais onde alguém apresenta um sistema para o time), e tornar a capacidade de ensinar um critério explícito de avaliação de desempenho.

Uma empresa de fintechs que atendi no Brasil instituiu uma regra simples: nenhuma feature vai para produção sem que pelo menos dois engenheiros diferentes sejam capazes de explicar como ela funciona. O resultado foi uma redução significativa no bus factor dos sistemas críticos em menos de um ano.

2. Pair programming e code review como ferramenta de distribuição de conhecimento

Pair programming não é só uma prática de qualidade de código. É uma das formas mais eficientes de transferir conhecimento tácito — aquele que não está escrito em lugar nenhum. Code reviews bem conduzidos têm o mesmo efeito. Quando múltiplas pessoas revisam um código antes de mergear, o conhecimento sobre aquele sistema se distribui naturalmente.

O problema é que muitas empresas brasileiras tratam essas práticas como opcionais ou as abandonam sob pressão de prazo. A liderança precisa proteger esses rituais, especialmente quando o time está sob pressão — que é exatamente quando a tentação de cortar atalhos é maior.

3. Rotação deliberada de responsabilidades

Uma das estratégias mais poderosas — e menos usadas — é a rotação de ownership técnico. Periodicamente, a responsabilidade de manter determinado sistema passa de uma pessoa para outra. Isso força a transferência de conhecimento, expõe gaps de documentação, e distribui o contexto sobre sistemas críticos ao longo do time.

No contexto de sucessão técnica, isso também é fundamental. Quando uma posição sênior abre, a empresa não pode depender de contratar alguém de fora para cobrir um conhecimento que deveria existir internamente.

4. Documentação como produto, não como burocracia

Documentação ruim é quase tão perigosa quanto ausência de documentação — ela cria falsa sensação de segurança. A documentação técnica precisa ser tratada com o mesmo rigor que o código: versionada, revisada, atualizada e testada. Runbooks para incidentes, ADRs (Architecture Decision Records) para decisões de arquitetura, e wikis organizados por sistema são investimentos que pagam dividendos toda vez que uma pessoa nova precisa assumir um contexto.

5. Incentivos alinhados com distribuição de conhecimento

Se você avalia e promove engenheiros apenas pela entrega individual, você está incentivando a concentração de conhecimento. Os critérios de avaliação precisam incluir explicitamente: quantas pessoas esse engenheiro ajudou a crescer? Qual é a qualidade da documentação que ele produz? O time consegue operar bem quando ele está ausente?

Esse realinhamento de incentivos é talvez o mais poderoso de todos — e o que mais encontra resistência, porque muda a lógica de poder dentro do time técnico.

O papel da liderança na resiliência organizacional

Bus factor alto é quase sempre um sintoma de falha de liderança. Não necessariamente incompetência — mas omissão. A liderança que não endereça ativamente a dependência de pessoas-chave está gerenciando o problema de forma reativa: esperando a crise acontecer para agir.

CEOs e CTOs precisam entender que resiliência organizacional em tecnologia não é responsabilidade exclusiva do time de engenharia. É uma decisão estratégica que começa na forma como a empresa estrutura seus incentivos, seus processos e sua cultura de aprendizado.

Existe também uma dimensão humana que a liderança precisa considerar. A pessoa com bus factor 1 frequentemente está sobrecarregada, ansiosa e presa. Ela não pode tirar férias de verdade. Não consegue desconectar. Muitas vezes, é a primeira a pedir demissão quando encontra uma oportunidade em que não carregue esse peso. Reduzir o bus factor é bom para a empresa — mas também é bom para as pessoas.

Quando uma organização depende de indivíduos para sobreviver, ela não é resiliente. Ela é frágil com boa sorte. A diferença entre as duas só aparece quando a sorte acaba.

Por onde começar na prática

Se você chegou até aqui reconhecendo sua organização em algum dos cenários descritos, o próximo passo é concreto. Não tente resolver tudo de uma vez — priorize pelo risco.

Comece identificando os três sistemas ou processos com maior criticidade para o negócio e menor redundância de conhecimento. Para cada um, mapeie: quem sabe, o que não está documentado, e quem poderia aprender. Em seguida, crie um plano de 90 dias para elevar o bus factor desses três pontos de 1 para pelo menos 2.

Esse exercício simples — feito com honestidade — revela mais sobre a resiliência real da sua organização de tecnologia do que qualquer auditoria formal. E ele dá à liderança um ponto de partida tangível para agir antes que a crise force a mão.

Empresas que constroem sistemas resilientes não dependem de heróis. Elas constroem times onde qualquer pessoa pode assumir qualquer contexto, onde o conhecimento flui livremente, e onde a saída de uma única pessoa é uma perda — não uma catástrofe.

Essa é a diferença entre uma organização de tecnologia madura e uma que está, permanentemente, a um pedido de demissão de distância do caos.

Se você quer avaliar o bus factor da sua organização e construir um plano concreto de resiliência técnica, entre em contato. É exatamente o tipo de problema que endereço com CEOs, CTOs e fundadores — antes que ele vire emergência.