4 (More) Good Things and 2 (More) Bad Things and 2 Misunderstandings About Working at Amazon: From 12+ Years in Management
A continuation of my previous article about my experiences at Amazon. What they do well, what they don't do well, and in this article, I also mention a few common beliefs I disagree with.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Last week I wrote an article about some good and bad things I experienced at Amazon. I intended it to be a single article, but the length got out of control. Like wildly out of control. So this is the continuation of that list. Both of these articles are a bit beefier than usual.
As I mentioned in my other article (but I’ll briefly repeat here), my specific 12-year tenure at Amazon makes me well suited to write this article. I started Amazon as a Level 5 manager (the most junior level of engineering manager at Amazon), and ended as a Level 8 Director / General Manager. This means I worked for years at the “line” level with individual junior engineers, and also worked closely with VPs and SVPs.
My experience was also across a wide area. I worked in Global Payments (a widely used platform team), 3rd Party selling on the retail website, AWS networking, Devices, and Games. My experiences weren’t simply in one or two organizations, but 5 different organizations. Even better, I worked as a bar raiser / bar raiser trainer almost all those years, so I had regular interactions across the entire company. This means I can identify what was unique in an organization, and what seemed to apply across all of Amazon.
As this article wraps up my final points, I realized that my number of good and bad things wasn’t even. Which is fine, but it sorta messes with my love of symmetry. Oh well.
Bad thing four — Empathy is not a leadership principle
As I said, getting things done is of higher value than everything else. This means that if you get things done, you can (usually) get away with being a jerk. And I think many leaders felt that being callous was part of how they were efficient with their time.
I was in a (crowded) room when Jeff Bezos literally asked a VP if he needed to hire their replacement because they couldn’t accomplish the task he wanted.
I’ve seen senior leaders ask junior people (in a room full of people) why they’re so incompetent.
I’ve seen senior leaders tell junior people to shut up because they talk too much without anything valuable to say.
This wasn’t an everyday, or even every week occurrence. But those leaders were not punished. Everyone shrugged because those employees were making mistakes. It felt bad, but results are what matters.
This type of attitude comes from the top down. With rare exceptions, most SVPs and VPs I observed were brilliant, but rude personally. They favored giving raw feedback immediately, and had zero patience for less than excellence.
As a non-extreme example, imagine you wrote a substandard document for a VP to review. It was common (I saw it repeatedly) for them to start reading, and then stop 5 minutes later.
They look at the Director. “This document needed to be better. It’s not answering my questions, and it’s wasting my time. Your organization needs to do better. When you’re actually ready to present, schedule more time with me.” and then they’d leave.
I understand that it’s more efficient to move forward quickly. I’ve repeatedly recommended that if a meeting isn’t valuable to you, you should get up and leave. Because, again, results are what matters.
But I think taken to the extreme, it means that empathy doesn’t come into the calculations.
In the above situation (for example), I’ve been there. It’s not horribly hard to say something like this:
“I really like where the document is going. I think the examples on the first page are good. But I have quite a few questions, and we won’t have time to cover them all today. I’m going to send a list of questions to the Director for you all to answer, and then we can meet again. Apologies for cutting this short, but I want to give you all this time back to work through my questions. Thanks!”
And then privately, I might tell the Director that the document wasn’t ready, and they need to proofread their team’s work better.
As another random example, I had another Director tell me that he’d like me to block transfers from his team to mine. Because people wanted to leave his team. I knew this was because he was a total jerk. I told him I wouldn’t do it. Our VP came and talked to me. I said it was because the Director was a jerk that people wanted to leave. He shrugged, and said that the Director’s team would be less effective if everyone left. So I should encourage them to stay.
Why? Because the Director was getting important things done, and the fact he was a jerk was simply not in the calculations. Getting things done was the top priority, and the fact that employees didn’t like working for him simply didn’t matter.
This behavior tends to cascade down to teams. If managers sees their leadership teams being rude, it tends to impact how everyone values work, empathy, and how collaboration works.
As a side note, in the above case, I told my VP that Amazon transfer policy means I wouldn’t prevent people from joining my team, but I was willing to not reach out to them directly. Because of good thing #1 above, my VP shrugged and said that was fine. Because he didn’t want to mess with how my team operated. So again, there are positives and negatives.
Contrast that with my time at Facebook (Meta) where I was repeatedly surprised by people volunteering to help each other, so that other people could have successful projects. And at their ratings meetings, I repeatedly saw people complimented on how nice they were, or how much they helped a co-worker.
Almost the only time I heard “they were so nice” at Amazon ratings discussions was related to a manager who was viewed as too nice. “They’re so nice to the people on their team, I’m worried they don’t hold a high bar.”
I’m not exaggerating, I heard that many times as a concern about a nice manager. Because the assumption is that having empathy for your team might impact your ability to deliver results.
I was literally told more than once that being friends with the employees working for me was a bad habit. Yikes.
Good thing four — Engineering managers were frequently engineers first
It was hard to hire good managers from outside the company. Amazon had very high expectations for their technical managers, and the interview failure rates were very high. And once they joined, many managers didn’t make it. Because Amazon expected a lot out of their engineering managers.
With Amazon’s ownership culture (see Good thing one in my last article), engineering managers were little CTOs.
They needed project management skills to balance the needs of potentially dozens of stakeholders, and their own operational roadmap.
They needed product management skills to take in rough requirements, and work with their team to build what actually was needed by the business. In balance with all their other requests, and the long-term plans of their product.
They needed technical skills to ask the right questions of their teams, review designs and architecture plans, usually negotiate deep disagreements in their teams, and usually estimate and scope projects without engineer intervention.
They needed people management skills to provide feedback to their team members, write performance reviews, manage the upwards careers of their stars, the downward/out careers of their poor performers, and manage their recruiting pipeline.
It’s a crazy job, and it’s hard to find people who can do all of the above competently.
Yet when a line manager’s team needed to grow from 9 to 16 engineers in the following year due to upcoming projects, you didn’t have a lot of choices. You needed a new manager, and you needed it soon.
This meant that when our teams needed to scale, we’d regularly turn to our emotionally intelligent engineers. I repeatedly tapped engineers on the shoulder and said, “would you be particularly upset if you became a manager?” Because I was in desperate need of help.
In my experience, this tended to work out decently well. Because while Amazon is not great at training, a few things about how Amazon operates meant that our junior managers tended to end up competent. Probably because of a few specific things.
Senior engineers are technically competent, which ensures their team built the right thing. So that tech bar was automatically hit.
Amazon’s documentation culture meant that there were rails on most important processes. Here’s a template for your quarterly plan, resource allocation plan, performance management document, and Q4 launch plan. Here’s a document for this week’s project management meeting. Here’s a document for the upcoming China launch, please fill in your relevant section. It’s hard to flail and fail if you have very solid expectations at all times.
Amazon has always been organized into little fiefdoms (see previous article). What this means though is that you mostly only need to understand how your team works, at least at a junior manager level. This drastically reduces the scope of product you need to understand.
I’m not saying all junior managers were great, but I think Amazon’s way of operating made the move into management not horrible.
And those managers who were successful were promoted. And those who were still successful were promoted. This meant that most of the time, you had brilliant ex-engineers as your Directors and VPs. Which was pretty fantastic. You never needed to dumb down a document for the non-technical leaders because they were all technical. And everyone knew what it took to build things, so everyone was simply focused on delivering results as quickly as we could.