Team Topologies

Arquitetura de software e desenho de times não são assuntos separados. A lei de Conway observa que sistemas tendem a copiar a estrutura de comunicação de quem os constrói: três times separados por camada produzem um sistema em três camadas, com uma reunião no meio de cada mudança.

A consequência prática é útil: se você quer serviços com fronteiras claras e times capazes de entregar sozinhos, precisa organizar as pessoas assim primeiro. É a “manobra reversa de Conway” — mudar a estrutura dos times para obter a arquitetura desejada.

Os quatro tipos de time

Alinhado a fluxo (stream-aligned). O time principal, e a maioria deveria ser deste tipo: responsável por um fluxo de valor de ponta a ponta — um produto, uma jornada, um domínio — incluindo operar o que constrói.

Plataforma. Oferece serviços internos que reduzem a carga dos times de fluxo: pipeline, ambientes, observabilidade, provisionamento. Trata os outros times como clientes, com produto, documentação e autoatendimento — o assunto da trilha de plataforma.

Habilitador (enabling). Ajuda outros times a adquirir capacidade nova — testes, segurança, observabilidade — por tempo limitado. O sucesso é a própria dispensa: se o time habilitador virou dependência permanente, ele virou gargalo.

Subsistema complicado. Cuida de uma parte que exige especialidade rara (motor de cálculo atuarial, processamento de vídeo, criptografia). Existe por necessidade, não por conveniência organizacional.

Se a sua organização tem cinco tipos de time e a maioria não é de fluxo, provavelmente há mais dependências que capacidade de entrega.

Modos de interação

Tão importante quanto o tipo é como os times interagem — e o modo precisa ser explícito, com prazo:

• Colaboração: dois times trabalham juntos, de perto, para descobrir algo novo. Produtivo e caro; deve ser temporário, porque borra responsabilidades.
• Serviço (X-as-a-Service): um time consome o que o outro oferece, com contrato claro e sem conversa a cada uso. É o modo alvo para plataforma.
• Facilitação: um time ajuda o outro a aprender. Temporário por definição.

O padrão de amadurecimento é ir de colaboração para serviço: descobre-se junto, depois transforma-se em interface estável e autoatendimento.

Carga cognitiva como limite

A ideia mais prática do modelo: um time tem um limite de quanta coisa consegue manter na cabeça. Estoure esse limite e tudo degrada — qualidade, prazo, plantão, retenção.

Sintomas de carga cognitiva excedida:

• O time é dono de sete serviços e conhece bem dois.
• Ninguém sabe explicar como um dos sistemas funciona.
• Toda mudança precisa da mesma pessoa.
• O plantão exige conhecimento que só metade do time tem.

As saídas, em ordem de preferência: reduzir o escopo do time (menos domínios), mover complexidade para a plataforma (o time deixa de operar Kubernetes e passa a consumir um golden path), ou isolar a parte complicada em um time especializado. Contratar mais gente para o mesmo time raramente resolve — aumenta o custo de comunicação sem reduzir a carga.

Aplicando sem reorganizar a empresa

Você não precisa de um redesenho organizacional para usar isso. Três exercícios com bom retorno:

1. Liste os times e classifique por tipo. Se quase nenhum é alinhado a fluxo, você encontrou o problema.
2. Desenhe as dependências: quem precisa esperar quem para entregar. Cada seta é um candidato a virar autoatendimento.
3. Pergunte ao time quanta coisa ele carrega — quantos sistemas, quantas tecnologias, quantos plantões. Compare com o que ele domina de fato.

E cuide do tamanho: times pequenos e estáveis (na faixa de cinco a nove pessoas) mantêm confiança e contexto. Reorganização frequente destrói os dois, e o custo aparece meses depois, sem que ninguém ligue uma coisa à outra.

Próximo passo: encontre onde o trabalho realmente espera em Mapeamento de fluxo de valor.