Antes de começar

Sua arquitetura de software não é “projetada” pela sua equipe técnica — é “desenvolvida” pela sua estrutura organizacional. Essa lei proposta em 1968 está sendo repetidamente validada na era da IA.
Estudos empíricos da Harvard Business School provam: a distância organizacional prediz taxas de defeitos de software com mais precisão do que a complexidade do código. O que você chama de “dívida técnica” é, na verdade, provavelmente “dívida organizacional”.
O império de microserviços da Amazon, o modelo de equipes da Spotify, o impasse do Siri da Apple — três empresas de trilhões de dólares ilustram a mesma lei por meio de destinos radicalmente diferentes.
Agentes de IA estão entrando no organograma. Quando os “nós” da sua equipe deixam de ser apenas humanos, a Lei de Conway será reescrita de maneiras que você nem imagina.

Em 1968, um programador desconhecido escreveu um artigo rejeitado pela Harvard Business Review com o motivo de “não provar sua tese”. 56 anos depois, a ideia central desse artigo tornou-se uma lei universalmente aceita na engenharia de software — e, em 2026, na era em que a IA reconfigura tudo, ela é mais relevante do que nunca.

1. Como um artigo rejeitado se tornou a “Lei da Gravitação” da engenharia de software

O profeta rejeitado pela HBR

Em abril de 1968, Melvin Conway publicou no jornal Datamation um artigo com título aparentemente modesto: “How Do Committees Invent?” (Como os Comitês Inventam?).
A tese central do artigo resume-se a uma única frase — suficiente para deixar qualquer CTO em insônia:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Traduzindo para a linguagem do dia a dia: o organograma da sua empresa é a versão exata do seu diagrama de arquitetura de software.
Conway descreveu no artigo um caso elegante: uma empresa atribuiu oito pessoas para formar dois grupos, cada um encarregado de construir um compilador — um grupo de cinco e outro de três. O resultado? O grupo de cinco desenvolveu um compilador de cinco estágios; o grupo de três, um de três estágios. Não porque a tecnologia exigisse essa divisão, mas porque — cada pessoa precisava “possuir” sua própria unidade de trabalho.
Conway descreveu essa relação em termos matemáticos como “homomorfismo” (homomorphism) — uma correspondência que preserva a estrutura entre a organização e o design do sistema. Não é coincidência. Não é acaso. É uma lei quase matematicamente inevitável.

Ironicamente, Conway originalmente submeteu este artigo à Harvard Business Review, mas foi rejeitado pelos editores com o motivo de “não provar seu argumento”. Sete anos depois, Fred Brooks citou formalmente essa ideia em seu clássico livro “The Mythical Man-Month” e nomeou-a oficialmente como “Lei de Conway”.
Desde então, uma observação rejeitada por uma das principais revistas comerciais tornou-se uma das leis mais amplamente citadas na engenharia de software.

A “sentença final” de Martin Fowler

Se Conway foi o Copérnico que propôs a hipótese, então as pesquisas empíricas das últimas duas décadas foram o telescópio.

Em 2022, o cientista-chefe da ThoughtWorks, Martin Fowler, escreveu um comentário amplamente disseminado na indústria: “Se houver uma única lei na área de arquitetura de software que todos os praticantes concordem, é a Lei de Conway. Ela é suficientemente importante para ter influenciado cada sistema que já vi; é suficientemente poderosa para que qualquer tentativa de resistir a ela seja destinada ao fracasso.”

Isso não é uma especulação teórica de um acadêmico em sua torre de marfim. Fowler observou repetidamente, em centenas de consultorias em empresas globais, o mesmo fenômeno: o organograma da organização é a sombra do blueprint do software, independentemente de os gestores perceberem isso ou não.

Aqui há um significado sutil, mas crucial, que muitos ignoram: Fowler disse que “qualquer um que tente opor-se a ele está fadado ao fracasso”, e não “qualquer um que tente utilizá-lo“. Qual a diferença? Opor-se à Lei de Conway significa impulsionar mudanças arquiteturais sem alterar a estrutura organizacional; já utilizá-la significa ajustar primeiro a organização, permitindo que a arquitetura “cresça naturalmente”.
Essa diferença determina o sucesso ou fracasso de projetos de transformação digital. Na segunda parte subsequente, ao discutirmos Team Topologies, detalharemos a estratégia-chave chamada “Manobra Inversa de Conway” — que, em essência, consiste em utilizar, e não opor-se, a essa lei.

II. Do laboratório ao campo de batalha: Três estudos confirmam esta lei

A “Hipótese do Espelho” da Harvard Business School

