Conceito desenvolvido por Matthew Skelton e Manuel Pais, publicado originalmente no livro Organizing Business and Technology Teams for Fast Flow de 2019 – “O verdadeiro gargalo, o real limitador à nossa capacidade de entrega de software, não é a tecnologia, mas um fator humano, a Carga Cognitiva da Equipe.”
Além da Teoria da Carga Cognitiva, outro alicerce teórico do Team Topology é a Lei de Conway. Os autores, Skelton e Pais, argumentam que, se você ignorar essa teoria, que recebeu a alcunha de Lei dada sua ubiquidade, sua estrutura organizacional e sua arquitetura de software estarão em constante conflito.
Os 3 conceitos-chaves são: Há 3 tipos de carga cognitiva a serem consideradas, 3 modos de interação a serem desenvolvidos em combinação e 4 tipos de times, um com domínio do fluxo de valor, um habilitador (especialialidades transversais), um de plataforma (infraestrutura) e um de subsistemas complexos.
LEI DE CONWAY
A Lei de Conway, formulada por Melvin Conway em 1967, afirma que: “As organizações que desenvolvem sistemas são limitadas a produzir designs que são cópias das estruturas de comunicação dessas organizações”. Em termos simples: o software vai ter a “cara” da empresa que o criou.
Conway trabalha três pontos centrais: Espelhamento (se a interação entre os times é ruim, a integração entre os módulos que eles criam também será ruim), Comunicação (a forma como as pessoas conversam e se organizam dita a arquitetura técnica) e Manobra Reversa (organizar seus times como você deseja que seu software seja).
Um exemplo frequente é o dilema de desenvolvimento monolítico ou usando microsereviços, esta abordagem aponta que é preciso ter times pequenos e ágeis para a partir deles desenvolver uma arquitetura de microsserviços desacoplada e ágil. Não adianta tentar criar um sistema dinâmico e integrado se seus times são isolados em silos.
TEORIA DA CARGA COGNITIVA (3 tipos)
A Teoria da Carga Cognitiva foi desenvolvida por John Sweller na década de 1980, publicada em seu artigo seminal de 1988. A teoria surgiu para otimizar o design instrucional, adaptando a carga mental à capacidade limitada da memória de trabalho humana – A sobrecarga gera desperdício e retrabalho!
Resumindo, é o esforço mental imposto à memória de trabalho durante o processamento de informações. Essa teoria explica que, como a capacidade da memória é limitada, o excesso de estímulos causa sobrecarga, prejudicando a aprendizagem e a efetividade da mesma.
Assim, o verdadeiro gargalo no desenvolvimento e entrega de software de valor, depende de como a organização gerencia o esforço mental de suas equipes. Se um time tem responsabilidades demais, a entrega desacelera e a consequência é o desperdício, retrabalho, baixa qualidade, impedimentos e, em extremos, burnouts.
A organização dos times deve respeitar o limite de quanto um ser humano consegue processar. Team Topology propõem três tipos de carga cognitiva, a Intrínseca representando a complexidade de domínio, a Extrínseca representando o desperdício ou processos desnecessários, e a Germana representando o foco no aprendizado de valor.
OS QUATRO TIPOS DE EQUIPES SEGUNDO A TEAM TOPOLOGY
Em meio a conceitos e perspectivas para a definição da estrutura organizacional dedicada a desenvolvimento de software, há apenas 4 tipos fundamentais de equipes necessários. Deliberadamente prescritivo, são: Stream-Aligned Team, Platform Team, Enabling Team e Complicated-Subsystem Team.
Tipo 1: Stream-Aligned Team – Equipe alinhada a um fluxo de trabalho único e valioso. Tem como características: Full-stack/full-lifecycle e ter a propriedade de ponta a ponta (“You Build It, You Run It”). Tem como propósito, entregar valor de forma: rápida, segura, independente e ter mínimos hand-offs com outras equipes.
Tipo 2: Platform Team – Equipe que fornece APIs, ferramentas, serviços e conhecimento por autoatendimento, tratados como produto interno. Tem como Característica ser um produto interno, simplificar a complexidade, construir o essencial (TVP), adoção voluntária e entregas úteis, simples e documentadas. Tem como Propósito, promover a melhoria contínua sem gerar dependências, aumentar a autonomia dos times e ajudá-los a incorporar boas práticas, técnicas e ferramentas.
Tipo 3: Enabling Team – Equipe formada por especialistas que ajuda os outros times a adquirirem novas capacidades e superar bloqueios. Tem como Características o engajamento temporário, coaching, mentoria e facilitação, incorporar práticas como DevOps, segurança, dados, etc e elevar a maturidade técnica. Tem como propósito, aumentar a autonomia dos outros times, acelerar o aprendizado, boas práticas e remover bloqueios críticos que impedem o fluxo de valor.
Tipo 4: Complicated-Subsystem Team – Equipe responsável por um subsistema que exige conhecimento profundo e especializado. Tem como características, lidar com complexidade intrínseca ao domínio, oferecer serviço, centralizando especialistas para reduzir custo, duplicação e dependências. Tem como propósito, reduzir a Carga Cognitiva geral, permitir que os outros times consumam capacidades complexas, simplificando o acesso a tecnologias avançadas.
OS 3 TIPOS DE MODOS DE INTERAÇÃO
Os 3 tipos definidos no framework Team Topologies, de Matthew Skelton e Manuel Pais, são:
Tipos de interações no Team Topologies são as formas estruturadas como as equipes se comunicam e colaboram para garantir um fluxo rápido de entrega e reduzir a carga cognitiva. Elas servem para definir limites claros de atuação e responsabilidades, evitando a entropia e dependências desnecessárias ou ineficientes.
1. Colaboração (Collaboration) – Duas equipes trabalham juntas por um período determinado para resolver um problema compartilhado, descobrir uma nova solução ou cruzar competências. É ideal para inovação e descoberta, mas exige alta carga cognitiva de ambos os lados.
2. X-as-a-Service (X-como-Serviço) – Uma equipe fornece algo (um componente, API ou plataforma) que outra equipe consome com o mínimo de interação direta. É focado na previsibilidade e na redução da necessidade de reuniões constantes.
3. Facilitação (Facilitating) – Uma equipe (geralmente uma equipe de especialistas ou enabling team) ajuda outra equipe a aprender uma nova tecnologia, reduzir uma lacuna de conhecimento ou remover um impedimento técnico. O objetivo é aumentar a autonomia da equipe facilitada.
DOCUMENTAÇÃO (REGRAS EXPLÍCITAS)
O livro propõe que os times tenham uma interface documentada, com suas regras e processo, definindo o que a equipe faz, o que fornece e como outras equipes devem interagir com ela. O objetivo é tornar explícitos os modos de interação de forma clara e transparente (Collaboration, X-as-a-Service, Facilitating), reduzir atrito e ambiguidade entre equipes.
Finalmente, algumas dicas sobre o que evitar (anti-patterns), como equipes temporárias, sem ownership, pois perdem contexto e quebram continuidade, e também evitar hierarquias rígidas e microgerenciamento. Quanto a plataforma, é importante ser imposta, precisa ser discutida e co-criada, evitando burocracia e resistência ao uso.
Jorge Horácio "Kotick" Audy 