A (dis)gruntled staff write-up gives some hints of the weak tech culture at Amazon.
The most surprising thing I encountered when joining was how manual most processes are. It blew my mind how many business critical processes were managed with excel spreadsheets being shared via email chains.
These processes track a rapid turnover of staff, while not really tracking the obvious risks such as problems leading to the turnover.
When I onboarded, there was a huge backlog of work that needed to be done with PMs and engineers asking for commitments on when I could deliver things by – urgent to not block progress, but also ironic that they are asking a person who has no clue what they are doing to deliver critical work. I realized over time that this was the norm. People come and go which has the net impact of making you feel like you are just a resource.
Given how the word “dystopia” was crafted during industrialization to be an inverse of utopia, in the past I have used the following phrase to help people understand what they might be getting themselves into:
The best people can ever achieve leaves them treated like owned and controlled assets in a dystopia…
This new article is a fascinating read that lays out just how horribly Amazon treats people, especially engineers and how weak their safety culture is as a result.
To be blunt: it sucks. To make matters worse, since each team owns its infrastructure, there are varying degrees to which safety mechanisms (automated testing, one-click rollbacks, logging, etc.) are implemented. This creates a chicken and the egg problem of infrastructure vs. product development. One usually happens at the expense of the other. So when the morale on the team dips (usually related to lack of clarity or setbacks making things take a long time), people leave the team, which further damages morale and can easily result in a mass exodus.
This complete lack of safety (for both product and staff) becomes even more alarming when the author announces that building is being done before design.
…most teams don’t want to “wait around” for design to assist in the process and are anxious to start building, which usually results in half solutions. It is easier to partially solve the problem than think through things from first principles. …employees become “resources” (cogs) plugged into gaps to stop the bleeding rather than contributing out of their core competencies. This was further evidenced when one of the projects I was assigned to had an engineer who had never done web development (didn’t know HTTP, HTML, CSS, or JavaScript) was tasked with doing the front end system design for a React application as well as the API that would power the UI.
This is a great read and emphasizes clearly how a very talented and technical individual could not even last a year at Amazon because the culture is so unmistakably unsafe.
The great irony is how the author emphasizes the documentation requirements of Amazon, driven by traditional manual processes using simple spreadsheets and file sharing through email (all very non-cloud), and yet none of the number crunching seems to be directed at proper long-term goals like staff, product and ultimately consumer safety.
I’ve written about this before in terms of American love of American football, and of course it’s not the first time I’ve read an account like this of a company that cares little or not at all about some of the most important metrics for success.
