In What is Developer Relations?, I described the broad areas that developer relations encompasses:
- Awareness
- Education
- Feedback
- Community
The most common job title for a person working in developer relations is developer advocate. Let's look at the daily responsibilities of a developer advocate.
The Developer Advocate Job
Most of the time (though not all of the time), developer advocates come directly from engineering and development jobs. For example, I moved into content and dev rel from a full stack C# and JavaScript job. In my opinion, developer advocates should be developers, since they need to truly understand where developer users are coming from and what they care about. That’s not to say there isn’t plenty of room for non-technical people in dev rel, but for the role of developer advocate, it’s a necessity.
A developer advocate is responsible to some extent for all four of the areas of dev rel. Because the surface area of the job can be so large, though, the daily job of a developer advocate can vary widely. This is especially true depending on the size of the team. A larger team might allow for more specialization in one key area and a larger organization may split out certain facets of developer relations into its own team. This happens a lot with community, teams that work on SDKs or other open source projects (sometimes called developer experience), and technical content. Sometimes developer advocates do all of these things and other times they are focused on something specific. In the latter case, developer advocates will collaborate with community, SDK, and content teams for joint projects.
What does a developer advocate do?
A day in the life of a developer advocate might look something like this:
9-10 am: Prepare talk for upcoming conference.
10-10:30 am: Meet with content team for collaboration on GraphQL article.
10:30 am-12 pm: Respond to DMs, Slack messages, and forum posts asking questions about the product or talks and articles you've written.
12-1 pm: Lunch (you've gotta eat!)
1-1:30 pm: Meet with SDK team on feedback you've gotten from early access users.
1:30-2:30 pm: Collaborative live stream with a compatible company on how your products work together.
2:30-4 pm: Work on new features for internal tooling.
4-5 pm: Write quarterly report on conference and meetup impact.
And this isn't even when traveling! Here's a pretty close example to something I've experienced on the road:
7-8 am: Meet with program participant (only overlap in time zones).8-9 am: Last minute slide tweaks and practicing.
9 am: Speak at conference
9:30-12 pm: Hang out in hallway answering questions from attendees.
12 - 1 pm: Sit with conference attendees at lunch but forget to eat because you're answering questions!
1 - 3 pm: Sit in hallway answering DMs, messages, and forum posts but pausing to say hi to people and answer questions.
3-5 pm: Sneak back to hotel room to attend meetings with various teams and teammates.
5-6 pm: Collapse for an hour to recharge.
6-8 pm: Dinner with attendees and other speakers.
8-...?: Hang out with attendees and other speakers.
Lots of different stuff going on there!
Developer Advocate Responsibilities
Let’s group all of these and expand on them. I like to think of this as two sides of a conversation, speaking and listening:
- Speaking: Awareness & Education. This is largely content. Content can mean writing blog articles, recording tutorial screencasts, doing live streams, appearing on podcasts, speaking at conferences and meetups (in person or remote), and any other creative way you can think of to make content. It might also mean running or sponsoring events, like having a booth at a conference or sponsoring a Hackathon and participating as a judge. This usually also includes the marketing for any of this, such as social media promotion for your content. Sometimes your company will have dedicated marketing or social media teams, but even then it’s often up to you to promote your content in addition to whatever they’re able to do.
- Listening: Community & Feedback. Activities here include talking to event attendees, reading and responding to forum posts, managing the forum, running incentive programs to empower developers in their own careers, working with the SDK team on product feedback, and going through and answering DMs on various platforms like Slack and Discord. This is the supportive part of the job, the part where we listen to users and the community at large and use that feedback to improve on ourselves and the product.
Both sides of the conversation are important. Without the listening side, the speaking side will come off as inauthentic, tone deaf, or as just being a marketing shill. We don’t want any of that. We need the feedback, questions, concerns, wins, and losses of our developer users to help us make useful and interesting content. Without the speaking side, though, users may never know about solutions to their problems. They may get frustrated for lack of educational material. I don’t know about you, but if I get frustrated with a software tool I’m using, I have a pretty low threshold until I’ll just replace it with something else. Unless I have to use something for work, I have plenty of options, so why stick with something that’s painful and counter-intuitive? Articles, conference talks, podcasts, streams — that’s what helps the user feel like the voice they have matters and that their problems will get solved.
There’s another part of the developer advocate job that I haven’t mentioned yet, and that’s maintenance and logistics. This includes things like building and maintaining internal tools, writing up reports on events, documenting strategy, managing open source libraries or microsites (tiny, single-purpose sites that demonstrate one specific feature or side product), and self-education. This is sort of like all of the normal stuff that any other dev job would have in addition to your main focus. Admin work, emails, paperwork: turns out even in developer relations you can’t escape that. That said, a lot of fun engineering projects become part of this, especially when you can use them to learn a new skill and then create content around it.