Laying the Groundwork for a Successful Developer Relations Hire

One of the most common questions we’re asked by founders and execs is “When should I hire my first developer advocate?” This is no surprise to us. More and more companies are developer-focused, or at least offer an API, and have come to grips with the fact that marketing and sales aren't the right tools for driving product or platform adoption. That’s why we say software is adopted, not sold.

Jobs in developer advocacy, evangelism, and community are more in-demand than ever, attracting and retaining a developer advocate is less about stats like funding or company size, and more about organizational readiness.

Before you ask, “When should we hire a developer advocate,” we recommend asking “Are we ready to hire a developer advocate?” The latter question will help you focus your efforts through understanding what kinds of activities will impact your business the kind of person you should attract.

Before we dive in, let’s clear the air on role terminology. The titles developer advocate and evangelist are often used interchangeably, but developer advocate is the more modern choice and the one that we recommend. Developer Relations is the umbrella term for the team and a set of programs and practices. A “DevRel” can refer to anyone doing developer relations, be it a developer advocate, evangelist, or technical community manager.

So how do you know when your company is ready to hire your first DevRel?

Two ways to get ready

Before you make that hire, you should do two things:

• Do some DevRel yourself — by the time you’re ready to hire an advocate, your team has been doing DevRel activities for some time, ideally for at least a year
• Clearly define expectations — you know what type of DevRel you’re looking for and you have defined expectations and success criteria

Many assume the first step to hiring an advocate is to post the job description. But unless you’ve done DevRel yourself and have clearly defined the success criteria, you’ll experience at least two types of negative outcomes.

First, hiring will take longer than you expect, since your job description won't resonate with the right candidates and you probably won't have a good way to assess a good fit. As a result, you may never close a hire at all.

Second, if you do make the hire, burnout is infinitely more likely because the new advocate won’t get the support and understanding from the rest of the team that they need.

Want to avoid these bad outcomes? Let’s dig into each point to understand how you can avoid the common pitfalls of building a DevRel team.

Invest in DIY DevRel from the beginning

Today, here are far more DevRel job openings than there are people to fill those roles. One job board we track has more than 250 open roles at any given time. As a result, DevRel folks can be picky and deliberate about the companies they work for and the products they work on.

You will find it hard to hire a developer advocate if you haven’t invested in the role yourself.

DevRels are attracted to teams with a clear track record of valuing DevRel activities, especially when it’s clear that the founders are fully onboard. In fact, your first DevRel should scale what’s already working, not completely start from scratch.

Before you open that job req, consider how you can demonstrate that DevRel is already a priority.

That’s why our first piece of advice for founders on this point is to spend some time doing developer relations yourself. This is particularly true for technical founders. Yes, this can be a lot to ask, but we’ve seen the investment payoff in many ways.

First, you’ll know exactly what it takes to be successful in the role.

Second, you’ll have demonstrated to the DevRel community that you’re serious about investing in developer relations, which can help build confidence in and credibility for your company. DevRels put their reputation on the line for the companies they represent, and companies with no history of participation represent unknowns and risk.

Content and speaking

One way to start doing DIY DevRel is to get the whole company writing developer-centric content, especially the engineers. This includes defining and facilitating the content production pipeline yourself, or partnering closely with marketing to deliver a cadence of useful technical content.

You should also keep an eye on speaking opportunities for relevant audiences. Submitting “Calls for Proposals,” or CFPs, is a common task for many DevRels. Doing CFPs and speaking at events will not only get you in front of potential users, but also help you understand the processes and challenges your future DevRel will experience when they’re on the road.

Check out Tulula to find open CFPs.

Partner with companies that have more mature DevRel programs

Look for companies with complementary technologies and co-host events with them. This results in visibility for your brand, key learnings from the field, as well as intros to potential hires. These partnerships are a great way to bootstrap an early-stage program.

Content, speaking, and partnerships are important and visible aspects of a DevRel program. More visibility, for you personally and for the company, leads to more trust in the community—and trust plays a critical role in getting developers to adopt your technology.

In addition to seeding trust in the community, your hands-on role in these areas will create process and infrastructure for your new hire, while differentiating the role among a sea of other competitive openings.

Define and document success criteria

The second way to prepare for your first hire is to ensure you have clear expectations for the DevRel’s role and success criteria.

To do that, first determine the types of activities that will have an impact for your business. Code, Content, and Community represent three buckets of typical DevRel activities, and after doing DevRel yourself, hopefully you have a POV on which of those areas you want your new DevRel to focus on.

What kinds of outcomes in each area will impact your business goals?

What percent of their time and energy should your DevRel invest in each area to achieve those outcomes?

This exercise will help you avoid a common failure case: expecting one person to spend 100% of their time on all three areas.

Second, consider the DevRel archetype that will be most effective for your organization. Just as there are different types of PMs and different styles of marketers, there are multiple DevRel archetypes.

Here are a couple of the more common we’ve seen.

Focused subject matter experts

These folks are deep experts on a specific language, platform, and/or community. They tend to work alone in service of that community, though they’re very active in online discussions and in person. Not all developer advocates are developers, but the ones that fit this archetype usually are.

They tend to travel frequently to deliver talks in their area of expertise and present at meetups. They often generate a lot of content based on their learnings from the field and in the community.

Generalist force multipliers

This type of DevRel bridges the gap between internal teams and external users, and up to 50% of their job could be collaborating internally to help the company understand developers.

They create processes and programs to help engineers publish blog posts, help product teams get developer feedback, organize events, or manage and showcase the accomplishments of the community.

They are knowledgeable about the tech they represent, but are not necessarily a developer or an expert in adjacent technologies.

For any archetype, realistic expectations are key

There’s plenty of nuance to common DevRel archetypes, and this list isn’t exhaustive, but here’s the main idea: no DevRel can be successful if they’re expected to play too many roles. That’s a recipe for burnout.

Common Failure case: hiring for force multiplier, but evaluating success based on subject matter expert expectations, e.g. number of blog posts or lines committed.

Your job description should incorporate your expectations around activities and outcomes, and should highlight aspects of the archetype your company needs. And ultimately, once you make the hire, your reporting and goal setting should be based on the expectations you set.

Putting the groundwork in place

By following these steps, you’ll learn a lot about how DevRel can impact your business, and what’s necessary for program success. Along the way, you’re certain to learn lots about developers in your community, and even build some empathy for them as well as for your DevRel team.

Ultimately, you’ll avoid this common and tragic result: "We didn't really know what we expected, but it's not working out."