Introduction
Disclaimer: This post doesn't aim to be a serious evaluation of the Amazon principles. Seattle-based IT companies are generally allergic to questioning of their social status and philosophy, so might as well start with a disclaimer. To think is to write: You cannot do real thinking without writing. Occassionally you will get something right that is useful. Most times you might be wrong.
In many ways, the IT industry is where principles and ethics go to die. This is because IT either operates in a pie-in-the-sky manner where nothing that is done there matters (actual operations is done using predictable software that is the same since the 80s, i.e. MS Excel) or it intersects the real world in increasingly horrifying ways.
In many ways, with IT, the architecture comes first, and then later on is the domain knowledge and actual business case added on. As a result of the architecture-first approach, you end up with software that isn't used by operations or you get a disaster.
When software is actually used, it boils down to a situation similar to the following:
-
Customer puts in an order for a dog
-
An order for a dog is added to the operations ticketing system
-
The order for a dog is logged into a R&D ticketing system somewhere
-
A product manager gets involved, acknowledges the demand for dogs from multiple customers.
-
A developer is assigned to work on the R&D ticket. A developer has no idea what a 'dog' is, proceeds to research dogs for weeks.
-
The developer realizes there is a "cat" object class used internally that fits most of the requirements.
-
The developer slaps on some dog ears and a wiggly tail method onto the "cat" object, decides to go out for lunch.
-
The dog-eared cat gets added to a milestone.
-
QA on the dog-eared cat is done
-
New release is shipped to customer, customer is annoyed
-
Support is annoyed, asks developers why they shipped a dog-eared cat, response "dog-eared cat was easier to implement than a dog"
-
Developers will try to convince support 'dog-eared cat' is the new way of doing things
-
Support will try to convince customer 'dog-eared cat' is the new way of doing things
Contrast this to a situation where a person knows what a dog is, understands what kind of dog the customer prefers, and aims to deliver that exact dog the client wants on the exact day that they need it. Even if it is difficult to deliver that exact kind of dog, that difficulty is registered and understood since the person posseses the necessary domain knowledge. There is merit to the Amazon leadership principles as they operate in this second manner instead of the first.
The likely issue with Amazon leadership principles is that AWS largely functions on IT logic which is independent of principles. My aim here is to see if the Amazon principle hold true on the AWS side. So let's start with the first principle: 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.
DigitalOcean and Vercel deliver the value AWS should have by default
Leaders start with the customer and work backwards.
Perhaps the AWS design makes sense for corporate customers but I find it complex. When your infrastructure already looks like a 5-page diagram, 'simple' becomes a relative thing.
Perhaps it's better to think of AWS as a B2B service. For individuals, AWS is more complex than other cloud providers.
It seems that agreement on who the customer is, is required for the Amazon principles to function. This is in contrast to a "generic" solution which is applicable to almost anyone.
They work vigorously to earn and keep customer trust
I think in the modern environment "customer trust" either translates into 9s of availability and/or a self-service solution. A SDK with a stable API seems to be preferable to a full-blown solution with support. LLMs seem to have changed the landscape - automating to a certain extent personal interactions - and what customer trust means changes. I think that in a downsizing environment, support competes with the customers lower ranks - A customer might opt to cut expenses and rely on support more. As a result, staff that interacts with support might become more guarded and start demanding more self-service solutions as a result of lower trust.
Although leaders pay attention to competitors, they obsess over customers
Success weakens the mind in horrible ways. The thing with most principles is that they have variables (in this case, who do you consider a customer) which completely change how you perceive things. You can obsess over customers all you want, if a high-ranking management decision is made to cut costs and you are the more expensive option, tough luck. It is likely that the definition of customer will change in two ways during a financial crisis: from middle management to higher-level management and down to individual developer experiences. In other words, at a high-level companies will try to cut down on costs, while individual developers will prioritize the environment that keeps them productive.
Are the Amazon leadership principles bad?
I think the principles make a lot of sense but if you aren't critical of the models that are built based on these principles, you might end up with a model that no longer fits customer requirements or make it easier for a customer to distrupt you. It is very seductive to view the world in a single exclusionary way via a single comprehensive model. Physicists do it all the time as does philosophy and other scientific disciplines.
Benjamin Graham in his book the Intelligent investor talks about this problem of overreliance on models. The only way to stay relevant is to continually re-evaluate these principles depending on the changes in terrain.
It is likely that the Amazon principles become dogmatic and solidify into known patterns as each re-evaluation of the principles is risky. As a result, smaller competitors for which a higher level of risk is acceptable (due to their lower size) become competitive and are able to distrupt the larger cloud players.