Em abril de 1968, a revista Datamation, uma das principais publicações de tecnologia da época, publicou um artigo de Melvin Conway, um programador e pesquisador americano, com um título que parecia falar de gestão: “How Do Committees Invent?” O artigo fazia uma observação que parecia simples, mas que com o tempo se revelou uma das mais poderosas da engenharia de software. Conway observou que:

As organizações que projetam sistemas de software tendem a produzir sistemas que espelham as estruturas de comunicação dessas organizações.

Em outras palavras: o jeito como organizamos nossos times determina o jeito como o seu produto vai ser construído.

Essa observação ficou conhecida como Lei de Conway, e ela se aplica com surpreendente consistência em organizações de todos os tamanhos e setores.

Por que a Lei de Conway importa

A Lei de Conway é uma descrição de como as coisas tendem a funcionar na prática. Times separados constroem sistemas separados. Times que não se comunicam bem constroem interfaces mal definidas entre seus sistemas. Times organizados em torno de tecnologias constroem produtos que refletem essas tecnologias, e não as necessidades das clientes.

A estrutura cria incentivos e restrições que moldam as decisões de uma forma que muitas vezes passa desapercebido. Uma engenheira que trabalha em um time dedicado ao portal de busca vai naturalmente resolver problemas adicionando funcionalidades ao portal de busca. Não porque ela seja limitada, mas porque é isso que está dentro dos seus limites de atuação.

Quando a estrutura está errada, ela trabalha silenciosamente contra a estratégia.

A Manobra Reversa de Conway

Se a Lei de Conway descreve como a estrutura molda o produto, a Manobra Reversa de Conway propõe virar essa lógica: em vez de deixar a estrutura dos times emergir organicamente e depois observar o produto que ela produz, você define primeiro a arquitetura de sistemas que deseja ter, e então organiza os times para refletir essa arquitetura desejada.

A ideia é poderosa. Se você quer ter um sistema de microserviços bem definido, organize times que correspondam a esses serviços. Se você quer que certas partes do sistema evoluam de forma independente, crie times que possam trabalhar de forma independente. A estrutura dos times passa a ser uma decisão de design de sistema, não uma consequência acidental.

O problema é que a Manobra Reversa de Conway, como é frequentemente aplicada, parte de um pressuposto incompleto: a arquitetura de sistemas importa, mas não é o único fator que deve determinar como os times se organizam.

A arquitetura de sistemas é uma restrição técnica importante. Mas não é o único fator. O cliente e os objetivos de negócio também são fatores extremamente importantes. Quando esses fatores são ignorados em favor de uma reorganização puramente técnica, o resultado pode ser uma estrutura tecnicamente elegante que ainda assim falha em gerar resultado para as clientes e para o negócio.

O que aconteceu na Lopes

Quando entrei na Lopes para liderar a transformação digital, a estrutura de times do Lopes Labs espelhava os sistemas que o time havia construído. Havia um time dedicado ao portal de busca de imóveis, um time dedicado ao CRM web para franquias e corretores, e um time dedicado ao app dos corretores.

Do ponto de vista técnico, a lógica era razoável. Cada time conhecia profundamente o seu sistema. Mas do ponto de vista do negócio e das clientes, havia um problema fundamental: a Lopes opera um marketplace de três pontas. De um lado, a cliente final que quer comprar ou alugar um imóvel. Do outro, incorporadoras e proprietários que querem vender ou alugar seus imóveis. Como a compra de imóveis é uma das maiores, se não a maior compra de uma pessoa, é de se esperar a ajuda de um terceiro elemento, o consultor imobiliário, que são os corretores e franqueados que fazem a intermediação.

Para gerar resultado nesse marketplace, o time precisava entender e resolver os problemas de cada um desses atores e as relações entre eles. Mas a estrutura por sistema criava uma barreira invisível: cada time olhava para o seu produto, não para os usuários do produto. E quando o foco é o produto, a única forma de resolver problemas é adicionando funcionalidades ao produto.

Isso se manifestou de forma concreta. O principal objetivo do time era aumentar a quantidade de leads que chegavam às mãos dos corretores o mais rápido possível, pois quanto mais rápido o corretor contatasse o potencial comprador, maior a chance de conversão. A solução que o time estava desenvolvendo era um app para corretores com notificações push. Um MVP com 58 requisitos e funcionalidades definidos, e outros 90 já enfileirados para depois do lançamento.

Era claramente um problema de estrutura, pois o time estava organizado em torno do app, então a solução para qualquer problema passava pelo app.

Se, ao invés de foco no produto, o foco tivesse sido no ator para quem queremos resolver problemas, a pergunta passa a ser: como entregar o lead nas mãos do corretor o mais rápido possível? E aí outras soluções se tornariam óbvias. SMS, por exemplo. Ou WhatsApp, que no Brasil tem penetração muito maior do que qualquer app proprietário. Soluções mais simples, mais rápidas de desenvolver, e provavelmente mais eficazes, mas que estavam fora do campo de visão de um time organizado em torno de um produto específico.

Reorganizando em torno dos usuários

Antes de propor qualquer mudança estrutural, precisei entender como a Lopes operava. Só depois de ter clareza sobre o negócio, os atores do marketplace e as relações entre eles, foi possível desenhar uma estrutura de times que fizesse sentido.

