Amazon

The first thing to know about Amazon is that the experience varies from team to team and is very manager dependent. Your manager can also change a lot.

The positive things with my stay were:

• Majority of the cases, I was allowed to choose the technology suited for the task (but this might not be valid for you).
• I saw even VPs fired. Amazon does fire people regularly. This is dead sure. The good thing is that not only small guys get it; the big guys do too. So there is no such thing as an upper layer of torturers like you have at General Electric. While there is a small amount of "cliques," no higher-level manager can allow a team of courtiers to exist all the time. It is satisfying to see big windbags whacked when their luck ran out.

Very poor high and middle management. Some internal organizations are heavily political.

I counted myself in an averagely political organization. And even there I saw:

• Talented, smart, and fair managers and engineers were let go because their manager feared their position or wanted to show off.
• Mentally challenged, clueless, but servile puppets were kept.
• Technically illiterate people were promoted because politically there was a need to declare success for an actually failed, over-complicated, but heavily invested project.
• "The successful people" pumped and dumped useless projects (and then left fast before it became obvious for everybody what a mess they had done).
• Narcissistic maneuvering and passive-aggressive behavior by withholding information.
• Talented engineers "hooked" with "Amazonian leadership principles" (framed with false failings) and then set up with "Dev Plans" and later with Pivot or PIP (Personal Improvement Projects) and given projects that depended on other people who did not care to work. In other words, a most common tactic used by managers was to frame one engineer as failing one of the "Amazonian leadership principles." It was not hard. These leadership principles are conflicting by design, so you can frame one excelling one as a failure of the other. After the engineer was framed, he could choose between getting fired or five hopeless projects. Many chose the hopeless projects that they could not complete in time because it depended on others who did not work or had other things to do. So he failed and got fired. For the manager, it was a win-win. If the engineer somehow miraculously completed them, it was a win because he "managed" the engineer. If it failed, it was a win too because the engineer failed and not him/her. I saw this common, nasty, defensive tactic all the time.
• Bad project management. A lot of crunch on projects that in the end were canceled or completed and never launched.

Here are my advises to anyone trying to get a job or working at Amazon: Once in, choose between the following two options:

A. If you are very honest.

If you see any double-faced (double-talk) or dishonest behavior from your manager, do research on available jobs/teams.

• Measure somehow the team fluctuation.
• Check their code commit times (like is it during the night, etc.).
• Look at their incoming tickets, scrum boards, maybe contact and talk with members.

Once you decided on a job on the internal job site, before pushing the "interested" button, contact the hiring manager to see if he/she would have you. Maybe have an informal interview. If he/she is willing to have you, press the button then, because the moment you press it, your current manager will know that you want to switch. Your current manager needs to be the last person to know if you want to switch because he/she can prevent it by putting you on DevPlan (framing you with bad work) before it, and then you are not allowed to switch.

B. If you are willing to compromise.

"Windbag" and build big, over-complicated, useless things. Nobody will dare to call you out on them, and you will be heftily rewarded and promoted. Promote yourself too by submitting your "promotion document" (filled out by yourself with your favorite lies) every month.

Some internal organizations are doomed because they are rotten to the core, and you will not be able to get the required talent.

In other organizations, technical expertise, groundedness, and knowing what is realistically possible are a must for engineering managers.