I've been doing Developer Relations for about four months now. It's been a lot of fun! I can already tell I've been learning and growing my career in some new ways. I've also been able to see how DevRel can help a company.

I had a lot of misunderstandings about DevRel, and its role at a company. I want to explore those and speculate on some growth areas I see coming to the field.

# DevRel is all selfies and conferences, right?

I have to admit, when Developer Relations started getting popular, I had a lot of FOMO. I kept seeing people on Twitter, jet-setting around the world and drinking fancy drinks in tropical locations. It looked too good to be true!

Here are some things I didn't understand about DevRel but have learned over the last four months:

# 1. Conference talks are only a tiny part of the job

Conference involvement must vary heavily by company. Regardless, your company DevRel strategy almost certainly involves documentation, blogging, social media engagement, community building, making demos, starter projects, internal advocacy (mentioned later) and more.

I would wager that most DevRel conference talks you see are the final step of a vast engineering/marketing push. That person probably:

1. Embedded with the team as they built the project
2. Tested it and gave feedback
3. Organized community feedback sessions
4. Wrote official docs for the feature before launch
5. Wrote a blog post after launch
6. Made some demos to help bring the docs to life

And only after all of that, packaged it up and submitted it as a talk!

# 2. It's difficult work that requires your authentic self

I spent my entire career as an engineer. It's challenging work. It's fun, rewarding and high-paying work, but it is difficult!

Developer Relations uses a very different set of muscles. On the one hand, I don't end up with as many "deep work" tasks with tight deadlines. I still code a lot, but since I'm building demos and libraries around services our engineering teams made, it's a very different experience.

On the other hand, as an engineer, I could deep-dive into my particular product or part of the stack. It was pretty easy to become familiar and productive, and I could focus on my little kingdom.

DevRel is very different. The easiest way to describe it is that engineering requires a depth of knowledge, whereas Developer Relations requires breadth.

Engineering requires a depth of knowledge, whereas Developer Relations requires breadth.

# 3. Content switching between marketing and engineering is hard

Some organizations house Developer Relations under engineering, some under marketing. I feel like it fits better under engineering, but there is a fair amount of marketing involved. As an engineer, I had a tough time context switching between projects or between meetings and coding.

Switching from an engineering hat to a marketing hat is difficult for me. I'll be late for a meeting because I'm stuck and desperately trying to get my code to work. Then I'll hop on the call and fumble with my words as I try to explain why I think an event is worth attending. It feels like I need at least five minutes dedicated to switching my thought process.

# 4. Internal advocacy is as important as external

To be honest, I didn't even know internal dev advocacy was a thing until we hired our first person for the role! Three months in, I don't know how we lived without him.

Imagine having folks in your company intimately familiar with your APIs, tools, issues and upcoming features. You go to build a new product or feature, and they embed with you, helping you get up to speed on all the internal systems.

Seriously, think about this. Every job I've ever had, I've complained about wanting to use open-source tools instead of these confusing internal ones?

Going back over my career, there isn't a single job I've had where I wouldn't have significantly benefitted from having an internal dev advocate helping me ramp up on our authentication, serverless platform, storage APIs, etc.

# My predictions for DevRel in 2022 and beyond

# 1. Internal advocacy is going to blow up

I think this is going to be the next big thing. Teams of folks who are intimately familiar with your tooling and APIs. Available for office hours or embedding with your team. They know how to get started and who to talk to. They help write internal documentation, surface pain points to infra teams and make feature teams more productive.

Does your company have internal developer advocacy? I'd love to hear about it!

# 2. People will start moving into leadership roles from DevRel

I also suspect that we'll see more developer relations folks making it into leadership roles. The role gives you a great breadth of experience, and you get to know the engineering org intimately, but you also have a great understanding of what the sales and marketing teams are dealing with.

Typically I've seen folks from engineering or product promoted into leadership. This works great, but they often have to work hard ramping up on whichever org they weren't previously in. DevRel folks often know everyone at the company already, and I think this is super valuable.

What do you all think? Am I way off base with my predictions? Does your company have any developer relations people?

---

• ← GitHub find which PR deleted a file
• JavaScript format number→