Thread regarding Amazon.com layoffs

Continues 1:

A document review meeting always begins by reading the document. The assumption is that you have not read the document in detail and so there is a practice to create space for everyone to thoroughly read through. One quirk I find amusing is that everyone wants the document to have line numbers so they can reference specific points quickly. After the document is read, the discussion begins and stakeholders go through each point. The meeting ends with some sort of action item (go do this, meeting with these people and update the document, etc).

I found this to be a very helpful practice that I think would benefit organizations of all sizes, however it does reinforce that people are not the source of truth for information which leads to my next implication.

• Teams are Fragile

When I first joined Amazon, there was a huge push for an aggressive start date. This was because I was backfilling an open role. The designer who’s place I was taking was still at the company but focused on other projects so the product team had been without a designer for 6 months. 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 is the norm. People come and go (which has the net impact of making you feel like you are just a resource). I reviewed the plan for the product I was working on and each quarter represented a scope of work (in my opinion) that you could build a whole company around - CRMs, Email Builder, Complex Automations etc, and my first thought was LOL we are never going to build all that yet it was what had been promised to stakeholders.

This uncovered an imbalance that I think exists in many large companies: the path to promotion between PM, Engineering and Design are all different and have incentives that conflict with one another. In many cases, in order for a PM to get promoted they need to deliver some large scale “win” which consequently can encourage overcommitment, fudging impact numbers / justification.
In my case, being overly ambitious contributed to poor morale on the engineering team, which in turn lead to longer delays in project execution and shorter on call rotations. In just over 7 months, that team lost 6 engineers, the Engineering Manager and the PM (2 left, then the PM left, then the lack of clarity became a huge snowball and 4 more engineers left the team and then finally the engineering manager who was trying to backfill all those roles ended up leaving).

The churn I experienced was significant (having another project I supported turn over PMs in the middle, and multiple other team members on another project leave the company or join new teams). Some of the churn could probably be attributed to upstream leadership issues, however in the cases of engineering there is a brutal downward spiral that happens when someone leaves the team. When someone leaves, they try and backfill the position which in today’s engineering climate, takes a very long time. In the meantime, the on call rotation shrinks meaning each engineer has to be on call more frequently.
When an engineer is on call, they are not working on the product (implementing features etc), they are a point of contact for other teams who want to integrate, and are responsible for fixing issues (regardless of what time of day they happen). To be blunt: it sucks.

Continues 2:
To make matters worse, since each team owns their own infrastructure, there are varying degrees to which safety mechanisms (such as 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.

Everything is Urgent (but takes forever)
When the scale of a company grows, doing (literally) anything requires a strong sense of urgency. This is especially true for programs that are working across various teams to unite a workflow or solve a customer issue that bridges various silos. The job title of Program Manager is essentially someone who coordinates work horizontally across a large organization. Because of the federated operating model, there are many programs and teams who’s charter is to solve a problem that requires integrating with multiple tools or products.

I report to a centralized UX team which supports the whole sales and marketing organization and owns the “UX” from internal tooling to customer facing properties related to devices. This inherently means that the majority of the work cuts across silos. In order to achieve the ideal customer experience to bring together workflows, consolidate etc. It also means that you naturally inherit the constraints of every single surface you are integrating with. It is nearly impossible to be aware of all of these constraints so the process usually follows a similar pattern:

• Design a solution

Review with stakeholders
Surface all the problems or things you didn’t account for
Rinse repeat
On a well executed project, design and research will be involved early and go through these iterations so that when the teams are ready to build they have a decent level of clarity. However, most team’s don’t want to “wait around” for design to be available to assist in the process, and are anxious to start building which usually results in half solutions. It is a lot easier to partially solve the problem than to actually think through things from first principles. For me personally, it meant that a lot of my work was meeting with stakeholders and learning about different processes and deep diving into the solution. In an isolated sense, I like this work, however it is impossible to get to the depth of knowledge required to actually solve a problem if you are responsible for more than one project at a time (I was responsible for 3-4 large projects which I toggle between).
I was hired as a Sr Design Technologist, which bridges the gap between design and engineering and is able to offer technical solutions to customer experience issues. Unfortunately, the majority of my time is spent doing “program” style work which leaves about 10% of my time for technical work. Ultimately this is not what I want to be doing with my career. The larger point here is this: companies’ critical needs will always trump your career ambitions and often there is a large delta between the job you were hired to do, and the job you actually do. The negative side of this is that 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 asthe API that would power the UI.

• Everything is built in house

This is probably an add-on to some of the other implications, but Amazon in particular is obsessed about data security and so it builds all of its tools in house. On one hand, from a frugality (a leadership principle) and scale (cost) perspective this makes sense, however it means that employees have to deal with tooling that is duct taped together and usually doesn’t actually solve the problem because the work necessary to make a really good solution would have required working across teams and that is too difficult. If I am being perfectly honest, I can’t think of a single internal tool at Amazon that is better than a commercial counterpart.

• Closing thoughts:

I think everyone’s experience at a big company will vary by organization and even by team. In my case, the team I reported into has actually been phenomenal. The team was incredibly supportive of one another and makes really great efforts to stay connected especially operating as a remote team. We had a good cadence for meeting as a team (2x a week), and the team had a top tier manager. I have learned a lot working under this manager. She was tough and pushed everyone to dig deeper and not settle for what’s easy, but she was also kind and joyful (what a powerful combination). I also really admired how responsible and good at communicating / followup everyone on the team is (our 2 researchers in particular). They add so much value to every aspect of the surface area we cover.

I also really enjoyed the opportunity to get more hands on experience with AWS. That 10% has been fun - contributing to a Vue.js app that generates marketing graphics - migrating from EventBus to Vuex, adding routing etc). I migrate the app from an EC2 instance to S3 + Cloudfront (using Lambda Edge for authentication). I also got to do a deep dive on permissions and learned a lot about Cognito (user & identity pools) and IAM roles (while integrating with an external OAuth provider). I wish that I could have gotten more hands on experience with Dynamo DB. There is a perfect project for using it and it would be fun to work on data modeling and building an API to power our front end app but also extend its a capabilities to be able to generate graphics with a service. Unfortunately this work probably falls in the high impact low priority category and wont be executed any time soon.

I don’t regret my decision to work at Amazon. I learned a lot in a really short amount of time, but I also realize that it was not the place for me long term and I am at peace with that. On to the next one.