Lead image for Finding and Hiring Developer Relations Professionals

Finding and Hiring Developer Relations Professionals

To say that Developer Relations is booming is an understatement. 

Half of all DevRel programs were instituted less than two years ago. A quarter of companies doing DevRel have multiple programs active and 33.5% of these companies aren’t even what we think of as traditional “technology” companies.

It seems that any business with a connection to third-party developers is considering a DevRel program. On top of that, Developer Relations requires a unique set of skills that are difficult to develop quickly. This has led to a scramble for scarce talent when it comes to hiring DevRels.

As a former engineering manager and CTO, I can empathize. Hiring engineers in a competitive market was tough and the job market almost always felt painfully lopsided. In this piece, I’ll outline a framework for hiring developer relations professionals with insights drawn from other leaders in the space. By the end of this, you should have a good sense of what DevRels commonly do and how you can source and attract the best ones to your organization.

Are You Ready to Hire a DevRel?

Before you start your search, you should consider whether you genuinely need one and where they’re going to fit into your org.

Developer relations covers a vast multitude of activities which are almost never done by the same person. Your DevRel could be anything from an evangelist to a community manager, a technical content creator, or a support liaison. 

Source: State of Developer Relations Report 2022

If you want your very first hire to be an “all-purpose” DevRel or you want them to figure out the mix of activities themself, you’re setting them up for failure. Qualified candidates will actively avoid companies without a clear goal and plans to execute DevRel.

Josh Dzielak, Co-Founder and CTO at Orbit, says as much in his blog:

“Your first DevRel should scale what’s already working, not completely start from scratch…DevRels put their reputation on the line for the companies they represent, and companies with no history of participation represent unknowns and risk.”

Before you actually hire a DevRel, founders or executives should spend some time doing the job themselves. This will give you a sense of what works in the space and save you a ton of time and money later.

Defining Scope of Work and Success Criteria

The more specific you can get with your DevRel job description, the more likely you are to find the right person. 

You’re also going to have to find the right metrics to measure their success. This tends to be a particular problem, as Shawn Wang, Head of Developer Experience at Airbyte, points out in his excellent blog post

“I’ve been asked to measure all these in my work: GitHub stars on my demos (yuck), traffic attributed to my Google Analytics UTM tag (yuck yuck), number of badges I could scan at a conference (yuck yuck yuck). All well intentioned but ultimately not meaningful, because they value quantity over quality, breadth over depth, free-and-superficial over paid-and-indicating-serious-interest.”

Here’s a more systematic way to go about it: 1) list the activities you want your DevRels to perform, 2) set logical targets for those activities, and 3) work out how many people it’s going to take to perform those activities. 

Typically, DevRel tasks can be categorized into three buckets: Content, Community, and Code.

1. Content

Content is a cornerstone of developer relations. In fact, according to the State of Developer Relations Report 2022, the primary challenge for DevRel programs today is keeping up with “continuous content creation.”

Adam Duvander, Founder at EveryDeveloper, puts it like this:

“Imagine a room full of developers, ready to hear your conference talk. How many are in the audience—50? 100? 500? As awesome as web development is, there’s a natural cap to who can hear your message in person.

A blog post can garner the same attention month after month. If you are strategic about what you publish, your content will attract even more developers.”

Developer-focused content tends to be very technical and edges up right against the documentation world. Everything from use cases to integration tutorials, implementation guides, FAQs, and support collateral are useful content assets. 

It’s not unusual for companies to have multiple full-time DevRels just for content creation. Alternatively, you can have someone set content strategy internally and outsource the writing to a specialized agency.

Content Metrics:

  • Pageviews
  • SERP ranking/domain authority
  • Newsletter signups
  • Product demo/trial signups

2. Community

If you don’t have a way to reach your developers, the rest of your DevRel program doesn’t amount to much. 

Community engagement can take different forms. Online forums like StackOverflow, Reddit, Hacker News, YouTube comment sections, and various Slack groups are typically where developers will have discussions that shape opinions and behaviors.

Your DevRels absolutely have to be there in order to influence, but also to engage with and collect feedback from the audience. The thing about online communities, though, is that a) they’re vast spaces and b) the discussions aren’t instantaneous. This means that if community momentum is important for you, you’ll probably have to devote full-time technical community managers to these forums.

The other place community interaction can happen is at conferences and in-person events. Here the conversations tend to be rapid and robust. Companies typically deploy Developer Evangelists at these events to speak, persuade, and to listen.

The trick is to let the excitement of an event bleed into online forums later, where the discussion about your product is kept alive and you can hype up the next event you’re organizing. This sort of operation requires deep coordination within your DevRel team.  

Community Metrics:

  • Members in Slack/Discord
  • Number of weekly new topics in StackOverflow/GitHub Discussions
  • Attendees at events and talks
  • User contributions (content/community responses) 
  1. Code

Code- or product-focused DevRels can bring tremendous value to both the community and their company. For instance, in the lead up to a product launch, you might see them beta testing the product, often in association with users, or creating interesting demos around the application.

