Antes de adotar IA, reorganize seus times em torno de fluxos de valor

Antes de levar IA para a sua empresa, há uma alavanca cujo retorno supera qualquer ferramenta ou modelo que você venha a escolher: reorganizar os times técnicos em torno de fluxos de valor. Já vi demais empresas comprarem as ferramentas, subirem os modelos, treinarem as pessoas — e a entrega continuar arrastada, com o time mais exausto do que antes. A causa raiz quase nunca é IA fraca. É que os times estão cortados por camadas técnicas (front-end, back-end, algoritmo, operações, segurança). Uma funcionalidade ponta a ponta atravessa quatro, cinco times, e cada handover deixa algo cair no chão. O requisito perde um pedaço. O contexto perde um pedaço. O senso de dono perde um pedaço. Acerte as fronteiras dos times, e a IA encontra onde amplificar. Erre as fronteiras, e a IA só acelera a produção de dívida em cima de uma estrutura quebrada.

Este artigo apresenta um método de desenho organizacional que você consegue colocar em prática — Team Topologies (Skelton & Pais, 2019). No centro dele há três ideias: cortar times por fluxo de valor, vigiar a carga cognitiva de cada time, e tratar a plataforma interna como produto. Vou destrinchar isso com um caso real da manufatura.

Um CIO de manufatura (caso anonimizado a partir de um projeto real) me contou o seguinte: subir uma funcionalidade de IA para inspeção inteligente de qualidade não era tecnicamente difícil. Câmeras detectam defeitos, o modelo é pronto. O difícil era a entrega. O time de front-end fazia a interface, o time de MES reworkava o fluxo de ordens de serviço, o time de algoritmo fazia o deploy do modelo, o time de operações cuidava dos servidores, e o time de segurança ainda precisava auditar tudo. Uma funcionalidade, 5 times, 4 handovers formais, 3 meses de arrasto. Ninguém estava cruzando os braços. Cada handover simplesmente deixava cair alguma coisa.

1. A Lei de Conway só conta metade da história

A Lei de Conway diz o seguinte: a arquitetura de um sistema espelha a estrutura de comunicação do time que o constrói. Divida seus times em front-end e back-end, e você vai ter um sistema separado em front-end e back-end. O time se comunica de um jeito, o sistema cresce daquele jeito. Evidência empírica confirma isso vez após vez.

Mas Conway só nos disse que isso acontece. Ele não disse como desenhar times para que uma boa arquitetura cresça sozinha. Skelton e Pais fecharam essa lacuna com Team Topologies (2019): quatro tipos básicos de time, três modos de interação, e um princípio que perpassa tudo — vigiar a carga cognitiva.

2. Os quatro tipos de time: opções para uma reorganização, não jargão para decorar

Vou passar por esses quatro tipos como opções que você pode acionar durante uma reorganização. Não precisa decorar definição.

Times stream-aligned — o cavalo de batalha da sua organização, e a esmagadora maioria deles. (O livro diz “most”, sem proporção fixa.) Um “stream” é um fluxo contínuo de valor. Um time stream-aligned é dono de um trecho desse fluxo de ponta a ponta — entender o requisito, construir, subir para produção, operar. Um único teste diz se um time se enquadra: ele consegue entregar valor nas mãos do usuário sem depender de outro time? De volta àquele CIO: se a funcionalidade de inspeção inteligente pertencesse a um único “time do stream de inspeção” — com gente que entende de front-end, de integração com MES, de deploy de modelo e de operações, tudo no mesmo time — a funcionalidade sai com zero handover. É esse o formato que deveria existir.