Em 2012, MacCormack e colegas da Harvard Business School publicaram um estudo de grande impacto, conhecido na comunidade acadêmica como “Hipótese do Espelho” (Mirroring Hypothesis).

O método foi engenhoso: eles compararam software comercial e software open source que executavam funções idênticas. O software comercial foi desenvolvido por equipes corporativas hierárquicas; o software open source, por comunidades descentralizadas.

Os resultados confirmaram a previsão da Lei de Conway: produtos desenvolvidos por organizações com baixa acoplamento são significativamente mais modularizados. Equipes corporativas fortemente acopladas, mesmo quando buscam intencionalmente um design modular, acabam produzindo sistemas que refletem exatamente a estrutura organizacional — com alta acoplamento.

A estrutura organizacional atua como um “campo gravitacional” — você pode resistir a ela temporariamente, mas, com o tempo, a arquitetura do sistema será puxada de volta para uma forma isomórfica à da organização.

Qual é a verdadeira lição para tomadores de decisão corporativos? Quando sua equipe de tecnologia repetidamente diz “precisamos refatorar”, o que realmente precisa ser refatorado pode não ser o código, mas a organização. Mas como distinguir entre “dívida técnica” e “dívida organizacional”? Isso exige um método sistemático de diagnóstico — apresentaremos um modelo completo de avaliação na 12ª postagem, Framework para Decisão de Adoção de Ferramentas de IA Empresarial.

O “Experimento Windows Vista” do Microsoft Research

Em 2008, Nagappan e colegas do Microsoft Research conduziram um estudo quantitativo em larga escala sobre o projeto Windows Vista. Eles buscavam responder a uma pergunta-chave: qual fator prediz com mais precisão os defeitos (bugs) em software?

As hipóteses incluíam: complexidade do código, número de linhas de código, frequência de alterações, experiência dos desenvolvedores… e uma variável que parecia não ter relação com “tecnologia” — distância organizacional (ou seja, a distância na estrutura organizacional entre as equipes que desenvolvem módulos relacionados).

As conclusões da pesquisa deixaram muitos tecnocratas inquietos: a distância organizacional é um preditor mais forte da taxa de defeitos de software do que a complexidade do código. Em outras palavras, módulos desenvolvidos conjuntamente por equipes “distantes” no organograma tendem a ter mais bugs do que módulos extremamente complexos, mas mantidos por equipes que colaboram de perto. O que você pensa ser um bug causado por código mal escrito pode, na verdade, ser resultado de uma má estrutura organizacional.

A implicação empresarial dessa descoberta é muito mais profunda do que parece à primeira vista. Ela significa que — sua estratégia de QA deve seguir a estrutura organizacional, e não a complexidade do código. Módulos desenvolvidos por equipes diferentes exigem cobertura de teste mais rigorosa e processos de revisão mais apertados, mesmo que o código em si pareça simples. Hoje, com a explosão de código gerado por IA (o Copilot já gera 46% do código escrito pelos usuários), esse princípio tornou-se ainda mais crítico — detalharemos o caso da Coinbase ao discutir o “paradoxo da produtividade” no artigo 8.

O “Acelerado” e o “Alerta” da Pesquisa DORA

A equipe DevOps Research and Assessment (DORA), da Google, liderada por Nicole Forsgren, Jez Humble e Gene Kim, publicou o maior estudo já realizado sobre eficácia na entrega de software.

A descoberta central está altamente alinhada com a Lei de Conway: “Se implementarmos uma arquitetura com baixo acoplamento e boa encapsulação, acompanhada por uma estrutura organizacional correspondente, conseguiremos não apenas acelerar o ritmo e a estabilidade da entrega, mas também manter um crescimento produtivo linear ou até superlinear mesmo quando as equipes de engenharia se expandirem significativamente.” No entanto, o relatório da DORA de 2022 também identificou um efeito colateral intrigante: embora arquiteturas de baixo acoplamento aumentem a eficiência de entrega, elas podem intensificar o esgotamento das equipes. A razão pode ser que, quando as equipes são altamente autônomas e isoladas umas das outras, os membros perdem a percepção do propósito global, sentindo-se como “apenas uma engrenagem”.

Este é um importante lembrete — alinhar arquitetura e organização não é uma bala de prata; resolve problemas de eficiência, mas pode criar problemas culturais. Uma inferência profundamente reflexiva: se arquiteturas de baixo acoplamento + organizações de baixo acoplamento já fazem desenvolvedores humanos se sentirem isolados, o que acontece quando agentes de IA são adicionados às equipes? A IA não “sente isolamento”, mas os humanos ficarão ainda mais isolados. Essa dimensão raramente é discutida, mas em nossas fontes de pesquisa, um relatório da BCG de 2025 introduz o “dilema de coordenação dos gestores intermediários” — que é exatamente o tema central de nosso Artigo 11.

