Job 9: Amazon ElastiCache
Towards the end of my time on the Alexa project, one of my managers asked in our one-on-one where I saw myself in five years. I thought about this for a little, and realized that, while I wasn't tied to the idea of being a CTO, I wanted to have more autonomy over running a larger engineering organization, so the goal I came up with was to become the primary technical leader for an organization with at least 100 million dollars in annual revenue. In stating this objective, I realized I didn't see a clear path to achieving this goal as part of the Alexa organization in that timeframe. Alexa clearly hoped to exceed that amount of revenue, but I didn't see myself being put in charge of all of Alexa within five years (and there wasn't really any way to subdivide Alexa revenue).
So, I started to ask around. When I worded the goal, I kind of had in mind AWS services, each of which are able to talk about having their own revenue stream independent of the rest of AWS, so I talked with some of my former coworkers from the RDS team, and found out they were looking for a new engineering manager for the ElastiCache product. ElastiCache was very similar to RDS, and in fact had borrowed most of the original code from RDS as a starting point, so this seemed like a pretty good fit. I interviewed, and decided to transfer, shortly before the official Alexa launch. (At the time I accepted the transfer, Alexa leadership was in the midst of evaluating whether or not to launch, and seemed likely to delay yet again. In the end, they decided to launch and Alexa was announced to the public shortly after I joined the Elasticache team. I often wonder if I would have stayed on Alexa, knowing they would launch that year, and how things might have been different if I had done that. We are not Marvel superheroes, though, and don't get to know what happens to us in our alternate universes.)
For reasons that have little do with the Elasticache team, I didn't end up staying in this role more than about six months. However, when I started out at this role, I did something that ended up being the germ of this website project ten years later. There were fifteen engineers on the team, and I was the only engineering manager. (One of my directives was to hire or promote another manager.) This left me pretty short on my own time, leading me to try to ruthlessly prioritize what I did myself, and what I would delegate to others (or just not do). I started out by writing a list, somewhat like this:
- Careers — For each person on my team; how are they progressing in their career? What gaps need to be addressed to get them ready for a promotion?
- Team — How well does the team work together? Do we work as a group, or as N individuals? What is our culture? Who are we?
- Recruiting — How do we identify and recruite the next engineers to join our team? How many do we need? When do we need them?
- Quality — Are we creating software with enough quality? When we find defects, do we fix them? How can we prevent them?
- Product — What features do our customers need us to build next?
- Operations — How well is our system performing in production? Are our metrics trending in the right direction? What will be the cause of our next major outage?
- Business — Are we making money? Is it enough? Where do we need to cut expenses? Where do we need to invest more?
- Project — What are we working on now? What comes next? When will it ship? Can we do more, or are we approaching burnout?
- Architecture and Design — How does our software come together? Is it built in a way that it will remain easy to maintain over time? How will it scale as our business grows?
Once I wrote this list, it was relatively clear that I needed to focus on managing the careers of the people on my team and team culture, with a healthy amount of time to help with recruiting. For a lot of the other areas, success would come more by delegating responsibility out to either engineers on my team or to partners in product and program management roles. This probably should have been obvious, but I guess it took being put in a place where I was forced to ruthlessly prioritize my time to identify the things I had to delegate.
My next opportunity came knocking before this list yielded dividends, but it has become a framework that I have periodically used to help me evaluate my current team and identify gaps that need to be addressed. I've added and removed items to this list from time to time, but generally think that effective software teams generally need to be good in most of these areas. I've thought about writing a book, but books are monolithic and daunting, so more recently, I've decided to just make those ideas part of a website — this website.
1: Lessons I'm Learning
I don't talk very much about this role. I don't have tons of interesting stories from my six months on the Elasticache team. Similarly, I would not be surprised to learn there are engineers on the team who barely remember that for a few months they had a manager named Jeff. Until writing this article, I didn't even really associate my time on this team with the list of "Things I manage" that has become an informal checklist I refer to often to think about how my current team is doing. Like the story of a butterfly flapping their wings and causing a hurricane on the other side of the world, every role we take has the possibility to change and shape our future in ways that are impossible to predict.
One of the things that drew me to this role was that a lot of the code for Elasticache started out as a straight copy of the code we had written for RDS about five years earlier. One of my teammates from the RDS team had joined as a senior engineer a little before me, so this started out as a bit of a nostalgia role. I remember at least one conversation we had where one of the engineers on the team asked why we had written some code in a particular way. The implication was clear — they thought it was a poor choice, but without understanding it, the team had been reluctant to change it and make it better. My RDS teammate and I looked at each other, shrugged, and said something to the effect of, "Probably because we had a launch deadline and didn't have time to do this the right way and thought we could come back to it later". Ever since then, whether thinking about a new team I'm joining or myself as a person (or our direction as a country), I try to remember that, while we are the sum total of our past, the best way to respect that past is to always do whatever we think is best for our future.