What’s a day-to-day of a developer relations engineer like?

Nobody has ever heard of Developer Relations Engineering (also known as Developer Advocate), but it’s an awesome role! I only heard about it 6 years into my career, and I’m so glad I did.

I found out about Developer Relations Engineering shortly after the pandemic started, and at the time, I was working full-time as a software engineer on Firebase at Google. I tried out Developer Relations Engineering as a 20% project (at Google, we have this great policy where we can spend 20% of our time doing projects not directly related to our actual role) from Jan 2021 until the end of Sept 2021. At that point, I started a half-year rotation to try it out full-time. As of May 2022, I have officially changed my title to Developer Relations Engineer, and I thought I’d share what it is since before I found out about it, I had no idea what it was.

In short, developer relations engineers (shorthanded DREs, DevRel, or also called Developer Advocates in the tech world) help developers (people who develop apps) understand how some technology (like Firebase, which is what I work on) can solve challenges and issues they have in app development, and for users already using said technology, we teach standard practices and show how to use the technology that could best help them. There’s a bit of engineering, a bit of community management, and a bit of marketing all rolled up into one.

DevRel exists for all products designed for developers, because we want to understand our users (app developers) and help them accordingly. As some examples: Firebase, Android, Flutter, Google Cloud Platform, and generally, platforms used by developers built by companies all have developer relations.

What do we actually do? Well, in order to teach and show how to use Firebase, we’ll create technical content: write blog posts, make videos, write code for samples and step-by-step walkthroughs (known as codelabs) of how to use particular products or features, present at conferences, and engage with our users through various means like events, Stack Overflow, and other forums. Writing external user documentation (such as introducing the products and API guides) and libraries is also part of our job, although technical writers do more of the former and another developer relations team does more of the latter so I haven’t personally done much of either.

A big part of our job is also to gather feedback about our products. A lot of the time, we’ll ask developers we meet what they’d like to see, and we always write down what questions they have too. If we keep getting the same feedback or questions, that’s probably a sign of needing to change our product or content.

The tl;dr of “What is DRE?” is maybe: “Technical content creator and feedback gatherer, a bridge between internal teams and external users”

I’ll dive a bit deeper into what each content piece above entails, except for the external documentation and libraries bit since I haven’t really worked on that. In all of our content, we’re thinking about: “why would a developer care about what we’re writing about?” As a result, we want to form a story about why what we’re saying will help them. Will it make launching a feature easier? Will it make their app more secure? Will it give them more information on what the app users might like more?

Blogposts

When we write blogposts, the typical process is drafting, making images if needed (or asking our producer team to make them), getting feedback, iterating, and then posting it. Oftentimes, our blogposts won’t have much code, and if they do, we’ll make sure the code works before we start drafting. In the final post, we’ll just include the relevant code into the blogpost. Generally speaking, writing is a pretty straightforward process. Here is a list of blogposts I’ve written for the Firebase blog.

Videos

Videos are a bit more complicated. First, we have to decide what type of video we’re making — is it part of an existing series, or is it going to be a new one? We have a lot of existing series for Firebase already, such as short animation videos, fundamentals, and release notes, just to name a few.

If we want to make a new series, we have to carefully think about why we need a new series that can’t be fit along with an existing one, what’s going into that series, and what the purpose is. Naming a series is difficult also! We’ll write a document outlining all of this information, along with what each video is going to be. Then, after deciding we indeed do want to create a new series, we’ll talk to the producing team (people who help us record, post-process audio and video, make graphics, include music, all that good stuff) about the series, along with what sort of graphics and music we’d want for our video openings.

With all of that settled, we can finally start on the actual videos themselves. Each video starts somewhat like a blogpost — we’ll have to draft what we want to say in the video. Some people will have word by word, others will have loose scripts. Either way, most people will have written some sort of a script. This drafted script gets passed around to other teammates for review, and after everyone’s happy, we’ll talk to the producing team to get a recording time on the calendar! In the meantime, we practice our script so we can iron out any coloquial issues.

Next is my favorite part, which is getting to record in our studios! The producing team makes sure the lighting and audio are good, along with ensuring we have a clean shirt and no stray hairs in our face. Our script then gets put on a teleprompter so no, we don’t have to memorize it!

After recording, we wait for the producing team to give us the video. Most of the time for videos, we’ll have accompanying slides and/or code to go along with the video, and the producing team will beautify our slides. We put together the video recording with the corresponding code / slides, which is usually super tedious and long, definitely a lot less fun in my opinion than recording in the studio.

Finally, after all visual content is put together with the studio recording, the producer team will do their magic and add music, iron out any scuffles, change screens as necessary, and give us a copy of what the final video looks like. We’ll go through it and add any comments for changes, and after a few iterations, the video will finally be ready to put on our Youtube channel!

