“You come in here, you get your mind right, you only do two days. The day you come in and the day you come out” - Avon Barksdale (The Wire)
Some uncomfortable truths
Today I’m going to traffic in stereotypes. Humans are built to take shortcuts, so stereotypes are often the way we work. They get a bad rap - even if sometimes they’re true on average. One challenge of writing this article was the realization that there are limited effective substitutions in an English thesaurus for “asshole.” Which will prove unfortunate for the next few pages. But also perhaps a sign that some of the stereotypes I’ll joke about here have a basis in reality. Or maybe because we tend to remember assholes big, bold personalities. There’s probably some peak-end bias at work here.
In addition to this post being filtered out due to the original profanity, there’s a risk that this could come across as “Amazon is great, and definitely greater than any other place.” That is 110% not my intent. Amazon has good and bad things like anywhere else. As an example of “not fantastic” I’ll share my answer when people asked me at Convoy about differences between that place and my earlier work;
At Amazon as a manager the results you got were considered super important. The bigger the better. It’s entirely true that Amazon as a culture raised the customer above all else.
At the same time, avoiding burning through legions of people on your team to
achieve a result often fell into the category of “nice to have.”
At Convoy the company was long on employee experience - if you had impactful results but the team didn’t feel supported then you weren’t assured professional success.
That’s not to say that all Amazon teams felt that way. Different cultures existed in different areas, and what might play in one spot could be verboten in another. In general people development didn’t get a ton of time in most talent reviews I attended. The marketplace of being able to switch teams during the growth years exerted a limiting function as to how bad a manager you could be while achieving results. That could have been the intended mechanism for continually improving people management - though seems like a stretch.
My point is that Amazon is/was not perfect, even if I occasionally raise it on a pedestal1. The intent of this article is to step back a bit and think about my career after Amazon (which is approaching 8 years after that 13 there) and share some observations what I’ve been sharing casually with folks when the topic comes up. I often hear “I wish I’d heard that sooner” - so I’m hoping this information will be helpful to folks leaving Amazon, and also those working with an ex-Amazonian.
I’m not going to delve into the working environment of Amazon - whether it’s a sweat shop with people crying at their desks, etc. It’s been a while so maybe by now they have private rooms for the crying2. I’m joking - they would never spring for that sort of extra expense. ;-)
BTW - I’m sure the part about people assuming you as an ex-Amazon employee being an asshole definitely doesn’t apply to you. I found it an amusing, though somewhat understandable stereotype ever since venturing past Amazon’s lightly decorated halls. Personally I’d say “intense” or “focused bordering on angry” - but "tomayto, tomahto.”
What to know about jobs post-Amazon
Some observations in no particular order that may prove helpful. Stuff I’ve observed, and also commonly mentioned by other ex-Amazon folks I’ve spoken with.
When you’re looking for a job
When you’re interviewing at some other company you may hear “our culture is a little different than Amazon.” What they could mean is “we hired some people from Amazon and they were assholes - we want to make sure that’s not you.” This may be a good sign, or it might be a red flag. I highly suggest being curious to ask about their experiences.
If you’re a leader from Amazon that has gotten used to managing multiple functions (eng, product, science, etc) you should probably forget about that unless you’re going to be a SVP/CTPO at another place. Most of the rest of the universe has functional reporting. In reality it’s worth reminding your self that functional reporting works reasonably well and isn’t inherently to be shunned. Having someone report to you only gets you being listened to at most 15% of the time due to “authority.” you’re going to have to persuade to align folks regardless of the org chart anyway.
Employers may assume you don’t understand how to work with limited resources. Amazon seems so large that they’d deploy 100’s at a problem when they could use 3. You may feel I’m being ridiculous - that Amazon would assign 3 people but put them in different divisions so they repeat, but give them so much that total capacity for the project is only 1/3 of a full time person. But the point still stands - folks may view you as only knowing how to operate with a major company behind you. If you stop to think about it you would have benefited from tremendous infrastructure and available expertise - so it’s worth thinking through how to address this concern if it comes up.
When you’re at a new job
Things to know
People may still use the phrase “single threaded owner” but they usually mean someone is “in charge” of a cross area initiative, not that everyone reports to them. Also - there’s a really really strong chance this “single threaded” person will actually have multiple areas of ownership - not truly “single.”
It is not always best to move from a functional reporting to a GM like structure. You may not believe me, but I discuss the pros and cons in part II of this article. I’ve been through two such transitions outside of Amazon so I feel I have some practical experience to share. I know I wrote above that GM reporting relationships are rare. They are, but when a new Amazonian shows up they often think they should implement them. Which is part of the reason I wrote part II.
If you’re viewed as a top 20% writer at Amazon you’re likely to be viewed as a true standout writer elsewhere. I think it’s similar to Kal-el moving from the red sun to earth’s yellow sun.3 This is sort of nice. But I also urge folks to not assume that the style they wrote at Amazon is the only effective one. I try to cover things I believe should be universally avoided in part II. But as a counter example, I know a genius technologist who’s fond of including a steady diet of sharp metaphors and references to 80’s era pop culture. Their docs are different than the Amazon standard, but they’re very specific, efficient, and have that extra touch of flare.
Goals may be less debated than you’re used to, and they may be less sharp (ie; specific, observable, and targeted). They definitely are more likely to be based on outputs (aka lagging measures). I’ve seen less debate about the second order impact of goals as well. I would say that these are all areas where Amazon best practices are very very useful.
Don’t expect everyone to be as interested in metric as you are.
If someone refers to “a deck” they’re not referring to the thing you barbecue on outside your house and keep meaning to replace some of the boards on4.
The enterprise may not have the same religious objection to Powerpoint as you do. I wouldn’t suggest dying on this hill. At least not at first. I tremendously hate Powerpoint (and did before Amazon fwiw). But good communication can take place with other tools, even if it’s less effective. Generally I suggest trying to shape the path to a change with great examples instead of just insisting on never doing a presentation.
When you ask to see the WBR deck (or the engineering OE equivalent) it may look less formal than you expect. This could mean that things are running on a wing and a prayer. Or everything may be extremely buttoned up and run as well or better than anything you’ve ever seen. Don’t assume. But do dive deep to check.
The post-mortem process may look very different than you expect. Feel free to forward this handy guide to COE’s.
Things to avoid doing
Don’t say “At Amazon we did things this way _____.” At least try not to say it more than once a week. It really, truly annoys people.
Using the phrase “mechanisms” or anything in the Amazon Leadership Principles without explaining what you’re talking about. Ideally share the concept without using the word Amazon.
Don’t be surprised you think you’re just sharing your thoughts but people think you’re an asshole. It’s worth remembering that asking a “what” or “how” question is less likely to trigger a defensive response. But maybe leave the “what’s the ‘so what’ in this document?” question until you’ve built more credibility. I know it sounds cool where you’re from. But the way we talked as kids in Brooklyn doesn’t work outside of the city either. Read the room a bit.
Most places don’t need to recreate all of Amazon’s infrastructure. You probably don’t need a microservice for everything. I’m not saying anything you don’t know, but a reminder can’t hurt I suppose.
When people explain some Amazon process in a way that isn’t how you remembered. Just be curious, no need to laugh and immediately correct. :-)
Do … not … attempt … to recreate the AWS wheel of random reporting. just don’t. Unless you are really sure. It’s not as cool as you think it is. Unless your goal is to really stress people out for minimal benefit.5
Things that really may take some getting used to
If you show up with a document (instead of a powerpoint) folks may expect you to project it and take people through it (ie; read it out loud). No, I’m really not joking.
Coworkers you meet are likely not used to engineers getting up in Product’s face, and vice versa. Actually, I’m kidding - engineers are always used to product getting up in their shit. ;-) Sorry, I couldn’t help myself.
Seriously though, I’m not saying to avoid questions across discipline boundaries. You’re trying to help but (a) it may be confusing and (b) because of that sometimes there will be defensiveness.Statistically speaking you’ll end up somewhere less customer obsessed. I’ve been part of discussions where the clear customer benefitting choice is A, and the one where the company gets a slightly better short term result at the expense of customer’s experience is B. I’d expected zero debate once that was clear - only to experience a lot of leaning toward B. It can take some getting used to. I still think it’s worth taking the right side of that debate6. But if you expect it to happen you can react to it more productively.
You may feel a lot less stress. Even if you feel a bit of Stockholm Syndrome for feeling that way. While this NY Times article still reads partially as uninformed to me in places, this quote rings true even years later “Amazon is where overachievers go to feel bad about themselves.” It’s not so bad to change up your environment it turns out.
Please subscribe below and continue on to art 2 of this article: What to expect when you’re expecting your new boss from Amazon. Plus - for everyone, some key thoughts about single threaded owner org models (often call GM organization models).
Yes - I realize you can also critique this as hopelessly out of touch as I haven’t worked at Amazon for 7 years or so. Putting my context into the annoying to everyone categories of “back when I was a kid and walked to school uphill both ways” or “It was when I was banging!.”
Thanks HB Siegel for that joke about crying rooms. He made it what seems like a lifetime ago when a certain NY Times article indicated it was a common scene there. At least I’m pretty sure he was kidding.
Though now that I think of it, I’m not really sure how the sun thing works.
Oh, that last part might just be me.
I’m sure it has a place at AWS given the scale. But if you don’t believe me ask yourself how you’d feel if your boss instead of working to ensure you understood how your systems worked, occasionally diving into your metrics, and generally trusting you - instead decided you should just play Russian Roulette?
I occasionally see something from outside of Amazon that makes me wonder if it’s still as customer obsessed as I remember. I haven’t tried cancelling Prime recently so that would be a test to see the current state of things.
I would have enjoyed this more as a PowerPoint. JK! What a beautiful piece, Rich, every paragraph hit home.
I remember reading that quote about "Amazon being where overachievers go to feel bad" during my own stint at Amazon and wow was that true. I didn’t realize how much tension I was carrying until I left, always on the edge of burning out but still falling short. It wasn't until I started my next job that I could take a look around and go "Wait, no. I do understand how to build good software!"
They could use this post as part of the exit paperwork you need to fill out :)