O problema mais comum em grandes empresas é que o sistema roda ponta a ponta, mas os times estão fatiados em camadas técnicas horizontais. Cada entrega ponta a ponta precisa atravessar as fronteiras de reporte de vários times. Troca de setor, e o padrão se repete — só mudam os nomes. Em finanças, uma funcionalidade de crédito e risco precisa cruzar quatro grupos: o time do app, o time do core bancário, o time de modelos de risco e o time de dados. E-commerce e telecom comprimem a mesma dor em palavras diferentes: uma promoção cruza catálogo, transação, marketing e armazém; uma mudança de plano cruza canal, billing, CRM e rede. Sempre que times fatiados na horizontal tentam servir um fluxo de valor que corre na vertical, os handovers se multiplicam. Essa é a doença.

Times de plataforma — pavimentando a estrada para os times stream-aligned. Um time de plataforma oferece infraestrutura, CI/CD e serviços compartilhados para que os times stream-aligned consumam capacidade em self-service, em vez de abrir ticket e esperar. Um teste: sua plataforma interna é operada como produto — com usuários, roadmap, SLA — ou deslizou para ser uma “terceirização interna” que vive de ticket? A maioria das áreas de TI de grandes empresas está presa na segunda. Constroem uma plataforma que ninguém usa, os times de negócio contornam e fazem cada um o seu, e o time de plataforma degrada até virar um prestador terceirizado. Spinnaker da Netflix (entrega contínua) e Backstage do Spotify (portal do desenvolvedor) são os exemplos de manual de uma plataforma operada como produto. As pessoas vivem trocando esses dois: Spinnaker é da Netflix, Backstage é do Spotify. Não erre disso na frente da diretoria.

Times de habilitação (Enabling Team, no Team Topologies) — ajudam os times stream-aligned a subir de nível, com o objetivo explícito de trabalharem até se tornarem dispensáveis. Um time de habilitação não entrega o negócio diretamente. Ele eleva a capacidade dos times stream-aligned: um coach trazendo uma tecnologia nova, um guia para uma transição DevOps, um consultor de segurança e conformidade. A relação com o time stream-aligned é de mentor e aprendiz, não de cliente e fornecedor. Para grandes empresas, esse é o papel que um consultor externo de transformação deveria cumprir — transferir capacidade, não fabricar dependência de longo prazo.

Times de subsistema complexo — para os problemas duros que exigem especialização profunda. Quando um subsistema demanda profundidade real — um motor de risco, um algoritmo de recomendação, criptografia, codecs de vídeo — você o separa como um time próprio de especialistas, em vez de estourar a carga cognitiva de um time stream-aligned. Eles devem ser raros. Uma organização que vê brotar muitos times de subsistema complexo, na maioria das vezes está transformando em silos o que deveria ser capacidade de plataforma.

Só nomear os tipos de time não basta. É preciso definir como eles interagem. O Team Topologies traz três modos de interação. Colaboração — dois times trabalhando juntos de forma profunda, adequada para territórios novos e incertos, mas com alto gasto de energia e só em rajadas curtas. X-as-a-Service — um time oferece uma capacidade como produto que outro time consome por conta própria; é o modo mais eficiente e deveria ser o padrão. Facilitação — usado apenas por times de habilitação. A pergunta central do desenho organizacional é como empurrar o máximo possível de interações rumo ao X-as-a-Service. Se seus times ainda se apoiam em “colaboração” no longo prazo, a plataformação não aconteceu. Pegue a situação do CIO: o time de inspeção e o time de plataforma deveriam interagir como X-as-a-Service. A plataforma expõe um ponto de entrada de CI/CD em self-service, e o time de inspeção usa sem precisar combinar nada. Se todo deploy ainda exige uma reunião de “colaboração” com o time de plataforma, a plataformação está faltando — e o problema não é atitude. É que a plataforma nunca foi tratada como produto.

3. Por que “colocar mais gente” e “colocar mais processo” ambos falham: carga cognitiva

Essa é a contribuição mais subestimada do Team Topologies. Ele coloca a carga cognitiva no centro do desenho organizacional.

Um time de 5 a 8 pessoas tem uma carga cognitiva finita. Peça a um time manter uma dúzia de sistemas sem relação entre si, interfacear com seis ou sete fontes upstream e ainda lidar com três frameworks novos de uma vez — ele satura. A qualidade cai. A entrega atrasa. As pessoas entram em burnout.