Before that, we’ll fill out a metadata sheet, with information about the video name, description, video breakdown so viewers can have an easier time finding content if they’re looking for just a specific part, and any social media post’s content.

The video process is usually quite long, but it’s super satisfying to get a video out! My proudest video(s) are my Firebase Codealong series where I take people through building an expense tracker app using Firebase and React, along with a Mandarin version of “What is Firebase and how to use it”.

Codelabs

Users often find having step-by-step instructions with a sample app super helpful. For that reason, we write codelabs, which is exactly that. I haven’t created a codelab myself, but I do know that it entails writing an entire app along with writing directions. It also possibly includes maintaining the app after the codelab is released, just in case any products change. In my mind, codelabs take an extremely long time.

Conference / Meetup Talks

One of my favorite aspects of being a DRE is traveling for giving talks and attending conferences! The talk preparation process is quite extensive, but the good news is, talks can be re-used in different regions of the world. I’ve done this a lot of times for meetups, and it’s super efficient!

In any case, if we’re creating an entirely new talk, we need to first figure out what people would want to hear about. Afterward, we really want to tell a story of why people would care, and we’ll create the presentation. We’ll draft what we want to say, and then create slides to go with it. Like all the other processes, we’ll pass both to teammates to take a look, and after everyone’s happy with them, the slides will go to our producer team to beautify.

The hardest part about giving talks is presenting it, because aside from remote times, we likely have to memorize what we’re going to say. I’ve been lucky and most times, I got to have a screen hidden from the audience so I could see my script. But, we often can’t rely on that and I have had to talk without any scripts before.

Being on Firebase, I also have the chance to go to our big conferences without giving a talk, and my role there is to answer questions, talk to developers, and get feedback about our product.

Deciding on Content

How do we decide on what our content is going to talk about? That is, how do we know what to write the blogpost or make the video about, or what sort of code walkthroughs should we provide? When I first started out, I asked my mentor and manager for ideas, essentially working on other people’s projects. As time has gone on, I’ve seen the type of content that gets received well, and having interacted with people who are either interested in or already using Firebase, I figure out what we think developers need and make content accordingly.

Day to Day

So now to answer the actual question of day-to-day work: it varies! This is my favorite aspect of developer relations. Because we do such a wide variety of tasks, I can pretty much choose what I want to do each day, whether that means writing for blog posts or video scripts, preparing for or doing a presentation, recording my screen for videos and editing accordingly, updating existing code walkthroughs, or coming up with a new idea on what we should be doing. Aside from big pushes for conferences where there are certain tasks that absolutely need to get done, we work on whatever we’d like to work on and there aren’t any tight deadlines.

Is DRE for you?

DevRel is a very different role than being a software engineer, and there’s a lot more people interaction. Typical DevRels I’ve met are people who like interacting with others, because that’s basically our job.

How do you know whether DevRel is right for you? Many DevRels I know love coding and learning new technologies, and this makes sense because we need to learn the product we’re working on in order to teach and show developers how to use it. As such, we also enjoy teaching, although this type of teaching is not in the sense of standing in front of a classroom (although presentations at events are similar to this) but teaching in the form of creating content. Explaining, if you will. DevRels also enjoy variety, doing different types of tasks every day, and thrive in ambiguity. Lastly, we usually get to travel quite a bit for events, but this isn’t required if we don’t want to do events.

DRE vs SWE

Aside from the actual work, are there any differences between devrel and software engineering? The biggest difference I’ve noticed is the ambiguity of devrel versus as a software engineer, the managers and PM’s will have decided the feature or product to be built and my job is to figure out the code to build it. There’s a lot less ambiguity and more direction, compared to devrel which is basically “figure out what developers need and provide them with it”. Sounds vague? It sort of is. We generally know what sorts of content we should probably provide for new features or products, but for existing content, we need to really get into the community and understand what they’re constantly asking about.

Another big difference I’ve noticed is the collaboration for software engineers and the lack of doing so for devrel. I’m not sure if this is just how my team is, but most of the time, I don’t really know what my teammates are doing and don’t regularly chat with them to ask. Maybe this would be better if we were in the office? As a software engineer, we had weekly meetings about what everyone is doing, had discussions about building the feature, and we work pretty closely with each other on the actual coding. I don’t have a strong preference, as fewer meetings mean more time for me to work and a more flexible schedule while more meetings mean more human interaction and a more cohesive feeling of team.

My personal opinion on Devel is that it’s a lot of fun, and it fits my personality very well. I get bored easily and like variety, and all the work I get to do is already work I enjoyed from before — we do a lot of writing, speaking, traveling, meeting people — and I do all of that a ton outside of my work life already. It’s pretty great!