Em 1968, o engenheiro Melvin Conway formulou (1) uma observação que o tempo não envelheceu: as organizações tendem a produzir sistemas que espelham a sua estrutura de comunicação interna. Por outras palavras, a forma como organizamos as pessoas, a organização real, acaba por ditar a forma como os produtos, serviços ou processos são concebidos.
Por exemplo, se três departamentos independentes, com comunicação escassa entre si, forem responsáveis por desenhar um novo serviço ao cliente, o resultado será, quase inevitavelmente, um serviço fragmentado, que reflete as fronteiras internas da organização e não as necessidades do cliente. A estrutura organizacional tornou-se, sem querer, o principal arquiteto do produto.
Quase sessenta anos depois, esta ideia tornou-se ainda mais relevante porque vivemos num contexto em que a velocidade de mudança exige que as organizações recombinem pessoas, conhecimentos e processos de forma contínua.
A organização real é feita de comunicação
O organigrama mostra quem reporta a quem. A organização real é outra coisa: é feita de padrões de comunicação: quem fala com quem, com que frequência, sobre o quê. É nesse tecido que as decisões se tomam e os problemas se resolvem ou persistem.
A estrutura de comunicação não é um pormenor de funcionamento interno; é uma alavanca de desempenho. Quando os fluxos de informação são lentos, ambíguos ou interrompidos por fronteiras organizacionais desnecessárias, nem os melhores profissionais conseguem compensar o que a estrutura dificulta.
Team Topologies: um modelo para pensar a estrutura de equipas
Em 2019, Matthew Skelton e Manuel Pais apresentaram o modelo Team Topologies para desenho da estrutura e interações de equipas (3). Embora tenha emergido no mundo do desenvolvimento de software, a sua lógica é suficientemente universal para se aplicar a organizações de qualquer sector.
O modelo assenta em dois pilares complementares: os quatro tipos de equipa e os três modos de interação entre equipas. Em conjunto, definem não apenas o que cada equipa faz, mas como as equipas se podem relacionar entre si.
Os quatro tipos de equipa
1. Equipa de Fluxo (Stream-Aligned Team)
É o tipo central do modelo. Organizada em torno de um fluxo de valor contínuo – um produto, um segmento de clientes ou uma linha de negócio -, tem autonomia para entregar resultados de ponta a ponta, sem depender constantemente de outras equipas. É responsável, ágil e orientada para o impacto direto no cliente ou utilizador final. Por exemplo, numa seguradora, seria a equipa dedicada ao produto de seguro de saúde individual, ou numa cadeia de retalho, a equipa que gere a experiência de compra online.
2. Equipa de Plataforma (Platform Team)
Fornece um conjunto integrado de serviços, tecnologia e conhecimento que permite às equipas de fluxo realizar o seu trabalho com maior autonomia e velocidade. O seu “cliente” interno são as outras equipas da organização, e o seu sucesso mede-se pelo sucesso dessas equipas. Exemplos incluem a equipa de recursos humanos que centraliza o recrutamento para toda a organização, ou a equipa de infraestrutura logística que assegura o reabastecimento das lojas de uma empresa de distribuição.
3. Equipa Facilitadora (Enabling Team)
O seu propósito é desenvolver e aumentar as capacidades das equipas de fluxo, sem que essas equipas tenham de fazer todo o esforço associado. Identifica lacunas de competência, dissemina práticas e apoia a adoção de novas formas de trabalhar. A sua interação é, por natureza, temporária e orientada para a transferência de conhecimento. Reconhece-se numa equipa de transformação digital que apoia na adoção de novos modelos de gestão de projetos, ou numa equipa de excelência operacional que acompanha unidades fabris na implementação de metodologias de melhoria contínua.
4. Equipa de Subsistema Complicado (Complicated Subsystem Team)
A equipa de subsistema complicado justifica-se quando determinada área exige um exige um grau de especialização tão elevado que integrá-las numa equipa de fluxo seria contraproducente. A sua existência protege as equipas de fluxo de serem sobrecarregadas com domínios que exigem anos de especialização. É o caso da equipa de modelação estatística para ensaios clínicos numa empresa farmacêutica, ou da equipa de algoritmos de personalização de conteúdo num grupo de media digital.
Os três modos de interação
Tão importante quanto definir o tipo de cada equipa é decidir como as equipas podem interagir entre si.
Colaboração (Collaboration)
A colaboração é o modo indicado quando a incerteza é elevada e é preciso aprender depressa. Duas ou mais equipas partilham responsabilidades e descobrem soluções em conjunto, o que acelera a aprendizagem, mas tem um custo real em tempo e alinhamento. Deve ser usada de forma deliberada e temporária, não como modo de funcionamento permanente.”
Serviço (X-as-a-Service)
Uma equipa fornece algo que outra consome de forma autónoma, sem necessidade de coordenação frequente. É o modo ideal quando a interação está bem definida e os requisitos são estáveis libertando as equipas para o seu foco principal e reduzindo o esforço de coordenação. O risco está na rigidez: um serviço que não evolui ao ritmo de quem o usa torna-se rapidamente um obstáculo.
Facilitação (Facilitation)
Uma equipa experiente acompanha outra durante um período delimitado, com o objetivo de desenvolver competências ou superar um obstáculo concreto. A prazo, o resultado é maior autonomia e menos dependências. O custo é o tempo de profissionais experientes afastados do trabalho direto e o risco de, quando mal-executada, a facilitação se transformar numa dependência ou ser sentida como micro-gestão.
Em suma, os modos de interação não são neutros. Cada um tem as suas vantagens e desvantagens.
Estruturar equipas é uma decisão estratégica
Numa era em que a transformação é contínua e a complexidade cresce, a capacidade de estruturar equipas com propósito torna-se uma vantagem competitiva real.
Na próxima vez que estiver a definir a estrutura de um projeto, lembre-se de Conway: que resultado quero alcançar e que estrutura e padrões de comunicação preciso criar para o conseguir?
Referências
(1) Conway, M. E. (1968). How do committees invent? Datamation, 14(4), pp. 28–31.
(2) Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
(3) Skelton, M. and Pais, M. (2022). Team Topologies: Organizing Business and Technology Teams for Fast Flow (2nd ed.). IT Revolution Press.
