How I Rewrote My Job Description (Over and Over Again) At Amazon
Develop a healthy disregard for your day job
I’ve always been fascinated by behavioral patterns at large. Being at Google, Amazon and Microsoft for 24 years gave me access to the data from the yearly company surveys. These consist of hundreds of questions sent to tens of thousands of engineers so they provide a wealth of insights. All kinds of interesting patterns emerge when you look at aggregated data.
In one of these companies, one of the statements engineers had to rate was something like “I have the opportunities to reach the next level in my current team.”
The aggregated results for this question were always disappointing to me. I tracked it over a few years, but it was always about the same. Never above 45%. More than half of engineers from company [redacted] did not feel their current job gave them growth opportunities.
This was disappointing to me on multiple levels. One, I legitimately wanted people around me to succeed and thrive. But two, I saw opportunities all around me, and it really bothered me that others couldn’t see them. Maybe I’m just a “glass half full” kind of guy. So many opportunities, that I didn’t have time to tackle them myself. I would often package some up and give them to promising, hungry engineers around me. A few of these individuals took these little golden eggs that I neatly packaged for them, ran with them, and made something amazing, growing their career significantly in the process. Others, for whatever reason, did not.
I recently read the book “Outliers — The Story of Success” by Malcolm Gladwell. It is a fantastic read. Gladwell analyzes the lives of outliers, people that did extraordinary things, like Bill Gates, Steve Jobs, or Jeff Bezos, and comments, “outliers are those who have been given opportunities — and who have had the strength and presence of mind to seize them.”
The most common excuse for not seizing an opportunity is that you don’t have enough time, or that it’s not aligned with your day job.
I’ve always had a healthy disregard for what my “day job” was currently defined. Rather than thinking, “this is what my boss told me to do so I must do it”, I’ve always viewed it as “this is what my manager believes the business needs right now, but if I have data to prove there’s something more important for the business that I could do, I should consider that route.”
I’m not telling you to ignore your manager. But I am telling you to partner with your manager on an alternate path if you believe in it.
I will share an example from my own life.
My story goes back a decade. I was an SDET (Software Design Engineer in Test) at Amazon. Back then, Amazon had the approach to embed a test-focused engineer in each development team, and I was that guy (one of my stories talks about the dev:test ratio at Amazon). We were the advocates for engineering and operational excellence, and helped the team to ensure the quality of the product.
I asked my Dev manager what she wanted me to do, in my first 1:1 with her. Her response was short and sweet and to the point. “I have ten devs in my team. They are following Agile. So every sprint they’ll release 1 or 2 little features in the product, and I want you to test them.”
I was a Level 5, which is in between entry level (L4) and senior engineer (L6). Her response made me frown.
You see, the role as described by her was never going to help me grow to Senior for two simple reasons.
- It was time-bound. I was to work on 3-week chunks, never really looking beyond my current sprint. I expect Senior Engineers to be looking at problems beyond the current sprint, thinking about what the business looks like six months from now, a year, two years from now. One of the indicators that somebody has reached that Senior inflection point is they think more strategically (long-term), not just tactically (short-term).
- The scope was very limited. My devs cranked up one or two features, and I was to be laser-focused testing just those features. What about looking at the product as a whole? What about the higher-level interactions between my product and its ecosystem of dependencies and callers? Another indicator that somebody has reached that Senior inflection point is they think about the bigger picture, not just locally at the feature level, but more globally at the product level and beyond.
I understood those things and I was hungry. I explained my view to my dev manager in our next 1:1. She was sympathetic to my concerns but essentially said “we’re stretched thin, this is what I need you to do so suck it up and do it” in slightly more polite terms.
Well, okay… The job as defined by her was easy. I was making good money, Amazon stock was doubling every six months, and I could do my job in less than 40 hours per week. I could just as easily have continued doing it for the rest of my life, and get pretty good performance review ratings. Job security! Life-work balance!
But, that wasn’t me. I had wasted too much time not pursuing what I was passionate about and not living up to my full potential career-wise. I needed to challenge the status quo.
I attended the weekly operational reviews for the team, where we looked at our operational load and some of the new bugs that had come in that week. One thing that jumped out at me was that my team was dedicating 2 people to operations, so 20% of the team. Whichever two poor engineers were oncall that week, they knew that pager was going to go off many, many times during the day… and in the middle of the night too. Being on call was a death sentence for the week. It was unhealthy. We started talking about getting a third person oncall to alleviate the pain. So 3 out of 10 people on call meant less people to actually work on features that mattered to our customers.
We had a lot of tech debt. We needed to not just tactically fix a bug in isolation, but think more strategically about what root causes were the biggest sources of operational pain and go after them. Right now, we were just playing a desperate game of whack-a-mole, with a very reduced time-frame (“right this minute”) and reduced scope (“this bug right here”).
I started reading every single bug that came, and creating a taxonomy of things that could have prevented that particular bug from even occurring. After a month I had some pretty decent ideas on root causes that were giving us a lot of grief.
In my next 1:1 with my dev manager, I pitched spending my time on that problem. My math was simple. I had the trends of bug growth over the course of the last 2 years and I knew it was going to continue getting worse. I could create a tool to reduce the number of bugs coming in by enough so in the next 12 months, it was going to save 1 headcount. I needed 1 month to work on it. So that was a 12:1 return on investment.
Once again she was unimpressed, repeating something to the extent of “yeah dude but these features that my devs are cranking up need to get tested and you’re a tester so suck it up and just do your damn day job. The devs will have to suck it up and deal with the ops.”
I hope I’m not making this individual sound like a bad person. She was not. We’re still good friends today, a decade later. But, she too, was overwhelmed by the pressures that her leadership team was putting on her for delivery, so she didn’t have time for my shenanigans.
But, I knew I was onto something. My math was correct. My root cause analysis was correct. And it was going to make the lives of my ten developers much easier. So I showed it to the devs and I made them a proposition. This tool was going to take a month for a dedicated person to write and deploy. They could do half my day job for two months, while I was working on this thing, and that was going to free up X many hours of operations per week after that. Invest a little in the short term with a payoff in the long-term. It was a gamble, but I had done enough research that my devs trusted me and bought into it, and helped me convince the manager.
She was annoyed that I was exhibiting such a healthy disregard for the “day job” she wanted me to do, but she was intrigued and maybe a little amused by my stubbornness. “OK, fine, but this better do what you promised.”
It did.
This bought me some credibility and currency with her and developers around me to continue investing time on these more strategic, longer-term, bigger-picture bets to reduce operational load. I think I struck a cord by tackling something that was very personal to a lot of my devs: they did not like to get paged in the middle of the night, and I was genuinely trying to make their lives better. A year later, we were down to 1 person oncall, from our forecasted 3+.
My “day job” looked entirely different than it did a year ago. I had freedom to roam around the product, looking for areas where tooling or processes could reduce toil, and my devs were doing most of the actual sprint testing. In order to reduce operations, I had to work across many teams outside my immediate team and influence them to change some of their behaviors, and that sometimes took months, so I was clearly working beyond what my original position had been scoped to do. I was writing tools that empowered them to do their own testing. It was a much more scalable and sustainable world to live in.
I had an original day job, I had a very opinionated dev manager that wanted me to just do that, and somehow, I had shown backbone and a healthy disregard for status quo and found something that was much more impactful to do with my talent.
Again: I’m not encouraging you to ignore your boss. But I saw an opportunity to do something where I provided a significantly higher value to the team and the company, and I relentlessly pursued that despite being discouraged. It wasn’t about not wanting to do my day job, it was about wanting to provide a higher value to my employer.
And, I also got very, very lucky. I got lucky that I found some low-hanging fruit to tackle. I got lucky that my devs bought into my vision. I got lucky that the thing I predicted was going to make their lives easier actually did. This gamble could have also gone very, very wrong. I took a calculated risk, and it paid off.
Six months later, I was promoted to Senior Engineer at Amazon. My strategic work reducing operations, and working across many teams, was a significant data point in that promotion. That would have not happened if I hadn’t pushed back on what I thought I should be doing with my life (or at the very least, it would have taken a lot longer).
I did initially have to spend some of my personal time to analyze bugs into a taxonomy and think about tooling to proactively prevent them from happening, as I still had a demanding “day job” that didn’t let me work on “side projects.” But this investment paid very well in the sense of accelerating my career. Assuming that it helped me get promoted six months faster, investing an extra twenty hours of my life had a fantastic return-on-investment. I’m very strict about life-work balance, but occasionally I’ll take a personal-time gamble on a high ROI task that I believe in.
I’ve continued to follow this “healthy disregard for my day job” throughout my career, which has led me to again and again rewrite my job description. Sometimes, the business needs what the business needs, and you just put your head down and deliver what’s needed. But other times, it’s healthy to question yourself and whether you’re working on the most impactful thing that you should be working on. And if you’re not, how do you get there?
