Quando entrei na Amazon, Jeff teve uma ideia: nenhuma equipe deveria ser tão grande que não pudesse ser alimentada por duas pizzas. Naqueles primeiros dias, algumas equipes eram tão pequenas que uma pizza seria suficiente para realizar o trabalho. Mas nunca se tratou realmente de alimentar engenheiros famintos. Poderíamos facilmente ter dito uma “equipe de seis sanduíches”, mas os sanduíches não evocam as mesmas imagens que a pizza. Pizza é o que você pede quando você e seus colegas estão amontoados no quadro branco até tarde da noite.
Queríamos manter as equipes pequenas o suficiente para que todos na sala soubessem no que todos estavam trabalhando, sem a necessidade de reuniões. Cada membro da equipe period dono do produto. Você tinha autonomia para tomar decisões com o mínimo de burocracia possível. Você foi capacitado para agir rapidamente, experimentar e não ter medo do fracasso. Se a decisão fosse reversível, você não precisava de permissão para tomá-la. Você conseguiu, aprendeu com isso e, se deu errado, você reverteu. O custo de uma decisão errada e reversível é quase sempre inferior ao custo de tomar essa decisão lentamente.
À medida que nossa base de clientes crescia, também crescia o número de nossas equipes. Quando você passa de três serviços para mais de duzentos, você não consegue manter a mesma estrutura organizacional. É física simples: à medida que os sistemas crescem, também cresce a sua entropia. Cada serviço requer proprietários, e os proprietários precisam coordenar-se com as equipes de cujos serviços dependem. As estruturas organizacionais ficam em camadas, as dependências se multiplicam e os ciclos de aprovação aparecem onde não existiam antes. De repente, uma equipe que costumava controlar um problema de ponta a ponta agora precisa do alinhamento de várias equipes antes de escrever uma única linha de código. Em algum momento, a inércia de qualquer empresa em crescimento começa a atuar contra a própria cultura que a tornou bem-sucedida. Isso não significa necessariamente que a qualidade do produto será prejudicada, mas, a menos que você lute contra isso, significa que a velocidade de entrega diminuirá.
Junto com a abordagem de duas pizzas para gerenciar o tamanho da equipe, usamos uma abordagem única para definir nossos produtos – trabalhando de trás para frente, a partir do cliente. EU escrevi sobre isso em 2006:
O processo de definição do produto Working Backwards trata de concretizar o conceito e alcançar clareza de pensamento sobre o que iremos construir. Normalmente tem quatro etapas:
- Comece escrevendo o comunicado à imprensa
- Escreva um documento de perguntas frequentes
- Defina a experiência do cliente
- Escreva o guide do usuário
Alcançamos sucessos notáveis trabalhando de trás para frente e resolvemos problemas reais para milhões de clientes usando feitos de engenharia que ainda me surpreendem até hoje. Nossas equipes ainda estão dimensionadas em torno do nosso modelo de duas pizzas. Eles ainda se movem rapidamente e quebram as coisas, mas esperam até que tenham definido totalmente o problema e toda a linha de negócios entenda claramente como irão resolvê-lo juntos.
Mas há uma mudança acontecendo em nosso setor, e continuo ouvindo histórias na Amazon que me desafiam a pensar de maneira um pouco diferente sobre o processo de dar vida aos produtos. Se você observar as quatro etapas acima, verá que o que elas têm em comum é pensar profundamente sobre o espaço do problema e depois escrever sobre ele. Tirar a ideia da cabeça e colocá-la no papel é como você aprimora a ideia. Você abre buracos, descobre o que não sabe e compartilha com seus colegas para chegar a uma compreensão compartilhada do que será construído. É um trabalho árduo escrever um documento nítido e quase impossível se você não tiver clareza de espírito sobre o problema do cliente que deseja resolver. Mas há outra razão muito deliberada para usarmos a escrita na Amazon: a escrita permite que qualquer pessoa construa um produto porque não exige que você saiba como codificar. Um gerente de produto, um designer de UI, um analista de negócios, qualquer pessoa com uma ideia bem escrita e argumentos convincentes poderia definir o que será construído a seguir.
Mas o que acontece quando qualquer pessoa com uma ideia pode conversar com um agente de codificação e produzir a estrutura funcional de um produto em uma única noite?
No remaining de janeiro de 2025, alguns dos nossos cientistas estavam conversando entre si e perceberam que todos estavam pensando no mesmo espaço problemático de forma independente. Como você dá a um agente uma memória que persiste? Como você permite que vários agentes coordenem sem um gargalo central? Como você mantém os humanos no controle enquanto o sistema é dimensionado? Eles precisavam de um sistema operacional para agentes. Eles decidiram ficar juntos em uma sala por alguns dias e ver o que conseguiam fazer.
Thomas Delteilque é um dos principais cientistas do nosso Equipe rápida da Amazonestava preocupado com o ritmo a que as boas ideias estavam a morrer. O ciclo de propor uma ideia, esperar pela discussão, construir uma prova de conceito, fazer benchmarking, buscar visibilidade para ela e depois esperar novamente pela próxima rodada de aprovações estava matando ideias antes que elas chegassem a um único cliente. Então, quando a conversa se voltou para o que eles poderiam construir se parassem de esperar por permissão, Thomas passou a noite inteira usando Kiro para construir o primeiro protótipo do que se tornaria o Amazon Fast Desktop. Quando ele fez uma demonstração no dia seguinte, a primeira pergunta da equipe foi “como faço para colocar isso no meu laptop computer agora?” e a segunda foi “em que posso ajudar?” Poucas horas depois de vê-lo pela primeira vez, o projeto tinha um proprietário para o feed de atividades, um proprietário para a memória, um proprietário para o gráfico de conhecimento e um proprietário para o chicote de agente.
Dentro de uma semana, Swami Sivasubramaniannosso vice-presidente de Agentic AI, viu o protótipo e deu whole apoio à equipe. Três engenheiros se juntaram. Na segunda semana, eles tinham um gerente de desenvolvimento de software program e mais alguns engenheiros, alcançando uma divisão aproximadamente igual entre ciência e engenharia. Eles foram deliberados em não escalar muito rápido. Cada pessoa contratada foi selecionada porque tinha uma habilidade específica e teve que se adaptar a uma cultura que period totalmente diferente da forma como a organização mais ampla operava. Esperava-se que eles assumissem o problema e o entregassem com autonomia, e propriedade significava a mesma coisa que sempre significou na Amazon: você constrói, você é o dono.
Leo Ohannesianoo gerente de produto recrutado para se juntar à equipe Fast cinco dias após o início do esforço, passou anos trabalhando em organizações que começaram com um PRFAQ, passaria por ciclos de revisão, garantiria financiamento, atribuiria proprietários e definiria prazos. Nesta equipe inicial, não havia nada disso. Mudar para um modelo em que um pequeno grupo de funcionários seniores tinha whole confiança para tomar as decisões corretas produziu uma velocidade que ele nunca havia experimentado em sua carreira.
Um grande impulsionador do que tornou esse ritmo possível foi que cada pessoa da equipe usou o produto como seu principal assistente de IA desde o primeiro dia. Thomas estava construindo do jeito que queria que fosse um assistente, e tudo o que não gostava, ele consertava. Todos na equipe operavam da mesma maneira. Eles não deixaram arestas para um designer suavizar mais tarde ou registraram um ticket para um engenheiro de front-end resolver no próximo dash. Se você percebeu que algo estava errado enquanto o usava, você period o dono e consertou. Cada revisão de código veio com um vídeo da experiência porque a revisão do código isoladamente não diz nada sobre se o produto parece adequado para uso. Esta foi uma inversão deliberada de como a equipe havia trabalhado antes, onde você faria um benchmark primeiro e descobriria a experiência depois. Aqui, a regra period: não examine nada até estar satisfeito com a experiência que você tem.
Clara Ligórioengenheira principal sênior que liderou o desenvolvimento do Kiro, falou sobre sua experiência em meu re: Inventar palestra ano passado e escreveu recentemente sobre esse mesmo padrão. Sua observação é que, quando a construção de um protótipo leva dias, não meses, faz mais sentido prototipar antes de escrever. Sua equipe começou a usar o IDE em tempo integral desde o momento em que o primeiro protótipo funcionou, e o desenvolveu diariamente com base no que realmente precisavam.
Escrever ainda é tão importante como sempre, e deve ser você quem escreve, não sua IA. Escrever força você a pensar com clareza e enfrentar lacunas em sua lógica. O que mudou é que escrever não é mais a única forma de tornar uma ideia tangível. Os agentes de codificação estão reduzindo o tempo entre a definição do problema e a obtenção de algo actual em mãos para avaliar. É hora de alterar a forma como pensamos sobre o processo que nos trouxe até aqui. Você aprenderá mais em uma noite de construção do que em duas semanas escrevendo sobre o que você acha que vai acontecer. Somente depois de passar algum tempo com o protótipo, usá-lo como um cliente o faria e desenvolver uma compreensão actual do que ele pode ou não fazer, é que você inicia o processo de redação. O documento que você produz após a construção é fundamentalmente melhor do que aquele que você teria escrito antes, porque não está mais baseado em suas suposições.
Então, como podemos alterar o Working Backwards? Quando você tem convicção sobre o problema do cliente, mas tem uma incerteza genuína sobre se sua abordagem funcionará, você começa construindo um protótipo. Então você o usa da mesma forma que um cliente faria. Você quebra coisas, encontra as lacunas que sua intuição deixou escapar, depois compartilha com alguns colegas e, se houver entusiasmo em torno do que você construiu, você escreve o documento. Ter algo tangível para clicar enquanto você escreve altera a qualidade do documento. Você não está mais descrevendo algo que apenas imaginou em sua cabeça. Você está descrevendo algo que existe agora e foi testado sob pressão, e sua escrita refletirá isso.
A equipe do Fast Desktop não é mais um punhado de pessoas em uma sala de conferências. Eles cresceram para centenas de engenheiros, cientistas, designers e gerentes de produto. Essa é a trajetória pure de um produto que centenas de milhares de pessoas usam todos os dias. Cada equipe que ultrapassa um certo limite enfrenta a mesma atração gravitacional em direção à sobrecarga que descrevi anteriormente. A maneira como você luta contra isso permite às suas equipes a liberdade de operar como um conjunto de equipes de duas pizzas, cada uma com propriedade clara e autonomia para tomar decisões reversíveis sem pedir permissão. Você combate isso mantendo o ciclo de suggestions curto: construir, usar, aprender, iterar. Você combate isso contratando pessoas que se sentem desconfortáveis quando não assumem o controle do problema de ponta a ponta e dando-lhes as ferramentas para agirem sobre esse desconforto.
Duas pizzas sempre foram uma questão de cultura de propriedade, e as ferramentas acompanharam a cultura. O que tornou a equipe do Fast Desktop bem-sucedida foi a mesma coisa que sempre produziu o melhor trabalho que já vi na Amazon: um pequeno grupo de pessoas que confiavam umas nas outras, controlavam o problema de ponta a ponta e agiam de acordo com suas convicções.
Agora, vá construir!