Foi por isso que aquele CIO ficou confuso quando me disse: “Coloquei mais três pessoas, por que continuam lentos?” A raiz é que aquele grupo já carregava coisa demais e desconectada. O headcount estava bom. Colocar mais gente só faz mais corpos girarem no mesmo caos. Colocar mais processo é pior — o processo devora mais uma camada de carga cognitiva, e quem realmente conseguia entregar acaba gastando ainda mais tempo com formulário, reunião e aprovação.

A gordura mais fácil de cortar numa grande empresa é a carga que a própria organização cria — atrito entre times, troca constante de contexto, corredores de aprovação. Cortá-la não exige nenhuma tecnologia nova. Exige perturbar menos.

Um caso concreto. O líder de um time de core bancário tinha 7 pessoas interfaceando com quatro fontes upstream — risco, atendimento, reporte regulatório, marketing — ao mesmo tempo em que mantinha três módulos sem relação entre si. Só de processar assinaturas cruzadas, reuniões de alinhamento e trocas de contexto entre times, quase metade da energia do time era consumida por dia. Entregue a esse time a melhor ferramenta de IA do mercado, e ela não gruda. As pessoas não têm banda cognitiva sobrando para aprender nada de novo ou mudar a forma de trabalhar. Para salvá-lo, você reduz a carga primeiro: retira os módulos sem relação e deixa o time ser dono de um único fluxo de valor.

A regra do Two-Pizza Team da Amazon é sobre custo de comunicação — quando o headcount cresce, o número de canais de comunicação entre os membros (n(n-1)/2) explode, e a decisão fica lenta. O Team Topologies vai uma camada mais fundo: passado cerca de 8 pessoas, a carga cognitiva também escapa do controle. O que o desenho organizacional realmente faz é dividir times por carga cognitiva, de modo que a carga de cada time caiba numa faixa suportável — e não desenhar linhas de reporte por função.

Um check-up de uma frase para grandes empresas: aquelas suas “pessoas mais ocupadas” estão cada uma carregando mais de 5 coisas desconexas ao mesmo tempo? Se a resposta for sim, nada de headcount ou de processo vai salvar. É preciso redividir.

4. Como agir: o Conway reverso

Essa é a jogada mais operacional do livro. Não desenhe a arquitetura primeiro para depois reorganizar os times para encaixar nela. Mude a estrutura dos times primeiro, e deixe a arquitetura crescer no formato que você quer.

A abordagem tradicional tem um arquiteto desenhando uma arquitetura-alvo (“vamos de microsserviços!”) e então exigindo que os times se reorganizem para servir a ela. Isso quase sempre falha. A estrutura atual de times continua puxando a arquitetura de volta para o próprio formato. A Lei de Conway, fazendo o que ela faz.

O Conway reverso inverte a ordem. Reorganize os times em torno de fluxos de valor primeiro — carve out os times stream-aligned, levante um time de plataforma — de modo que as fronteiras dos times se tornem as futuras fronteiras de serviço. Aí a arquitetura converge, por conta própria, para uma divisão sensata de serviços, porque os times passam a se comunicar naturalmente por API em vez de enfiar a mão num banco de dados compartilhado.

