Contratar mais devs não faz o produto andar mais rápido: o gargalo é outro

Resposta direta: Contratar mais desenvolvedores raramente acelera um produto. A Lei de Brooks mostra por quê: cada pessoa nova adiciona onboarding e coordenação antes de adicionar entrega. O gargalo real costuma ser clareza de decisão e dívida técnica. Se o time constrói a coisa errada, mais gente só constrói a coisa errada mais caro. Resolva direção e base técnica antes de assinar novas vagas.

O roadmap está atrasado. A diretoria pressiona. E a primeira reação de quase todo comitê executivo é a mesma: abrir vagas. Parece lógico. Mais mãos, mais código, mais entrega.

Só que não é assim que produto digital funciona. Quem já passou por dois ou três ciclos de contratação em massa sabe o final da história: o headcount dobra, a folha dobra, e a velocidade percebida fica praticamente onde estava. Às vezes piora.

Este artigo desmonta o mecanismo. Não é opinião, é matemática de coordenação somada a um diagnóstico que a maioria das empresas se recusa a fazer: o gargalo quase nunca é capacidade de escrever código.

A Lei de Brooks: por que gente nova desacelera antes de acelerar

Em 1975, Fred Brooks formulou o que virou uma das observações mais citadas e mais ignoradas da engenharia de software: adicionar pessoas a um projeto atrasado o atrasa ainda mais. É a Lei de Brooks, do livro The Mythical Man-Month.

O raciocínio tem três engrenagens:

• Onboarding consome quem produz. A pessoa nova não sabe onde estão as regras de negócio, os atalhos do código, as decisões históricas. Quem ensina é justamente o dev sênior que estava entregando. Nos primeiros meses, cada contratação subtrai capacidade antes de somar.
• Comunicação cresce em progressão geométrica. O número de canais de comunicação entre pessoas segue a fórmula n(n-1)/2. Um time de 6 tem 15 canais possíveis. Um time de 12 tem 66. Você dobrou o time e mais que quadruplicou o custo de manter todo mundo alinhado.
• Trabalho de produto não fatia infinitamente. Nove mulheres não geram um bebê em um mês, na imagem do próprio Brooks. Tarefas com dependência entre si não aceleram por paralelismo. Aceleram por sequência bem decidida.

Brooks escreveu isso há cinquenta anos. O motivo de a lei continuar valendo é que ela não descreve tecnologia. Descreve gente coordenando trabalho complexo. Isso não mudou.

O gargalo real: quase nunca é capacidade de código

Aqui está o ponto que a maioria dos comitês não quer encarar. Quando um produto anda devagar, a pergunta certa não é "quantos devs temos?". É "onde a entrega morre?". Na prática, ela morre em três lugares.

1. Clareza de decisão: o que construir

O sintoma clássico: o time de desenvolvimento fica parado esperando definição, ou pior, constrói três versões da mesma funcionalidade porque produto, comercial e diretoria pediram coisas diferentes.

Isso não é problema de capacidade. É problema de direção. E direção não melhora com contratação, porque o funil de decisão continua com o mesmo diâmetro. Você só aumenta a fila de gente esperando a decisão sair.

O custo disso é invisível no relatório de RH e brutal no caixa: são os Custos Invisíveis de construir funcionalidade que ninguém pediu, refazer fluxo que ninguém validou, lançar tela que ninguém usa. Já detalhamos o tamanho desse buraco em o erro de R$ 1 milhão que nasce de uma decisão de produto sem diagnóstico.

2. Dívida Técnica: o quanto o código resiste a mudanças

O segundo lugar onde a entrega morre é dentro do próprio código. Dívida Técnica é isso: decisões de tecnologia e design mal feitas no passado que cobram juros em cada sprint do presente. O dev não está lento. O terreno é que está minado.

Os números do setor são conhecidos: dívida técnica consome até 40% do orçamento de TI. Ou seja, em uma operação carregada de dívida, quase metade de cada dev novo que você contrata vai trabalhar para o passado, não para o roadmap. Você não comprou velocidade. Comprou mais gente pagando juros.

O mecanismo completo está em quanto custa a dívida técnica que não aparece no seu relatório. A versão curta: contratar em cima de dívida é escalar o desperdício.

3. Overhead de coordenação: o imposto de cada cadeira nova

O terceiro assassino de velocidade é o que a Lei de Brooks previu: reunião de alinhamento, cerimônia duplicada, handoff entre squads, code review empilhado, decisão que agora precisa passar por mais camadas. Cada pessoa nova paga um imposto de coordenação, e esse imposto é cobrado de todo o time, não só dela.

Times pequenos com direção clara atropelam times grandes com direção confusa. Sempre foi assim.

Faça a conta: o custo por entrega sobe enquanto a folha dobra

Vamos plugar números para tirar isso do campo da retórica.

Um time de 6 desenvolvedores, a um custo total médio de R$ 15.000 por pessoa ao mês, custa R$ 90.000 mensais. Suponha que esse time entrega 10 iniciativas relevantes por trimestre. O custo por entrega é direto:

