Looking back on four years at AWS as a developer advocate
Today is officially the four year anniversary of my start date at AWS as a developer advocate. I thought I’d take a moment to write up my thoughts on the past four years working in this incredibly interesting role, at one of the most interesting companies in the world, on some incredibly interesting technology.
The Background
I started at AWS on January 3rd, 2017 as a developer advocate for container services. First of all I have to give a shout out to Abby Fuller for referring me for the role. We worked together at a startup called Airtime that was creating a social media app focused on synchronous, live interactions. Airtime initially had some scaling issues, and was struggling to build and deploy new features fast enough. The backend needed to be rebuilt for increased scalability, reliability, and flexibility of product feature development. Containers, container orchestration, and continuous integration + continuous deployment were a few key concepts that we wanted to build into the fabric of the developer workflow. EC2 Container Service (now known as Elastic Container Service) became generally available right around the time that Airtime began this effort, and it was a natural fit for our needs. I feel lucky to have been able to experience ECS as a customer almost from its very inception.
As one would expect there were challenges and difficulties along the way, but the project was successful. Airtime’s new and improved backend system proved more than capable of achieving our scalability goals, and most importantly it enabled a more rapid pace of development thanks to the ECS container orchestration automating our releases and enabling true continuous deployments. In late 2016 I was proud to watch Abby share our success story with ECS on stage at the AWS Summit in New York. Abby made the jump from Airtime to AWS soon after, and referred me for a developer advocate role at AWS within the container services organization.
A new role at AWS
I remember one of the questions that I was asked during my interview in Seattle was “what do you see a developer advocate doing at AWS?” This was a question both for me and for AWS in general. The “developer advocate” role did not officially exist yet at AWS. There was no job title for it in the system, so I was given a substitute title of “product manager” which resulted in me being issued a super weak Windows laptop. I had to open a ticket and explain that as a developer advocate for container services I actually needed a developer machine that could run Docker and containers.
Beyond the laughable early mixups was a deeper need to define the developer advocate role, and what it meant. From the beginning I made two main goals for myself, both of which continue to this day:
- Educate and spread awareness of AWS container services externally, and help users of AWS container services connect as a community.
- Listen to customers and bring their feedback to engineers and product managers inside of AWS to make container services better for customers.
On the second goal I started out with my own opinionated ideas about what AWS needed to do, based on my own personal experience as a customer, but I knew I needed more than that.
Connecting with customers
I did not start out as an active social media user. In fact at the time I joined AWS I had maybe 50 followers on Twitter and I rarely participated on any social media platforms. But I realized that if I searched “aws ecs” on Twitter there was a treasure trove of customer feedback there. Happy customers, confused customers, and angry customers were all sharing their thoughts and blog posts about ECS. In addition there were questions on Stack Overflow, posts on Reddit, and issues on Github. My first year at AWS I spent a lot of time talking to customers in person at events and at the AWS loft in NYC, and reading and responding to folks on social media.
One of the first things I created was the Awesome ECS list. I realized that many of the individual ECS users I chatted with were publishing their own independent solutions and references, often without being aware of each other. My goal was to connect all these folks together and help them discover each other’s guides and content, so that they could have a stronger sense of community, and could help each other as well. I also wanted to give people who were creating content about AWS container services some positive feedback for putting in that effort, by driving traffic to their content.
Today the Awesome ECS list has 2.4k stars, contributions from 27 different people, and significant daily traffic from folks who are searching for how to get started on ECS.
Connecting with internal engineers and product managers
Ironically I spent my first year at AWS connecting more successfully to external customers than to internal team members. I believe there were a few reasons for this:
- I was a remote employee from day one, so that made it harder to connect with the core Seattle employees. I did more travelling to conferences, events, and customer workshops than I did to visit the core Seattle folks in person.
- I was used to much smaller organizations, having worked exclusively at early stage startups. I remember the first time I visited Seattle I walked in with a misguided impression of what “two pizza team” meant and thought I’d be able to meet everyone working on ECS in one week. (Spoiler alert: like all significant sub-organizations at AWS, the container services organization is not a single two pizza team: it is subdivided into small two pizza teams that all work together on pieces of the bigger picture). I had to develop some new skills to learn how to navigate a much larger team than I was used to, and find the right people to talk to.
- Initially I focused too much on the outreach and marketing side of developer advocacy, and not enough on the internal advocacy side. This is a fairly common mistake I think. It is easy for orgs that are new to developer advocacy to turn their developer advocates into an extension of marketing.
Learning more about product management
I recognized that I needed to have a closer relationship with product managers inside AWS. Knowing what each one was working on and which ones were responsible for the product pieces that customers had feedback on was only the minimum. Instead of just throwing feedback onto product managers I spent more time learning about how PM’s in AWS operated. I learned what a PRFAQ was, and began participating in the internal feedback process for PRFAQ’s. I also started writing my own PRFAQ’s with solutions for customer needs.
I also recognized that ECS customers did not think about ECS in a vacuum. What they thought of as “ECS” was usually actually a combination of ECS and its related services, including CloudWatch, Elastic Load Balancing, etc. I started building more relationships with engineers and product managers outside of ECS itself.
As I unlocked more potential of the developer advocate role and started having more impact by bringing customer feedback to the product development process I was promoted from developer advocate to “senior developer advocate”.
Keeping my developer skills fresh
Developer advocacy requires marketing skills, and product skills, but I feel the third pillar is maintaining developer skills. “Developer advocate” doesn’t just mean I advocate to developers, it means I am a developer who is also an advocate. Personally I feel the need to actively develop things in order to stay credible as a developer, so that means staying hands on and coding regularly.
Every year as a developer advocate I work on a significant coding project. It has to be more than just a “hello world”. I usually build early in the year, taking advantage of new stuff that became generally available at re:Invent, so that my code can be both a learning project for me and a reference for others. Not all of these coding projects have fully seen the light of day yet, but they have all led to me releasing something as open source for the community, as well as giving me tons of firsthand experience I can bring back to the developer teams I work with.
My first project was a microservices architecture which led to me releasing sample CloudFormation templates for microservices on ECS and releasing Containers on AWS as a guide for walking people through the different networking possibilities for ECS services.
The next major project I worked on was in celebration of the launch of AWS Fargate. I built a serverless chat application using all fully managed AWS services: AWS Fargate, Amazon Elasticache, and Amazon DynamoDB. I open sourced it, and the application is still running at fargate.chat
After that I decided to build a more complex, fully serverless application that used both AWS Lambda and AWS Fargate. At the time there was a fair amount of questions from folks about whether they should use Lambda or Fargate. Then and now the answer is “use both”. Most significantly complex applications have components that fit both compute models. My sample serverless web crawler uses both Lambda and Fargate to discover and parse changelogs from hundreds of thousands of open source projects. It is open source itself and runs at changelogs.md This demo application was also my first steps into the world of AWS Cloud Development Kit, and is still one of the most complex sample applications defined using CDK.
In 2020 I focused in on developer experience and AWS Cloud Development Kit. I revisited my first microservice application and redeployed it to use AWS App Mesh. My learnings from that project showed me that we needed higher level tooling for deploying a service mesh alongside ECS. This led to me coding ecs-service-extensions as a higher level CDK module that allows you to extend an ECS service with plugins that add functionality like service meshes, observability, autoscaling, or network ingress.
Looking to the future
I remember when I joined AWS my original goal was to stay four years, in order to complete my initial stock vesting schedule, and then I would reevaluate. Now that the time has come I still have so much more that I want to do in this role, with this amazing team. I have seen such massive growth of all our container services already, but I know there is a lot more to come. More features, more user experience improvements, and more tools to make customer’s lives easier. That keeps me excited, and makes it easy to imagine another 4 years at least.
I have seen over the past years how my work as a developer advocate at AWS has evolved and the balance of marketing, product, and coding has shifted each year. Obviously 2020 was an unusual year. I was able to connect with many more folks online even if we couldn’t travel to be there face to face at an event. With Covid-19 still ongoing and vaccine rollout looking like it will take a long time it seems unlikely that I’ll be doing much/any travel to events this year either.
On the bright side this means another year strong on product and coding focus. I have already been working on ECS developer experience, with AWS Copilot, a new ECS console, and CDK infrastructure as code for ECS. My goal for 2021 is to double down on all these ECS experience focused areas, while adding a few new and exciting things as well. But more on that later…
So here’s to another year as a developer advocate at AWS, and many more to come! Feel free to reach out to @nathankpeck on LinkedIn if you have any questions about developer advocacy, working at AWS, or if you would like to work with us at AWS as well.