Team Topologies na Prática: Escolher a Estrutura de Equipa Certa
O "Team Topologies" de Skelton e Pais (2019) deu à liderança de engenharia um vocabulário partilhado para a estrutura de equipas. Mas já vi organizações a ler o livro, renomear todas as suas equipas para encaixar nos quatro tipos, e não mudar nada sobre como o trabalho realmente flui. Outras criam equipas de plataforma antes de terem algo para platformizar.
Aqui está como realmente aplicá-lo na prática, incluindo quando reestruturar e quando deixar as coisas como estão.
Os Quatro Tipos de Equipa: Uma Revisão Rápida
Se já leste o livro, passa para a próxima secção. Se não leste, aqui está o modelo central.
As equipas stream-aligned são as unidades primárias de entrega de valor. Detêm um fluxo de trabalho — um produto, um conjunto de funcionalidades, um domínio de negócio. Multifuncionais e capazes de entregar end-to-end. A maioria dos teus engenheiros deve estar aqui.
As equipas enabling ajudam outras equipas a adotar novas tecnologias ou capacidades. Não constroem coisas para outras equipas — ajudam outras equipas a construir coisas por si próprias. Temporárias por design.
As equipas de plataforma fornecem serviços internos que as equipas stream-aligned consomem como self-service. CI/CD, deployment, infraestrutura partilhada. Se as equipas precisam de abrir um ticket e esperar, construíste um bottleneck, não uma plataforma.
As equipas de subsistema complexo detêm componentes que requerem conhecimento especializado profundo — modelos ML, pipelines de dados em tempo real, motores financeiros complexos. Criadas quando a carga cognitiva é demasiado elevada para uma equipa stream-aligned suportar.
Quando Criar Cada Tipo de Equipa
O erro mais comum é criar todos os quatro tipos de uma vez porque o livro descreve quatro tipos. Na prática, introduzes-os à medida que a necessidade surge.
Stream-Aligned: Começa Aqui, Sempre
Cada organização de engenharia começa com equipas stream-aligned, quer as chame assim ou não. Se tens uma equipa a construir um produto, isso é uma equipa stream-aligned.
À medida que cresces, a questão torna-se: como divides? A resposta deve seguir as tuas fronteiras de domínio, não as tuas camadas técnicas. Divide por percurso do utilizador, domínio de negócio, ou área de produto — não por frontend/backend/infraestrutura.
Quando criar uma nova equipa stream-aligned: Quando a carga cognitiva numa equipa existente é demasiado elevada — detêm demasiados domínios, a mudança de contexto é constante, e a equipa está sempre ocupada mas a entregar lentamente.
Plataforma: Não Antes de Teres Procura Real
É aqui que vejo mais erros. A conversa vai assim: "Devíamos ter uma equipa de plataforma." "O que é que eles construiriam?" "Sabes... a plataforma."
Uma equipa de plataforma faz sentido quando:
- Múltiplas equipas stream-aligned estão a construir a mesma coisa de forma independente. Três equipas a construir cada uma a sua própria pipeline de deploy ou configuração de logging sinaliza que uma capacidade de plataforma partilhada pouparia tempo.
- As equipas stream-aligned estão a gastar tempo significativo em trabalho não diferenciante. Se as equipas de produto gastam 30% do seu tempo na manutenção de infraestrutura ou CI/CD, uma equipa de plataforma pode absorver esse fardo.
- O modelo self-service é viável. Se a "plataforma" requer trabalho personalizado para cada consumidor, tens uma fila de serviços partilhados, não uma plataforma.
Não cries uma equipa de plataforma quando: Tens menos de 4-5 equipas stream-aligned, ou quando a "plataforma" é realmente apenas as necessidades de infraestrutura de uma equipa disfarçadas de iniciativa partilhada. Começa com documentação e bibliotecas partilhadas. Se a procura por uma plataforma real crescer, saberás.
Enabling: O Tipo Mais Subutilizado
A maioria das organizações não tem equipas enabling, e deveria. A equipa enabling é a resposta a uma questão que ouço constantemente: "Como fazemos todas as nossas equipas adotarem X?"
X pode ser:
- Observabilidade (logs, métricas, traces)
- Uma nova framework de testes
- Melhores práticas de segurança
- Uma migração de uma base de dados para outra
- Padrões de design de API
Sem uma equipa enabling, a adoção ou é mandatada de cima para baixo (criando ressentimento) ou não acontece de todo. Uma equipa enabling trabalha ao lado das equipas stream-aligned como coaches — pair programming, workshops, construindo ferramentas que facilitam a adoção.
Princípio chave: As equipas enabling devem ter um limite de tempo. Existem para transferir uma capacidade, não para a deter permanentemente. Se a tua está a "ajudar as equipas a adotar observabilidade" há 18 meses, algo está errado.
Subsistema Complexo: O Tipo Mais Raro
Precisas de uma equipa de subsistema complexo quando o conhecimento especializado necessário para um componente é tão profundo que integrá-lo numa equipa stream-aligned sobrecarregaria a carga cognitiva dessa equipa.
Exemplos:
- Um motor de recomendação em tempo real que requer expertise em ML
- Um módulo de processamento de pagamentos com requisitos regulatórios complexos
- Uma pipeline de transcodificação de vídeo que requer conhecimento profundo de media engineering
- Um compilador ou runtime de linguagem
O teste é simples: Um engenheiro generalista sólido numa equipa stream-aligned conseguiria manter este componente? Se sim, não precisas de uma equipa dedicada. Se a resposta é "apenas se passar 80% do tempo nisto", esse é o teu sinal.
A maioria das startups e organizações de engenharia de média escala tem zero ou uma equipa de subsistema complexo. Se tens mais de duas, questiona se estás a super-especializar.
Os Três Modos de Interação
Os modos de interação são a parte do Team Topologies que as pessoas saltam, e não deveriam. Como as equipas interagem importa tanto como como estão estruturadas.
Modo de colaboração. Duas equipas trabalham juntas de perto durante um período definido. Alto bandwidth, alto custo. Usa para descoberta e trabalho em fase inicial, não como estado permanente. Se duas equipas estão permanentemente em colaboração, devem fundir-se.
Modo X-as-a-Service. Uma equipa fornece uma capacidade através de uma interface bem definida. O modo principal entre equipas de plataforma e stream-aligned. Só funciona se for genuinamente self-service.
Modo facilitante. Uma equipa ajuda outra a aprender ou adotar uma capacidade. Como as equipas enabling interagem com as equipas stream-aligned. O objetivo é a autossuficiência.
Quando Reestruturar (e Quando Não)
As reorganizações são caras. Cada reorg perturba relações e custa semanas de produtividade.
Reestrutura quando: As equipas não conseguem entregar end-to-end sem bloquear umas as outras. O âmbito de uma equipa é tão grande que estão permanentemente a mudar de contexto. Duas equipas estão em modo de colaboração permanente (funde-as). Tens procura clara de plataforma mas sem equipa de plataforma.
Não reestrutures quando: Apenas queres "experimentar o Team Topologies." O problema são as pessoas, não a estrutura. A equipa funciona bem mas não encaixa na taxonomia. Reorganizaste há menos de 6 meses.
Erros Comuns
Criar uma equipa de plataforma demasiado cedo. Construindo ferramentas que ninguém usa enquanto as equipas stream-aligned resolvem as suas próprias necessidades.
Não ter equipas enabling de todo. Cada iniciativa de adoção torna-se um mandato de cima para baixo ou um esforço grassroots que se apaga.
Rotular equipas sem mudar como trabalham. Renomear "Equipa Backend" para "Equipa de Plataforma" não a torna uma.
Ignorar a carga cognitiva. Toda a framework é construída sobre ela. Se não estás a avaliar se as equipas estão sobrecarregadas, estás a perder o ponto.
Na Conectia, quando integramos engenheiros sénior LATAM em organizações de engenharia em crescimento, prestamos muita atenção à estrutura da equipa. O engenheiro certo na equipa errada entrega menos valor do que um bom engenheiro numa equipa bem estruturada. Os nossos engenheiros têm experiência com configurações distribuídas e multi-equipa e compreendem como as dinâmicas de equipas stream-aligned, de plataforma e enabling funcionam na prática — não apenas na teoria.
A estruturar as tuas equipas de engenharia para o crescimento? Fala com um CTO — colocamos engenheiros sénior que compreendem as dinâmicas de equipa e se integram perfeitamente na estrutura da tua squad desde a primeira semana.
