You can take Amazonians out of Amazon…
Part 2: A guide to your new ex-Amazon Manager. Plus: GM org structures analyzed for everyone.
Welcome back - this is part 2/2 of a series of tips for working post Amazon employment, and working with folks who’ve just made that transition.
Today’s article has two parts
An introductory user’s guide for your new “ex-Amazon” manager.
The common ex-Amazonian’s impulse to reorganize teams in the Amazon model. It can be powerful fuel, but so can nitroglycerine. I’ll share tips to identify which compound you’ve got on hand.
BTW - before anyone complains about the “realism” of the cartoon above. It turns out that ChatGPT is super touchy about Baby Yoda. Clearly Disney has dirt on Sam Altman. With that PSA out of the way, let’s continue.
What to expect from your new, ex-Amazon boss
Hopefully you’ve read through the earlier primer for folks leaving Amazon to get inside their head. But you’re likely still thinking “they just hired this person from Amazon and I’m going to report to them. What else should I know!?”
I’ve had two jobs in the last several years where I joined a company, only to have my new boss be replaced by an ex-Amazon VP. In both cases I quite liked my old manager, so it wasn’t a case of “oh, good - we’ll finally get someone with their head on straight here.” Even though I was familiar with the new manager’s experiences it wasn’t always entirely smooth sailing. This makes me especially sympathetic for folks who have less of a sense what might be expected based on past cultures their manager has worked in.
When I left Amazon I had a deep immersion in how that company does things. For the most part I do think Amazon has their head screwed on straight in terms of operating.1 Folks at Amazon are so confident in the operating style that it’s an implicit dogma that running things any other way would be a horrible mistake. Lots of other places seemed to be achieving success with different principles though, so that couldn’t be correct. This left me curious to learn what other systems had to offer. My goal being to keep what worked and leave the rest2. That’s a big part of the reason I left to discover what else the business world knew.
OK - back to your new manager…
Many of the stereotypical things they might think or expect can be inferred from Part I. But there is more to learn. First, I’ll share some Amazon specific terminology they may toss about, followed by some behaviors you may observe.
Terminology/structures
“S-team” - is a reference to the C-suite of your company, whatever you call that.
“OP1” - they’re referring to annual planning. It’s short for “operational planning.” There’s a first version OP1, and then a later one OP2. Often they’re really referring to a planning doc more-so than the process. The document you write to explain your plan for the following year is also often referred to as the “OP1” doc.
“Tenets” - may come up as super important to them and as something you need to write out and debate before making a decision. In this context they’re referring to operating principles that help the team make consistent decisions. You can read more here in an article I wrote just about Tenets.
“one way” or “two way” doors - in reference to different types of decisions. Decisions you can reverse easily are two way doors - if you screw them up you just make another decision and undo things. One way doors are things that once stepped through are very hard to take back - things in this segment of decisions benefit from moving slowly and intentionally (ie; lots of writing and debate).
“working backward” or “PR/FAQ’s” - are references to a process (or the related docs) that envisions the end result (ie; what is success and how would we know we achieved it) before starting on the work. It’s aligned with my writing on goal setting. Though the format they have in mind is more structured. Google is your friend for the details. If you read my piece first on goals first I think you’ll quickly get the gist.
Single threaded leader orgs/GM models - They may have all sorts of ideas about swapping existing reporting structure for one that is less functional (engineers report to engineers, etc) and more single threaded (sometimes referred to as a General Manager (GM) model. That’s specific enough I’ll talk about that in the next section.
Inputs vs. outputs (in relation to goals). For a fuller description you can checkout my article on goal setting. But the short version is not to set goals on outputs you don’t control (say revenue, or losing weight) but on inputs you do control (say in time to get back to customers, or going to the gym 5x per week).
Behavior
They will be shocked (shocked I say!) at the idea of using Powerpoint in a meeting. They also will likely want to do a silent read of the doc in the meeting. Here’s a pretty good overview of what that silent read might look like3. Some are more or less dogmatic about whether it’s OK to just have people read the doc before the meeting. FWIW, I see both sides of this one. I sort of hate to read under pressure in the meeting. Reading in the meeting can be best because folks are busy and may not have time to read before. In practice it also avoids people pretending they read your work and then just skimming to try to look smart. Which doesn’t really help the team, nor feel very good to the authors.
They likely will talk about the customer and customer experience a lot, and actually really care.
Will respect (and expect) diving deep. Not that they expect micromanagement (though I know some people will debate that). But that if you’re the leader of an area they will expect you to understand what is going on by at least occasionally diving deep to audit and understand. I know this may be very surprising in some places. In my last role I was often told with some disbelief “none of the other VP’s ask questions like this.” Inferring I was doing something wrong. If you feel their questions are causing the team to thrash then I think it’s worth saying something. But if they’re asking foundational questions, or building context it seems a lot better. Do you really feel better if your boss doesn’t want to understand what you do and how you think about it?
Generally they’ll strongly prefer “I don’t know, but will find out” to spinning an answer to try to look good. There will be exceptions. But TBH it’s just much easier to be able to admit you don’t know - so you may as well just do that anyway.
They’ll likely will be dismissive of any unqualified adjective in written work. If they’re feeling peevish they’ll refer to such writing as using “weasel words.” While I think that vocabulary is unhelpful - what they’re referring to is something such as “we are having a lot of problems with customers not being able to log into the site.” “A lot” could be 0.1% of customers, 10% of customers, or 85% of customers. It’d be bad if different people (silently) assume different values. In general you should be specific when you discuss something. Seeking clarity around adjectives and broad statements is a common Amazon trait. Similarly - they’ll probably call out a statement such as “we should do ______” unless it’s followed by the underlying reasoning. Including the observable impact of doing or not doing the thing, plus the cost/time estimate to do it. They usually want the facts and assumptions that lead to a suggested decision, not just what you decided. Especially for two-way doors.
While Amazon really cares a ton about goals, ex-employees may be only glancingly familiar with OKR’s as a system. At least in the past Amazon goal setting has been more homebrew. You may hear ex-Amazonians talk about S-team goals, VP goals, team goals etc - that’s one of the ways the company creates a hierarchy of goals. It’s probably pretty obvious which ones are broader and thus should be prioritized.
They are likely to care a lot about things outside their functional area. So if they’re the new CTO they’ll have as many product questions as the CPO. Also - you may suddenly notice some tension between these roles when this starts.
Questions such as “what would 10x the current business size?” may start being asked. Sometimes they’re a distraction, but this “think big” approach is generally rewarded at Amazon. It helps ensure one isn’t operating/thinking in a local minima - it’s not that they’re trying to take over the entire company. Though it’s also possible they want to take over the entire company.
You could hear “the way we did this at Amazon” a disconcerting number of times. In the sense that if you played a drinking game based on this phrase you’d be hospitalized by 11am. A corollary to this is they may suddenly propose all their old co-workers for open roles. I know it’s frustrating - because I’ve been told that several times. Try to be patient and maybe leave a copy of part I of this series laying on their desk.
They may be absolutely shocked at the decadence of your mini-kitchen, free lunch, or just decent free coffee4. Don’t worry, they’ll quickly get over this one.
The whole GM leader thing…
Amazon is very different from lots of companies in how it organizes. Reporting is often business lines with all disciplines reporting to one leader rather than functionally.
Functional reporting has all engineers report through some CTO/VP of engineering (and possible line level EM’s etc), all product managers report to Product leaders (CPO), Scientists to scientists, Designers to designers, etc. Execution teams are organized in various different ways but your “manager” typically is from the same domain as you. By the time you get to a Senior VP or C-suite leader multiple disciplines may report to them. But usually not before that.
Amazon often takes a different approach and has senior manager and director level leaders who have a reporting relationship to all the resources required to do the work of their business area. Meaning that a senior manager as a leader of leaders may have engineering, product, designers, scientists etc. reporting to them. You still get much of the same “but the product manager doesn’t understand us” from the engineers (and vice versa) but the person who everyone reports to is much closer to the key decider/aligner. In theory, and I would say usually in practice, this makes decision making faster because there are less levels to escalate through to get different disciplines/areas (often different perspectives) on the same page.
Senior managers in this scenario are less common than VP’s/Directors, but I use the example to make it clear how different this is. While I’m not 100% sure of the origin of this, my understanding is that Jeff Bezos felt it was important for folks with a technical background to grow as broad business leaders, so he looked for opportunities to create those conditions. He also cares a LOT about customers so everyone was expected to think critically about the outcomes of their work in those terms. This naturally forces people to think of why they’re building things. There’s also the story5 about how the foundational belief that things were best with a leader who only thought about one problem and was empowered to act on it. This all contributed to the creation and popularity of the single threaded leader reporting style of organization.
An example of a domain with a single threaded leader could be the Buy Box - the decision about which seller’s (or Amazon retail’s) offer would be the one you get if you “buy now” on the detail page. That might seem just one minor detail on the page, but it’s fairly complicated under the covers. You need to have software that renders the button, decides which offer “wins” (is shown), how to make that decision taking into account short and long term economics of the system, and vend this information to other teams that leverage it. The problems span high scale engineering, user interfaces, seller relations. economics, ML, and data engineering. This would be an area where the company would benefit from a single person whose job it is to think through the problem without distraction and lead the many types of employees who can make it most customer focused and most beneficial to the company.
Why I have some thoughts on this model
Twice outside of Amazon, my new boss6 was hired straight from Amazon and interested in implementing this model. Debated followed about whether to make the switch to this GM model, and if so when. I’d also served in this capacity (or close to it) on three separate occasions within Amazon. This got me thinking about what has to be true for you to successfully operate with this approach. What I came up with follows. I’m sure there are more factors - but I think it’s a good sanity check to ensure you’ve thought through the following before making a switch.
Factors that contribute to a successful switch to a GM system
Before you worry about reporting, do you have structural areas that are already mostly self sufficient? In the sense that 90% of the decisions in that area can be made without needing something from a different area to be successful. If that’s not the case then you don’t have separable enough areas of concern for the reporting to be the problem. If you setup GM reporting then you want that GM to have the ability to make almost all decisions in that area. If your business isn’t structured today to allow that then they’re still going to have ask people in different areas for permission to get done what they need to do. Consider first setting up goals that allow local empowerment even with functional reporting. It’s more of a two-way door than starting with the GM model. You’ll quickly see anything you got wrong by setting up cross functional Pods first.
Is there a problem that needs solving? There are lots of questions in life, even many problems. Almost all of them can be interesting, but not as many are truly important. If things are going well and you just want to have a GM model because it seems “right” you should be wary. A sign of this can be suddenly wanting to implement a GM model across all of the company. Often a specific area may have a bottleneck or business opportunity that would benefit from running quickly and in sync locally. If you’re looking at say 1 out of 5 teams to do a GM approach as a scootch first this often makes more sense than stepping in and switching all teams. Doing even one team is still largely a one way door, but it’s at least a sign you’re thinking more critically about plusses and minuses of the switch.
Do you have staff that are ready to lead cross functionally? It may seem Amazon is awash in such people, or at least awash in people who feel they can do it. Amazon has been fostering this culture of caring across discipline areas to drive customer outcomes for several business generations. Folks have lots of practice thinking about it, and because people get to practice it at lower levels of org reporting there’s a deeper bench of folks that have at least some experience having credibility working across roles. And credibility is a big thing even beyond ability. As explained in the next bullet point.
Are the people you’re selecting going to be seen as credible with new disciplines? Most people can figure most things out, the main factor is rate of learning. Credibility is arguably like that. If a person is solid and you work with them enough you’ll respect them even if that wasn’t your intial impression. But if you’re a Product Manager who’s “known” as someone who is dismissive of engineering concerns, unsympathetic for the pain of 2am oncalls due to rush delivery, and doesn’t think through things end to end - then suddenly being put “in charge” of engineering is going to cause some concerns. Being empathetic across disciplines is a learnable skill, but the time to learn it ideally is well before you suddenly start putting people in charge of folks who view you as “other” to their lived professional experience.
Is the gain worth the pain? Making a switch like this is usually going to cause pain - have you thought about whether the juice is truly worth the squeeze? There are a lot of common stressors that could cause thrash. These include
Layering: In most cases someone is going to be layered in terms of reporting - meaning your product manager lead may be reporting to your engineering manager or vice versa. Be especially wary if say all the product people think this is a great idea and all the engineers hate it - it’s likely because all the PM’s think they’re going to be in charge, and the engineers feel they’ll be reporting to a bunch of unconstrained PM’s.7
Concern from IC’s and line manager: most people are not used to reporting to people (directly or indirectly) to those that don’t “understand their domain.”
Concerns from people managers that their ability to advance in the org is limited if they’re more a deep domain leader.
All of these issues can create thrash in terms of people quitting or just being so stressed out they don’t get their work done.
There’s no right or wrong answer here. I’ve worked in functional areas, and I’ve led at least three significant pieces of Amazon as a single threaded / GM leader. Just expecting it to work though without the underlying conditions and shaping the path is being overly optimistic.
Conclusion
I enjoyed my time at Amazon, and learned a ton. There are few places better as a training ground for operating and having long term vision - including thinking about what will happen a few steps forward of any action. According to internal dogma if you don’t operate in the Amazon way you’ll be lucky to survive. But that’s clearly wrong too - and I’ve intentionally spent time proving that to myself.
I’ve noticed the positive and negative biases surrounding time with Amazon and thought it might be helpful to some to share perspective on these. Please share your thoughts and experiences in the comments.
If you’re considering any of these changes in your organization I’d be happy to talk them through with you live. It’s a lot of fun for me, and likely valuable to get a view from the future. Especially if a single threaded leader wholesale change is being debated.
Though I do think the leadership principle on frugality can sometimes be misinterpreted in action to align with the description “so frugal it hurts” I once saw written on a developer’s office door, or the more direct “frugalupidity” (frugal stupidity).
With apologies to the great Bruce Lee. Though his “Absorb what is useful, discard what is useless and add what is specifically your own” was what I was optimizing for. Also, TBH the snack closets at Facebook were embarrasingly seductive.
It’s not to my recollection written by someone who worked at Amazon but I think it’s a really good summary.
It’s likely readers will think I’m joking. But I’m not. In my last role at Amazon one of our superior advantages in internal recruiting was our “snack closet.” Our VP had decided that it would be nice if we recreated to some extent the perk than many tech offices had of some free snacks. At that point Amazon’s only edible perk for all employees was free coffee in the break rooms. I used to say that there were also free bananas. But one of the most brilliant engineers I’ve ever known pointed out that anyone in the community could come by and get a banana, hence not an employee perk. The VP set aside some budget for a locked closet that was stocked with snacks for the team. When potential internal transfers came by to meet folks we always made a point of walking them by that closet. 100% of them walked away wide eyed at the largess - I’m pretty sure we closed a lot of people that way.
BTW - the closet locked otherwise other teams likely would have emptied it out. That recollection has inspired me to add a future post on “wild food stories from tech” to my to-do list.
I’m pretty sure this story was true because I was in the room on one of the many occasions he made his point. </end humble brag>
New in this context means I’d been working there for at least a year before the new (ex-Amazon) CTO joined.
Or vice versa. But probably not in my experience.
This is an informative and detailed post. I wish this post existed when I was transitioning from a management consulting (powerpoints-heavy!) to Amazon. In my first month at Amazon, my very first deliverable was drafting OP1!