De volta ao CIO. Não pedi que ele escolhesse um framework de microsserviços. Pedi que fizesse algo bem mais simples: erguer “inspeção” como um time próprio de stream. Puxar uma pessoa de cada um dos times originais de front-end, MES, algoritmo e operações. Seis pessoas, donas da funcionalidade de inspeção de ponta a ponta. Três coisas aconteceram em três semanas. Na primeira semana, descobriram que uma etapa que vivia gargalada no fluxo de ordem do MES na verdade nem precisava do time de algoritmo — resolveram dentro do time. Na segunda semana, decidiram por conta própria trocar o deploy do modelo de “ficar na fila do time de operações” por self-service dentro do time, porque o time de plataforma tinha aberto um ponto de CI/CD em self-service para eles. Na terceira semana, subiram a primeira pequena funcionalidade ponta a ponta, sem cruzar nenhuma fronteira de time. Nenhum headcount adicionado, nenhuma ferramenta trocada — as camadas horizontais foram recortadas em fluxos verticais. O ciclo de entrega caiu de 3 meses para 3 semanas. Um bônus inesperado veio em seguida: o time começou a propor melhorias por conta própria, porque pela primeira vez enxergavam o stream inteiro e eram donos do resultado de ponta a ponta. Quando isso cruzava 5 times antes, ninguém se sentia responsável pelo fluxo de inspeção como um todo.

Para quem decide, essa é uma conclusão contraintuitiva, mas de alta alavancagem: pare de se torturar sobre o diagrama de arquitetura e comece a cortar o organograma. A arquitetura é o resultado. A organização é a alavanca.

Quem está usando

Bancos (setor de foco oficial da TT + referência de regulação forte). O site teamtopologies.com mantém uma coluna de especialistas, “When DORA metrics meet governance in banking”. A pesquisa DORA ali citada é dura: aprovações externas correlacionam negativamente com lead time, deployment frequency e restore time — quanto mais aprovações cruzadas a posteriori entre times, mais lenta a entrega e mais lenta a recuperação de incidentes. Isso é exatamente a tese deste artigo: embutir conformidade dentro do time stream-aligned e antecipar a aprovação, em vez de depender de assinatura cruzada depois do fato. Bancos digitais britânicos como a ClearBank aparecem repetidamente no ecossistema oficial. O setor bancário é o cenário mais instrutivo para reorganização por fluxo de valor sob regulação pesada.
Zalando (e-commerce, o exemplar de plataforma como produto). Sua plataforma interna para desenvolvedores serve como capacidade em self-service para os times stream-aligned — um referencial de plataformação que a comunidade TT cita com frequência.
AutoTrader UK (classificados automotivos). Um caso real de adoção que a TT cita repetidamente — reorg por fluxo de valor somada à produtoização da plataforma interna.
KPMG UK (tornou-se parceiro oficial de soluções TT em 2024). Leva a TT para clientes de grande porte e financeiros — um sinal de que a TT já entrou na consultoria empresarial mainstream.
Netflix / Spotify (exemplares espirituais de “plataforma como produto”, não casos de adoção da TT). Ambos operavam suas plataformas como produto bem antes do livro da TT sair em 2019, validando o princípio — mas não são adoções do modelo de quatro times da TT.

Referência: teamtopologies.com/examples (biblioteca oficial de casos) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (coluna de especialistas sobre DORA em bancos)

5. Quando não funciona

O Team Topologies não é bala de prata. Quatro falhas comuns, cada uma mapeando para uma patologia real de grandes empresas.

Mudar o nome sem mudar a estrutura. Renomear “time de front-end” para “time stream-aligned” enquanto as linhas de reporte continuam por camada técnica — a Lei de Conway não se importa com o que você chama as coisas. Esse é o desfecho mais comum de uma reforma cosmética em uma grande empresa: etiquetas novas, mesma estrutura velha.

O time de plataforma não é tratado como produto. Sem roadmap, sem experiência de usuário. Os times stream-aligned continuam a contorná-lo, e a plataforma degrada até virar uma terceirização que vive de ticket.

Todo mundo está “colaborando”. Colaboração é uma interação de alto gasto de energia, adequada apenas para rajadas curtas em territórios novos e incertos. Depender dela no longo prazo significa que a plataformação não aconteceu. A superfície parece “cultura colaborativa saudável”. A doença é a plataformação ausente.

Os KPIs não foram atualizados. O organograma mudou, mas você continua medindo por função — linhas de código front-end, contagem de bugs — e o comportamento do time reverte num piscar de olhos para o formato antigo.

