Como você dimensiona práticas de engenharia conforme o time cresce?

Question

Accepted Answer

Práticas que funcionam para 3 engenheiros quebram em 30. Coordenação informal, conhecimento tribal e processos manuais não escalam. Um TL sênior deve **evoluir práticas à frente da curva de crescimento**, formalizando apenas estrutura suficiente para manter a velocidade sem burocracia.

## O que precisa escalar

```text
✓ CI/CD — fast, reliable, automated; manual deploys don't survive growth
✓ TESTING — automated suites; you can't manually verify everything
✓ CODE REVIEW — clear norms, reasonable turnaround, ownership boundaries
✓ DOCUMENTATION — written knowledge replaces "ask Bob"
✓ ONBOARDING — repeatable, not bespoke per hire
✓ DECISION-MAKING — clear ownership; who decides what
✓ ON-CALL / OWNERSHIP — defined, rotated, not heroic
```

## Um exemplo concreto

Com 5 pessoas, todos conhecem todo o sistema e implantam manualmente. Com 25, isso é caos, você precisa de um pipeline de CI/CD real, propriedade de serviço, runbooks escritos e normas de revisão, ou o time vai parar lutando um contra o outro.

## Adicione estrutura no momento certo

Não imponha processo pesado a um time pequeno (isso o sufoca), e não se apegue à informalidade de startup em um grande (isso desmorona). Adicione cada peça de estrutura *conforme a dor aparece*, idealmente um pouco antes. Fique atento aos sinais: aumento de conflitos de merge, gargalos de conhecimento, deployments instáveis.

## O trade-off

Mais processo negocia flexibilidade por consistência e escala. Muito pouco e times grandes se debaterão; muito e você sufoca a velocidade que os tornou bem-sucedidos. Calibre continuamente.

## Por que isso importa

As práticas que levaram um time pequeno ao sucesso vão ativa e ativamente esmagar um maior.

Um TL que dimensiona práticas proativamente mantém um time em crescimento rápido; um que não faz isso vê a velocidade desmoronar conforme o time cresce, a armadilha clássica de escalabilidade.