A forma como uma empresa organiza suas equipes acaba aparecendo, quase sempre, na arquitetura do software que ela produz. Nessa ótica, Murilo Moura Alencar, board member e Tech, People & Game Strategist, examina que essa relação ainda é pouco considerada nas decisões de gestão. Reestruturações costumam ser discutidas em termos de hierarquia e orçamento, raramente em termos do sistema que as equipes vão construir.
O fenômeno foi descrito em 1968 pelo programador Melvin Conway, num artigo que deu origem à chamada Lei de Conway: organizações que projetam sistemas tendem a produzir desenhos que copiam suas próprias estruturas de comunicação. A seguir, por que essa observação continua relevante e como usá-la a favor da empresa.
O que diz a Lei de Conway?
A ideia central é simples. Murilo Alencar comenta que, para que duas partes de um sistema funcionem juntas, as pessoas responsáveis por elas precisam conversar. Por isso, as fronteiras entre módulos de software tendem a acompanhar as fronteiras entre equipes.
Se uma empresa divide o desenvolvimento em três grupos que pouco se comunicam, o resultado provavelmente terá três grandes blocos com integrações frágeis entre eles. Se uma única equipe cuida de tudo, o sistema tende a ser mais coeso, mas também mais difícil de dividir quando a empresa crescer.
Por que isso importa para gestores
Murilo Alencar aponta que muitas dificuldades atribuídas à tecnologia têm origem na estrutura organizacional. Integrações que vivem quebrando, entregas que dependem de várias equipes ao mesmo tempo e funcionalidades simples que levam meses costumam refletir divisões de responsabilidade mal desenhadas.
Nesses casos, trocar ferramentas ou reescrever partes do código resolve pouco. Enquanto a estrutura de comunicação continuar a mesma, o sistema tende a voltar ao mesmo formato. O problema técnico é, em boa parte, um problema de organização. Reconhecer isso evita investimentos caros em soluções que atacam o sintoma, e não a causa.
A manobra inversa
Se a estrutura das equipes molda o software, o raciocínio também funciona ao contrário. Especialistas passaram a chamar de manobra inversa de Conway a prática de desenhar primeiro a arquitetura desejada e, a partir dela, organizar as equipes.
O livro Team Topologies, de Matthew Skelton e Manuel Pais, publicado em 2019, popularizou essa abordagem. A proposta é formar equipes alinhadas a fluxos de valor para o cliente, com autonomia para entregar de ponta a ponta, e reduzir ao mínimo as dependências entre elas. Equipes de plataforma e de apoio existem para facilitar o trabalho dessas equipes principais, e não para criar novas filas de aprovação.
Cuidados ao reorganizar
Reestruturar equipes tem custo alto. Relações de trabalho se desfazem, conhecimento se dispersa e a produtividade costuma cair por algum tempo. Reorganizações frequentes, sem objetivo claro, podem causar mais dano do que a estrutura que pretendiam corrigir.
Na visão de Murilo Moura Alencar, a mudança só vale a pena quando está ligada a um objetivo técnico e de negócio bem definido, como reduzir dependências que travam entregas ou permitir que uma área cresça de forma independente. Envolver as próprias equipes no desenho da nova estrutura aumenta as chances de que ela funcione na prática.
Organograma também é arquitetura
A Lei de Conway lembra que decisões de gestão e decisões técnicas estão profundamente ligadas. Murilo Moura Alencar frisa que quem desenha o organograma também está, em parte, desenhando o software da empresa.
Líderes que reconhecem essa relação tomam decisões mais coerentes sobre como dividir responsabilidades, onde investir em comunicação e como estruturar o crescimento. O resultado são sistemas mais fáceis de evoluir e equipes que conseguem entregar sem depender de longas cadeias de coordenação. Antes da próxima reestruturação, vale perguntar não apenas quem vai liderar cada equipe, mas que tipo de sistema essa nova divisão tende a produzir.