Essas quatro apontam para um julgamento: entre estrutura organizacional, estrutura de incentivos e arquitetura técnica, mudar qualquer uma das três sem que as outras duas acompañem, e a transformação falha.

Uma variante para setores fortemente regulados. Finanças e telecom vão perguntar: funções como segurança, conformidade e risco de TI são exigidas por regulação como independentes (segregation of duties). Elas não podem ser simplesmente dobradas dentro dos times stream-aligned. Isso é uma restrição legal dura, não inércia organizacional — não force a separação. Mas você também não precisa voltar às filas de aprovação horizontal. Dois caminhos. Primeiro, embutir representantes de conformidade e segurança dentro do time stream-aligned: eles sentam no time, ao mesmo tempo em que reportam em linha pontilhada para a função de conformidade — colados ao fluxo de valor e ainda assim preservando independência. Segundo, organizar a conformidade como um time de habilitação, que ajuda os times stream-aligned a construir requisitos regulatórios dentro do fluxo — checagens de conformidade rodando dentro do CI, por exemplo — deslocando a aprovação para dentro do time em vez de depender de assinatura cruzada depois do fato. Os requisitos regulatórios viram qualidade embutida do time stream-aligned, não um portão de revisão externa. Essa é a chave para setores fortemente regulados conseguirem “fluir”.

6. Você pode estar se perguntando

“Estamos cortados por camada técnica há dez anos — uma reorg não vai ser traumática?” Vai, mas bem menos do que você imagina. Não precisa derrubar a empresa inteira e recomeçar. Escolha o fluxo de valor mais engasgado — em geral, aquele de que todo mundo mais reclama — e erga-o como um piloto de um único time stream-aligned. Como aquele CIO: 4 a 8 semanas, um time pequeno, e você vai ver uma mudança nítida na velocidade de entrega. Deixar o resultado vender a próxima rodada funciona muito melhor do que deixar um slide deck vender.

“Como isso se conecta com a transformação de IA que já estou rodando?” Diretamente. A IA não conserta uma organização mal ajustada. Ela amplifica o que já está lá: times de alto desempenho que pegam IA ficam mais rápidos; times mal ajustados que pegam IA só fabricam dívida mais rápido. Por isso o diagnóstico organizacional vem antes da compra de ferramentas. É também o motivo de eu colocar a “avaliação de capacidade” bem cedo no meu método-assinatura, o 7-Step AI Transformation Coaching Framework — olhar primeiro a organização e as pessoas, depois falar de ferramenta.

“E se não conseguirmos formar os quatro tipos de time?” A maioria das organizações não consegue, e não precisa. Os dois primeiros que você deveria ter são times stream-aligned (para garantir entrega ponta a ponta) e um time de plataforma (para parar de reinventar a roda). Times de habilitação e de subsistema complexo entram conforme a necessidade; muitas organizações começam sem eles, e tudo bem. Não fabrique times só para completar os quatro tipos. Isso é o rabo abanando o cachorro.

7. Lições para quem decide

Lição um: antes de adotar IA, desenhe um mapa de topologia de times. Antes da última ferramenta de IA que você adotou, você chegou a desenhar a topologia dos seus times? Com times cortados por camadas técnicas, por mais forte que seja a IA, você está apenas acelerando dívida sobre uma estrutura quebrada. Esse único checklist bloqueia pelo menos metade do investimento de TI desperdiçado numa grande empresa. Ação concreta: liste todos os times e marque de qual fluxo de valor cada um é dono ponta a ponta. Os que você não consegue marcar estão cortados por camada técnica, e são a prioridade de reorganização.

Lição dois: faça um check-up de carga cognitiva. Pare de perguntar “tem gente suficiente?”. Pergunte quais times mantêm mais de 5 sistemas sem relação entre si ao mesmo tempo, e quais pessoas interfaceiam com mais de 3 fontes upstream. Trazer isso à tona é muito mais útil do que adicionar headcount ou processo. A IA consegue absorver parte da carga — escrever código, buscar referências, pré-triagem — desde que você redistribua a carga de forma deliberada, em vez de jogar “implantar IA” como mais uma tarefa em cima de um time já saturado.

