5 principles from Amazon’s culture to be a better engineer
Unlock the secrets of engineering excellence with insights from Amazon's culture. Learn how to navigate company politics, foster a culture of excellence, and make fast, informed decisions.
Get the free AI Agent Building Blocks ebook when you subscribe.
This is a compilation of public information and an opinion commentary on them All opinions here are my own.
This is part 2 of the previous week’s post
—
A great company is made of great people.
There’s no doubt companies like Amazon, Meta, or Apple have great engineers.
But culture can’t be left up to chance. Otherwise, Amazon’s US offices and Amazon’s Europe offices would be completely different.
We need a company culture to speak the same language.
As an engineer, I have found them helpful in navigating conversations with non-tech people
And I think you may find them useful too, even if you don’t work at Amazon.
In this post, we’ll cover:
Jeff Bezos’ uncomfortable phone call during a meeting
How to scale your thinking and not rely on good intentions from people.
How to deal with company politics when a disagreement appears between teams.
How to create an engineering culture of excellence.
How to make fast decisions.
#1 Truth-seeking
In a meeting Customer Support was defending their team with their metric indicating the time they spend to answer isn’t impacting customers negatively.
However, the signals coming from Customer Anecdotes indicated frustrated customers because of the time.
So Jeff Bezos picked up his phone and called customer support.
Everyone stayed silently in a meeting room for 10+ minutes until someone picked up.
Metrics are proxies. Software systems are proxies.
Remove layers of abstraction and go to find what’s happening in reality for your customer
#2 Mechanisms, not good intentions
To define the way your team works, share some guidance and keep an eye on everyone’s work to correct the course.
If you want to scale to 2-3 teams, you can’t review all the work. You set something written and try to get some people to keep an eye on the work.
If you want to scale to an entire company, writing a wiki is just a good intention. You are not ensuring those principles are applied.
A mechanism defines, implements, and gets feedback as an input to continue evolving. It’s about thinking in Systems.
“We don’t raise to the level of our goals, we fall to the level of our systems”. - James Clear in Atomic Habits
It just happened that Jeff called it “good intentions” and “mechanisms”.
You’ll find all the principles in this post are mechanisms. Even if I don’t go into detail, they set a system for the idea to work. They don’t rely only on people
#3 Escalations
When I find a disagreement with an engineer in my team, we usually go to a Senior Engineer or the manager as a tie-breaker.
So if we find a disagreement between teams, we’ll go to the closest common ancestor between those. This looks like a big deal in office politics. You are going to their manager, you are giving a complaint…
Instead of leaving it up to people to interpret the emotions, Amazon defined a mechanism for it. Escalations are a resource you have when things are blocked, they are not evil by themselves.
In some situations, you may agree with the request a team is making, but can’t tackle it based on other priorities. An escalation from a high-level leader from the other team can help you re-prioritize.