Prototyping a career in Developer Relations

I currently work as a Senior Tech Writer and am contemplating a career progression to Developer Relations. It seems like the logical next step in my career, but there are a lot of unknown unknowns in making that decision. To help me decide, I am following the method proposed in Designing Your Life which talks about prototyping the life you want to live to see if it works for you. This video details my experiment of prototyping a career in Developer Relations:

Paraphrased transcript:

My starting point was to figure out what DevRel is and what it means to me. My favorite definition is that Developer Relations is building relationships with the developer community. Building genuine, authentic, mutually beneficial relationships with your users.

Building a relationship with your users kind of involves the same principles of any relationship: genuinely caring for the other person and understanding their pain points and then figuring out how you can best help them achieve their goals and resolve their pain points.

This sounds really good in the abstract but my goal with the Developer Relations experiment was to figure out if I would actually like doing it as a job. I needed a concrete, measurable framework that I could devise my experiment and projects around.

I started reading a bit more and I came across this excellent framework by Eddie Zaneski. He talks about Developer Relations as having three areas or three components: Code, Content, and Community.

Code involves creating sample applications and sample repositories and plug-and-play applications that will help your developers get productive with your product faster and reduce the barrier to entry or the friction of onboarding. And the reason for this is that you have to remember that the developers who come to you for your product don't actually care about your product as much as they care about achieving their goals. As a Developer Relations person or Developer Advocate, my job would be to help the users reach their end goal by minimizing the friction for our product which is a small part of their overall tech stack.

The second part of the framework is Content which involves technical documentation, technical blog posts, Twitter content or social media content, slide decks for conference presentations, or tech videos.

And then the final part of the framework is Community. This involves developing one-on-one personal relationships with your users in the form of online forums or again, social media, or meeting with them in person at conferences and meetups, or organizing and participating in events like hackathons.

The first time I heard of the framework and I realized what each of the areas mean, and the activities that are part of each of the areas, it was super overwhelming. I was confused about how one person would do all of these things. So I asked a couple of experienced developer advocates about how do they manage all of these activities and they told me that they don't!

The expectation is not that one person would be an expert in all of these areas. The expectation is that you choose one area to be an expert in and then be reasonably good enough in the other two areas.

That got me thinking about how do I figure out which area do I want to be an expert in. Content seems like the most logical area for me but I was really curious about Code and Community as well. So I decided to devise projects for each of these areas and then prototype and experiment. So here's the experiment plan I came up with:

For Code, I enrolled in Udacity's nanodegree program for Full Stack Web Development. And the reason for that is that I wanted to go back to the beginner mindset. I feel like I have been so focused on CockroachDB for the past two years that I have kind of lost touch with the end-to-end tech stack and the pain points that the users go through at each of the user journey of which CockroachDB is just one part. And I hope this course will help me get back to the Code Newbie beginner mindset that'll help me understand my users better.

For Content, I started live-tweeting tech events that I went to. I do make tech videos but I want to make more of them. And I want to experiment with tech doodles and tech zines.

And for Community, I have been attending a LOT of tech events. I think I have attended an event almost every week for the past two months. And I have been traveling a lot for the events as well. Because developer relations involves a lot of travel, I wanted to see if I actually like
traveling as much as is needed or do I just like it in theory.

So that is my Developer Relations experiment. I will keep sharing the results and my observations and the things I learn on this channel.

If you are thinking of making a career change to Developer Relations, I highly recommend that you come up with your own experiment and prototype your career as a DevRel person before making the leap. And if you do that experiment, I would love to know about it, so please let me know in
the comments down below.

And if you are an experienced Developer Advocate, I would love to know your opinion or your feedback on my experiment, so again, please comment down below and let me know.

Thanks for watching (or reading)!