This is a gratitude post to all the stuff I loved about Amazon (and its culture) and some lessons I took away from it.

I’ll start with the small, under-appreciated, but still important stuff. One, as much as I’ve poo-pooed some internal tools for being bad quality, the important ones to my job were often great quality and incredibly useful. Having a company-wide system that just work (without any onboarding) and requires a single line changes to record & measure metrics means you get to test hypothesis real quick and only changes that you think are impactful. Using Weblab (A/B test & feature gates) is another great practise that let you release changes methodically to small percentage of users and measure statistical impact to top level metrics across the org (so you don’t screw up something and get more signals). Another aspect is the great resources in the form of great wikis and videos on all sorts of topics like writing, engineering, etc.

In terms of the heavyweight takeways, I have two - git gud at operations, and git gud at writing. Again both are pretty overloaded & generic words. By operations I specifically mean, thinking about the system in production. Thinking about its maintenance and development. Thinking about how you plan to deploy a change. Thinking about automation. Thinking about building a pragmatic system that you can be oncall for. In a way, it’s about owning your system and giving a shit about the customer experience.

On the other hand, I equate writing to a pseudo-strategical-thinking superpower. I personally ended up writing a lot of investigation doc, where i would deep dive issues, write up a potential fix and send it to folks in the US (that way I didn’t have to stay up late) to review. I did get to write a few design docs, but most of them never made it into production. I still enjoy the feeling of writing a doc, because it’s so intentional and you really get to structure your thoughts for your audience. It’s also hard to BS your way into writing about something if you just understand it at a surface level.

The last point I’ll make is that people matter. I really enjoyed working with senior engineers (folks who’ve been at Amazon for like 5-10 years) from our US sister team. You really see the level of quality and details they show in their work and it’s something that rubs off on you when you work with them. Plus they have great intuition for how things might go wrong. One example was when I was working with a senior engineer on a document, and I came back from my weekend staring at a perfect design doc with the diagrams that really communicated what we were trying to do and the doc structured in the correct way.

Looking back, I’m grateful for my time there.