Incentivo à inovação e velocidade com as equipes de duas pizzas da Amazon

A Amazon, como muitas empresas que começaram durante a era das pontocoms, foi organizada para agilidade e entrega constante de valor aos clientes. Em sua primeira Carta aos Acionistas em 1997, Jeff Bezos discutiu a importância de ficar obcecado pelos clientes e oferecer a eles valor contínuo a longo prazo, mesmo às custas do lucro corporativo de curto prazo. Essa obsessão implacável pelos clientes dependia da contratação e manutenção de uma estrutura organizacional de criadores capacitados que estavam entusiasmados em acordar todos os dias para resolver os problemas mais complexos dos clientes e criar inovações em nome deles.

“Estabelecer um alto padrão em nossa abordagem de contratação”, escreveu Jeff, “tem sido e continuará sendo o elemento mais importante do sucesso da Amazon.com.”

Isso era mais fácil de realizar naqueles primeiros dias, quando a empresa estava focada no comércio eletrônico, e as equipes e a arquitetura técnica na qual elas confiavam para oferecer inovação rápida eram mais centralizadas e fortemente acopladas. Mas com o tempo, conforme a Amazon expandiu o número de negócios e novas inovações para atender às necessidades de nossos clientes, começamos a sentir pressão na velocidade e na agilidade com que poderíamos executar os trabalhos. O desejo de continuar sendo uma “máquina de invenção”, como Jeff descreveu em sua Carta aos Acionistas de 2015, uma empresa que pode “combinar as capacidades extraordinárias de atendimento ao cliente possibilitadas pelo tamanho com a velocidade de movimento, agilidade e mentalidade de aceitação de riscos normalmente associada às startups empreendedoras”, começou a ser impactado. Nossa arquitetura e organização fortemente unidas não estavam nos ajudando a avançar tão rápido quanto queríamos ou precisávamos.

Para lidar com a crescente lentidão e ineficiência, mudamos fundamentalmente nossa arquitetura técnica para o que ficou conhecido como arquitetura de microsserviços. Dividimos nossa arquitetura monolítica em uma vasta rede de serviços únicos e autônomos. Ao fazer isso, conseguimos lançar rapidamente inovações e ofertas, iterar rapidamente os serviços existentes com base nas necessidades em constante mudança dos clientes e experimentar novas ideias constantemente para inventar em benefício dos clientes.

Mas simplesmente reformular a tecnologia que nossos construtores usaram para impulsionar a inovação não foi o suficiente. Também precisávamos reestruturar a forma como as equipes eram organizadas para maximizar a capacidade delas de permanecer próximas aos clientes e às necessidades deles, lançar rapidamente produtos e serviços inovadores e aproveitar melhor a agilidade e a velocidade que uma arquitetura de microsserviços poderia oferecer. Essa estrutura organizacional ficou conhecida como “equipes de duas pizzas” da Amazon.

O conceito das equipes de duas pizzas da Amazon é simples: nenhuma equipe deve ser grande o bastante para que sejam necessárias mais do que duas pizzas para alimentá-las. Deixando de lado a quantidade e a natureza dos recheios (não temos tempo e espaço para resolver a questão “deve existir pizza de abacaxi?”), idealmente, essa é uma equipe de menos de 10 pessoas: equipes menores minimizam as linhas de comunicação e diminuem a sobrecarga de burocracia e tomada de decisão. Isso permite que equipes de duas pizzas passem mais tempo se concentrando em seus clientes e constantemente experimentando e inovando em benefício deles, a maior prioridade das equipes de alto desempenho na Amazon.

Equipes menores também aumentam a propriedade e o empoderamento. Isso pode mitigar o Efeito Ringelmann: uma tendência de diminuição da produtividade individual em grupos maiores. À medida que os recursos da equipe se intensificam, há menos foco no esforço individual, pois as pessoas confiam mais nos outros para dividir os fardos. A magnitude da contribuição individual diminui à medida que o tamanho da equipe aumenta. Inversamente, o esforço individual aumenta à medida que o tamanho da equipe diminui.

Equipes menores também aumentam a satisfação dos funcionários, o que é uma preocupação fundamental, pois as organizações atuais se esforçam para atrair e reter os melhores talentos. Um estudo notável de Hackman e Vidmar mostra que a satisfação individual diminui à medida que o tamanho da equipe aumenta. Muitas vezes, em equipes grandes, as contribuições individuais são menos reconhecíveis e a propriedade individual de áreas específicas se torna mais difusa.

Isso foi confirmado em estudos sobre a força de trabalho. O estudo "The State of the American Workplace" da Gallup mostrou que organizações com menos de 10 funcionários obtiveram níveis de engajamento de 42% ou mais, enquanto o nível médio de engajamento de organizações maiores estava abaixo de 30%.