• Antes: R$ 90.000 × 3 meses = R$ 270.000 no trimestre ÷ 10 entregas = R$ 27.000 por entrega

Agora a empresa dobra o time para 12 devs. Folha vai a R$ 180.000 por mês. Só que os canais de comunicação foram de 15 para 66, os seniores viraram professores de onboarding e a dívida técnica continua onde estava. Na prática, a vazão não dobra. Sobe, digamos, 30%: de 10 para 13 entregas no trimestre.

• Depois: R$ 180.000 × 3 meses = R$ 540.000 no trimestre ÷ 13 entregas = R$ 41.538 por entrega

Leia de novo. A folha dobrou, a velocidade subiu 30% e cada entrega ficou 54% mais cara. Do ponto de vista de Eficiência de Capital, a empresa pagou o dobro para piorar o unit economics da própria engenharia. E se a direção estiver errada, essas 13 entregas mais caras podem incluir funcionalidades que nenhum cliente vai usar.

É por isso que "entregamos mais features" é uma métrica perigosa quando desacompanhada de resultado. Volume de entrega sem impacto no negócio é primo direto das métricas que dissecamos em métricas de vaidade contra métricas de valor.

Quando contratar faz sentido, então?

Não é dogma contra contratação. É sequência. Contratar acelera quando três condições já existem:

• Direção clara: existe um diagnóstico do que gera resultado e um roadmap priorizado por impacto financeiro, não por opinião do executivo mais barulhento.
• Base técnica que aguenta: a dívida crítica está mapeada e sob controle, e o código aceita mudança sem quebrar em cascata.
• Trabalho paralelizável: as frentes são independentes o suficiente para que gente nova produza sem virar fila na mesa de quem decide.

Com essas três condições, cada contratação vira alavanca. Sem elas, vira diluição. O produto digital deve ser tratado como Ativo Digital: cada real investido nele precisa ter retorno rastreável. UX bem feita, aliás, tem um dos melhores retornos do mercado, com ROI médio de 100:1. Jogar dinheiro em headcount sem diagnóstico é o oposto disso.

Vale o mesmo raciocínio para a tentação de "resolver refazendo tudo": reescrever sistema sem entender a causa raiz repete o ciclo com tecnologia nova. Antes de qualquer decisão desse porte, leia o que considerar antes de refatorar a interface de um sistema digital.

FAQ

Por que contratar mais desenvolvedores não acelera a entrega?

Porque a capacidade de escrever código raramente é o gargalo. A Lei de Brooks mostra que cada pessoa nova adiciona custo de onboarding e coordenação antes de adicionar produção. Se o gargalo real é decisão lenta ou Dívida Técnica, mais gente só aumenta a fila e o desperdício.

Como saber se o meu gargalo é gente ou é direção?

Olhe onde o trabalho para. Se devs esperam definição, refazem escopo ou constroem coisas que morrem sem uso, o gargalo é clareza. Se toda mudança pequena vira semana de trabalho e bugs em cascata, o gargalo é dívida. Só se o trabalho está claro, a base é sólida e ainda assim falta braço, o gargalo é gente.

O que é a Lei de Brooks?

É a observação de Fred Brooks, em The Mythical Man-Month, de que adicionar pessoas a um projeto de software atrasado o atrasa ainda mais, por causa do tempo de rampagem e do crescimento geométrico dos canais de comunicação. Vale desde 1975 porque descreve coordenação humana, não tecnologia.

Quanto a dívida técnica custa de verdade?

Estimativas do setor apontam que a dívida técnica consome até 40% do orçamento de TI. Em termos práticos: em uma operação endividada, boa parte de cada contratação nova trabalha para consertar o passado, não para entregar o roadmap.

Conclusão: o que resolver antes de abrir a próxima vaga

A pressa em contratar é compreensível. Mas velocidade de produto se compra com clareza e base sólida, não com cadeiras. Antes de aprovar o próximo lote de vagas, percorra esta sequência:

1. Diagnostique onde a entrega morre. Mapeie o fluxo da ideia até a produção e encontre o ponto real de espera: decisão, dívida ou capacidade.
2. Resolva a clareza primeiro. Um roadmap priorizado por impacto financeiro, com dono e critério de sucesso por iniciativa. Sem isso, qualquer contratação amplifica ruído.
3. Mapeie e pague a dívida crítica. Não toda a dívida, a que trava as iniciativas prioritárias. O objetivo é Fricção Zero entre a decisão e a entrega.
4. Meça custo por entrega, não volume de entrega. Se o custo por resultado sobe enquanto o time cresce, o problema não é falta de gente.
5. Só então contrate. Com direção clara e base sólida, cada dev novo vira alavanca em vez de diluição.

Se você olha para o seu roadmap e não sabe dizer com segurança onde a entrega morre, esse é exatamente o problema que um Discovery estratégico resolve: um diagnóstico profundo de negócio, produto e base técnica antes de qualquer decisão de investimento, seja em contratação, redesign ou reescrita. É a forma mais barata de não gastar milhões no lugar errado.

Fale com a UX Agency e entenda como um Discovery estratégico se aplica ao seu cenário.