3. O “Momento Conway” de Três Empresas de Trilhões

Amazon: Um e-mail do CEO que mudou tudo

Por volta de 2002, Jeff Bezos enviou, dentro da Amazon, o famoso “API Mandate” — todos os times deviam se comunicar exclusivamente por meio de interfaces de serviço (APIs), proibindo qualquer acesso direto aos repositórios de dados de outros times.
A última linha desse e-mail, diz-se, era: “Pessoas que não cumprirem estas regras serão demitidas.”
Muitos veem a arquitetura de microserviços da Amazon como uma decisão técnica. Mas, sob a ótica da Lei de Conway, o que Bezos fez foi, na verdade, uma decisão de estrutura organizacional: ele primeiro impôs, por meio de gestão, o corte das “abreviações de comunicação” entre equipes, e a arquitetura de software evoluiu naturalmente para módulos de serviços isolados.

Foi assim que Bezos posteriormente propôs os “Two-Pizza Teams” — cada equipe não deve ter mais pessoas do que duas pizzas conseguem alimentar (geralmente 5-8 pessoas), cada equipe possui seu próprio serviço, faz deploy independente e interage com o exterior apenas por APIs.
O império de microserviços da Amazon não foi desenhado por arquitetos — foi “crescido” pela estrutura organizacional. Este é o exemplo mais clássico e positivo da Lei de Conway.

Mas há um aspecto que muitos artigos não mencionam: o sucesso da Amazon não se deve apenas ao fato de Bezos ter compreendido a Lei de Conway, mas também porque ele resolveu simultaneamente o problema do “alinhamento de incentivos”. Cada “equipe de dois pizzas” possui seu próprio DRE (demonstrativo de resultados do exercício), sendo autônoma não apenas tecnicamente, mas também comercialmente. Isso significa que as equipes têm motivação intrínseca para manter fronteiras claras entre os serviços — pois fronteiras ambíguas implicam responsabilidade ambígua, e responsabilidade ambígua implica avaliação ambígua. O alinhamento triangular entre estrutura organizacional + estrutura de incentivos + arquitetura técnica é a imagem completa do modelo da Amazon. Empresas que copiam apenas a estrutura organizacional, mas ignoram o design de incentivos, geralmente captam apenas a forma, sem o espírito.

Spotify: o modelo ideal enfrentando a “entropia” da realidade

O modelo “Squad” da Spotify foi um dia considerado a bíblia do design organizacional na Silicon Valley: pequenas equipes autônomas de 5 a 8 pessoas (Squads), múltiplas squads formando tribos (Tribes), especialistas técnicos transversais formando capítulos (Chapters) e comunidades impulsionadas por interesses formando guildas (Guilds).
O pensamento por trás desse modelo é altamente coerente com a Lei de Conway — estruturas de equipe pequenas e autônomas geram serviços de software pequenos e autônomos.

Mas a própria Spotify acabou admitindo que a realidade é muito mais complexa do que o modelo sugere. À medida que o negócio cresce, as dependências entre equipes tornam-se inevitáveis, e a autonomia pura começa a gerar custos de coordenação. Isso revela uma implicação frequentemente ignorada da Lei de Conway: a estrutura organizacional não é algo projetado uma vez e esquecido — assim como o software, ela tem uma tendência à “aumento de entropia”. À medida que a complexidade do negócio cresce, os limites organizacionais se tornam mais nebulosos, os caminhos de comunicação se alongam e a arquitetura do sistema degrada-se. Uma organização técnica excelente não é aquela que “projetou uma boa arquitetura”, mas sim aquela que estabeleceu a capacidade contínua de alinhar organização e arquitetura. Essa capacidade será explorada na segunda parte, sobre Team Topologies — que oferece um framework mais sistemático e operacional do que o modelo da Spotify. ## Apple: Por que o Siri foi “esmagado” pelo ChatGPT O plano de atualização da IA do Siri da Apple, em 2024-2025, quase se tornou o “contraponto” da Lei de Conway.

A raiz do problema não está na tecnologia. A Apple possui talentos de pesquisa em IA de classe mundial e recursos financeiros abundantes. Mas o desenvolvimento do Siri envolve duas equipes cuja estrutura organizacional apresenta uma fissura estrutural: a equipe de pesquisa em IA (liderada por John Giannandrea) e a equipe de desenvolvimento de produto (liderada por Craig Federighi).

