A lei de Brooks e por que contratar lentifica o time
"Adicionar pessoas a um projeto atrasado o atrasa ainda mais." A Lei de Brooks, formulada em 1975 no livro The Mythical Man-Month, continua sendo uma das observações mais precisas e mais ignoradas sobre engenharia de software.
O mecanismo é simples: novos membros do time precisam de tempo para aprender o sistema, o código, os processos e as relações. Durante esse período de rampa — que pode durar de 1 a 6 meses dependendo da complexidade — eles consomem tempo de outros membros para treinamento e revisão sem contribuir com produção equivalente. Em projetos com prazo crítico, isso pode ser desastroso.
Mas a Lei de Brooks não diz que contratar é sempre errado — diz que o momento e o ritmo importam. Contratação bem planejada, com onboarding estruturado e integração gradual, aumenta a capacidade do time sem o efeito de afunilamento temporário que Brooks descreve.
Quando faz sentido escalar
A decisão de escalar o time deve ser baseada em evidências de que o limitante atual é capacidade humana — não processo, não clareza de produto, não dívida técnica, não organização do trabalho existente.
Antes de contratar, pergunte: o time atual está operando com 80%+ de capacidade de forma consistente? Os entregáveis que não estão sendo feitos são bloqueados por falta de pessoa ou por outro fator? Se contratar alguém hoje, essa pessoa teria trabalho claro para fazer na segunda semana?
Se as respostas forem "sim, sim, sim", escalar faz sentido. Se houver dúvida em qualquer uma, o investimento pode ser melhor alocado em processo, ferramentas ou clareza de produto antes de adicionar mais pessoas.
"Escalar um time disfuncional cria um time disfuncional maior. Antes de crescer, certifique-se de que o que você tem está funcionando."
Squads versus componentes: como estruturar
O modelo de squads — times pequenos e autônomos com ownership sobre uma área do produto — se tornou o padrão para times de TI que crescem além de 10-15 pessoas. A referência é o modelo do Spotify (squads, tribes, chapters, guilds), mas o conceito pode ser adaptado para contextos muito diferentes.
A divisão em squads funciona bem quando as áreas do produto são suficientemente distintas para permitir desenvolvimento paralelo com baixo acoplamento. O problema do acoplamento é crucial: squads que precisam se coordenar constantemente para fazer entregas independentes não têm os benefícios da autonomia, mas têm todos os custos de coordenação da estrutura.
A alternativa é a estrutura por componentes — times organizados em torno de camadas técnicas (frontend, backend, infraestrutura) em vez de áreas de produto. Essa estrutura é mais simples de organizar, mas cria dependências entre times para cada feature que atravessa múltiplas camadas — que é quase toda feature.
Para a maioria das empresas além de startup-stage, squads por área de produto com interfaces técnicas bem definidas (contratos de API, eventos, ownership de domínio) é o modelo que escala com menos atrito.
O papel do onboarding no escalonamento
O onboarding é o gargalo mais subestimado no crescimento de times de TI. Empresas investem meses em recrutamento e semanas de salário por contratação, e depois deixam o novo membro descobrir como as coisas funcionam com mínimo suporte estruturado.
Um onboarding eficiente para escala tem três propriedades: é repetível (pode ser feito para múltiplas pessoas ao mesmo tempo sem degradar), é progressivo (aumenta gradualmente a autonomia e responsabilidade), e é documentado (não depende de que as mesmas pessoas do time original estejam disponíveis para cada contratação).
O investimento em criar documentação de onboarding — arquitetura do sistema, decision records, guias de desenvolvimento, contexto de produto — tem retorno composto: cada novo membro que não precisa de mão nas costas libera tempo dos membros existentes para trabalho de valor mais alto.
Uma métrica simples para avaliar a qualidade do seu onboarding: quanto tempo leva para um novo desenvolvedor fazer o primeiro commit em produção? Times com onboarding excelente conseguem isso na primeira semana. Times com onboarding fraco levam 30 dias ou mais. O gap entre esses dois extremos é custo real — tempo de pessoa cara que não está sendo utilizado eficientemente.
Como preservar cultura técnica ao crescer
Cultura técnica — as práticas, valores e formas de trabalhar que definem como o time escreve e revisa código — tende a se diluir em crescimento rápido. Com 5 pessoas, a cultura se transmite de forma orgânica. Com 20, precisa de mecanismos explícitos.
O que preserva cultura técnica em escala:
- Padrões documentados: guias de estilo, ADRs, documentação de arquitetura. A cultura que vive só na cabeça dos fundadores do time não escala.
- Code review como mecanismo de transmissão: revisões de código são a forma mais eficiente de transmitir valores técnicos — desde que os revisores façam isso de forma explícita e educacional, não apenas como aprovação ou rejeição.
- Líderes técnicos em cada squad: quando o time cresce para múltiplos squads, cada squad precisa de alguém que encarne e transmita os valores técnicos da organização.
- Guilds ou capítulos técnicos: grupos que atravessam squads por disciplina (frontend guild, backend guild, SRE chapter) criam espaço para alinhamento técnico entre times que trabalham em áreas diferentes do produto.
Documentação como alavanca de escala
Times que não documentam não escalam. A equação é simples: cada bit de conhecimento que existe apenas na cabeça de membros do time é um gargalo em potencial — toda vez que alguém precisa dessa informação, precisa interromper quem sabe para perguntar.
Documentação não significa burocracia. Significa fazer o conhecimento acessível de forma assíncrona. Uma decisão de arquitetura documentada em um ADR de 300 palavras economiza horas de explicação para cada novo membro. Um runbook de incidente documentado permite que qualquer eng de plantão resolva o problema sem escalar para o único expert.
O incentivo para documentar precisa ser explícito. Em times onde documentação não é valorizada culturalmente, as pessoas inevitavelmente a depriorizarão em favor de código novo. Gestores que tornam documentação uma expectativa tácita — não pedindo explicitamente, mas não valorizando também — não têm direito de se surpreender quando o time não documenta.
Os sinais de que o time cresceu demais
Alguns indicadores de que o time pode ter crescido além do ponto ótimo ou crescido mais rápido do que a estrutura suporta:
- Reuniões de coordenação estão consumindo mais de 20% do tempo dos devs
- Há conflitos frequentes sobre quem é responsável por qual parte do sistema
- O tempo de onboarding está aumentando — novos membros levam mais tempo para se tornar produtivos do que levavam 6 meses atrás
- Ninguém consegue desenhar o mapa completo de como o sistema funciona
- Mudanças em uma área do sistema frequentemente causam problemas inesperados em outras
Esses sinais indicam que a estrutura e os processos precisam escalar junto com o headcount — ou que o crescimento precisa ser pausado até que a fundação esteja mais sólida.