Customer Obsession: Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
Customer Obsession is great, but I often see Amazonians taking this too simplistically: "Start with the customer" doesn't have to mean "ask customers what they want and then give them faster horses". In the early days of AWS I saw a lot of what I call "cool engineering driven" products: When EC2 launched, it wasn't really clear what people would do with it, but it was very cool and it was clear that it could be a big deal in some form, sooner or later. Some time around 2012, the culture in AWS seemed to shift from "provide cool building blocks" to "build what customers are asking for" and in my view this was a step in the wrong direction (mind you, not nearly as much as the ca. 2020 shift to "build what analysts are asking for in quarterly earnings calls"). This tension of what customers are asking for vs what customers really need shows up in areas like resilience. Amazon's "Well-Architected Framework" strongly exhorts customers to avoid building production workloads in a single Availability Zone — but Amazon's cross-AZ bandwidth pricing is painful, and Amazon doesn't provide useful tools for building durable multi-AZ applications. Most customers are not going to implement Paxos, and very few customers — certainly not executives who are removed from actual development processes — are going to ask Amazon for Paxos-as-a-service; but if Amazonians sat down and asked themselves "what do customers need in order to design their applications well" they could probably come up with several services which Amazon already has internally. AWS should return to its roots and release important building blocks — the things customers will need, not necessarily what they're asking for.
Ownership: Leaders are owners. They think long term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say "that's not my job."
This principle is both too narrow, and not being fulfilled, in my view. It's not enough to simply act on behalf of the entire company: It's important to act on behalf of the entire technological ecosystem. Some Amazonians are great at this — I recently commited patches to FreeBSD's bhyve because an Amazonian was putting together a standard for interrupt handling in large VMs, and even though Amazon doesn't make any use of bhyve (at least, I don't think it does!) he understood the importance of getting standards widely accepted across the entire virtualization space rather than narrowly in the code Amazon relied upon. There's a saying in computer security, that anything which makes one of us less secure makes all of us less secure: Attackers will leverage an exploit against one system to allow them to attack another system. While the same does not directly apply in other fields, working with others to produce the best results for everyone will be much better in the long-term than focusing solely on what Amazon needs right now. But in general Amazon doesn't even live up to its stated (narrow) promise of having leaders acting on behalf of the entire company — it's simply too siloed. Amazon is famously secretive, and this applies internally as well as externally: When AWS launches two similar services, it's often because two teams didn't know what each other was working on. How can leaders act across the entire company if nobody knows what's happening outside of their team? They can't; and if Amazon wants to allow its best people to be true Owners, Amazon needs to start breaking down walls.