Hoje: Modelo Spotify, Lei de Conway, como estruturas evoluem e casos reais.
Como escalar autonomia sem perder alinhamento?
Em 2012, o Spotify compartilhou como organizava seus ~250 engenheiros. O modelo virou referência mundial.
Quatro conceitos-chave:
O modelo resolve problemas reais de escala, mas exige maturidade cultural.
Autonomia com alinhamento
Chapters evitam silos técnicos
Guilds promovem inovação cruzada
Escala sem burocracia pesada
Não é receita pronta — cada empresa adapta
Exige confiança e cultura forte
Chapters fracos = perda de qualidade
O próprio Spotify já mudou o modelo
"Organizações que projetam sistemas são limitadas a produzir designs que copiam as estruturas de comunicação dessas organizações."
— Melvin Conway, 1967
Em outras palavras:
Time de frontend, time de backend, time de dados.
Cada um tem seu deploy, seu banco, sua API.
Resultado: 3 sistemas com integrações frágeis entre eles.
Front, back e dados no mesmo time, mesma missão.
Comunicação direta, decisões rápidas.
Resultado: um produto coeso, deploy unificado.
A Amazon usou essa ideia para criar as "Two-Pizza Teams": se o time precisa de mais de 2 pizzas para comer, é grande demais.
E se, em vez de aceitar que a estrutura dita a arquitetura, você fizesse o contrário?
A Manobra Reversa de Conway propõe: organize seus times de acordo com a arquitetura que você quer ter.
Crie squads pequenos e autônomos, cada um dono de um serviço.
Mantenha um time unificado com comunicação constante.
Empresas como Netflix e Amazon reorganizaram times antes de migrar para microsserviços.
A estrutura ideal para 5 pessoas não funciona para 50. E a de 50 não funciona para 500.
Empresas passam por fases previsíveis de crescimento organizacional. A estrutura precisa acompanhar.
Vamos ver as 4 fases típicas de uma empresa de tecnologia:
2–10 pessoas
Todo mundo faz tudo. Sem hierarquia. Comunicação direta.
Estrutura: nenhuma formal
10–50 pessoas
Primeiros gestores. Times por função. Processos mínimos.
Estrutura: funcional simples
50–300 pessoas
Squads por produto. Líderes técnicos. Cultura explícita.
Estrutura: produto/squad
300+ pessoas
Tribes, chapters. Governança. Múltiplas camadas.
Estrutura: Spotify / matricial
Quando a empresa cresce mas a estrutura não acompanha, aparecem sintomas:
Decisões demoram cada vez mais
Reuniões com gente demais
Ninguém sabe quem decide o quê
"Não é minha responsabilidade"
Deploys quebrando com frequência
Times bloqueando uns aos outros
Código monolítico que ninguém entende
Onboarding leva meses
Se 3+ sintomas são familiares, é hora de repensar a estrutura.
De monolito para microsserviços — reorganizando pessoas antes do código.
Estrutura: projetizada → por produto. A AWS nasceu como consequência dessa reorganização.
Cultura de "liberdade com responsabilidade" — pouquíssimos processos formais, altíssima autonomia.
Times pequenos e autônomos
Sem aprovações para deploy
Cada time escolhe suas ferramentas
"Context, not control"
Feedback radical e transparente
Paga os maiores salários do mercado
200M+ de assinantes
Milhares de deploys por dia
Líder em confiabilidade (Chaos Engineering)
A Netflix contrata os melhores e confia neles. Funciona para eles — mas exige um nível de maturidade que a maioria das empresas não tem.
De startup brasileira a uma das maiores fintechs do mundo — crescimento de 5 para 8.000+ pessoas em 10 anos.
~50 pessoas, 1 produto (cartão de crédito)
Time único, funcional, comunicação direta
Monolito em Clojure
Fase: Startup → funcional simples
Múltiplos produtos (conta, investimentos, seguros)
Squads autônomos por domínio de negócio
Centenas de microsserviços
Fase: Scale-up → squads por produto
O Nubank é um exemplo claro de Conway reverso: reorganizaram times para viabilizar a migração de monolito para microsserviços.
Estrutura matricial com forte influência de engenharia.
Áreas por produto (Search, Cloud, Ads, YouTube)
Dentro de cada área: times funcionais
Gestores técnicos + gestores de produto
Carreira dual: IC (Individual Contributor) e Manager
Engenheiro L7+ = poder de VP
Cultura de "design docs" e revisão por pares
Matricial funciona em escala gigante...
...se houver cultura técnica forte
...e processos claros de decisão
| Critério | Funcional | Produto | Matricial | Projetizada | Spotify |
|---|---|---|---|---|---|
| Autonomia dos times | Baixa | Alta | Média | Alta | Alta |
| Especialização | Alta | Baixa | Alta | Média | Alta* |
| Velocidade de entrega | Baixa | Alta | Média | Alta | Alta |
| Complexidade de gestão | Baixa | Média | Alta | Média | Média |
| Escala ideal | Pequenas | Médias | Grandes | Variável | Médias–Grandes |
| Exemplo real | Bancos tradicionais | Amazon | Consultorias | Nubank |
* Spotify mantém especialização via Chapters
Em dupla ou trio. Tempo: 20 minutos.
Uma empresa de e-commerce com 120 pessoas está organizada de forma funcional (Engenharia, Produto, Design, Dados, Comercial). Eles têm 3 produtos: marketplace, app de delivery e programa de fidelidade.
Problemas:
- O app de delivery compete por devs com o marketplace
- O time de dados é gargalo para todos
- Features levam 2 meses do pedido ao deploy
- O time de fidelidade tem 2 devs e nenhum designer
1. Identifique os problemas organizacionais usando a Lei de Conway como lente.
2. Proponha uma nova estrutura (pode ser Spotify, squads, matricial ou híbrida).
3. Desenhe o organograma da nova estrutura.
4. Explique: em qual fase de crescimento essa empresa está?
Use draw.io ou papel. Vamos discutir em sala.
14/04, 16/04 e 21/04: sem aula (viagem + Tiradentes). Atividades assíncronas no Telegram.