O que você não sabe sobre como é trabalhar na AWS

Você irá mais longe ao entender o que uma empresa valoriza e o que motiva seus funcionários

Author Photo
4:01 pm - 01 de setembro de 2021

O dia 27 de agosto de 2021 foi o meu último dia na Amazon Web Services (AWS). Passei dois anos lá, a maior parte do tempo gerenciando a equipe de marketing e a estratégia de código aberto da empresa. Enquanto aparentemente ajudamos o mundo a entender melhor o trabalho de código aberto que a AWS faz, na verdade passamos a maior parte do nosso tempo dentro da AWS, ajudando o mundo a entender melhor por que e como contribuir para os upstreams de código aberto relevantes dos quais seus serviços podem depender. O resto do tempo foi gasto fora da empresa, trabalhando com empresas de código aberto, como Confluent e Databricks, para melhorar as parcerias da AWS com essas empresas.

Ah, e ao longo do caminho, ajudei a apagar certos incêndios que eclodiram quando a AWS foi apontada por fazer “coisas ruins” para empresas e comunidades de código aberto.

Na minha experiência, muito da ira dirigida à AWS sobre o código aberto é mal colocada. Não, não é que a AWS seja perfeita, embora a empresa continue sendo uma das maiores contribuintes do mundo para projetos de código aberto. (Se você medir pelo número de contribuidores ativos ou código, você pode ver os dados por si mesmo executando este código.) Em vez disso, é principalmente um erro pensar na AWS como uma entidade monolítica com uma abordagem comum de código aberto. Este é um dos principais mitos sobre a AWS que leva a mal-entendidos, mas há mais, como tentarei abordar aqui. Nada do que vou escrever aqui é segredo, embora seja quase como se a Amazon escondesse tudo à vista de todos.

A regra das duas pizzas

O fundador e ex-CEO da Amazon, Jeff Bezos, instituiu a “regra das duas pizzas” no início da história da empresa: “Tentamos criar equipes que não sejam maiores do que podem ser alimentadas por duas pizzas.” Isso é um pouco exagerado, mas o princípio é religiosamente respeitado em toda a AWS. As equipes tendem a ser relativamente pequenas e, tão importante, são quase totalmente autônomas.

O que isto significa? Bem, isso significa que você pode estar certo de que a equipe de serviço X não está contribuindo para um projeto de código aberto, mas isso não significa que o mesmo seja verdadeiro para as outras equipes de serviço (mais de 200 delas). A equipe ElastiCache, por exemplo, emprega um dos cinco mantenedores do Redis. Outras equipes fazem contribuições significativas para Rust, Apache Lucene, Kubernetes, OpenTelemetry, etcd, Apache Iceberg, OpenJDK, GraphQL e muito mais.

Existem equipes de serviço que ainda não trabalham com upstreams de código aberto? Claro, assim como existem na Microsoft, Google, Alibaba, etc. Mas enquanto eu trabalhava para a AWS, vi essa mudança. É um processo lento precisamente porque a Amazon quase nunca funciona por decreto de cima para baixo. Se você deseja que a Amazon contribua mais, você precisa se concentrar em equipes individuais e, tão importante, você precisa falar o idioma Amazon.

Sim, os princípios de liderança são reais

Por “falar o idioma Amazon”, estou me referindo à linguagem e ao processo de pensamento embutido nos 16 Princípios de Liderança da empresa. Antes de ingressar na AWS, pensei que estes princípios deviam ser slogans cafonas na melhor das hipóteses, mas descobri que eles fornecem uma estrutura comum para que mais de um milhão de funcionários da Amazon conversem entre si e trabalhem juntos. Eles permeiam virtualmente todas as discussões na AWS.

Quando entrei para a AWS, inicialmente evitei usar os princípios nas discussões. Não correu bem. Eu diria: “Devemos contribuir para o projeto X porque é a coisa certa a fazer!” Olhares em branco. “Precisamos dar aos engenheiros mais tempo para contribuir com o projeto Y para que possamos influenciar a direção do projeto.” Sobrancelhas levantadas. Eu não estava chegando a lugar nenhum.

