How to get a job in DevRel

Author

More and more people are looking to get a job in DevRel. And for good reason. As a career, developer relations offers variety, meaningful work, and the opportunity to learn new skills.

However, it’s not always clear how to get a first job in developer relations.

Some of the challenges include:

  • hiring managers often want experienced practitioners
  • job titles can mean different things from one company to the next
  • knowing which mix of skills, technical or otherwise, a job requires
  • standing out from the crowd.

Here, we look at some of the ways you can navigate those issues and increase your chances of landing that first role.

Decide which job you want to do

Developer relations isn’t just one job. In fact, there are several roles that fit under the DevRel umbrella.

Knowing which role suits you best will make it easier to narrow down the jobs to apply for and also help you to prepare for the recruitment process.

So, what are your options?

Job titles are hard to pin down

The first challenge is that “developer advocate” and similar job titles are used as a catch-all. One company looking for a developer advocate might want someone who focuses on producing content, whereas another actually wants a support engineer, and a third wants an all-rounder.

It’s essential to look past DevRel job titles and understand what gaps the employer is hoping to solve. In most cases, the job description will tell you but, even then, it could take some reading between the lines.

The second challenge is that, even where a company uses a specific job title, they might have a non-obvious view of what that person should do. Community manager roles seem particularly prone to mismatches between title and role. Some companies hire community managers into field marketing, social media management, and almost every role other than actual community management.

Developer relations roles

Even if job titles aren’t always accurate, there are seven or so broad roles that tend to fall into DevRel teams:

  • Developer advocate: usually an all-rounder who acts as a public interface between developers and the company, which tends to involve doing a little of all the roles below.
  • Developer evangelist: this can be interchangeable with “developer advocate” but some people use this to describe a role focused on awareness building.
  • Developer marketer: looks after the developer journey, messaging, segmentation, research, campaigns, and other traditional marketing activities but focused on developer audiences.
  • Developer educator/technical writer: produces educational, technical marketing, and other content to enable developers.
  • Community manager: ensures the smooth running of the developer community around a product or project.
  • Developer experience engineer: focuses on sample apps, SDKs, and other development that helps people to use the product.
  • Developer relations lead: sets the strategic direction for the team, acts as the face of the team within the company, and takes care of day to day management.

Larger teams will often have more specialised roles and more hierarchy than smaller teams. Some roles might perform a DevRel function but exist in another team, such as the marketing department.

Similarly, there are non-DevRel roles that contribute to a DevRel strategy. For example, an API product manager will work closely with a developer relations/experience team but could be located just as easily within or outside the DevRel team itself.

For your first role in developer relations, it’s best to go after opportunities that match your existing skills and experience. And that brings us to a question that many DevRel job seekers have asked themselves.

Do I need to be a developer to work in DevRel?

Do you need to be a developer to work in developer relations?

The answer isn’t as simple as “yes, you need to be a developer” or “no, you don’t”.  Instead, it depends on:

  • which DevRel job you want to do
  • what the company you’re joining wants from DevRel
  • the culture of the technical niche your product operates in
  • the other skills you bring to the table.

For example, a developer advocate working on an IDE aimed at C++ developers almost certainly needs to be an experienced C++ developer in order to have credibility within their target community. On the other hand, a developer educator creating tutorials for a CI/CD tool needs to understand the process of building software and must be able to have in depth conversations with subject matter experts but they don’t necessarily need to be a developer.

Perhaps a better question is: what level of technical experience do I need to work in developer relations?

We can answer that with a scale of technical expertise:

  • Experienced developer with credibility in a technical niche: developer advocates working in a specialised technology space
  • Confident developer who can learn new things quickly: developer advocates working on most products
  • Reads code and understands the detail of the technology space: developer educators/technical writers
  • Understands the detail of the technology space: developer marketers and DevRel leads
  • Understands broad concepts related to the product: community managers

The correlation between level of expertise and job title is going to vary from company to company and between individuals. Nonetheless, everyone working in DevRel should understand broadly what the product does and how it compares to alternatives but not everyone needs to be a developer.

Let’s take a moment to consider why this is important. Developer relations relies on:

  • credibility with developer audiences
  • empathy for developers and their work.

So, for the people who engage with developers on the most technical level — i.e. developer advocates — then their credibility depends on being developers themselves. Developer marketers and community managers, for example, bring different skills to their roles and are not expected to have deep developer experience. Nonetheless, a developer marketer must know enough to create messaging, segmentation, and journeys that resonate with developers and community managers should understand the technical motivations of their community members.

Google’s Head of Global Developer Programs, Uttam Tripathi, puts it like this:

Successful folks in DevRel bring a lot of empathy for developers. Focusing on how one can make the developer successful and keeping the developer’s interest first. Deep understanding of not just the technical details of the API/Platform but also perspective on potential use cases developers are likely to use.

Understanding the overall developer landscape and trends also helps folks be successful in DevRel roles. In addition to being the external advocate for the platform one is representing, it’s also important folks in DevRel are strong advocates internally and the voice of Developers within the company – influencing product roadmap.

Standing out from the crowd

Hiring managers often seem to be looking for experienced developer relations professionals. So, where does that leave you if you’re aiming for your first DevRel job?

As with every aspect of finding a job in DevRel, a lot of this depends on the specific job you’re going for.

Slack’s Director of Developer Relations, Bear Douglas, offers some reassuring advice when it comes to how much of a portfolio you need:

To make it past a resume screen, it can really help to attach a technical writing sample. If you’ve never done DevRel before, I wouldn’t necessarily expect that you have a substantial open source profile or highly visible community presence– but even attaching an answer you wrote on StackOverflow can help a hiring manager get a sense of how you communicate and engage with people outside your company.

Hashicorp’s Vice President of Developer Relations, Adam FitzGerald, emphasises having an authentic passion for technology:

For me, Developer Relations is primarily about trust.

Technical people build trust over time by repeatedly using a tool, product or platform that is predictable, delivers exactly what it promises and removes cognitive load for the user. That means if you want to work in developer relations you need to be willing to build trust with this technical audience. If you are a passionate user of that technology, that is a really good starting point and automatically helps build trust with other users.

You don’t have to be an over-zealous fan-boi or fan-gurl, because trust is also built through listening to users, empathizing with them and being honest about your technology’s short comings. But your authentic passion for a technology will be detectable by others that you talk to – without it you will sound like a snake-oil salesperson.

So, take a look at the tools you use or the technology that you admire and imagine yourself advocating for it’s adoption within your team, at your company or with one of your developer friends. If you can imagine yourself doing that, then you can probably work in Developer Relations for the company behind that technology.

If you don’t have professional DevRel experience, then you need to find other ways of demonstrating that you have the potential to grow into the role relatively quickly.

Build a portfolio that demonstrates your suitability for the roles that interest you. Become familiar with how different companies do DevRel and be able to talk about how their strategies and tactics differ from one another. Read blog posts, watch DevRel videos, attend events, and ask existing DevRel people for advice.

Further reading

Make sure you know your DevRel fundamentals and then take a look at these blog posts and videos: