Part Two - The culture I turned my back on

My retirement from Amazon gave me insight into why people are reluctant to come forward when suffering harassment. The implication was that I was in the wrong. My complaint was ‘investigated’ and a decision was made in favor of those I complained about, not surprisingly someone higher up the corporate ladder; I became the one at fault, my retirement ‘gift’ was a metaphorical slap in the face. 

I interviewed with Amazon at the age of 67 - almost 68. In fact, I started work with them two days before my 68th birthday. Interviews are different in Amazon. Yes, there are coding questions; these can be completed in the language of your choice and the emphasis is not on how correct the code is but your thought process, how you deal with ambiguity and how you come up with a solution; all other questions are centered around behavior as it relates to the Amazon Leadership Principles (LP). Amazon only hires the very best of the best, or so they claim, and they keep raising the bar. It can be daunting to be surrounded by people who are geniuses and top performers, particularly in a technical world. It is very easy to question your own ability. I honestly did not expect to be offered a job, partly because of my age and partly because I suck at interviews. Almost a year later The New York Times published an article slamming Amazon's brutal culture. I flatly denied all it reported to anyone who asked me. That was then.

In the first 3 years I had 8 different managers, most of them temporary while they tried to find a permanent hire. The temporary managers were in name only and had no interest in managing the team nor in career development for the individual team members, they were already too busy with their own teams. Finally, a QA Manager was hired, he stayed for a full year, the longest any manager had been in place. When he left I put forward a case to make me manager. I had managed QA teams in two previous companies and didn't want to return to the of the lack of leadership we had before. After some discussion it was agreed that I would take over as a QA Lead and it was another 18 months before I was given the title of Manager. 

Fortunately I didn't need the title of Manager to have access to all of the managerial tools and processes and I was included in the various meetings and emails related to people management. That was an eye opener!  When it was agreed that I take over managing the team, there was also a reorganization taking place. Up to this point, the QA team was responsible for two separate development teams. The reorg split the team into two separate QA teams, one for each development team. On my team there were two QAEs, me and one other, and two Software Development Engineers in Test (SDETs). It was decided that the SDETs would report directly to the development manager and QAEs to the QA manager. Essentially that was me with one direct report, plus I had open requisitions to hire another two, one located in Seattle with the existing engineer and one to be located in Austin with me (our developers were also divided across these two locations), plus we had two junior engineers in Bangalore to support as needed, they did not report directly, but had a dotted line, to me. Of the two SDETs, one was in Seattle and one in Austin.

During the course of the exactly 4 years that I was officially managing the QA Team, that is as a QA Lead, then as a Senior QA Engineer and finally as a QA Manager, I hired 5 engineers, achieved 9 promotions, pivoted 1 engineer (unregretted attrition), coached two Engineers off the Development List (DevList)  - more about that shortly - and to be clear I was not responsible for putting them on that list in the first place, and had just one engineer leave (regretted attrition) and he left for the same reason I did (see previous blog).  I also assisted one QAE to make the almost impossible transition to developer. This is not intended to be a resume of my achievements, I list these here because I feel the need to put forward an argument as to why I believe I was under valued and badly treated by Amazon.

As I mentioned, I did coach two of my direct reports off the DevList. One had been put on the list by the departing manager I replaced. I took over in early February and the annual review is done during December and delivered in late February; when I took over all that was left to do was deliver the message to my new direct report. There is supposed to be a shroud of mystery over the DevList - that is no one outside of management is supposed to know such a thing exists, because that would allow them to be aware of the ever possible pivot path; in reality most people are aware of it to some extent; some managers will be transparent with their staff, and word spreads as people move teams; of course, you do tell them if they are under performing and you make them aware that they are being coached for this. For that reason, when I delivered the bad news that he would be getting no increase in compensation that year, I assumed it would be expected. He said he had not been informed that his performance was in question, nor had he been coached. I also believed that he should not have been placed on the DevList in the first place, while he had some gaps in his skill set I felt that these could be filled with mentoring and his other skills made him a very useful member of the team. He was the first person I coached off the DevList; he later achieved promotion. 

The second was one of the original SDETs. Both SDETs reporting to the development manager were given mind numbingly boring projects to work on, essentially nothing to do with QA work, more development tasks that were too boring for the Software Development Engineers (SDEs) to do. The SDET in Austin was the first to go, that is he was placed on the DevList and avoided pivot by electing to move into a QAE role, this also meant that he would then be reporting directly to me. I set about coaching him off the DevList, this was not a difficult task as he turned out to be a first class QAE. Meanwhile, I filled both of the requisitions, the one in Seattle was an internal transfer and the one in Austin was an outside hire. 

I have worked in a number of different companies, and I can tell you that achieving promotion in Amazon is more difficult than any process I have ever experienced in my life before, and not least because the process changes almost every quarter, so with each new candidate it is a whole new learning curve. It is not just hard for the candidate to qualify for that promotion; they have to be seen to be actually performing at that level before they will be considered. The manager has to put in a lot of hours coaching, identifying projects required to fill 'gaps' and prepare a document. If the document is not written in the accepted Amazonian way, the promotion is likely to be denied even if every other requirement is fulfilled. The candidate in turn has to spend a lot of time working on projects that are purely designed to demonstrate some skill set and serve no other purpose - that is a lot of engineering hours wasted to achieve a promotion that is obviously deserved by most standards. Finally there is the effort required to get feedback. This has to be from engineers of good standing and a higher level than the candidate. Naturally everyone is so busy in Amazon, it is hard to get people to commit precious time to supplying feedback, so more hours are put into follow up there, and if the feedback is not written in the accepted Amazonian way, that too could jeopardize the promotion approval. An added complication is the ever revolving door, with each new manager the promotion in progress has to be restarted.

