{
  "$type": "site.standard.document",
  "canonicalUrl": "https://justingarrison.com/blog/2020-07-23-dev-to-devrel",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreib4oehcuyd44kzs3eqr7dsrnx4wnqeust2nq2wf4mruxbqaujmda4"
    },
    "mimeType": "image/png",
    "size": 731317
  },
  "description": "My experience switching from an engineer to a developer advocate",
  "path": "/blog/2020-07-23-dev-to-devrel",
  "publishedAt": "2020-07-23T00:00:00.000Z",
  "site": "at://did:plc:p7uix7mresfq4nfzxp3klgfa/site.standard.publication/3mmdn7mg2qm2d",
  "textContent": "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.\n\nI 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.\n\nTitles 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.\n\nAs 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.\n\nAfter 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.\n\nI 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.\n\nIt 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.\n\nHowever, 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.\n\nSo here are my unordered observations after making the career change.\n\nI write more code as a developer advocate\n\nI 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.\n\nThe 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.\n\nI 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.\n\nI enjoy writing code a lot more when it has a more finite purpose and won’t wake me, or anyone else, up at night.\n\nI get to learn new things all the time\n\nYou 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.\n\nEven 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.\n\nAs 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.\n\nI 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.\n\nSometimes 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).\n\nTrying 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.\n\nThere’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.\n\nI 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.\n\nI have more influence on product\n\nI’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.\n\nI’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.\n\nI 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.\n\nI 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.\n\nI’m not in sales or support calls\n\nI’ve only been at AWS for 3 months. On-boarding and meeting people internally is a big reason for this.\n\nSome possible reasons I don’t have these types of calls include:\n\n- COVID-19 and travel restrictions\n- I’m new and don’t have established relationships (internally or externally)\n- I don’t know what customers I should talk to\n\nIn 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.\n\nI’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.\n\nI have a lot fewer meetings\n\nI didn’t expect this at all. Between product, customer, team, and community I assumed I would be in meetings a lot.\n\nAs 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.\n\nSome 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.\n\nEven 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.\n\nThe 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.\n\nWe pay attention to what customers are saying\n\nAt 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.\n\nBecause 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.\n\nNow I find myself on the receiving end of too much news.\n\nI 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.\n\nIt’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.\n\nI 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.\n\nAs 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.\n\nI write a lot\n\nThis was expected before I joined, but I didn’t expect that I would spend more time on internal documents than external.\n\nProviding feedback and writing my own internal content takes time.\n\nIn 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.\n\nThe 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.\n\nThis obviously varies for different people and different teams. For right now I’m still learning and am pretty comfortable with focusing on internal docs.\n\nI’m more involved in open source\n\nIn 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.\n\nIn 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.\n\nThis is great for me because I love community. I love helping new people, providing feedb",
  "title": "From Dev to Devrel"
}