Turns out AWS can partner after all

Amazon Web Services (AWS) has never been the open source ogre that some have claimed, but it also hasn’t been quite as good as some have wanted. As AWS has grown larger, my personal view is that it has sometimes struggled to apply its own Leadership Principles or LPs (“Customer Obsession,” “Deliver Results,” “Insist on the Highest Standards,” “Bias for Action,” etc.). It has had difficulty controlling the customer experience while not stepping all over its partners’ toes when partners were often better situated to deliver a superior customer experience. In Amazonian-speak, the company wasn’t “Earning Trust.” Arguably, it failed to care for customers that might prefer “full-fat” partner software but were instead served a native AWS “skim milk” alternative.

That, apparently, was then. This is now.

The AWS of now keeps surprising the market with improved partnerships. Today AWS and MongoDB (disclosure: I work for MongoDB) announced a deep, strategic partnership that covers everything from extensive product integrations to joint developer relations initiatives to comarketing and coselling programs. This is a “very big deal” because the two companies have spent years fighting over compatibility of competing services and more. Nor is this the only example of AWS partnering well with erstwhile competitors: AWS and Confluent announced a strategic collaboration agreement in January 2022. I assume we’ll see others. Maybe many others.

As such, though AWS still has areas in which it can improve, it’s fair to say that old labels for AWS (like “strip miner”) are in serious need of a refresh.

This is not the AWS you’re looking for

In my experience, many outside observers don’t understand how AWS operates and therefore struggle to understand how it works with partners or customers. After I left AWS for MongoDB, I tried to describe some of the internal mechanics of AWS that both enable and complicate its approach to partnerships. To summarize, though everyone who works for Amazon is animated by the LPs, teams are intentionally kept relatively small and run autonomously, which affects the consistency of how LPs are used. This is good and bad.

For example, each individual team can interpret an LP such as “Customer Obsession” differently. Some might believe it’s best to contribute code to the relevant upstream open source communities, thereby minimizing technical debt and keeping higher fidelity to open source versions. Others, leaning into “Deliver Results,” might feel the need to patch a project without slowing down to make the effort to upstream those changes. Both teams have good intentions to serve customers, but they generate very different results.