Mas, no caso de equipes de duas pizzas da Amazon, não se trata apenas do tamanho. Um fator importante para permitir inovação e velocidade constantes em uma estrutura de equipe de duas pizzas é capacitá-las com um segmento único.

► Ouça o podcast: C-Suite Strategies for Leading Significant Change

A equipe de duas pizzas não se refere apenas ao tamanho, mas à promoção e ao impulsionamento da propriedade e independência ao nível da equipe.

Na Amazon e na AWS, as equipes de duas pizzas têm propriedade de um único segmento sobre um produto ou serviço específico. Em vez de manter sistemas complexos ou resolver problemas que abrangem vários serviços, linhas de negócios ou segmentos de clientes, as equipes de duas pizzas se concentram em apenas um serviço ou oferta e apenas nos clientes que o utilizam. Esse foco de segmento único promove eficiência e escalabilidade. O roteiro das equipes de duas pizzas, incluindo as diferenças e prioridades que elas precisam ter, está especialmente focado em inovar em prol apenas do serviço e do segmento de clientes que usa esse serviço.

A estrutura de duas pizzas também promove a responsabilidade da equipe. Equipes de duas pizzas não entregam algo que lançaram para outra equipe administrar. Essa propriedade de um segmento único se estende por toda a experiência do cliente e por todo o ciclo de vida do produto ou serviço de uma equipe de duas pizzas.

Dessa forma, as equipes de duas pizzas precisam ficar por dentro de cada parte do serviço, com uma diretriz clara e uma missão bem definida. Elas precisam permanecer próximas aos clientes e criar os mecanismos de rastreamento, métricas e KPIs corretos para garantir que o serviço ofereça valor constantemente aos clientes.

Isso também exige que uma equipe de duas pizzas tenha os recursos certos incorporados a ela, como engenharia, testes, gerenciamento de produtos e programas, operações etc., para ajudá-la a ter propriedade e executar os serviços de ponta a ponta.

À medida que a demanda por um produto ou serviço cresce, em vez de expandir a equipe para muitos outros membros, procuramos maneiras de dividir as equipes em equipes de duas pizzas separadas trabalhando em uma subárea de segmento único do serviço. Essa mitose mantém uma estrutura organizacional mais plana que preserva a agilidade, a autonomia e a propriedade de segmento único.

No final das contas, quando falamos de uma equipe de duas pizzas, não se trata apenas de tamanho, mas de promover e levar a propriedade e a independência ao nível da equipe, da concepção à execução, da melhoria operacional contínua à constante iteração e inovação do produto. Isso permite que as equipes trabalhem com rapidez, façam experimentações com antecedência e frequência e apliquem o aprendizado rapidamente para gerar valor constantemente para seus clientes. Inovação e experimentação mais rápidas também ajudam a reduzir os custos do fracasso, o aprendizado é mais rápido e os riscos são menores do que os que poderiam ser enfrentados em estágios posteriores de desenvolvimento.

Embora a estrutura da equipe de duas pizzas tenha funcionado para a Amazon e a AWS, reconhecemos que ela pode não ser adequada para todas as organizações ou para todas as unidades de negócios. Equipes de duas pizzas não são perfeitas e não estão imunes a limitações. Um exemplo é que, com tantas equipes autônomas e de um único segmento trabalhando rapidamente para atender às necessidades de seus próprios clientes, existe o risco de duplicação e desenvolvimento em silos. Você precisa da estrutura de governança correta para decidir quando e como combinar esforços que sejam puramente replicativos, sem sufocar a capacidade das equipes de impulsionar a inovação em suas áreas de propriedade.

Com a experimentação rápida, também é necessário colaboração entre as equipes para impulsionar a multiplicação do sucesso e racionalizar os recursos. Ainda mais importante é a capacidade de capturar e compartilhar o aprendizado dos fracassos para aplicar melhor essas lições a experimentos futuros e ajustar a direção da iteração e futuras decisões de investimento.

Um aspecto da organização da Amazon e da AWS que ajuda a promover a governança e a supervisão, ao mesmo tempo em que permite que as equipes funcionem de forma rápida, independente e autônoma, é o conceito de líderes de um único segmento.

O papel de líderes de um único segmento é vital para instituir o nível certo de supervisão para reter a capacitação de uma equipe para inovar de forma independente em nome de seus clientes.