Essas duas equipes têm prioridades diferentes, ritmos distintos e critérios de sucesso divergentes. A equipe de pesquisa em IA busca avanços na fronteira da capacidade dos modelos; a equipe de produto busca entrega estável da experiência do usuário. Quando a estrutura de comunicação entre esses dois “nós” organizacionais é fragmentada, o sistema resultante inevitavelmente também será fragmentado.

O que os usuários finalmente obtêm no Siri? Um “assistente medíocre montado à força” — cada módulo parece razoável por si só, mas, quando integrado, carece de uma experiência inteligente coesa. Isso é exatamente o que a Lei de Conway prevê: as rachaduras no sistema refletem as rachaduras na organização.

O caso da Apple merece especial atenção de tomadores de decisão chineses. Muitas empresas estão passando exatamente pelo mesmo dilema — equipes de IA e equipes de negócios estão sob diferentes VP’s, e projetos de implementação de IA tornam-se “jogos políticos entre dois departamentos” em vez de “entrega colaborativa de um único produto”.

Se sua empresa está impulsionando a adoção de IA, dê uma olhada no seu organograma: a capacidade de IA existe como um departamento independente ou está integrada às equipes de negócio? A resposta a essa pergunta pode ser mais determinante para o sucesso do projeto do que a escolha do modelo de IA que você utiliza.

4. A Era da IA: A Lei de Conway Está Sendo Reescrita

Quando os “nós organizacionais” não são mais todos humanos

Em 2026, a Lei de Conway enfrenta seu desafio mais profundo desde 1968. Ao formular essa lei, Conway pressupunha implicitamente que cada “nó” na organização era um ser humano — a estrutura de comunicação era entre pessoas.

Mas hoje, agentes de IA estão entrando nos organogramas. O Claude Code pode concluir tarefas de desenvolvimento em múltiplos passos de forma autônoma; o sistema Minions da Stripe gera mais de 1.000 PRs combinados por semana; o Cursor transformou a forma como 100% dos engenheiros da NVIDIA trabalham. O Gartner relata um aumento de 1.445% nas consultas empresariais sobre orquestração multiagente de IA em 2025.

O que acontece com a Lei de Conway quando alguns nós na organização deixam de ser humanos?

A discussão deste problema percorrerá a segunda metade de toda a nossa série — o fenômeno “Unicórnio Individual” no artigo 10, “A Lei de Conway Encontra Agentes de IA” no artigo 11, e “Engenharia Agente” no artigo 14 — mas aqui apresentamos três julgamentos preliminares para ajudá-lo a construir um quadro de pensamento:

Primeiro, a estrutura de comunicação se tornará uma estrutura de estratégia. A comunicação entre humanos depende de cultura, entendimento mútuo e interações informais. Mas entre humanos e agentes de IA não existe “entendimento mútuo” — você deve definir os limites da interação por meio de estratégias, regras e permissões explícitas. A capacidade de governança substituirá a capacidade de comunicação como variável central no design organizacional.

Segundo, o organograma se tornará um mapa de permissões. Organogramas tradicionais descrevem relações de subordinação e divisão de funções. O “organograma” da era da IA é mais como um grafo direcionado acíclico (DAG), que define capacidades e restrições — quais agentes podem acessar quais dados, executar quais operações e em quais condições exigem aprovação humana.

Terceiro, o conhecimento institucional migrará das pessoas para as estratégias. No passado, “quando um funcionário experiente saía, levava o conhecimento” era uma dor para todas as empresas. No futuro, o conhecimento crítico será codificado nas estratégias e contextos dos agentes de IA — isso é tanto uma oportunidade (o conhecimento não se perde mais) quanto um risco (erros na estratégia podem ser amplificados sistemicamente).

Cada julgamento é respaldado por uma grande quantidade de práticas industriais e dados. Por exemplo, o terceiro ponto sobre “transferência de conhecimento institucional” oferece um exemplo dramático, tanto positivo quanto negativo, com o caso da Klarna — após demitir 40% dos funcionários, descobriram que o sistema de IA não conseguia substituir o conhecimento tácito levado embora pelos demitidos, sendo obrigados a contratar novamente. Essa história será apresentada por completo no artigo 9, “As Lições da Klarna”.

