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.


Robert Williams

Board Member, BoxLock Inc.

1 年

Great stuff Raf

Petr Maly

Higher Education | Anglia Ruskin University | ex-Marshall | Ex-Amazon

1 年

Great article, thank you Raf Cannizzaro

Eve Taylor Robinson

Product @ The Farmer’s Dog

1 年

While I’ve never worked at Amazon, given the caliber of who they hire, I assume a large mental blocker to moving much faster is fear of failure / fear of being wrong / fear of looking or doing something “stupid”, especially as a newbie focused on making a good impression with a slew of people who have no idea who you are and whether they can trust you. I’ve never met a new person at any level who wasn’t concerned about first impressions. “Action is information / learning” is helpful shorthand when feeling deeply uncomfortable with an incomplete picture, even if you’re being humble and getting as much information as quickly as possible. Because it takes weeks, months!, to gain a semblance of confidence in making quick two-way decisions for a product.

Marina Fomina

Digital Marketing Strategy | Google Ads | Ex-Amazon | Agency Co-Founder

1 年

Love the post, Raf. This is a super relevant topic for me - and likely many others - as I’m learning about the ‘world outside of Amazon’ after a decade there. As I sort through the skills I learned there and decide on what to lean into vs leave by the wayside, it’s especially helpful to hear people’s thoughts on writing as a thinking vs operational process tool.

Mike Mallazzo

Commerce media @ PayPal

1 年

I'm a writer at heart so take with a grain of salt but I think the best thing ex-Amazon employees can do for the tech ecosystem at heart is aggressively bring docs culture to their new organiztions. Every consulting style deck that gets replaced with a thoughtful memo is a net boost to GDP

要查看或添加评论,请登录

社区洞察

其他会员也浏览了