If you woke up Andy Jassy (when he was still leading AWS) in the middle of the night and asked him the top challenges in one of the AWS services e.g. Redshift, he would likely be able to tell you immediately!
One of the reasons he can do that, is AWS’s mechanisms that work at a massive scale across 100s of services  - e.g. PE reviews, operational reviews, WBRs, OP1s etc. These practices allowed AWS to scale the business organically from 2 services with less than 100 people to 100s of services with 20,000+ people in less than 10 years.
The most effective SCALING mechanism (and secret sauce) is their leadership principles. If someone told me that a set of principles is the secret sauce for a $1T company, I would be skeptical too!
Most companies have core principles. When I joined AWS, I was surprised by how often folks internally referred to Amazon’s leadership principles. Most of them probably could tell you all the principles (all 14 16) instantly!
So what.. Why does it even matter and what does it have to do with scaling?
Designed correctly - Tenets/principles capture and guide behavior at the company that is valued. It is the fabric of the culture at Amazon. Folks who are not aligned with these principles find it hard to thrive at Amazon.
How has this helped Amazon scale? Amazon’s principles guide how decisions are made in the company at every level. You will see these principles internalized in calibrations, in feedbacks, in promotions, in hiring and used in many project conversations. Some principles like Customer Obsession deeply influence the company’s decision making frameworks. Every hire is based not just on technical competencies but how well they align with those principles. E.g. Ownership is a principle and your interview will likely have a question along - ‘Tell me about a time that you acted on behalf of a team outside yours’.
Having a shared rubric that is so well understood and internalized in daily vocabulary has allowed Amazon to scale to 900,000 people rapidly and push down decision making. AWS leadership doesn’t have to be in the hiring loop to ensure that DynamoDB’s next engineering leader is tested for culture fit and has customer focus. During calibrations or hiring bar, everyone in the room knows precisely what someone means when they say ‘X has good bias for action’. Leaders understand that they need to balance ‘bias for action’ with ‘insist on high standards’ on a project.
Why does this mechanism work at Amazon and how you can use this (CAP) framework?
Create principles that embody and guide the culture you want reflected in your teams. Ensure these principles reflect the judgement in day to day decision making. These often requires balancing multiple ‘aspirations’ that maybe at odds with each other - e.g. Move fast and Ship Quality Products. A quick litmus test for this - if you are not in the room and the set of folks making a key decision had these principles - would that allow them to consider similar facets that you would too? If yes, then good otherwise maybe refine your principles.
Apply these principles in daily decision making. Teams ideally internalize and use these principles in their work. E.g. the lambda runtime teams used Customer Obsession and Insist on High standards - to establish ‘Ease of use’ and ‘highly secure’ as guiding tenets for their project. This enabled engineers to balance both needs and not ship a product that is super secure but painful for customers to use.
People processes: Incorporate and connect these with people processes like hiring and reward systems. E.g. If ownership is one of your principles, that should be one of the core attributes for which you hire and you should reward folks who demonstrate it.
Please share with your friends.