A primeira e a segunda afirmações não são exclusivas da nossa perspectiva. Em julho de 2026, no podcast da a16z intitulado “Software in the Age of Agents”, Seema Amble, parceira da equipe corporativa da a16z, e Steven Sinofsky, ex-presidente global da Windows da Microsoft, chegaram a conclusões altamente alinhadas com base em observações diretas de investimento. Steven resumiu o cerne da primeira afirmação em uma frase: “O maior efeito de rede em software corporativo ocorre dentro da empresa” (The biggest network effect in enterprise software is inside of a company): a rede composta por relações interpessoais, processos e sistemas dentro da organização é o verdadeiro ponto de aderência. Agentes não conseguem se integrar a essa rede por “entendimento tácito”; só conseguem por meio de estratégias e permissões explícitas — essa é exatamente a força real que impulsiona a transformação da estrutura de comunicação em estrutura de estratégia. Seema corroborou a segunda afirmação a partir da perspectiva do acesso dos agentes aos sistemas corporativos: quando um agente precisa “executar” (escrever registros no sistema, alterar contas), ele imediatamente enfrenta toda uma cadeia de questões — identidade, credenciais, licenças de cobrança, permissões de aprovação — o organograma está sendo reescrito como um mapa de permissões: “quem pode acessar o quê, e quem autoriza o quê”. Essas duas afirmações não são previsões; são fenômenos já em curso nos projetos em que investidores de primeira linha estão colocando capital. (Convidados: parceiros da a16z / ex-executivos da Microsoft, perspectiva de VC.)

Cinco: Autoavaliação: Qual “erro de Conway” sua organização está cometendo?

Se você chegou até aqui e ainda acha “eu já entendo tudo isso”, quero que faça um exercício.

Abaixo estão cinco padrões comuns de desalinhamento entre organização e arquitetura, baseados na Lei de Conway e pesquisas relacionadas. Compare com sua própria empresa e veja quantos itens você identifica:

❶ Microserviços superficiais: O código foi dividido, mas 50 pessoas ainda discutem em um único grupo de chat.
❷ Ilusão da plataforma central: A plataforma central tornou-se gargalo de comunicação para todas as linhas de negócio.
❸ Ilhas de IA: Modelos produzidos pela equipe de IA não conseguem ser integrados aos negócios, porque organizationalmente “não caminham juntos”.
❹ Degradção da colaboração remota: O isolamento físico causou fragmentação desnecessária nos sistemas.
❺ Dificuldade de integração pós-aquisição: Falha na integração técnica devido à incompatibilidade cultural organizacional.

Próximos passos

Este é o primeiro de 15 artigos da série “A Transformação da Engenharia de Software na Era da IA”. A partir da Lei de Conway, estabelecemos uma compreensão fundamental: a arquitetura organizacional determina a arquitetura do sistema — isso não é metáfora, mas uma relação causal comprovada empiricamente.

Mas saber essa lei é apenas o começo. A questão real é: podemos invertê-la? Ao projetar intencionalmente a estrutura organizacional para guiar a arquitetura do sistema desejado — essa é a ideia central do “Inverse Conway Maneuver”. No próximo artigo, “Team Topologies — Uma Metodologia de Design Organizacional na Era Pós-Agil”, exploraremos como Matthew Skelton e Manuel Pais transformaram essa ideia em uma metodologia completa e operacional, incluindo quatro tipos básicos de equipes, três modelos de interação e o conceito de “cognitive load”, amplamente subestimado. Casos de prática da Netflix, Adidas e Accenture demonstrarão em quais condições o Inverse Conway Maneuver funciona e em quais falha. — > Nota da série: Esta série acompanhará continuamente as últimas evoluções em ferramentas de programação por IA, arquiteturas organizacionais e paradigmas de engenharia de software, como as novas implicações da Lei de Conway na era dos agentes de IA em 2026 e o grau de maturidade da nova ecossistema de ferramentas. Assine a série para obter insights atualizados continuamente. # Sobre esta série

“A Mudança da Engenharia de Software na Era da IA” é uma série de pesquisa aprofundada voltada para tomadores de decisão tecnológicos em empresas, composta por 15 artigos. Baseada em um estudo sistemático de mais de 200 artigos acadêmicos e relatórios industriais, oferece a você referências decisórias com marcação de nível de evidência. Aguarde mais conteúdos.

Fontes de referência:

Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: “O maior efeito de rede em software corporativo acontece dentro de uma empresa” + Seema Amble sobre agentes acessando sistemas empresariais e enfrentando limitações de permissões/credenciais/assentos de licenciamento — sustentam as afirmações 1 e 2 da seção 4; fonte primária — áudio original do podcast. Marcação de posição: parceira da a16z / ex-executiva da Microsoft, posição de VC. Convidados verificados: Seema Amble, parceira da equipe corporativa da a16z; Steven Sinofsky, ex-presidente do Windows da Microsoft (board partner); Elena Burger, redatora da a16z; lançado em julho de 2026.)