A nova estrutura saiu da lógica de sistemas para a lógica de usuários. Em vez de time de Portal, de CRM e de App, passamos a ter times organizados em torno dos atores do marketplace: um time focado no Cliente Final, outro em Incorporadoras e Proprietários, e um terceiro focado em Corretores e Franqueados. E mais um time que chamamos de Sistemas Centrais, responsável pela infraestrutura compartilhada que sustentava toda a operação.

A mudança foi feita em uma semana. Os primeiros dias foram turbulentos, como esperado pelo modelo de Tuckman. Mas após um mês, cada time já tinha clareza sobre quem eram seus usuários, quais eram os problemas que precisavam resolver, e quais eram os resultados que deveriam gerar.

O resultado mais imediato foi uma mudança de perspectiva. Os times pararam de pensar em funcionalidades para adicionar a sistemas existentes e começaram a pensar em problemas a resolver para usuários específicos. Essa mudança de perspectiva, por si só, abriu um espaço de soluções muito mais amplo.

O que a Manobra Reversa de Conway não resolve

A reorganização da Lopes não foi uma aplicação da Manobra Reversa de Conway no sentido clássico. Não partimos da arquitetura de sistemas desejada para definir os times. Partimos dos usuários do marketplace e da estratégia do negócio.

Essa distinção é importante. A Manobra Reversa de Conway é uma ferramenta válida e poderosa, mas ela responde à pergunta errada se for aplicada isoladamente. A pergunta “qual arquitetura de sistemas queremos?” é uma pergunta técnica legítima. Mas ela só pode ser respondida bem depois de responder à pergunta mais fundamental: “quem são nossos usuários, quais problemas precisamos resolver para eles, e quais os objetivos de negócio queremos alcançar?”

O inverso também não funciona. Se levarmos em conta somente nossos usuários, seus problemas e os objetivos de negócio, mas não levarmos em consideração a arquitetura de sistemas que queremos, isso irá cobrar um preço, pois vai chegar um momento em que evoluir o sistema terá restrições técnicas bem relevantes e difíceis de serem transpostas.

A estrutura dos times deve refletir tanto a arquitetura de sistemas quanto a lógica de criação de valor para as clientes e para o negócio. Quando esses dois fatores estão alinhados, a estrutura trabalha a favor da estratégia. Quando apenas um deles é levado em conta, a estrutura continua trabalhando silenciosamente contra.

Resumindo

• A Lei de Conway descreve uma realidade: a estrutura dos times molda o produto que o time vai construir. Times organizados em torno de sistemas constroem soluções dentro dos limites desses sistemas.
• A Manobra Reversa de Conway propõe inverter a lógica: definir primeiro a arquitetura desejada e organizar os times para refletir essa arquitetura. É uma ferramenta válida, mas incompleta.
• O que ela deixa de fora é o cliente e a estratégia do negócio. Uma estrutura elegante do ponto de vista técnico, mas que não reflete a lógica de criação de valor para as clientes, vai continuar impondo limites na forma como o produto resolve problemas das clientes e gera valor para a empresa.
• Quando o foco é o produto, a única forma de resolver problemas é adicionando funcionalidades ao produto. Quando o foco é o usuário e o resultado esperado, o espaço de soluções se abre.
• A reorganização da Lopes saiu da lógica de sistemas para a lógica de usuários do marketplace. A mudança foi feita em uma semana. O impacto foi imediato na forma como os times pensavam sobre seus problemas.
• Estrutura deve seguir estratégia e arquitetura, nessa ordem. A arquitetura de sistemas é uma restrição importante. Mas a estratégia define o que precisa ser construído antes de qualquer decisão técnica.

Masterclass: Por que a Estratégia Não Chega ao Produto

Nesta masterclass de 3 horas, Paulo Caroli e eu vamos explorar por que a estratégia se perde no caminho entre a liderança e os times, e como resolver isso. Três horas de conversa prática, com modelos que você pode aplicar na semana seguinte.

O objetivo é entender como transformar direção estratégica em decisões reais de produto.

Mais informações e inscrição:

https://www.gyaco.com/masterclass-caroli-e-joca/

Treinamento e consultoria em gestão de produtos

Ajudo empresas e lideranças (CPOs, heads de produto, CTOs, CEOs, tech founders e heads de transformação digital) a conectar negócios e tecnologia por meio de treinamentos e consultoria focados em gestão de produtos e transformação digital.

Podcasts da Gyaco

Na Gyaco, acreditamos no poder das conversas para promover reflexão e aprendizado. Por isso, temos o podcast Produto em Pauta, que explora o universo de gestão de produtos por ângulos diferentes:

• Mentorias: Nesta série, compartilho conversas reais de mentoria com profissionais de produto, partindo da ideia de que as perguntas de uma pessoa muitas vezes são as perguntas de muitas outras. Exploramos desafios concretos, refletimos juntas e transformamos experiência em aprendizados práticos que você pode aplicar no seu próprio contexto.
• Sem Filtros: Nessa série de episódios, Fabio Duarte, Paulo Caroli e eu temos conversas francas sobre produto, tecnologia e os incômodos reais que estamos vendo nas organizações.
• Além das Buzzwords: Nessa série de episódios, Felipe Castro e eu desmistificamos termos de produto com exemplos reais de nossas clientes.

Disponível no YouTube e no Spotify. Gravada em português e, no YouTube, com legendas em inglês.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer aumentar as chances de sucesso do seu produto, resolver os problemas das usuárias e atingir os objetivos da empresa? Conheça meus livros, onde compartilho o que aprendi ao longo de mais de 30 anos criando e gerenciando produtos digitais:

• Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia de sua empresa
• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.