O Verdadeiro Custo de uma Má Contratação Técnica
A estimativa padrão da indústria diz que uma má contratação custa entre 1,5x e 3x o salário anual da posição. Se você contrata um engenheiro senior por 80.000 euros ao ano e não funciona, está olhando para um buraco de 120.000 a 240.000 euros.
Mas essa cifra captura apenas o visível. A parte que você consegue colocar numa planilha. O que realmente destrói uma startup não é o dinheiro que foi embora — é o tempo que não volta e o dano que ficou para trás.
Os custos visíveis: o que você pode calcular
Vamos começar pelo óbvio, porque já dói bastante:
- Salário acumulado. Os meses que você pagou antes de perceber o erro. Normalmente 3-6 meses.
- Custos de recrutamento. Se usou uma agência, pagou entre 15% e 25% do salário anual. Se fez internamente, o tempo investido em screening, entrevistas e negociação.
- Indenização. Dependendo do país e do contrato, pode ser de um mês a vários meses de salário.
- Custo de reposição. Volta ao começo. Outra rodada de publicar vagas, filtrar currículos, fazer entrevistas técnicas, negociar. Se tiver sorte, 2-3 meses. Se não, 6.
Some tudo e chega facilmente àquela estimativa de 1,5-3x. Mas é aqui que a maioria das análises para. E é aqui que o verdadeiro dano começa.
Os custos invisíveis: o que não aparece em nenhuma planilha
Dívida técnica herdada
Um mau engenheiro não apenas não constrói o que deveria. Constrói mal o que toca. Código sem testes, arquitetura que não escala, dependências desnecessárias, abstrações que ninguém entende. Quando vai embora, esse código fica. E alguém tem que lidar com ele.
Já vi casos onde um engenheiro ficou 4 meses em uma startup e deixou uma base de código que o senior seguinte levou 6 semanas para reescrever antes de conseguir avançar. Essas 6 semanas são puro custo afundado — você não está construindo features novas, está desfazendo o trabalho de alguém que saiu.
Dano à moral da equipe
Isso é o que menos se mede e mais impacto tem. Quando um membro da equipe não rende, o resto sabe. Antes de você, normalmente. E cada semana que passa sem que você faça algo a respeito, sua credibilidade como líder se erode.
Bons engenheiros não querem trabalhar com maus engenheiros. Se demora demais para agir, o risco não é apenas perder o que não funciona — é que os que funcionam comecem a procurar outro lugar.
Deadlines descumpridos
Você contratou aquele engenheiro porque precisava entregar algo. Uma feature crítica, uma integração, um MVP. Cada mês que passa com alguém que não executa é um mês de atraso no seu produto. Em uma startup, isso pode significar:
- Perder uma janela de mercado. Seu concorrente lançou primeiro.
- Perder a confiança dos investidores. Não cumpriu o roadmap que apresentou na rodada.
- Perder clientes. Prometeu uma feature para o Q1 e não chegou.
Perda de conhecimento institucional
Quando alguém sai — mesmo alguém que não rendia bem — leva contexto. Decisões que tomou, conversas que teve com outros membros da equipe, entendimento do domínio do negócio. Parte desse contexto se perde para sempre. O próximo engenheiro começa com um déficit de informação que leva semanas para compensar.
A linha do tempo do desastre
Vamos colocar números no tempo:
- Meses 0-3: Contratação. Publica a vaga, filtra, entrevista, negocia, onboarding. Se tudo vai bem, 2-3 meses. Se o mercado está aquecido — e em tech está — podem ser 4-6.
- Meses 3-6: Lua de mel. O novo engenheiro se incorpora. Os primeiros meses são de ramp-up. É normal que não produza a 100%. Você dá o benefício da dúvida.
- Meses 6-9: A suspeita. Começa a ver sinais. Code reviews que voltam com muitos comentários. Tarefas que atrasam. Outros engenheiros que começam a reclamar em privado. Mas pensa: "Talvez precise de mais tempo."
- Meses 9-11: A certeza. Já sabe que não funciona. Mas agora precisa gerenciar a saída. Conversas difíceis, documentar o desempenho, processo de offboarding.
- Meses 11-14: De volta ao começo. Volta a contratar.
Resultado: até 14 meses perdidos. Para uma startup que tenta chegar ao product-market fit, isso pode ser letal.
Por que acontece: os erros mais comuns
Más contratações não são azar. São resultado de um processo quebrado. Estes são os erros que vejo com mais frequência:
Contratar com urgência, não com critério
"Precisamos de um backend developer para ontem." Soa familiar. A pressão por entregar faz você baixar a barra. Aceita o candidato que está "ok" em vez de esperar o que é "excelente." Esse atalho sempre sai mais caro.
Confiar demais no currículo
Um currículo impressionante não garante nada. Já entrevistei candidatos com experiência no Google e na Amazon que não conseguiam resolver um problema básico de design de sistemas. E vi engenheiros de empresas que você não conhecia que escreviam código impecável. O currículo diz onde alguém esteve. Não diz como trabalha.
Não fazer avaliação técnica real
Uma conversa de 30 minutos não é uma avaliação técnica. Se não está fazendo code reviews de código real, exercícios de design de sistemas ou pelo menos uma sessão de pair programming, está adivinhando. E adivinhar com contratações de 60.000-100.000 euros ao ano é um risco absurdo.
Avaliar entrevista, não produção
Tem gente que entrevista incrivelmente bem e produz mediocremente. E vice-versa. Se seu processo seleciona por capacidade de entrevistar em vez de capacidade de execução, está otimizando para a coisa errada.
Como prevenir: o framework que funciona
Não há garantia de 100%, mas dá para reduzir drasticamente o risco:
1. Vetting técnico rigoroso. Não apenas algoritmos e estruturas de dados. Avaliação de código real. Como estrutura um projeto? Como lida com erros? Como pensa sobre testing? Consegue explicar decisões de arquitetura que tomou em projetos anteriores?
2. Avaliação por engenheiros, não por recruiters. Um recruiter pode avaliar soft skills e fit cultural. Não pode avaliar se alguém sabe projetar um sistema de filas distribuído. Seus engenheiros seniores — ou seu CTO — devem estar no processo.
3. Período de experiência real. Não um período de experiência onde você observa se a pessoa "se encaixa." Um período onde atribui trabalho real com deliverables concretos e avalia a qualidade do output. 2-4 semanas costumam ser suficientes para saber se alguém executa de verdade.
4. Referências técnicas, não apenas profissionais. Não ligue apenas para o ex-chefe. Fale com alguém que revisou o código dele ou trabalhou na mesma equipe técnica. As perguntas que importam: "Você trabalharia com essa pessoa de novo? Daria a ela um projeto crítico?"
Como resolvemos isso na Conectia
Tudo isso exige tempo, expertise técnica e um processo bem definido. A maioria das startups em fase inicial não tem as três coisas. Tem pressa, tem um founder técnico que já está no limite da capacidade e não tem um processo de hiring comprovado.
É exatamente por isso que criamos a Conectia. Nosso processo de vetting tem taxa de aceitação de 8%. Não é um filtro de currículo — é uma avaliação técnica liderada por CTOs com experiência em produção. Avaliamos código real, capacidade de design de sistemas e experiência demonstrável em ambientes de startup.
Se um engenheiro não funciona, substituímos nos primeiros 30 dias sem custo adicional. Não porque esperamos que aconteça — nossa taxa de retenção é de 95% — mas porque entendemos que para um founder, a confiança no processo importa tanto quanto o resultado.
O custo de uma má contratação não é um número numa planilha. É tempo que não recupera, código que tem que reescrever e moral de equipe que leva meses para reconstruir. O melhor investimento que pode fazer não é contratar rápido — é contratar bem.
Cansado de processos de contratação que não filtram de verdade? Fale com um CTO — engenheiros seniores pré-validados com garantia de substituição em 30 dias.
