Escalar de 10 para 50 engenheiros não é multiplicar pessoas. É mudar como a organização funciona. Times pequenos se comunicam por instinto. Times grandes precisam de estrutura. Quem ignora essa mudança perde velocidade proporcional ao tamanho que atinge.
Estrutura de squads: 5 a 8 pessoas por domínio
Cada squad deve ser autônomo dentro do seu domínio de negócio. Tamanho ideal: 5 a 8 engenheiros. Grandes o suficiente para entregar valor sozinhos, pequenos o suficiente para manter comunicação direta. Squads por domínio (pagamentos, cadastro, busca) evitam a dependência entre times para cada feature.
Sem squads definidos, decisões ficam centralizadas no CTO. Com squads autônomos, decisões acontecem mais perto de quem executa. A mudança de velocidade é visível em semanas.
Time de plataforma interna: 2 a 4 engenheiros
Uma equipe pequena dedicada a ferramentas compartilhadas: CI/CD, monitoramento, bibliotecas internas, ambientes de teste. Sem isso, cada squad reinventa a roda. Com isso, squads focam no produto e ganham ferramentas consistentes.
O time de plataforma não é um centro de serviço. É um time de produto cujo cliente é a engenharia. Métricas de sucesso: tempo de deploy reduzido, incidentesmenos frequentes, onboarding de novos engenheiros mais rápido.
Distribuição de decisões técnicas
Crie um guia que define o que squads decidem sozinhos (escolhas de framework dentro do squad, design de APIs internas, padrões de teste local) e o que precisa de alinhamento (mudanças de infraestrutura, novas dependências de alto impacto, decisões de segurança).
Esse guia elimina gargalos. Sem ele, tudo passa pelo CTO. Com ele, o CTO só participa quando a decisão realmente afeta a organização inteira.
Regra dos 15% para qualidade técnica
Reserve 15% da capacidade de cada squad para trabalho que não gera feature: refatoração, testes, documentação, atualização de dependências. Não como projeto pontual, mas como prática contínua.
Times que não reservam esse espaço chegam em 18 meses ao ponto em que novas features exigem tanto trabalho de estabilização que o produto para. A prevenção custa menos que a correção.
Programa de onboarding de 30 dias
Primeira semana: ambiente funcionando, primeiro commit, entendimento do domínio. Segunda e terceira semanas: trabalhar em tickets reais com mentoria. Quarta semana: apresentar uma melhoria que o novo engenheiro identificou.
Onboarding bom não é sobre documentação. É sobre experiência guiada que gera confiança e contexto. Engenheiros que fazem bom onboarding permanecem mais tempo e contribuem mais rápido.
Medir resultados, não velocidade
Velocity é uma métrica de time, não de organização. Resultados que importam: tempo de ciclo de feature (do pedido ao deploy), taxa de bugs em produção, tempo médio de recuperação de incidente, satisfação do time.
Essas métricas contam a história real da organização. Velocity conta apenas quantos pontos foram fechados, sem dizer se o produto melhorou.