Como escalar squad sem perder qualidade

Escalar um squad sem perder qualidade exige padrões, contratos entre times e clareza de papéis. Adicionar desenvolvedores sem resolver esses fundamentos costuma gerar o efeito oposto: mais pessoas, mais coordenação, menos entrega.

A razão é estrutural. Quando um time cresce sem ajustar como as decisões são tomadas, como o código é revisado e quem é dono de quê, a comunicação informal que funcionava com cinco pessoas começa a falhar com dez, e colapsa com quinze.

O que acontece quando o crescimento não tem estrutura?

O sintoma mais comum é a queda silenciosa de qualidade. O lead time de uma feature que antes levava três dias passa para duas semanas. O número de incidentes pós-deploy sobe. Revisões de código viram formalidade sem critério real. Ninguém sabe ao certo quem decide a arquitetura de um novo serviço.

Esse padrão tem nome na literatura de engenharia: Big Ball of Mud, quando o sistema reflete a ausência de estrutura do time que o construiu. Não por acaso, a Lei de Conway descreve exatamente isso: organizações tendem a produzir sistemas que espelham sua estrutura de comunicação interna.

Times que crescem bem monitoram isso ativamente. As métricas DORA (frequência de deploy, lead time para mudanças, taxa de falha e tempo de recuperação) funcionam como termômetro de saúde durante a expansão. Se o lead time cresce consistentemente ao longo de um trimestre, é sinal de que coordenação está virando gargalo.

Como criar padrões que se sustentam com o time maior?

Padrões não são documentos que ninguém lê. São critérios acordados que guiam decisões recorrentes sem exigir reunião para cada caso. Dois formatos têm adoção ampla em times que crescem:

RFCs (Requests for Comments) documentam decisões técnicas antes de serem tomadas, abrindo para revisão do time. Gus Ubiratã Ferreira, engenheiro do Stripe, descreveu como RFCs ajudam times a escalar decisões de arquitetura sem depender de sincronização constante. O processo força quem propõe a articular tradeoffs, e quem revisa a dar feedback estruturado.

ADRs (Architecture Decision Records) registram o raciocínio por trás de decisões já tomadas. São úteis para onboarding e para evitar que decisões importantes se percam na memória coletiva do time. O repositório adr.github.io mantém templates e exemplos de como estruturá-los.

Code review também precisa de critério explícito. Sem isso, a revisão vira exercício de opinião pessoal, e o feedback que um dev sênior dá para um pleno varia completamente dependendo do dia. O handbook de code review do GitLab é uma referência pública boa: define o que é bloqueante, o que é sugestão, e qual é o tempo esperado de resposta.

Uma definition of done compartilhada fecha o ciclo. “Pronto” significa: testes passando, documentação atualizada, critério de code review atendido, feature flag configurada se necessário. Sem isso, “pronto” significa coisas diferentes para pessoas diferentes.

Como dividir o time sem criar silos?

Squads de cinco a nove pessoas funcionam bem. Abaixo de cinco, falta resiliência. Acima de nove, os caminhos de comunicação crescem rápido demais. Quando o time chega em torno de vinte pessoas, a divisão em múltiplos squads passa de opção para necessidade operacional.

A forma como o time é dividido molda a arquitetura resultante, isso é a Lei de Conway funcionando na prática. O livro Team Topologies, de Matthew Skelton e Manuel Pais, sistematiza isso: times organizados por camada técnica (frontend, backend, dados) tendem a produzir sistemas com muitas dependências entre camadas. Times organizados por domínio de produto ou capacidade de usuário conseguem entregar de ponta a ponta com menos handoffs.

A divisão por domínio é mais difícil de configurar no início, mas escala melhor. Um squad que cuida de pagamentos do início ao fim move mais rápido do que três squads que precisam se coordenar para entregar uma mudança no fluxo de checkout.

O ownership precisa ser explícito. Cada serviço, cada área do produto, cada dado crítico deve ter um time responsável. Quando algo quebra ou precisa evoluir, o caminho até quem decide não pode depender de memória institucional.

Quais papéis importam quando o time dobra de tamanho?

Com cinco pessoas, papéis informais funcionam. Com quinze, ambiguidade de papel vira fonte de atrito constante. Algumas distinções que ajudam:

O tech lead é responsável pela direção técnica do squad, facilitação de decisões de arquitetura e qualidade do código entregue. Não é gestor de pessoas, mas influencia o trabalho técnico de todos.

O staff engineer (ou sênior+ em times menores) atua em problemas que cruzam squads. Sua contribuição é mais em design de sistema, definição de padrões e desbloqueio de dependências entre times do que em features específicas.

O engineering manager cuida do desenvolvimento das pessoas, do processo e da relação com produto. Quando o papel se confunde com o do tech lead, ambos ficam sobrecarregados e nenhum entrega bem.

O IC sênior (individual contributor) é responsável por entregas de alta complexidade, mentoria de juniores e plenos, e contribuição para padrões do time. Não precisa de relatório direto para ter impacto relevante.

O overlap de papéis, especialmente entre tech lead e EM, é uma das causas mais comuns de ruído em times em crescimento. Deixar claro quem decide o quê evita tanto o vácuo de liderança quanto a duplicação de esforço. Se você ainda está avaliando a composição ideal do seu squad antes de crescer, o custo de um squad mal montado detalha os sinais de alerta e o impacto real de erros de composição.

Como saber se o crescimento está funcionando?

Times que escalam bem costumam manter ou melhorar frequência de deploy mesmo com o time maior. Lead time estável ou decrescente indica que o processo de entrega não está sendo afogado pela coordenação. Taxa de falha em produção controlada mostra que padrões de qualidade estão sendo respeitados na pressa de crescer.

Sinais de que algo está errado: features simples passam por múltiplos squads antes de chegar à produção; debates de arquitetura se repetem sem chegar a conclusão; onboarding de novos devs demora meses para atingir produtividade mínima; code review acumula filas sem critério claro de prioridade.

A diferença entre crescer bem e crescer em caos raramente está na qualidade individual das pessoas. Está nos padrões que o time adotou antes de precisar deles.

Para quem está pensando em trazer liderança de fora para apoiar essa transição, quando contratar um tech lead externo faz sentido discute os sinais que indicam essa necessidade e como avaliar o momento certo. E para times que ainda estão definindo qual modelo de liderança técnica faz sentido em estágio inicial, startups que escalam sem CTO explora alternativas antes do C-level full-time.

Crescimento sustentável em engenharia é menos sobre contratar rápido e mais sobre criar as condições para que cada nova pessoa contribua sem degradar o que já funciona.