Lição três: opere a plataforma interna como produto, ou ela inevitavelmente degenera em terceirização. A plataforma precisa de usuários, de roadmap, de SLA, e de alguém responsável pela adoção. Na era da IA, essa plataforma também precisa absorver o gateway de modelos, a biblioteca de prompts e o runtime de agentes — essa é a base que o próximo artigo sobre “framework de adoção” vai aprofundar.

Lição quatro: não deixe a IA cimentar as fronteiras erradas. Esta é especificamente para organizações que estão introduzindo agentes de IA. Quando você adiciona agentes ao time, um corte errado de time é amplificado: o agente vai automatizar ao longo das fronteiras existentes — erradas — deixando a estrutura quebrada ainda mais firme. Antes de introduzir agentes de IA, confirme que as fronteiras dos times estão certas. Esse é o foco do 11º artigo da série.

Autocheque reverso (responda sem maquiar): seu time é cortado por fluxo de valor, ou por front-end/back-end/operacional/segurança? Sua pessoa mais ocupada está carregando mais de 3 coisas desconexas ao mesmo tempo? Se sua plataforma interna não tem usuários, isso é uma luz vermelha de plataformação fracassada. Se alguma resposta te deixa inquieto, então antes de trazer IA, reorganize os times primeiro. É a alavanca de maior retorno que você pode acionar antes de qualquer outra coisa.

O que vem a seguir

Este é o 2º artigo da série “A transformação da engenharia de software na era da IA” (episódio 172 da coluna “Learn AI Slowly”). Saímos de Conway (a organização decide a arquitetura) e chegamos ao Team Topologies (como desenhar a organização). O próximo artigo (nº 3) levanta uma pergunta mais fundamental: quando a IA torna a produção de código quase gratuita, para onde migra o gargalo da engenharia de software?

Nota da série: esta série acompanha continuamente a evolução das ferramentas de programação com IA, das arquiteturas organizacionais e dos paradigmas de engenharia de software — por exemplo, como a Lei de Conway está mudando em 2026 na era dos agentes de IA, e a maturidade do ecossistema de ferramentas mais recente. Acompanhe a série para obter insights continuamente atualizados.

Sobre esta série

“A transformação da engenharia de software na era da IA” é uma série de pesquisa aprofundada escrita para CIOs, CDOs, CTOs e líderes de digitalização de setores como telecom, finanças, manufatura e e-commerce — 15 artigos no total. Construída sobre mais de 200 artigos acadêmicos e relatórios setoriais, oferece referências de decisão anotadas com nível de evidência.

Sou ex-engenheiro da IBM, coach certificado pela ICF, com experiência prática na entrega de projetos de IA e digitalização para operadoras e grandes empresas. O que está escrito aqui é o julgamento de campo conquistado acompanhando empresas pelo meio dos buracos.

Se ao terminar você estiver pensando “minha empresa também é assim?” — montei uma lista de autocheque de Team Topologies com 20 perguntas, e também ofereço uma conversa de diagnóstico 1-a-1 de 30 minutos para ajudar a localizar qual fluxo de valor reorganizar primeiro. Se quiser: deixe uma mensagem na conta oficial “AI Decision-Maker Insight” no WeChat, ou escreva para coach@iaiuse.com.

Referências

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (A fonte original dos quatro tipos de time / três interações / carga cognitiva — fonte primária.)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (Retrospectiva de adoção em múltiplas organizações — secundária.) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — exemplares de produtoização de plataforma interna.
AutoTrader UK — um caso de adoção oficialmente citado pela TT (link em teamtopologies.com a ser preenchido).
Biblioteca oficial de casos: https://teamtopologies.com/examples