A Lei de Conway diz que sistemas refletem a estrutura de comunicação das organizações que os criaram. Se sua organização é lenta, seu software será lento. Performance começa com pessoas, não com código.
Você pode ter os melhores engenheiros do mundo. Se a organização é disfuncional, o sistema será disfuncional.
A Lei de Conway na Prática
O que diz
"Organizações que projetam sistemas são
constrangidas a produzir designs que são
cópias das estruturas de comunicação
dessas organizações."
— Melvin Conway, 1967
Exemplos
Organização por camadas técnicas:
Time de Frontend
Time de Backend
Time de Database
Time de Infra
→ Sistema com acoplamento forte entre camadas
→ Mudanças simples requerem 4 times
→ Reuniões de coordenação constantes
Organização por produto:
Time de Pagamentos (full-stack)
Time de Catálogo (full-stack)
Time de Checkout (full-stack)
→ Serviços independentes
→ Deploys independentes
→ Times autônomos
Gargalos Organizacionais
1. Aprovações excessivas
Mudança simples:
1. Dev implementa (1 hora)
2. Espera review (1 dia)
3. Espera aprovação de arquiteto (2 dias)
4. Espera janela de deploy (3 dias)
5. Espera validação de QA (2 dias)
Total: 8 dias para 1 hora de trabalho
→ Throughput organizacional: 12% de eficiência
2. Dependências entre times
Time A precisa de API do Time B
Time B está ocupado com prioridade C
Time A: bloqueado por 2 sprints
→ Latência organizacional: semanas
3. Silos de conhecimento
Só João sabe como funciona módulo X
João está de férias
Bug crítico em X
→ MTTR: dias em vez de horas
4. Reuniões excessivas
Segunda: Planning
Terça: Sync com Time B
Quarta: Arquitetura review
Quinta: Grooming
Sexta: Retrospectiva
Tempo para código: 2h/dia
→ 75% de overhead organizacional
Métricas de Performance Organizacional
DORA Metrics
Deployment Frequency:
Elite: Múltiplos deploys/dia
High: 1 deploy/dia a 1/semana
Medium: 1/semana a 1/mês
Low: < 1/mês
Lead Time for Changes:
Elite: < 1 hora
High: 1 dia - 1 semana
Medium: 1 semana - 1 mês
Low: > 1 mês
Mean Time to Recovery (MTTR):
Elite: < 1 hora
High: < 1 dia
Medium: < 1 semana
Low: > 1 semana
Change Failure Rate:
Elite: 0-15%
High: 16-30%
Medium: 31-45%
Low: > 45%
Flow Metrics
Flow Efficiency:
work_time / (work_time + wait_time)
Exemplo:
Trabalho ativo: 8 horas
Espera (reviews, aprovações): 72 horas
Eficiência: 8/80 = 10%
Cycle Time:
Tempo desde início até entrega
Work in Progress (WIP):
Quantos itens em andamento simultaneamente
Patterns Organizacionais para Performance
1. Team Topologies
Stream-aligned Teams:
- Focados em fluxo de valor
- End-to-end ownership
- Minimiza handoffs
Enabling Teams:
- Ajudam outros times
- Especialistas temporários
- Transferem conhecimento
Platform Teams:
- Fornecem self-service
- Reduzem carga cognitiva
- APIs internas
2. Inverse Conway Maneuver
Em vez de aceitar que estrutura → arquitetura,
organize times para produzir arquitetura desejada.
Quer microserviços? Crie times pequenos autônomos.
Quer monolito modular? Crie time único com squads.
3. Inner Source
# Qualquer dev pode contribuir para qualquer repo
# Owners revisam PRs de outros times
# Reduz dependências bloqueantes
# Exemplo de fluxo
time_a_needs_feature_in_service_b():
# Em vez de esperar Time B:
time_a_implements_feature()
time_a_opens_pr_to_service_b()
time_b_reviews_and_merges()
# Resultado: dias → horas
4. Platform Engineering
Antes:
Cada time configura infra: 2 dias/deploy
10 times × 2 dias = 20 dias-dev/sprint
Depois:
Plataforma self-service
Cada time: 1 hora/deploy
10 times × 1 hora = 10 horas/sprint
ROI: 19.5 dias-dev economizados/sprint
Práticas que Aceleram
1. Trunk-Based Development
# Em vez de branches de longa vida
# PRs pequenos, merge frequente
git checkout main
git pull
# Mudança pequena
git commit -m "feat: add button"
git push
# PR reviewed e merged em < 4 horas
2. Feature Flags
# Deploy ≠ Release
# Código em produção, feature desligada
if feature_flags.is_enabled('new_checkout', user):
return new_checkout(cart)
else:
return old_checkout(cart)
# Permite:
# - Deploy contínuo
# - Rollback instantâneo
# - Testes em produção
3. Docs as Code
# Documentação versionada com código
# Review junto com PR
# Sempre atualizada
## API de Pagamentos
### POST /payments
Request:
...
Atualizado em: (auto-generated from code)
4. Runbooks Automatizados
# Em vez de: "chame o João às 3am"
# Runbook executável
@runbook("High CPU Alert")
def handle_high_cpu():
# 1. Coletar diagnóstico
metrics = collect_cpu_metrics()
# 2. Tentar mitigação automática
if metrics.is_spike:
scale_up()
return
# 3. Se não resolveu, escalar
page_oncall(metrics)
Medindo Progresso
Dashboard Organizacional
┌─────────────────────────────────────────────────┐
│ ORGANIZATIONAL HEALTH │
├─────────────────────────────────────────────────┤
│ Deploy Frequency: 12/day [ELITE] │
│ Lead Time: 2.3 hours [ELITE] │
│ MTTR: 45 minutes [ELITE] │
│ Change Failure: 8% [ELITE] │
├─────────────────────────────────────────────────┤
│ Flow Efficiency: 35% [IMPROVING] │
│ Avg Cycle Time: 3.2 days [ON TARGET] │
│ WIP per dev: 1.8 [HEALTHY] │
└─────────────────────────────────────────────────┘
Tracking ao longo do tempo
Q1: Lead Time = 14 dias
- Reduziu aprovações obrigatórias
Q2: Lead Time = 5 dias
- Implementou trunk-based
Q3: Lead Time = 1.5 dias
- Feature flags para desacoplamento
Q4: Lead Time = 4 horas
Anti-patterns Organizacionais
1. Hero Culture
❌ "João salvou a produção às 3am de novo!"
→ Indica: falta de documentação, testes, automação
→ João é single point of failure
→ Burnout garantido
2. Blame Culture
❌ "Quem deployou isso?!"
→ Times escondem problemas
→ Não reportam incidentes
→ Cultura de medo
3. Process Worship
❌ "O processo diz que precisa de 3 aprovações"
→ Processo existe para servir, não para ser servido
→ Revise processos regularmente
→ Elimine burocracia
Conclusão
Performance organizacional é multiplicador:
Time rápido × Organização lenta = Sistema lento
Time normal × Organização rápida = Sistema rápido
Para melhorar:
- Meça DORA metrics e flow efficiency
- Reduza handoffs e aprovações
- Automatize processos repetitivos
- Empodere times com ownership
- Elimine silos de conhecimento
A pergunta não é "quão rápido seu código roda?" mas "quão rápido você consegue mudar seu código?"
Organizações otimizadas para controle são lentas. Organizações otimizadas para fluxo são rápidas.