Os líderes executivos de hoje percebem o enorme benefício de poder oferecer inovação e transformação digital rapidamente. A capacidade de entrar rapidamente no mercado com novos produtos e serviços não é apenas crucial para oferecer valor constante aos clientes, mas também pode se tornar uma vantagem competitiva diferenciadora para sua empresa. Mas, à medida que a escala e o escopo dos negócios aumentam, os executivos precisam se certificar de que estão criando a estrutura e a liderança certas para garantir que as equipes tenham o poder de trabalhar com rapidez.

A governança e o gerenciamento de equipes devem fornecer “barreiras de proteção”, que são mecanismos que permitam às equipes agir rapidamente e tomar decisões de alta qualidade e alta velocidade, em vez de “pedágios” que impedem a velocidade ao aumentar as linhas de aprovação ou coordenação antes de permitir que as equipes progridam com experimentos inovadores.

Na Amazon e na AWS, o papel de líderes de um único segmento é vital para instituir o nível certo de supervisão para reter a capacitação da equipe para inovar de forma independente em nome de seus clientes, criando mecanismos consistentes que permitam o nível certo de inspeção e visão direcional. Líderes de um único segmento ajudam a fornecer uma visão estratégica e, em seguida, abrem o caminho para a equipe. Os líderes de equipe precisam ajudar a remover obstáculos, em vez de serem uma barreira pela qual todas as decisões precisam passar. Equipes pequenas, ágeis e autônomas, obcecadas diariamente por seus clientes, são as principais especialistas no assunto em seus serviços e segmentos de clientes.

Líderes de um único segmento precisam preservar a autonomia de sua equipe para tomar as melhores decisões para a empresa. O envolvimento de líderes de um único segmento na tomada de decisões da equipe é, na maioria das vezes, para ajudar a orientar a equipe em situações em que, mesmo com a instrumentação de dados correta e o melhor julgamento, o caminho a seguir pode não estar claro.

Um mecanismo usado na Amazon para facilitar a supervisão de um líder de um único segmento nesses postos de controle são as narrativas escritas. As narrativas nessas circunstâncias ajudam a delinear o problema enfrentado pelo cliente, trazem informações de análises profundas e dados que a equipe reuniu para informar as próximas etapas e articulam a decisão que a equipe recomenda, junto com os caminhos alternativos considerados e os riscos e benefícios de cada um desses caminhos.

Embora dedicar um tempo para escrever uma narrativa possa parecer contra-intuitivo para manter a velocidade e a execução constante, o uso de narrativas na Amazon e na AWS gerou benefícios extraordinários. Um deles é que esses documentos geralmente são altamente debatidos e refinados pela equipe, por partes interessadas e especialistas no assunto do segmento de ofertas e clientes da equipe, mesmo antes de chegarem à mesa de um executivo. Isso promove a colaboração e diversas perspectivas, desafia suposições e serve para refinar as ideias e recomendações contidas no documento. Em última análise, isso geralmente leva a decisões de maior qualidade.

Há muitas narrativas diferentes na Amazon e na AWS. Algumas estão focadas no lançamento de produtos, como nosso documento de PR e FAQ (Comunicado de imprensa e perguntas frequentes), que é o produto da nossa abordagem de trabalho na ordem inversa. Outras são avaliações operacionais de negócios (geralmente em cadências semanais, mensais e trimestrais) que fornecem inspeção e governança sobre as principais métricas, tendências, tensões, riscos e oportunidades que surgem nos negócios de uma equipe.

Temos narrativas que fornecem avaliações rigorosas de prontidão operacional antes do lançamento de qualquer novo serviço, nos aprofundando para garantir que aspectos da arquitetura de um serviço, sua qualidade e procedimentos de lançamento e os procedimentos associados de gerenciamento de incidentes e eventos sejam bem formulados e documentados. Outras narrativas, como nosso documento de correção de erros, são feitas post-mortem, quando um serviço afeta negativamente os clientes. Esses documentos são conduzidos pela equipe proprietária do serviço, não como um motivo de culpa, mas porque, como a equipe de um único segmento proprietária desse serviço, ela está mais próxima e tem mais conhecimento sobre esse serviço e seus clientes.

Nesses documentos de correção de erros (ou COE), a equipe se aprofunda para descrever completamente o que aconteceu, fornecendo análises quantitativas e dados relevantes sobre o impacto do fracasso de um serviço e por que ele ocorreu. Ela remove camadas para identificar as causas principais, incluindo todos os fatores contribuintes, e descreve como não apenas abordou a causa raiz, mas o que continuará a fazer para garantir que isso não aconteça novamente, atualizando ou criando novos mecanismos de inspeção e melhoria contínua. Esses documentos são então retidos em um banco de dados pesquisável para que o valioso aprendizado possa ser compartilhado de forma interfuncional.