Mas então tentei enquadrar meus argumentos com os tais princípios e as coisas ficaram muito melhores. Comecei a dizer coisas como: “É difícil ‘ficar obcecado pelos clientes’ e oferecer inovação com ‘frugalidade’ se não ‘ganharmos confiança’ com as comunidades das quais dependemos, fazendo contribuições para o código. Isso também nos permite ‘Insistir nos Padrões Mais Elevados’ porque nossas contribuições nos colocam em uma posição melhor para ‘Entregar Resultados’ e apoiar os clientes ”.

De repente, as pessoas entenderam o que eu quis dizer. Não é que eles eram densos antes; em vez disso, eu precisava falar a linguagem que expõe os princípios que regem tudo o que é feito na AWS (e, de fato, toda a Amazon). Se você quiser mudar o comportamento na AWS, deve enquadrar o resultado desejado usando os princípios. Minha equipe tornou-se cada vez mais hábil em fazer isso, e foi recompensada com um envolvimento cada vez maior da equipe de serviço nos projetos dos quais dependem. Isso não quer dizer que não haja espaço para melhorias.

O espírito é estar disposto

Em meu tempo na AWS, nunca ouvi uma única pessoa denegrir a importância do código aberto. Pelo contrário. Eu sei que é divertido caricaturar a AWS como um bando de capangas do mal com a intenção de explorar o código aberto de mineração, mas nunca encontrei ninguém que se encaixasse nessa descrição. Em vez disso, quando eu discordava dos gerentes gerais da equipe de serviço ou outros sobre a importância relativa do código aberto para seus negócios, nossas divergências invariavelmente se resumiam a quais LPs pesávamos mais em uma situação particular.

Por exemplo, “Obsessão pelo cliente” vem em primeiro lugar para todos na Amazon, mas pode ser lido de maneiras diferentes. Posso ver as contribuições de código aberto como essenciais para a obsessão pelos clientes a médio e longo prazo, mas um gerente geral da equipe de serviço também deve considerar o curto prazo, o que pode significar a criação de um ramo privado de código para garantir que uma empresa possa corrigir bugs rapidamente ou entregar recursos que os clientes estavam exigindo. Também é verdade que, embora todos os clientes pareçam gostar e querer código aberto, muitos valorizam a operacionalização desse código ainda mais (algo que Tim Bray apontou anos atrás).

Isso significa que garantir uma experiência perfeita para o cliente no curto prazo às vezes pode consumir os engenheiros que, de outra forma, poderiam estar contribuindo para o sucesso de um determinado projeto a longo prazo. Eu vi isso mudar para melhor na AWS, mas, novamente, não existe uma abordagem única para o código aberto em uma empresa cheia de equipes “duas pizzas”.

Isso também significa que os princípios como “Propriedade”, “Inventar e Simplificar”, “Insistir nos Padrões Mais Elevados” e “Entregar Resultados” podem aparentemente entrar em conflito com o desejo de boa parceria com administradores comerciais de projetos de código aberto. Se um cliente deseja que o Apache Kafka seja mais fácil para ele, a resposta imediata é criar um serviço que você possa gerenciar em seu nome, com o mínimo possível de peças móveis ou oportunidades de falha. Outra resposta é o parceiro para garantir uma experiência perfeita para o cliente. Embora a AWS talvez tenha achado historicamente a primeira opção mais fácil de entregar, estou encorajado por todo o sucesso que vi com o Confluent (no caso Kafka), bem como com outras empresas de código aberto.

Nesta área e em outras, a AWS ainda tem um longo caminho a percorrer – mas todos nós temos. Uma das coisas que mais amei por mais de 20 anos no código aberto é o quanto mais nós, como indústria (e como indivíduos e empresas), temos que aprender apesar de anos de tentativa e erro. Ninguém decifrou o código da maneira perfeita de construir e executar um projeto ou negócio de código aberto. Ainda estamos todos aprendendo.

Portanto, sejamos pacientes uns com os outros e procuremos entender por que uma pessoa ou empresa opera dessa forma, como tentei fazer aqui para a AWS.

Tags:

Newsletter de tecnologia para você

Os melhores conteúdos do IT Forum na sua caixa de entrada.