How to Start Doing Dev Rel Right Now

Many people tell me they consider developer relations their dream job, but they're not sure how to get started. In truth, you don't need a title to get started doing dev rel work and helping the community. In this article, I’m going to teach you how to build a personal dev rel strategy. You can use this in at least four different ways:

You can start building a body of work that you can take into an interview and talk intelligently about, including how you’ve measured success.
If you're a brand new developer advocate, you can use it as your starting point for your new job.
You can use it to apply to your day job as a way of leveling up in your current company.
You can use it as a basis for your personal content creation or “personal brand” (think of personal brand as your collective portfolio that you might use to get a job or consulting clients).

That last one has a lightbulb moment: dev rel and personal brand are really two sides of the same coin. You can apply many of the same principles of successful dev rel to your personal career. Instead of a product by a company, your product might be your consulting, an open source library you’ve written, or a book or video course. Knowing how to build a dev rel strategy will help you whether or not you choose to go into dev rel!

We’re going to go through five steps to building a personal dev rel strategy:

Step 1: Pick a tool or SaaS product that you absolutely love and that you feel has some level of credibility in the community.
Step 2: Dig into the wins, friction, and pain associated with this tool.
Step 3: Use that research to create a strategy around the four key areas of dev rel.
Step 4: Create content to support your strategy.
Step 5: Measure your impact and use the feedback to improve.

Step 1: Pick a product.

Step 1 is a quick one. What's a software tool or service that you absolutely could not live without? How about one that really delights you when you're working? If they're the same thing, even better! This might be somewhere you want to work someday, it might a software product you currently work on, or it might just be a tool or product you really like.

By the way, if you're currently a developer of a product (whether a software product or an app that supports a non-software product), learning this skill set can really make you stand out. You'll be able to talk intelligently with and provide value to marketing teams, documentation teams, sales reps, and product managers. That's a fantastic way to make yourself more valuable in your current job.

If you can’t decide, or if nothing really gets you excited or makes you geek out, just pick one. Write down your top three and literally just randomly pick one. The point of this exercise is to build experience, so you can always change your mind. You might not get more ideas until you start going through the process. As you’re writing a piece of content you might be like, “Oh wait, I could totally write about that new database as a service that I tried the other day.”

Once you’ve got a product or tool picked, it’s time to pretend that whatever company made that tool or service hired you to do developer relations for them. What would you do? What would be your goal? That’s what we’ll walk through in the next steps.

Step 2: Wins, Friction, and Pain

Since I can't read your mind, let's agree on an example for this exercise. Let's brainstorm on dev rel for a refactoring plugin. This nifty refactoring plugin basically makes your life wonderful. You find yourself wondering whether this thing could cook you dinner and walk your dog. Let's call it Refactor Wizard.

We need to get in the heads of our users and understand how they view Refactor Wizard. We might start by asking the following questions and doing whatever research we need to answer them:

Who uses this plugin? What types of companies do they work for? How many years of experience do they have? What languages are they working in?
What issues are they having with installing and using the plugin? What bugs are they finding?
What problems are they trying to solve by using the plugin?
What's the onboarding experience like? How quickly can they go from "What the heck is Refactor Wizard?” to "Wow this is cool!"?

Some of this information may not be publicly or easily available. That’s okay. Just do your best and gather what you can from your own experience, forums, documentation, discussions you might be a part of, or GitHub issues. We're trying to identify pain points that users are having while also noticing where the product really shines. That way we can bring feedback back to the company to improve weaknesses while also helping show problems that are currently being solved.

Since this is a product you love, you could start by asking yourself similar questions:

Why do I find this so indispensable?
Where do I get frustrated using this?
What would someone new to this tool find difficult? (Is there a steep learning curve for anything?)
How could this be even better?

Keep in mind that your experience may be different than others, especially if you've been using it for a long time or consider yourself an expert in it.

In both scenarios, you're trying to figure out what the tool is great at, where the sources of friction are, and what needs improving. I like to call this wins, pain, and friction.

Wins: what problems does the product do an amazing job at solving? Here are some examples for Refactor Wizard:

This refactoring tool can extract variables and functions like nobody's business.
It saved me 3 hours yesterday of mind-numbing refactoring.
It can convert between function types with a keyboard shortcut.

Friction: what bumps in the road do developers run into while using it?

Where does the developer have to think about what they're doing?
What interrupts their flow?
What features need to be more accessible?
Example: Every time I try to use Refactor Wizard to convert a class to an interface, it asks me a series of seemingly irrelevant questions.

