A equipe de duas pizzas precisa de uma wiki

O modelo de equipe de duas pizzas da Amazon é uma das ideias mais influentes no design organizacional moderno. Mantenha as equipes pequenas o suficiente para que duas pizzas possam alimentá-las (cerca de 5 a 8 pessoas). Dê a cada equipe a propriedade clara de um domínio definido. Deixe-as operar de forma autônoma, tomando decisões sem esperar pela aprovação de uma autoridade central.

O modelo funciona. Pesquisas mostram consistentemente que equipes pequenas e autônomas com limites claros de propriedade mantêm uma produtividade por pessoa maior do que equipes grandes. Elas se comunicam de forma mais eficiente, tomam decisões mais rápido e entregam com mais frequência. A explosão dos caminhos de comunicação que desacelera equipes grandes é contida dentro do número gerenciável de caminhos de cada equipe pequena.

Mas o modelo tem uma dependência que raramente é discutida na literatura de design organizacional: ele só funciona se a camada de conhecimento entre as equipes for forte o suficiente para lidar com a coordenação interequipes que a estrutura de equipes pequenas cria.

O problema entre equipes

Quando você divide uma equipe de 30 pessoas em cinco equipes de 6 pessoas, você reduz drasticamente o custo de coordenação interna (de 435 caminhos para cinco conjuntos de 15 caminhos). Mas você cria uma nova superfície de coordenação: as fronteiras entre as equipes.

A Equipe A é proprietária do serviço de pagamentos. A Equipe B é proprietária do serviço de usuários. A Equipe C é proprietária do gateway de API. Cada equipe é autônoma dentro do seu domínio. Mas os domínios interagem: o gateway de API direciona as solicitações tanto para o serviço de usuários quanto para o serviço de pagamentos, e o serviço de pagamentos precisa dos dados do usuário provenientes do serviço de usuários. Essas interações exigem coordenação interequipes, e a qualidade dessa coordenação depende de quão bem o conhecimento de cada equipe está acessível para as outras.

Se o conhecimento da Equipe A sobre o serviço de pagamentos estiver apenas na cabeça das pessoas da Equipe A, a Equipe B terá que interromper a Equipe A toda vez que precisar entender como funcionam os pagamentos. O custo de coordenação não foi eliminado pela estrutura de equipes pequenas. Ele foi movido de dentro da equipe para entre as equipes, e a coordenação interequipes costuma ser mais cara porque as pessoas envolvidas não compartilham o mesmo contexto diário.

A dependência da documentação

Equipes pequenas funcionam quando o conhecimento do domínio de cada equipe está documentado bem o suficiente para que outras equipes possam acessá-lo sem a necessidade de uma reunião ou de uma conversa no Slack.

Isso significa que cada equipe precisa de:

Documentação do sistema que descreva o que o serviço faz, como ele funciona e como interagir com ele. Não apenas documentos de API, mas contexto arquitetônico: por que foi construído dessa maneira, sob quais restrições ele opera e o que vai quebrar se você fizer certas suposições sobre seu comportamento.

Registros de decisão que expliquem o raciocínio por trás das principais escolhas técnicas. Quando a Equipe B encontrar algo inesperado no serviço da Equipe A, ela deve ser capaz de entender por que funciona daquela maneira lendo o registro de decisão, em vez de agendar uma reunião com la Equipe A.

Documentação de alterações que registre o que mudou e por quê. Quando a Equipe A modifica seu serviço de uma forma que afeta a Equipe B, a alteração e suas implicações devem estar visíveis na documentação, em vez de serem comunicadas por meio de uma mensagem no Slack que a Equipe B pode perder.

Conhecimento pesquisável que esteja acessível além das fronteiras das equipes. A Equipe B deve ser capaz de pesquisar na documentação da Equipe A tão facilmente quanto na sua própria, e a pesquisa deve funcionar por significado, para que não precisem conhecer as convenções de nomenclatura da Equipe A para encontrar o que precisam.

A escrita automatizada como facilitadora

A razão pela qual a maioria das implementações de equipes pequenas investe pouco em documentação interequipes é que o fardo da documentação recai sobre as equipes individuais, que já estão ocupadas com seu próprio trabalho. Pedir a uma equipe de seis pessoas para manter uma documentação abrangente para o benefício de outras equipes, além de entregar suas próprias funcionalidades, é pedir para que a documentação seja perpetuamente despriorizada.

A documentação autoescrita muda essa equação. A documentação de cada equipe é gerada a partir de suas atividades existentes: PRs, conversas no Slack, reuniões. A documentação permanece atualizada porque é derivada do próprio trabalho, em vez de ser mantida como uma tarefa separada. Outras equipes podem pesquisá-la porque ela faz parte de uma camada de conhecimento unificada que abrange toda a organização.

O modelo de equipe de duas pizzas é uma estratégia organizacional. A documentação autoescrita é a infraestrutura de conhecimento que faz com que ele funcione. Sem ela, equipes pequenas são apenas silos menores, e o custo de coordenação muda de lugar em vez de encolher.

Perguntas frequentes

E as APIs e os contratos das equipes? A documentação de APIs e os contratos de serviço são essenciais, mas insuficientes. Eles descrevem a interface, mas não o raciocínio. Uma equipe que sabe o que a API de outra equipe faz, mas não sabe por que funciona daquela maneira, tomará decisões de integração com base em um entendimento incompleto. Registros de decisão e documentação de arquitetura preenchem essa lacuna.

Como lidamos com as dependências entre as equipes? Documente as dependências explicitamente em uma camada compartilhada. Quando a Equipe A sabe que a Equipe B depende de um comportamento específico de seu serviço, essa dependência deve estar visível na documentação, de modo que as alterações que a afetam sejam sinalizadas antes de serem publicadas.

Isso se aplica a equipes que não são de engenharia? A mesma dinâmica se aplica a qualquer organização que utilize equipes pequenas e autônomas. Células de marketing, equipes de vendas, squads de produtos: todos precisam de uma camada de conhecimento compartilhada para coordenar as ações além das fronteiras das equipes sem reuniões constantes.

Leitura recomendada: O problema de escala do conhecimento, A Lei de Brooks ainda está certa, Como escalar uma equipe de engenharia. Páginas relacionadas: Documentos autoescritos, Pesquisa unificada, Para equipes de engenharia.