A contratação de um jogador formado na base para substituir uma estrela que acabou de sair — como no caso Savinho/Tottenham reportado pelo Abril.com.br — é um espelho fiel do que acontece em engenharia de software todos os dias. Perde-se um dev sênior, e a solução imediata da maioria das empresas é buscar alguém “pronto” no mercado, em vez de olhar para o próprio time. Na minha experiência liderando squads, isso é um erro estratégico clássico que custa caro no médio prazo.
O que o futebol ensina sobre pipeline de talentos em tech
Clubes como o Palmeiras mantêm categorias de base justamente para não dependerem do mercado toda vez que perdem um titular. Savinho foi negociado, e a resposta veio de dentro do clube. Segundo o Abril.com.br, o atacante se formou na base alviverde e foi promovido após a saída do camisa 10. Não foi um achado no mercado — foi um investimento de anos que finalmente deu retorno.
Por que isso importa para devs?
Porque devs seniores não nascem prontos. E o “mercado”, na maioria das vezes, só entrega gente que sabe resolver entrevistas, não gente que sabe resolver incidentes de produção às 3h da manhã. Times que não cultivam base dependem de uma janela de transferências permanente — e aí o ambiente da sua empresa vira hostil para qualquer um que tente crescer de verdade.
Academia de engenharia: como montar uma base de devs de verdade
Na minha experiência, três pilares sustentam um programa interno que realmente forma gente:
- Code review como currículo vivo: cada PR revisado por alguém mais experiente é uma aula particular de arquitetura, legibilidade e trade-offs.
- Pair programming semanal: junte um junior com um pleno, não com um sênior sobrecarregado que vai fazer a tarefa sozinho.
- Ownership progressivo: ninguém vira sênior lendo documentação — vira tocando feature em produção com suporte real.
Times que ignoram esses três pilares estão replicando o modelo “Faria Lima” do título da matéria: contratam caro, trocam rápido, e nunca formam ninguém.
Na Prática: um plano de 90 dias para um dev júnior
Aplico esse modelo há anos e funciona. Não é mágica, é disciplina:
- Semana 1–2: setup do ambiente, leitura do código legado mais crítico, primeira PR pequena (typo fix, teste simples, ajuste de CI).
- Semana 3–6: ownership de uma feature isolada, com code review diário e pairing sempre que travar.
- Semana 7–10: debugging de um bug real em produção, com shadowing do plantão — sem assumir on-call sozinho ainda.
- Semana 11–13: mentoria de outro dev mais novo (ensinar força o aprendizado, como diria Richard Feynman).
Ao final dos 90 dias você tem alguém que conhece o domínio, já levou tapa em produção, e tem base técnica para crescer. Não é pleno ainda, mas está no caminho.
Código: um onboarding check automatizado
Eu gosto de automatizar tudo que dá para automatizar. Esse script valida se o ambiente do novo dev está pronto antes da primeira reunião técnica — economiza aquele clássico “funciona na minha máquina” e dá previsibilidade ao processo:
#!/usr/bin/env bash
# onboarding-check.sh
# Uso: ./onboarding-check.sh
set -euo pipefail
check() {
local cmd="$1"
local min_version="$2"
if ! command -v "$cmd" >/dev/null; then
echo "❌ $cmd não encontrado"
exit 1
fi
echo "✅ $cmd: $(eval "$cmd --version 2>&1" | head -n1)"
}
check git "2.30"
check docker "20.10"
check node "18"
check python "3.10"
# Verifica acesso aos repositórios internos
if ! git ls-remote git@github.com:empresa/core-platform.git >/dev/null 2>&1; then
echo "❌ Sem acesso ao repositório core-platform"
echo " Peça ao time de infra para liberar sua chave SSH"
exit 1
fi
# Verifica conectividade com serviços essenciais
for endpoint in "https://api.empresa.com/health" "https://vault.empresa.com"; do
if ! curl -sf -o /dev/null --max-time 5 "$endpoint"; then
echo "❌ Falha ao acessar $endpoint"
exit 1
fi
done
echo "🚀 Ambiente pronto. Bem-vindo ao time."Time que automatiza onboarding, escala. Time que faz onboarding manual baseado em “pergunte pro Fulano”, não escala e ainda perde gente nos primeiros 30 dias.
Quando a estrela sai: como reagir à perda de um dev-chave
Savinho saiu, o Palmeiras promoveu alguém da base. Funcionou. Mas isso não acontece por sorte — é cultura institucional construída durante anos. Em tech, três armadilhas são recorrentes quando alguém-chave pede demissão:
Erro 1: contratar “alguém igual” correndo
Time em pânico aceita o primeiro currículo decente. Resultado: 6 meses depois, descobre que a pessoa não tem o contexto de domínio que o antigo dev tinha. Você trocou Savinho por um reserva qualquer e ainda perdeu o know-how institucional que morava na cabeça dele.
Erro 2: redistribuir a carga sem critério
O código do dev que saiu vira “órfão”, e alguém do time pega sem negociação de escopo nem ajuste de deadline. Burnout garantido em 60 dias — e perda em sequência do segundo dev-chave.
Erro 3: não documentar nada antes da saída
A maioria das empresas só percebe que não tem documentação quando o dev-chave já desligou o notebook. Documentação é seguro institucional, não burocracia. Quem trata como burocracia, paga caro depois.
O paralelo com a Faria Lima — e por que ele incomoda
O título da matéria do Abril.com.br provoca: “Os anéis que viraram o brinquedo favorito da Faria Lima”. A região virou símbolo de um mercado que paga caro, gira rápido e descarta com a mesma velocidade. Em tech, o Vale do Silício reproduziu esse modelo nos últimos 5 anos — e está pagando o preço agora, com rotatividade recorde e squads cada vez mais frágeis.
Na minha experiência, empresas que investem em base — academias internas, programas de estágio estruturados, mentoria real — retêm mais, gastam menos com recrutamento e sofrem menos quando alguém sai. Não é caridade com junior: é hedge estratégico.
Checklist: sinais de que sua empresa não tem base
- Toda vaga é publicada no LinkedJobs em menos de 48h após uma saída.
- Não existe programa de estágio, trainee ou rotação interna ativo.
- Júnior só “ajuda” sênior, nunca tem ownership real de nada.
- Conhecimento do sistema crítico mora na cabeça de 2–3 pessoas.
- Onboarding é literalmente “pergunte pro Fulano”.
- Nenhum ADR (Architecture Decision Record) foi escrito nos últimos 12 meses.
Se você marcou 3 ou mais itens, sua empresa está mais frágil do que imagina. Um “Savinho” de saída e o time inteiro vira problema — e a próxima contratação de救急 não vai resolver.
FAQ — Perguntas que devs realmente fazem
1. Como convencer minha empresa a criar um programa de base se ela só pensa em contratar pronto?
Mostre o custo. Calcule quanto sua empresa gastou nos últimos 12 meses com agências de recrutamento, signing bonuses e tempo de ramp-up de cada contratação. Depois compare com o custo de um programa interno bem estruturado (mentor + junior por 6 meses). Os números costumam falar mais alto que qualquer discurso sobre cultura.
2. Faz sentido um dev sênior “perder tempo” mentoreando junior?
Faz, e não é perda de tempo. Sênior que não mentoreia vira gargalo de conhecimento — toda decisão crítica passa por ele, e o time inteiro para quando ele tira férias. Mentoria força você a articular decisões que antes eram intuitivas, e isso melhora seu próprio código. É investimento com retorno duplo: forma gente e te faz melhor.
3. Quanto tempo leva para um junior virar pleno “de verdade”?
Em média, 18–24 meses em empresas com bom programa. Em empresas sem programa, júnior vira pleno no papel mas continua dependendo de socorro constante. O label não engana quem trabalha lado a lado com a pessoa todo dia.
4. Documentação: o que realmente vale a pena escrever?
Três coisas: ADRs (decisões arquiteturais e o porquê delas), runbooks de incidente (passo a passo para resolver problemas recorrentes), e contexto de domínio (por que essa regra de negócio existe). Código bem escrito é necessário, mas não substitui o “porquê” das decisões. ADRs são absurdamente subestimados.
5. E se o mercado realmente não tem o perfil que preciso?
Aí a resposta curta é: pare de procurar e comece a formar. Times que dependem só de mercado estão sempre reféns dele — e quanto mais raro o perfil, mais refém você fica. Construir base é justamente a solução para escassez. Palmeiras não esperou o mercado devolver um substituto do Savinho: foi lá e promoveu.
Considerações finais
O caso do Palmeiras — promover um jogador da base após perder uma estrela — não é exceção no futebol, mas virou raridade em tech. Empresas que tratam desenvolvimento de pessoas como estratégia de longo prazo saem na frente quando o mercado aperta, quando o orçamento aperta, ou quando o “Savinho” da sua empresa pede demissão numa terça-feira.
Se você lidera um time, comece pequeno esta semana: defina um plano de 90 dias para o próximo dev que entrar, documente o contexto do sistema crítico em um README simples, e proteja 2 horas por semana do calendário do sênior para mentoria. Três ações simples que mudam completamente a curva de risco da sua empresa nos próximos 12 meses.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.