Como a Amazon lidou com problemas que diminuíram a velocidade da equipe – e não era o tamanho da equipe que mais importava.

Em seu livro “Working Backwards: Insights, Stories, and Secrets from Inside Amazon”, os veteranos da Amazon Colin Bryar e Bill Carr discutem o conceito de “equipes de 2 pizzas”. A ideia por trás das equipes de 2 pizzas é que elas sejam pequenas o suficiente para serem alimentadas com duas pizzas, com o objetivo de aumentar a velocidade de desenvolvimento do produto.

A frase tornou-se sinônimo da abordagem da Amazon para o desenvolvimento de produtos, mas eles revelam que a Amazon não enfatiza mais isso:

“Todos concordamos desde o início que uma equipe menor funcionaria melhor do que uma
maior. Mas depois percebemos que o maior preditor do sucesso de uma equipe não era se ela era pequena (…)”

Porém a Amazon descobriu que o tamanho da equipe não era o principal fator que atrasava as iniciativas — mas sim a dependência com outras equipes:

Para resolver os problemas de dependência com outros times, eles mencionam que as empresas normais tentam melhorar a comunicação entre as equipes, para que trabalhem com mais eficiência. Mas a Amazon seguiu na direção oposta. A comunicação entre as equipes foi considerada um “bug” e não uma “feature”. Eles não queriam melhorá-la, mas eliminá-la, para que as equipes pudessem se mover mais rapidamente sem dependências.

Para reduzir a dependência e as necessidades de comunicação entre equipes, Jeff Bezos enviou o famoso memorando sobre API para toda a empresa:

1. Todas as equipes passarão a expor os seus dados e funcionalidades através de interfaces de serviço [APIs].
2. As equipes devem se comunicar por meio dessas interfaces.
3. Não haverá nenhuma outra forma de comunicação entre processos permitida: nenhuma ligação direta, nenhuma leitura direta do armazenamento de dados de outra equipe, nenhum modelo de memória compartilhada, nenhum back-door. A única comunicação permitida será por meio de chamadas de interface de serviço pela rede.
4. Não importa qual tecnologia eles usam. HTTP, Corba, Pubsub, protocolos personalizados — não importa.
5. Todas as interfaces de serviço, sem exceção, devem ser projetadas desde o início para serem externalizáveis. Ou seja, a equipe deve planejar e projetar para poder expor a interface aos desenvolvedores do mundo exterior. Sem exceções.
6. Quem não fizer isso será demitido.
7. Obrigado; tenha um bom dia!

Imaginar receber um e-mail do CEO dizendo que você será demitido se não expor suas APIs. Tenho certeza de que foi uma maneira muito eficaz de mudar a cultura 😅

Este mandato foi essencial para a criação da AWS (as APIs já existiam e estavam preparadas para serem expostas ao mundo exterior), mas o principal objetivo era reduzir as dependências entre equipes. Você não precisava falar com uma equipe para interagir com seus recursos, bastava usar a API deles. Isso teve um efeito significativo na velocidade dos times.

Outra questão que contribui para desacelerar as coisas é a dependência na tomada de decisão, na forma de os líderes terem que aprovar as coisas. Bryan e Carr escreveram:

“Muitas empresas se veem lutando contra seu próprio aparelho burocrático, que aparece na forma de camada sobre camada de permissão, propriedade e responsabilidade, tudo trabalhando contra um progresso rápido e decisivo.“

Para combater isso, a Amazon introduziu o conceito de “single-threaded leader” e “single-threaded teams”, que eram líderes e equipes com uma única área de responsabilidade. Essa abordagem garantiu que cada time tivesse um líder claro, totalmente responsável por seu sucesso e sem outras distrações, o que aumentou ainda mais a velocidade do desenvolvimento do produto. “A melhor maneira de fracassar na invenção de algo é torná-lo o trabalho de meio período de alguém”.

Se você perceber, é quase como se a Amazon pegasse o conceito de microsserviços e o introduzisse na estrutura da organização. Exemplos de uma responsabilidade de single-threaded leader seriam o programa de afiliados da Amazon ou o negócio de livros digitais, este último com alguns single-threaded teams para focar ainda mais o trabalho de desenvolvimento de produto.

Em conclusão, as equipes de 2 pizzas têm a fama, mas os responsáveis por revolucionar o desenvolvimento de produto na Amazon foram reduzir as dependências da equipe e ter single-threaded leaders/teams que focavam em uma única área.

Este é um alerta para o pessoal do produto que está tentando implementar coisas que funcionaram em outras empresas: às vezes simplesmente não funcionou de verdade, às vezes a empresa já mudou ou a prática nunca foi difundida (Exemplo, Spotify Model) e/ou a prática requer uma cultura organizacional que sua empresa não compartilha. É necessário pensar nos princípios por trás de uma prática, em vez de apenas segui-la cegamente.