Justin Garrison
July 23, 2020

From Dev to Devrel

Posted on July 23, 2020  •  11 minutes  • 2273 words

I switched from a role as a Sr. Software Engineer leading a team of Site Reliability Engineers for Disney+ to a Developer Advocate for containers at AWS. Here are some of my experiences and observations about the role change, and what it might mean for you if you’re looking to do a similar switch.

I was a long time engineer in various roles. As I changed roles my title changed from Sysadmin to Sr. Systems Engineer and then to Sr. Software Engineer - Lead.

Titles have different responsibilities and expectations depending on where you work. As a systems engineer I was responsible for provisioning, configuring, and scaling lots of servers, but they never required me to be on call because my customers (artists) were only using the systems during work hours.

As a lead software engineer I was responsible for prioritizing team initiatives, discovering and addressing customer needs, and writing and reviewing code. I was also responsible for a lot of infrastructure that I was on call for every other month.

After 7 years of being responsible for building and maintaining production systems I switched to a developer advocate role for a lot of reasons. The main reason was a lot of the parts of my job that I enjoyed (e.g. teaching people, guiding product) were things that appeared to be responsibilities for a developer advocate.

I have been public speaking in my free time for a while because I loved the opportunity to help people learn from my experience and it always taught me new things.

It may also be important to point out that I became a developer advocate right when COVID-19 quarantine happened. The usual things you may associtae with a developer advocate (e.g. traveling, conference, etc.) I haven’t done.

However, during all of my interviews I made it very clear that I would not be able to travel for at least the first year due to having a 1 year old baby at the time.

So here are my unordered observations after making the career change.

I write more code as a developer advocate

I was surprised the most by this. As a DA at AWS I have a lot of freedom to pick areas I want to focus on. This is partially an AWS thing and partially the DA role, I think.

The really refreshing thing is I don’t have to write code to implement a feature or support for years in production. I can learn something new and never get paged for my terrible implementation with a new language/framework/tool.

I get to find a customer pain point, write sample code to fix it, and then document my findings for internal product teams so they can implement it in their own way or teach customers to enable them to understand the problem and find their own solution.

I enjoy writing code a lot more when it has a more finite purpose and won’t wake me, or anyone else, up at night.

I get to learn new things all the time

You know how you have a backlog to learn a new tool, framework, service, library, etc., and your schedule is so full of meetings that you’re lucky if you get 4 hours a week to dedicate to learn the new thing.

Even when you take 4 hours you still feel guilty because there’s an entire backlog of bugs, feature requests, and deadlines you’re not doing.

As a DA I’ve been lucky enough to spend ~50% of my time learning new things. I spend a ton of time reading about new products and services we’ve shipped or will be shipping.

I equally spend time writing code to test the things we’ve made. I try to find the sharp edges in our products to make it better for customers.

Sometimes I do that before the product has been released, but many times I don’t even know about a new service until I see the blog post announcement (AWS is a big place).

Trying and learning new things is one of the joys that brought me to tech in the first place. It’s so refreshing to be able to spend time to understand who the customer is, and bring customer feedback to the product team on how it can be better.

There’s never enough time to try everything that comes out. I spend a good deal of time with products that AWS doesn’t make too.

I have a lot of experience with tools from my 7 years as a practitioner, but the industry changes so fast I still try to understand when a tool might be the best fit.

I have more influence on product

I’ve heard devrel is different at lots of companies and so far I’m happy with how it is structured at AWS. Devrel at AWS is part of the product organization.

I’m in product design conversations, I review PRFAQs , I give product feedback, and write my own documents for ideas I think would be useful. Even when I’m wrong (which has been frequent) everyone I’ve talked to has been helpful in showing me where my assumptions were inaccurate or gaps in information were leading me down a different train of thought.

I am directly able to take things I’ve learned using AWS services and tell the product team how I would like to see things different or where a use case may not be supported and they have always been receptive to my feedback. I’ve been asked to participate in additional conversations to help refine those ideas and literally advocate on behalf of the customer.

I always felt like I got great customer support as an engineer at Disney, but being one step removed from the product engineers always made it seem like the process took longer than it needed to. Even if implementation still takes the same amount of time I now get more regular feedback loops and it’s my job to help improve the products and I feel even more invested.

I’m not in sales or support calls

I’ve only been at AWS for 3 months. On-boarding and meeting people internally is a big reason for this.

Some possible reasons I don’t have these types of calls include:

In any case, I expected there to be at least 1-2 customer meetings per week. For the past 3 months that has not been the case. I have only had 1 customer meeting and that was because I volunteered for it.

I’m happy for that, but also I know there will be times when I’ll want to dive deep with customers to understand their use cases and pain points.

I have a lot fewer meetings

I didn’t expect this at all. Between product, customer, team, and community I assumed I would be in meetings a lot.

