O melhor desenvolvedor do seu time pode ser o maior problema dele
Toda empresa tem aquele profissional. O cara que resolve qualquer problema. Que sabe de cor como funciona cada módulo do sistema. Que fica até tarde quando o deploy dá errado. O herói. O salvador. O indispensável.
Agora me responde: o que acontece quando essa pessoa tira férias? Ou pede demissão? Ou simplesmente fica doente por duas semanas?
Se a resposta é "o time para", você não tem um profissional excepcional. Tem um ponto único de falha disfarçado de talento.
O risco do conhecimento centralizado
Dados do relatório State of DevOps, publicado pelo DORA, mostram que times de alta performance se caracterizam por distribuição de conhecimento, não por concentração. Times onde o conhecimento é compartilhado entregam com frequência 46 vezes maior e recuperam-se de falhas 2.604 vezes mais rápido do que times com conhecimento centralizado.
A romantização do gênio técnico isolado é um dos maiores problemas da indústria de tecnologia. Crescemos ouvindo histórias de fundadores brilhantes que codavam sozinhos na garagem. Esses mitos criaram uma cultura que valoriza a genialidade individual acima da competência coletiva.
O problema é que software moderno não é construído por uma pessoa. É construído por times. E times que dependem de um indivíduo são times frágeis.
O bus factor igual a um
Bus factor é uma métrica informal que indica quantas pessoas do time precisariam sair para o projeto parar. Se o número é um, você tem um risco existencial. E esse risco geralmente está escondido atrás de métricas positivas. O "herói" entrega rápido, resolve bugs complexos e está sempre disponível. Os indicadores de curto prazo parecem ótimos. Mas a dependência está se aprofundando a cada sprint.
O impacto na cultura
Quando uma pessoa concentra conhecimento, as outras param de aprender. Por que investir tempo entendendo o módulo de pagamentos se o João resolve qualquer problema em 20 minutos? O time delega inconscientemente. O João aceita porque gosta de se sentir indispensável. E um ciclo vicioso se instala.
Pesquisa da Harvard Business Review sobre dinâmicas de time em empresas de tecnologia mostra que times com alta dependência de indivíduos específicos têm rotatividade maior entre os demais membros. As pessoas que não detêm o conhecimento crítico sentem-se desvalorizadas.
Práticas que distribuem conhecimento
Code review obrigatório. Todo código que vai para produção precisa ser revisado por pelo menos uma outra pessoa. Quem revisa aprende. Quem escreve recebe feedback. O código melhora.
Pair programming regular. Duas sessões de uma hora por semana já fazem diferença. Coloque o sênior com o pleno. Rotacione as duplas. Em três meses, o conhecimento que estava concentrado em uma pessoa está distribuído em quatro ou cinco.
Documentação de decisões técnicas. ADRs (Architecture Decision Records). Um parágrafo explicando o contexto, a decisão tomada e por quê. Quando alguém precisar entender por que o sistema funciona daquele jeito, a resposta está registrada, não na cabeça de uma pessoa.
Rotação de responsabilidades. Se a mesma pessoa sempre faz o deploy, sempre resolve os incidentes, sempre cuida do banco de dados, rotacione. Vai ser mais lento no início. Mas vai criar redundância que protege o time no longo prazo.
Não estou dizendo para punir competência. O profissional que se destaca deve ser reconhecido. Mas o reconhecimento não pode vir ao custo da fragilidade do time. O melhor sênior não é o que resolve tudo sozinho. É o que ensina os outros a resolverem.