What Is It Like To Work For Amazon Web Services

What you don't know about working with AWS

You lot'll go further by understanding what a company values and what makes its employees tick.

Matt Asay By

Correspondent, InfoWorld |

What you don't know about working with AWS — AWS logo

August 27, 2021, was my last day at Amazon Web Services (AWS). I spent two years there, most of information technology running the company's open up source marketing and strategy squad. While ostensibly helping the earth better sympathise the open up source work AWS does, we actually spent most of our time inside AWS, helping product teams sympathise why and how to contribute to the relevant open up source upstreams upon which their services might depend. The residual was spent exterior the company, working with open source companies such as Confluent and Databricks to improve AWS partnerships with those companies.

Oh, and along the style, I helped put out dumpster fires that erupted when AWS was perceived to be doing "bad things" to open up source companies and communities.

In my experience, much of the ire directed at AWS over open up source is misplaced. No, it'south not that AWS is perfect, though the company remains one of the world'southward biggest contributors to open source projects. (Whether you measure by number of active contributors or lawmaking, you can meet the data for yourself by running this code.) Rather, it's more often than not an error in thinking of AWS as a monolithic entity with a mutual arroyo to open source. This is one of the chief myths about AWS that leads to misunderstanding, just there are more than, every bit I'll try to tackle here. Nix I'll write here is clandestine, though it's almost every bit if Amazon hides it all in manifestly sight.

2-pizza teams

Amazon Founder and old CEO Jeff Bezos instituted the "two-pizza rule" early in the visitor's history: "Nosotros try to create teams that are no larger than can be fed by ii pizzas." This is a bit of an exaggeration, but the principle is religiously adhered to beyond AWS. Teams tend to exist relatively modest and, just equally important, they are almost wholly democratic.

What does this mean? Well, it means that yous might exist correct that service team 10 isn't currently contributing back to an open source projection, but that doesn't hateful the same is truthful of the other service teams (more than 200 of them). The ElastiCache team, for example, employs one of the five maintainers of Redis. Other teams brand meaning contributions to Rust, Apache Lucene, Kubernetes, OpenTelemetry, etcd, Apache Iceberg, OpenJDK, GraphQL, and more than.

Are there service teams who don't yet piece of work with open source upstreams? Of course, just as there are at Microsoft, Google, Alibaba, etc. But while I worked for AWS, I saw this shifting. It'south a ho-hum procedure precisely because Amazon almost never works by top-downwards fiat. If you want Amazon to contribute more, you need to focus on individual teams and, but as importantly, you lot need to speak Amazonian.

Yes, those LPs are real

By "speak Amazonian" I'm referring to the linguistic communication and thought process embedded in the company's sixteen Leadership Principles (LPs). Before joining AWS I idea the LPs must be cheesy sloganeering at best, jingoism at worst, but it turns out they provide a common framework for more than one million Amazon employees to talk to each other and work together. They permeate almost every discussion at AWS, including the famous "vi-pagers" that are used to heighten ideas and decide operational plans.

When I joined AWS, I initially avoided using the LPs in discussions. It didn't go well. I'd say, "We should contribute to project Ten considering it's the right thing to do!" Blank stares. "We need to requite engineers more fourth dimension to contribute to projection Y then we tin influence the project's direction." Raised eyebrows. I was getting nowhere.

But so I tried framing my arguments with the LPs and things got much amend. I started proverb things similar, "Information technology's hard to 'Obsess over Customers' and evangelize innovation with 'Frugality' if nosotros don't 'Earn Trust' with the communities we depend on by making code contributions. This too allows u.s.a. to 'Insist on the Highest Standards' because our contributions put united states of america in a better position to 'Deliver Results' and support customers."

Suddenly, people understood what I meant. Information technology'southward not that they were dumbo before; rather, I needed to speak the language that calls out the principles that govern everything that is done at AWS (and, indeed, all of Amazon). If y'all want to change behavior at AWS, you must frame the desired upshot using the LPs. My team became increasingly adept at doing this, and it's paying off in ever-greater service team involvement in the projects upon which they depend. This is non to say there isn't room for improvement.

The spirit is willing

In my fourth dimension at AWS, I never heard a single person disparage the importance of open source. Quite the reverse. I know it'due south fun to caricature AWS equally a agglomeration of evil henchmen intent on strip-mining open source, but I never encountered anyone that fit that description. Rather, when I'd take disagreements with service team full general managers or others about the relative importance of open source to their business, our disagreements invariably came down to which LPs we weighed heaviest in a particular situation.

For example, "Customer Obsession" comes first for all Amazonians, but it tin be read in different ways. I might view open source contributions as disquisitional to obsessing over customers in the medium to long-term, but a service team full general manager too must consider the near term, which might mean creating a individual branch of code to ensure a company could rapidly set up bugs or deliver features customers were enervating. It's too the case that although customers all seem to similar and want open source, many value the operationalization of that lawmaking even more (something that Tim Bray pointed out years agone).

This ways that ensuring a seamless customer experience in the short term tin can sometimes consume the engineers who might otherwise be contributing to the longer-term success of a given project. I've seen this changing for the better at AWS but, again, at that place is no 1-size-fits-all approach to open source in a company filled with two-pizza teams.

Information technology likewise means that LPs such every bit "Ownership," "Invent and Simplify," "Insist on the Highest Standards," and "Deliver Results" can seemingly conflict with the desire to partner well with commercial stewards of open source projects. If a customer wants Apache Kafka made easier for them, the immediate response is to build a service that you lot can manage on their behalf, with as few moving parts or opportunities for failure as possible. Some other response is to partner to ensure that seamless customer experience. Though AWS has perhaps historically plant the first option easier to deliver, I'grand encouraged by all the success I saw with Confluent (in the Kafka instance), as well as other open up source companies.

In this expanse and others, AWS notwithstanding has a means to get—but and then we all practice. One of the things I've loved most for more than 20 years in open source is just how much more nosotros, as an industry (and as individual people and companies), have to learn despite years of trial and error. No one has cracked the code on the perfect fashion to build and run an open source project or business. We're all withal learning.

So let's exist patient with each other, and seek to understand why a person or company operates equally information technology does, as I've tried to practise here for AWS.

Matt Asay runs partner marketing at MongoDB.