As a lead software engineer I was in meetings for at least 50% of my week. I easily averaged 4 meetings a day and that includes a day dedicated to no scheduled meetings.

Some of that is cultural differences at AWS and some of that is freedom and responsibility in the role to work on what I think is the most important. Also, a good portion of that is not having sprint planning, backlog grooming, sprint showcase, etc.

Even though I don’t feel like I’ve been very productive (mostly because I’ve been on-boarding) I can see how only having a handful of recurring meetings on my calendar will help me be way more productive and focus.

The way meetings are conducted at AWS is unlike anything I’ve ever experienced. In 3 months of meetings only 1 has had a slide deck, but that’s information for a future post.

We pay attention to what customers are saying

At my past 3 jobs I typically was one of only a few people with a twitter account. I was almost always the only person who regularly used an RSS reader and kept up with technical news, projects, and interesting blogs that surfaced in developer spaces.

Because of that I shared a lot of news, projects, tweets, etc. with co-workers. In most cases they had never seen or heard the thing I was sharing.

Now I find myself on the receiving end of too much news.

I never thought I would learn so much about how people use social media, articles, and blogs to gain insights into what customers are doing and want.

It’s really interesting to see conversations sprout from tweets from individuals, blog post from small startups, or random deep dives into a new announcement. I had heard AWS was customer obsessed and I assumed they paid attention to big users, but I didn’t realize that if you so much as tweet something about an AWS service there is probably someone who sees it and it may end up on a PRFAQ even if they never respond or favorite your tweet.

I know this isn’t the case everywhere, but not only devrel employees are paying attention. Project managers, engineers, and maybe even management show up in threads I would have never seen at previous companies.

As a matter of fact previous employers actively discouraged engaging with anyone online about work related topics. For a long time I was terrified to post personal things online for fear of getting in trouble at work.

I write a lot

This was expected before I joined, but I didn’t expect that I would spend more time on internal documents than external.

Providing feedback and writing my own internal content takes time.

In the 3 months I’ve being doing devrel I only have 1 blog post and a 3 other documents that will be made public. Everything else, so far, has been internal facing.

The amount I’ve written has been greatly impacted by on-boarding, learning processes, learning projects, and generally just trying to focus while the world seemingly falls apart.

This obviously varies for different people and different teams. For right now I’m still learning and am pretty comfortable with focusing on internal docs.

I’m more involved in open source

In 6 years as an engineer I was able to open source 1 project and had 1 public PR related to work which each took 3 months of legal reviews. All of my other contributions were to internal, private repositories or were made in my free time.

In the past 3 months I haven’t been committing code to open source projects yet, but I’ve been a lot more active in issues, community slack channels, and SIG email lists and calls than I previously was allowed.

This is great for me because I love community. I love helping new people, providing feedback to issues, and also contributing code.

I need to make sure I balance my time and have been intentionally slow to commit to anything. Being involved in open source is a big driver for me to continue down the devrel path.

Things I’m worried about

There’s a few things that worry me about devrel I haven’t found solutions for yet.

One is I’ll stop being a practitioner and become a talking head. I’m writing more code than ever, but that doesn’t mean I understand the constraints of building and operating real systems inside companies. Some of that I can get from listening to customers, but as time goes on I’m afraid my memories will fade and I’ll forget the pain of upgrading a complex system, or overly simplify the process developers have to take to push code to prod.

I wish there was some way for me to take on responsibilities in real life productions systems outside of AWS for a time to keep the problems fresh in my mind.

The second is I spend too much time typing. I have wrist problems and all this coding and writing has me trying to find different ways to be productive without being at my computer.

I think travel and speaking would help, but for at least the next year I need to find a way to take more breaks.

My third observation is devrel can be a bit of an echo chamber. Maybe it’s because I’m new to this job, but I see a lot of posts (including this one) about devrel.

I don’t remember seeing them when I was an engineer which makes me think they were always there and I never paid attention to them. Which then makes me think it’s probably harder to get a message to engineers than I think, and there seems to be constant questions about business value of devrel teams.

I never put thought into proving the value of engineering to an organization, but maybe I have doubts about the perceived value of devrel for the organization.

There are great people putting lots of thought into devrel and what it means for companies to have dedicated teams in this space. I’ve learned a lot from people like Mary Thengvall , Swarna , and Ashley Willis on what it means to support devrel teams, building inclusive communities, and providing value to the organization.

Lastly, will I ever be able to go back to engineering? I see a lot of talk about management to IC switching, but rarely see devrel to engineering.

Some days I wish I was still an engineer talking to other engineers. It’s probably just me, but it seems like now that my title has changed all of my experience and desire to help people are invalidated behind a pretence that I’m trying to sell something.

Follow me

Here's where I hang out in social media