How To Leave Amazon (and join an earlier stage company)

Not saying that you should leave (personal preference, it is a great company and I owe a lot to it) but if you do, and are L7+, chances are you are going where you'll have high leverage and the ability to steer and influence how the new company operates. That's where high-profile mistakes happen. I made or seen all of them!

Meta Point: however magical and reasonable things at Amazon may seem to you, they were created and implemented at a stage that was much, much later than any company you'll join. I can say with confidence that while many of the key pillars Amazon is built upon (customer obsession, decentralized decision-making, speed, emphasis on data, written over verbal communication etc...) will continue to apply, they will take a completely different form at a different company. It's your job to figure that part out, without simply copying/pasting things. Also, other new principles may find their way in and you should let them!

Here is a couple of tips:

Listen and don't make ANY big changes for a while.

The company that just hired you was able to do so due to making a lot of correct decisions in the past. Some of that stuff may now look inefficient in retrospect ("it's a monolith! it won't scale 10x! where is the documentation! it's spaghetti code!"), but odds are that many of the decisions were likely the correct ones at the time. Tech debt is an example: easy to say "why didn't you build it with scale in mind?", but the complicated reality is that had they done so they would have been too slow and lowered their odds of success. And their success is paying your salary now: so be humble and respect what was done. Try to gain as much context as possible, and talk to engineers, leaders, customer service, and always start from a place of humility. The right ideas and solutions are probably already there, but folks have been missing an avenue to express them and a catalyst to make them happen (that's why you are hired).

Writing.

You are going to be so used to nicely articulated thoughts in documents, that most communication will seem sort of fuzzy everywhere. Again, wait. Docs at Amazon work (or do they? that's for another day) because the whole system rotates around it. How they are written, how they are used for alignment, and how they are read and critiqued. Trying to do that at a startup is a humongous and largely counterproductive feat. Writing well is important, but try to position it as a THINKING tool, not as a communication tool. If ppl find writing useful to think and make good decisions, then there is a chance they'll adopt it (because it makes their work better). All the process that Amazon has around writing is completely overkill everywhere else.

This said I found writing a company-wide strategic doc (think OP1) helpful at first. The goal shouldn't be to influence the strategy or drive any change, it would instead be to learn the basics of the business for yourself. In writing the doc, you are going to be forced to go around, meet people, ask good questions, and dig into data. This will paint a clearer picture in your head, and help you avoid costly mistakes: it's a very powerful use of the first month. But don't have the expectations that others will read it, it doesn't matter. It's a self-training and thinking tool and will likely earn you trust across the board because you'll be asking questions to gain context, instead of offering solutions without context.

Resist hiring like crazy.

Honestly, 2020-2021 is littered with company SVPs/CTOs coming in, multiplying the org size, and watching things blow up in their face (layoffs, runaway costs etc...). Most problems can be resolved without crazy hiring, but with changes in culture, good priorities and direction, skill training, and perhaps a few key personnel insertions where desperately needed. Until the machine works, adding more pieces will slow things down, not speed them up. At TFD we ship at a pace that is multiples and multiples of what we could ship just a year ago, but the org only marginally grew in comparison.

Pay particular attention to all the roles that are somehow about managing the process. A 50 ppl start-up doesn't need a Program Management organization, trust me. But rather help your team get upskilled on how to run "programs", or avoid "programs" in the first place, as they are likely a symptom of waterfall methods, and thinking in too large chunks. Similarly, you might not need Data Analysts for everything, but you need good data infrastructures and training folks to self-service their data, and maybe maintain a core of deep expert analysts for gnarlier problems.

Talk to customers, use the product, and get into the effing details

There likely won't be the infrastructure (both people and data) so that you can sit in your office and have folks come in with all that you need. You need to get in and figure it out yourself at first. Write your own SQL (there won't be a clean table, but there will be a way to get it anyway), talk to cx agents, TALK TO CUSTOMEEEEEERSSSS, use the product etc..

I can't stress this enough: you can't make progress nor earn anyone's trust if you don't know your shit. It's going to be a lot of work, no one said it was going to be easy.

Get more comfortable with A LOT MORE speed

If there is an obvious problem, a startup can have a team come together, quickly design a solution, and ship it in a matter of hours or days. Adding process (a six pager????) to this is just insane. Don't do it. Is it uncomfortable not to have a great thought-out doc? well, get used to it. Action IS information. The best doc is getting to customer feedback in hours. Remember the Amazon "2-way door" decisions that Amazon correctly touts as needing action? multiply that 1000x. Speed of execution matters more than the quality of decisions at first, once speed is there, then you need to focus on making better and better decisions. (I am speaking of 2 way door decisions, 1 way doors still need to be thoughtfully thought out, but I bet the CEO is thinking about them day in and out, so talk to them!)

Also, shipping something at Amazon in a month is considered pretty fast. Lots of downsides of screwing things up. At earlier stage startups the goal should be to ship daily, ideally multiple times a day. Don't get complacent.

Get other exec leadership onboard early (ideally at the interview stage) and align that there will be tradeoffs to be made.

Likely at first, there will be months of assessment and then months maybe even a year or so of heavy investment in fixing the infrastructure. Your job is to set such an expectation, but also find a way to ship customer value along the way. This is the hardest part of the job, but failing to set the expectations will set you up for failure and so will just fixing the infra without shipping value.

I once attended a great talk from an early VP of Engineering at Facebook. He unapologetically said that they were investing 50% of their time in building the infrastructure for current and future experimentation. So be bold and don't fear putting significant effort into improving the "machine", then assess as you go and then you can reduce the split.

In conclusion, don't throw the Amazon experience but apply extreme scrutiny to how your experience will emerge and transfer to the new environment

Don't throw Amazon away, be grateful for what it taught you, but let the incredible experience there emerge under the lens of the new context. Maintain clarity of judgment and be critical every time you are tempted to say "at Amazon, it worked like this", and ruthlessly prioritize where the focus should be. Former Amazon employees can be of incredible value to any company, but like in all things, judgment is paramount.