I was always curious how different is the life of engineering managers in Big Tech, compared to my experience in a startup. This week I finally decided to find out, and interviewed Gilad Naor!

Gilad worked at a startup for 9 years, reaching the director of engineering role. Then, in 2017, he decided to go on an adventure with his wife and 3 kids.

They moved 10,000km across the world to Seatle and he got accepted to Amazon, where he stayed until 2019.

After Amazon, Gilad spent 3 years as an Engineering Manager in Meta. In the last 2 years has coached hundreds of managers. Most recently, he teaches courses at the new Management Delta community

Today he’ll share:

• 3 things engineering managers should learn from Amazon

• What he doesn’t miss about working at Amazon

• What he still misses the most

Passing the mic to Gilad!🎤

3 things to learn from Amazon

#1 Solve problems with mechanisms

My first meeting at Amazon was baffling.

I entered a room with about a dozen Software Development Managers (SDMs) and Product Managers (PMs). Everyone sat in silence and looked at their laptops or the printed papers they had before them.

It was my second day at Amazon, and I picked up one of the extra sheets and started reading. After those first ten awkward minutes, everyone finished reading and the meeting began.

Why do Amazon meetings always start this way? This is a specific example of how Amazon approaches problem-solving. It is the "Good Intentions Don't Matter" approach.

In a famous internal video, Jeff Bezos talks about why good intentions are irrelevant. When things don't work, it does not matter what people wanted. All that matters is fixing the problems with mechanisms.

For example, many busy managers come to meetings without first reading the prep material. They all intended to read the 6-Pager before the meeting. They just got sidetracked by the latest emergency. Scolding the managers won't solve the problem. A mechanism will. This is why all Amazon meetings start with a study period. The remaining meeting time is then spent on high-quality decision making.

Meta solves the same problem by creating cultural norms. I can't count the number of times that I heard a senior leader cut off the presenter: "Stop, assume that everyone here already read the slides. Let's get to the point." This is a culture-first approach. I have seen this work well in some teams, and not work at all in other teams.

At Amazon, the solution is part of the company's "operating system".

The tip

When things don't work ask 5-Whys and keep probing until you go beyond humans making decisions. Find the Mechanism that will work even when people are new or under-qualified or have a bad day. These are the solutions that work.

Anton here - I completely agree! I remember being annoyed that people don’t update the Jira tickets. Finally, after requesting multiple times, now we just update them in a couple of minutes the first thing in the daily standup.

#2 Be precise

In Amazon, I learned to never use "Weasel words".

I stopped using terms like "significant", "low latency" or "annoying." Instead, I used specific metrics, like "P99 latency jumped 375% from 12ms to 45ms." This required more upfront work, but led to discussing reality as it is, not as I imagined it to be.

I was working on my first 6-Pager, and it was hard and frustrating. My manager connected me with a mentor that taught me how to write like an Amazonian. She taught me all about weasel words, how to identify them, and how to avoid them.

But what sticks with me to this day is actually all the 1:1 meetings with my manager. I learned that weasel words don't only appear in business documents. They also appeared in how I gave feedback to my team members. I learned to do the homework so that I could give specific feedback.

I stopped saying "You are too blunt in meetings." Instead, I said "In the meeting with Christopher you cut him off when he started suggesting the React-based solution. We missed an opportunity to check more approaches. I also noticed that Christopher stopped contributing to other meetings."

This feedback is factual and thus indisputable. It is really so easy for the other side to understand. It is the first step to actionable advice.

The tip

Most people don't know this about me, but I am an amazing singer. World-class, actually. The only problem is that I am a world-class singer when I sing in my head. Once I actually open my mouth, well, people tend to run away.

This is the same way with ideas.

We think that we have a clear and precise grasp of a technical, business, or managerial area. The act of communicating with others raises the gaps in our understanding. Writing our thoughts down and avoiding weasel words forces us to be better thinkers. It is a Mechanism.

#3 Full autonomy in your team

Amazon does not care how you work. You have a clear goal to achieve, and that's it.

As a manager in a startup, I spent too much time learning about Agile methodologies such as Scrum or Kanban. I wanted my teams to use a standard process that leveraged industry best practices. 

When I worked in Big Tech, I found absolutely none of that! There is no standardized process. Each team self-organizes and chooses how they want to work for each specific project.

The team autonomy goes further:

• The tech-stack—You own your micro-services and choose how to build it.

• 2-pizza teams—The team is independent. A single team may include: backend, frontend, design, ux, and product management.

• Software Development Lifecycle (SDLC)—Daily standups? Sure, if the team wants it. Scrum? Kanban? Something else? Again, whatever the team chooses.

• No Product versus Engineering—It is common for PMs to report directly to Senior SDMs, and vice-versa. 

• As the leader, you own everything about the product, regardless of your role. And your leadership will hold you accountable to achieving the business goals. Being a technical manager is no excuse.

As another example:

When you come up with a new idea (Think Big!) it is your job to turn it into a reality. It is up to you to convince senior leadership that it makes business sense.

If leadership approves the project they may give you funding ("head-count"). It will then be your responsibility to hire. It will be your job to work across the entire funnel - from writing the job description, through sourcing candidates, all the way to convincing candidates to join.

The tip

The Ownership principle extends to developers.

Give people autonomy. Let developers own complete features. Be there to support them, give them the boundaries of their freedom, and hold them accountable.

If you treat everyone as a leader, you will find that most people are.

What I don’t miss about working in Amazon

Amazon’s latest CEO, Andy Jassy, introduced two new Leadership Principles (LP) when he took over in 2021. One of them is “Strive to be Earth’s Best Employer.” This principle creates a people-first counterbalance to the strong focus on results.

Back in 2017, there was a large variance in how managers treated their employees and managers. I worked with some of the best managers in the world. I also worked with a few results-obsessed managers who did not see the people behind the work. It takes just one bad experience to make the entire day turn sour.

At the time, we were going through some drastic family health challenges. This magnified the effect of any bad interaction. All companies have good and bad apples, but at the time it felt like Amazon as a whole did not prioritize creating a minimum bar here.

I have no personal experience from Andy Jassy’s tenure, but it does seem like Amazon is making changes in this direction.

What I Miss the Most

The Principals of Amazon (POA) talks.

Every week or so, one of the most senior individual contributors at Amazon gave a technical talk. These level 7+ engineers dove deep into how they solved world-class problems.

These talks were polished. Each presenter worked with several coaches to refine and hone their presentation. I attended several talks in person, watched others live, and also watched some recordings.

There were no other tech talks before or since that taught me as much as the POA talks. I remember learning about the hard challenges that only distributed systems at S3's scale can face. Or how and why to write a completely new database from scratch. All directly from the people that solved these problems.

Here’s an article by an IC7+ Amazonian who also talks about the POA talks.

Final words

Anton here - thanks a lot to Gilad for taking the time to share his story!

I thought that the new format of hearing about how engineering management works inside other companies would be interesting - at least it is to me :)

Let me know what you think about it, and if there are questions you want me to ask.

Further reading on Amazon

In the last year of Tech Books, we covered more than 50 different books. 3 of them are about Amazon!

1. In The 7 Best Startup Stories I covered The Everything Store, which tells the origin story - how an online book store became a trillion-dollar company.

2. In This is Why Amazon is Unbeatable, Orel covered The Bezos Letters, which talks about how Bezos made some critical decision (and how he seriously screwed up other times).

3. In You are thinking in the wrong direction, Orel Zilberman and Fran Soto covered Working Backwards, where you can read on the origins of the 6-pager and the PRFAQ method.