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.
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.
⭐ 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.
🌲 #4 Bar raising programs
I can’t be the best at everything. But I can potentially be the best at anything.
In career-growth talk, it’s common to talk about being T-shaped. Generalist enough to prevent being lost in different contexts. But specialized in something where you are better than anyone else around you.
It’d be a waste to have specialists in your company working as knowledge silos.
Instead, make them the ones who maintain the high bar of engineering excellence. And give them a fancy name like “Bar Raisers”, creating a program where they create this influence.
Engineering programs are a great way to share knowledge and learn
Last Friday I spent 5 hours addressing the detailed comments a bar raiser and the shadow bar raiser left on a document. The level of detail and careful dedication to this particular process is something we can’t expect everyone to have. We need people to specialize in bar raising concrete processes
🚪 #5 1-way doors and 2-way doors
One leadership principle is “insisting on high standards”.
Another one is “bias for action”.
It’s typical to have a technical design with a short-term and a long-term alternative. You can argue that the short-term is having a bias for action, while the long-term is insisting on higher standards and raising the bar
How do you decide when to apply one or another?
That was a common question I had. Both are customer-obsessed. I thought in the end, all the cultural concepts were up to interpretation.
But there’s a way to choose: Understanding the impact of your decisions.
If your decision is irreversible, or reversing it is so costly that it’s out of the table… then it’s a 1-way door and you better have evaluated all options before crossing it.
But if the decision is easy to reverse, embrace an experimentation mindset. Move fast, fail fast, get the learnings, and iterate.
These are only 5 of a list of useful concepts I have learned at Amazon.
I found they shaped the way I think about decisions and problems, both as an engineer and in life.
If you think you’d like to learn more about other principles, such as the ones below, hit the ❤️ icon and subscribe below
Why Jeff Bezos banned power points
What’s the minimum bar for an MVP to go to market
How to plan next year’s roadmap
👏 Weekly applause
These are some great articles I went through during the week
How Tinder Scaled to 1.6 Billion Swipes per Day by
System Design Newsletter. It was interesting to see a data-centric perspective of processing the multiple flows: Swipes, matches, or location indexing.
A Simple Pattern for Finding Next-level Scope by
. This pattern helped me on my SDE1 to SDE2 promotion. My SDE2 at the time delegated a project on me so he had the capacity to do SDE3 level scope. It was a win-win for both, we both worked on next-level scope.My Strategies for Work Life Balance by
. This post was a reminder for me to 1) break down complex work into smaller pieces I can fit daily and feel progress on, 2) Celebrate all achievements along the way, 3) pay attention to your hobbies outside of workFrustrated with your “incompetent” mentee? by
Techlead Mentor. Debug your mentee problems, not only technical ones.
One of the best read this week! at least for me based on what I am going through. 100% escalation is not bad, if something is a company principle then there shouldn’t be exceptions.
Interesting concept about the bar raising people. How do they find the time to do it? Or they have X% of the week dedicated to bar raising?
Great article Fran!