Friction is a little more subtle than win or pains, but it can lead to a lot of improved experience. I’m sure you’ve experienced it: think about having to manually restart a server every time you make a change to a file. The “watch file and reload” concept was a revolution when that came along! There’s an entire category of development now around friction called developer experience or developer ergonomics. This is sort of like UX (user experience).

Pain: where does the product suck?

What can't I do with this product?
What does the marketing material promise that the experience or feature set fails to deliver?
Where is there poor or non-existent documentation?
What groups of people are at a disadvantage using the product or are excluded entirely from using it? (Super important but often overlooked!)
Example: Refactor Wizard crashes every time I try to refactor a function with more than three parameters.

Remember, you can ask those same questions about:

The SDKs
The APIs
The docs
The signup experience
The buying experience
The customer service experience

As you gather these notes, you can start to spot trends and begin to build a strategy.

Step 3: Use Your Research to Create a Strategy

Once you have your notes on wins, friction, and pain, you can start to build a strategy. Remember that dev rel includes four main areas. Here they are again with some examples:

Awareness: Speaking at conferences and meetups, appearing on podcasts. Education: Making video tutorials, writing articles, partnering with other tools or platforms to create or host content. Feedback: Talking to users about what’s working and what’s not and using it to drive feature development. Community: Answering forum questions, helping other people achieve their career goals, finding the "power users" in your community and promoting what they're working on (not just specific to the product).

Since this is your first ever dev rel strategy, don’t stress out about trying to do everything at once. For this exercise, let’s focus on building content to increase awareness and to educate our users.

To build your first strategy, you’re going to do the following:

Pick one of the pain points or friction areas that you’ve found in your research.
Come up with three different content ideas from different angles.
Create and publish the smallest iteration of all three of them as fast as you can.
Revise and improve on them over time.

For our example, let’s say that Refactor Wizard has a poorly documented feature for converting a function with more than three parameters into an input object. In addition to submitting a PR to the docs (which you may or may not be able to do), you could create some pieces of content that would help educate users on how to properly use this feature. Let’s brainstorm on that next.

Step 4: Create Content in Support of Your Strategy

Once you’ve decided on the point of friction or pain you want to create content on, you can come up with your content ideas. It’s helpful to look at the issue from a variety of angles. Here are some examples:

How do I solve the problem?
How can I avoid the problem entirely?
What’s the opposite of the problem?
What’s an example of where this problem matters?
What’s a real world use case for solving this problem?
What other technologies might be commonly used when this problem is encountered?

Our Refactor Wizard content ideas might look like this:

A step-by-step tutorial on refactoring functions with more than three parameters
An overview of patterns that help you write better functions that don’t have more than three parameters
How the Framework X team used Refactor Wizard to overhaul all of their function signatures (hint: this would make a really cool stream!)

Right now, don’t worry about the length or depth of these pieces of content: just do your best! They could be short blog articles, videos, a conference or meetup talk, or something else. I suggest picking one or two types of content with which you have at least a little experience with. The key here is doing this exercise quickly so you can start to measure the results and improve. If you’re brand new to creating content, start with whatever medium feels least intimidating.

Step 5: Measure Your Impact and Use the Feedback to Improve

Now that you’ve got some content written out, you’ll want to define some quantitative and qualitative metrics to track. In order to do that, though, you’ll need to try to get your content out to the world. You could do this by tweeting, creating an email marketing newsletter, or doing some careful posting on forums (just don’t ever be that person who barges into a thread and says “HEY READ MY ARTICLE”). Content marketing has had entire books written about it, so I’m not going to dig too deep into this right now, but start thinking through where you might have the most impact.

If you’ve written something you think the company who makes the product would really appreciate, many have guest author programs. Company blogs often have huge audiences, they’re constantly on the lookout for new content, and they often pay for articles. Do a little digging on their site and try to find someone in content marketing or marketing in general that you can email or DM.

Once you’ve got your content published and you’ve found ways of getting it in front of people, you’ll need some metrics. Here are some examples to get you started:

Hard engagement numbers: Views, clicks, attendees, listens
Conversions: sign-ups, sales, downloads, new free trials
Sentiment/Perception: tweets, emails, forum posts, GitHub issue mentions
Feedback: in response to talks, forum posts, blog comments, DMs

Again, depending on what you’ve picked, you may not have access to things like sales numbers or signups. That’s okay. Use what’s available to you. You might track numbers like views of your article and likes on your tweets, and then also keep an eye on GitHub issues to see if there are fewer or less mentions of the particular pain or friction you’ve written about.