Frequently, they’re also responsible for non-core integrations and developer support. At SendGrid, for instance, Developer Evangelists are custodians of all their official API wrapper libraries and open source documentation. 

As part of these activities, DevRels are also well placed to funnel user feedback back to the product teams.

Code Metrics:

  • Open source code contributions
  • Number of user issues funneled through DevRel
  • Monthly users of product/integrations
  • Launch day users and mentions

Finding DevRel Professionals

Developers, especially senior ones, rarely spend time browsing through run-of-the-mill job boards, even though they may well be open to a career change. You have to reach out to them where they spend time.

1. Look to Promote from Within

Companies tend to underestimate how big a role product and organizational familiarity can play in the success of a DevRel. 

Often, the ideal candidate can be found among the ranks of your own engineers and technical leads. Similar employees like solution architects and sales consultants who have technical backgrounds and direct experience working with customers can be good choices as well.

This is a good way to make your first DevRel hire for a number of reasons: a) there’s less of a learning curve involved, b) if they don’t enjoy the experience, you can always transition them back to core engineering, and c) it establishes a starting point that newer hires can scale from.

2. Consider Champions Among Your Customers 

You don’t want to make a habit of poaching engineers from your customers. But the fact is, a developer who has argued for your product at their company and can identify with other users of your product is really the perfect candidate. 

And frankly, you’d be surprised how often this kind of thing happens naturally. Big champions of a tool will leave their company for the tool because they see more potential in that product than their current role.

3. Look for ‘Non-DevRel’ DevRels

You’ll often come across engineers who are doing DevRel activities like creating content and speaking at conferences without actually being a DevRel.

Keep an eye out for these people as you browse through blogs and videos and ask them if they’d like to make a job out of it. Relevant HN bloggers, Twitter influencers, YouTubers, and Slack contributors can all be good candidates.

4. Use Specialized Job Boards

If you’ve hired other developers, you’ll know this. LinkedIn and similar job boards are simply not the right places to look for a DevRel. The space is big enough now that there are specialized job boards that cater to DevRel careers. Whether you’re looking for a Developer Advocate, Technical Writer, Community Manager, or Documentation Engineer, you’ll find one there.

5. Talk to Your Content Partners

One of the more creative ways to discover “hidden” candidates is talking to business partners like your technical content agency. At Draft.dev, for instance, we work with over 300 software engineers to create authoritative developer-focused content. 

We don’t mind making introductions that benefit both our clients and writers. In fact, for clients who need less than a certain volume of content, we often refer them to freelance writers anyway for scaled-down service. 

Hiring DevRel Professionals

Once you have a list of applicants for the role, you’ll need to start filtering through them to make hires. 

You’ll want to get this right since your first few DevRels tend to set the tone for the whole team. Moreover, they’re expensive to hire. The median base salary for a DevRel is a little more than that of a senior developer in the U.S. — $148,105. 

Step one is outlining the necessary values. Some of the best DevRels I know aren’t necessarily great engineers, but they do have these qualities:

  • Empathy
  • Passion for sharing knowledge
  • Willingness to learn new technical topics

Check for value-alignment as you hire your candidates. Make sure you use a process to do this so that you can test them objectively and standardize the quality of your hires.

Here’s a process that I’ve used to recruit a number of developers over the years as well as one that we’ve used to hire over 150 people at Draft.dev:

1. Transparent Job Description

By now you will have set out your DevRel expectations. List them out in as much detail as possible in the job description. At Draft.dev, we also make it a point to publicize the salary for every role so that candidates can decide at the outset if it’s a fit for them or not.

2. Preliminary Screenings

Initially, you’ll want to screen applicants based on their resume. I recommend asking the remaining ones to remotely complete a mini-assignment that takes anywhere between 15-30 minutes. 

This will let you test a couple for the skills in the job description. For instance, questions such as how they’d react in certain interactions with product users can let you test for communication skills and empathy.

3. Technical + Cultural Interviews

A reasonable grounding in technical subject matter is essential for this job. After all, your DevRels will need to competently talk to users and address their questions.

Consider evaluating their experience with things like API standards and best practices, documentation, SDKs, general programming skills, and whatever else is necessary for your product and community. You’ll also want to test their soft skills and situational responses in real time.

4. Paid Trial

Finally, ask your top two or three candidates to complete a paid trial that mimics the day-to-day of the job. This will let them experience your work style first-hand and vice versa. PostHog, for instance, hosts what it calls a SuperDay, which is a paid full day of work at the company.

Provided your finalists make it through a reference check, you now have your first DevRels. Rinse and repeat for future hires. Don’t be afraid to experiment with your process either. The beauty of using one is that you have data that lets you improve the outcome each time.

Want to learn more about Developer Relations? Read more about it on our blog, and if you need compelling developer-first content as part of your DevRel strategy, schedule a discovery call with us today.

Karl Hughes

By Karl Hughes

Karl is a former startup CTO and the founder of Draft.dev. He writes about technical blogging and content management.