Taking a Promotion to Customer

After 7 years, 8 months, and 13 days, I had my last day at Amazon Web Services on August 11, 2023.

Over that time, I managed to have 5 different job titles (2 as an individual contributor, 3 as a manager), 5 different managers, working on 2 different AWS products.

A lot changed over (almost) 8 years. When I joined AWS, I was the second engineer on the fledgling RDS team in Sydney. As a Systems Engineer in an operationally-focused team, I spent a lot of time diving into all aspects of a complicated distributed system. After a couple of years of seeing various recurring problems and patterns, I realised that I could fix more if I wasn't an IC fighting fires, so I turned to the dark side and became a manager. My manager and I started building up the team and building up a base of operationally excellent software to support. In September 2018 my manager moved to another part of AWS, and I took over the whole team (then 15 people). Although I'd had direct reports before, this felt like my first real management role, and it was a pretty big adjustment. The team continued to grow - by the end of 2018, I had 23 direct reports (a mix of Software Development Engineers, System Development Engineers, and Systems Engineers). Somewhere in there I got a promotion and helped hire 2 extra managers so I could split up the different teams1.

Through 2019 I had a small team, trying to explore some of the big areas of RDS ripe for improvement after 10 years. This was a big year of exploring options for improvement, suggesting fixes large and small, and then seeing some internal re-organisations completely change the priorities of my team. After 4 years, I started to look for other options in AWS, and found an opportunity to work on a completely new service - AQUA for Redshift. In February 2020 I started with no team, a bunch of headcount to hire, and a whole lot to learn. A few of my previous team from RDS asked to join me, which helped bootstrap the team. It's no secret that most of AWS is built on AWS. Building a control plane for a new system from scratch meant the team got to use a lot of AWS technology that didn't exist when RDS was designed, or was higher up the dependency graph and thus couldn't be used.


A few of the key highlights for me:


There's no other company working in cloud computing that matches the scale of AWS (although you could argue that Azure and GCP are near enough to be equivalent). The pace is relentless and the scope/impact of the work you do is epic, especially when you consider not just the direct customers of AWS, but their customers and the people impacted. This is keenly felt whenever there's an AWS outage, especially for one of the core services and/or in one of the bigger regions. This leads to a lot of pressure, and a never ending backlog. But the feeling of knowing that your work has such a large impact across the internet is something amazing that's hard to describe.


There's a lot written about the "2 Pizza Team" model of Amazon, and how it allows for a lot of autonomy and independence for teams. That does match my experience, but Amazon also comes with a lot of benefits of scale. There's a lot of internal tooling, process, and support teams that's not viable if you don't have a huge company to find it. Hiring is one of those areas.

  • Scale

  • Hiring

  • My team

  • Manager craft

  • Great leaders, and their faith in me

  • The LPs

Some Metrics
  • Role and location - 5 managers, 5 job titles, 9 desk assignments across 3 buildings in 1 city
  • Hiring - 395 interviews (177 as bar raiser), 37 direct report reqs filled
  • Operations - 3500+ sev 2 tickets worked , 20 COEs written
  • Phonetool - 906 icons received, 21 awards owned/managed
  • Code - 522 changes (40,606 lines added; 22,907 lines removed) on 35 packages
  • Email - 241 mailing lists, 64 outlook rules

  1. As an aside, this was a super-weird phase in my time at AWS. I had worked with a recruiting team to drive a hiring event that hired 8 engineers for the team in November 2018. I also drove the resume reviews and initial screening for the two manager candidates. Once they were hired, I wrote down the plan to break up the team and divide up the engineers and projects into logical groupings that would make sense and work to the strength of the engineers and the managers. And I ended up not having the new hires roll up to me - the managers reported to the same manager as me, and I ended up with 6 engineers and a couple of projects, with most of my previous stuff handed over to others. Looking back, I can see how this made sense to my manager at the time, but I can tell you it felt pretty shit at the time. I also think that I would've been able to handle it too. 


Comments powered by Disqus