In all likelihood, your initial numbers might be pretty small or you might not be getting good data. That’s okay! That’s valuable feedback you can use to improve. For example, if you’re not getting much traffic, you could start researching ways to grow your audience or guest author programs. If you’re getting any positive comments, take those to heart! For every person who actually makes a positive comment, there are many that thought the same thing but didn’t post it. This is a good sign that you are onto something. Also, if you’re going through this exercise for the purpose of preparing for developer advocate interviews, you’ll already be way ahead of the game just by knowing what the process is and how to measure it. Don’t stress too much about the results when you’re first getting started.

Let’s talk about negative comments for a sec. If you see a negative comment, you’re immediately going to have an emotional, almost visceral reaction. That’s normal and there’s not much you can do about it since it’s buried in your psychology. Don’t respond when you’re in that emotional reaction! Let yourself cool off a second and ask yourself some questions:

Who is this person?
Do they have a valid point, or are they just a troll?

If they make a personal attack on you, just flag, delete, block, whatever you need to do. Don’t engage and don’t worry about it. Sometimes a negative comment does have some merit, but that also doesn’t mean you need to totally change course based on one comment. Take a negative comment as data. See if there is validity to their point and something you can learn, and watch for trends. If you start seeing the same comment repeatedly, maybe there’s something you can learn from. That said, everyone’s got an opinion and you can’t please everyone, so at some point you just have to make decisions and do your best. Regardless, outside of trolls (whom you should ignore), do your best to respond with kindness. I can’t tell you the number of times a negative commenter has backtracked and been a little embarrassed because they didn’t realize a real human would respond to them. Sometimes people are just having a bad day.

In any case, you can take the metrics you’re tracking and feedback you’re getting and use that to revise and improve both your strategy and your content. Maybe what you thought was a big issue turned out to be no big deal. In that case you can find another point of friction or pain, create new content, and track its impact. Maybe it turned out to be a way bigger issue than you anticipated! In that case, you could lean in and expand your content.

Expanding Your Content: Tools in Your Dev Rel Tool Belt

Let’s say you’ve really struck a chord with users on a particular topic. How can you expand your scope, depth, and breadth of addressing that issue? Most importantly, how can you do so without feeling completely overwhelmed? All of a sudden you might feel like you have to simultaneously make podcasts, videos, articles, sample projects, TikToks, and anything else that comes along. It turns out you can be a little more strategic about this.

Here’s a rundown of where different types of content work:

Podcasts are personal. You can talk directly to a specific audience.
Written tutorials are long lived. They can be reference material for many years. This has a benefit but also a maintenance cost.
Conference talks in person can be huge for getting attention. A well executed talk or shout-out at a strategic conference can be a huge win. On the other hand, online conferences and meetups have a much more commoditized feel. It's tough to stand out in the crowd, but still a great format for education, especially if the event will provide a video of your talk.
The beauty of doing small meetups, whether online or in person, is the high level of engagement and interaction you can get. You might only be able to talk to ten people, but maybe you help them in a way that completely changes their career trajectory.
Live streams on Twitch are very short lived but great for building community goodwill and relationships. YouTube offers a modicum of durability but not much. Streams get rewatched if the content or host is good enough and has a fan base.
Video courses or YouTube videos are fantastic for showing hands-on tutorials or explaining something in a way that documentation doesn't quite nail. They do have a long maintenance cost similar to written tutorials, though not quite as hefty because there is a certain expectation of an "expiration date" for videos.

Knowing this, you can tailor your strategy according to the problem you’re trying to solve or the feature for which you’re trying to create awareness. Is there a specific audience that cares about this fix? Get on a podcast to talk to them. Did a new feature roll out that is wicked cool? Make short demonstration videos and longer tutorial videos along with a long form blog article that can serve as supplemental documentation.

Summarizing Our Strategy

Let’s review the steps to creating a personal dev rel strategy:

As you work through each step, take notes and think about how you might be able to improve in the next iteration. Even better, blog about the process! Imagine walking into a developer advocate interview and being able to say something like, “Over the last six months, I’ve been working on a personal developer relations strategy. I’ve created 12 pieces of content which have reached 15k developers. My work has also led to Feature A, Bug Fix B, and Docs Improvement C.” You will blow them away!

You can do the same thing with your boss if you choose to use the strategy to level up in your current job. If you’ve used the dev rel strategy for your day job’s product, you can basically say the same thing you would for the developer advocate interview. If not, focus on how you’re building influence and leadership in the larger developer community. The more valuable you are to the larger community, the harder a good company will try to keep you! If they don’t care about keeping you, then you’ve already built yourself a reputation to find your next job.

For more resources on dev rel, content creation, and customer research, check out the resources page for Getting Started in Developer Relations.

This article was adapted from a chapter in my book Getting Started in Developer Relations. If you're looking to break into Dev Rel, give it a look! It's helped lots of people make the leap.