As difficult as the promotion process is, the pivot process is ten times more difficult; it is more emotionally draining. The reports available online, such as the NY Times article are correct. Amazon has a pruning process. Indeed, they do 'hire and develop the best', but they are also always raising the bar (or moving the goalposts) and if the best don't keep improving they will sink to the bottom, though a better analogy is that the bottom will rise up to their level. However, the huge flaw in this logic is that they demand that each department (org) within Amazon prune a certain percentage of their staff; the exact percentage varies but is usually between 3% and 7%. If you happen to have a very high performing org, and another org has a majority of low performing, or staff that perform to a lower standard than yours, you still have to prune the percentage for that year - so you let some of your engineers go, while another org keeps engineers who are never going to be as good; essentially Amazon is losing high performers just to satisfy some stupid notion that doing so raises the bar; in practice it could well be lowering the bar. There is also the competition between groups within that org to try to keep their staff by denigrating the other managers' staff. The other inefficiency of this process is it incurs more unnecessary work recruiting, interviewing and onboarding new staff to replace those pivoted out; from start to finish the entire process is extremely stressful both for the employee and the manager. It is also disruptive for the team. Those are only a few of the things that frustrate me about this process. I do know of managers who deliberately hire in order to have a suitable pivot to avoid losing any of their existing staff.

There is also another side, less traumatic but also detrimental (in my opinion), to this method of leveling performance. That is the Top Tier (TT). Again only a certain percentage of staff in each org can be given this 'grade'; it carries with it a more substantial increase in compensation and stock grant. My objection to this is that as only the very few can reach this level, those who are equally deserving, but possibly not as well liked or as well known, within the hierarchy of the org's management, are left feeling under valued.

When one of my engineers in Austin transferred over to the development team, I replaced her with an internal transfer who turned out to be a serious mistake, though he did introduce me to the entire pivot process and a lot more I would happily have remained ignorant of. 

In order to pivot a candidate, they first have to be coached; this process was called putting them on the Development List - DevList, they are then given projects to challenge them to prove they can perform up to some standard and all of this takes more time, plus the required documentation is more busy time. As I said, I only had to go through this process once in my 4 years, and while that one engineer was most definitely not high performing and should have been gone long before he joined our team, this proved very difficult to achieve. He had already worked in three other orgs within Amazon before joining my group. And while I have got to admit that hiring him was a mistake on my part, I can be excused in part because as an existing Amazon employee we do not go through the same rigorous interview loop - the assumption is that this was done when he was first hired (an assumption I never made again). Secondly, he had been through the DevList process twice before with different orgs and knew way more than I did about it. Before digging deeply into his bag of tricks to avoid pivot, he suggested to me that I should take him off the DevList and he would look for another position within Amazon - leading me to believe that is how he managed to survive this long - an engineer on the DevList is immediately excluded from moving within Amazon. I was not going to do what the other managers had clearly done and take the easy way out. I was still prepared to fight for what was best for Amazon. What followed was 9 months of sheer torture for both me and the candidate as he played every legal card in his repertoire; I became friendly with our HR representative over the course of those 9 months as we tried to deal with this case. Due to a number of reasons I can't go into the details more than I have done, sufficient to say that he finally did leave Amazon. 

Other managers have had totally different but equally stressful cases to deal with. As bad as my experience was, at least my employee was definitely under performing and would never be able to do the job he was hired for; other managers have to go through the motions and still get rid of the employee no matter how they perform, just to make up that percentage; I have proved I have no objection to pruning dead wood, but by imposing a specific percentage each year we definitely lose good talent and add unnecessary workload to managers and the team. Believe me when I tell you, it is not the manager's choice. In almost every case they are forced into it by more senior managers or directors being pushed to make their quota. This process is often more stressful for the manager than it is for the employee, particularly as it repeats every year; while you don't always have to pivot one of your direct reports, you do always have to go to battle to save them.

Apart from that one under performing pivot, for the four years I managed the team, it was happy and high performing. The one remaining SDET in Seattle sadly was not so lucky and he was pivoted out the year before I left. He kindly gave me this quote on his situation:

"I came to believe that the only viable path to acceptance on my team was to transition from SDET to SDE.

As an SDET, when I used to report to a QA Manager, I had a future: I mentored, I presented at conferences, I made meaningful design choices, and spread influence and code across teams. When I started reporting to the Development Manager, not only did these opportunities seem to dry up, but I began to notice that I was being hailed louder and more persistently by a narrative I had heard in the background for my, then, entire 5+ year tenure at Amazon: SDEs are first class engineers, QAEs and SDETs are second class engineers. I set out to prove myself worthy of my job, ironically, by attempting to transition from SDET to SDE (a role I've never had the temperament for). After a year of teething, dealing with my dad's death, and being withered by the aspersions of a toxic senior SDE, I was offered a pivot plan, and opted to take a golden parachute instead."

While I was not pivoted, my departure was nonetheless unwelcome. I felt I had no choice but to retire, and unlike the pivot, I left without a payoff; perhaps I should have forced the pivot but I didn't have the stomach for that - not only would it have been dishonest, I don't think I could have tolerated the treatment for that length of time and above all, my team would have suffered. 

Amazon demands loyalty from its staff but does not repay this as I discovered. If you missed my earlier blog entry on the events leading up to my retirement, it is here.

To read more from the many Amazonians, past and present see here. 

The Business Insider has a lot more to say about this.