ARN

Should you work in developer relations?

If you love technology, learning, and meeting people, developer relations could be right for you. It’s definitely a job in high demand
Caroline Lewko (CEO - Wireless Industry Partnership)

Caroline Lewko (CEO - Wireless Industry Partnership)

If you read my recent scribe about feature flags, you will see that several of the companies mentioned seek to distinguish themselves by catering to developers. Vendors focus on them because developers have an outsized influence on what gets used in a company, whether it is a database, a feature flag implementation, or a cloud provider.

Because of the important role developers play in technology selection, software and service product companies are spending more and more on something called “developer relations.” For developers who like to talk, write, make videos, and do more than heads-down coding—it is a pretty good field to be in right now.

What does developer relations mean?

I spoke with Caroline Lewko, who is writing the book on developer relations. She explains, “Developer relations is everything that goes around supporting a developer product.” It incorporates marketing, documentation, product decisions, and community support.

Lewko’s co-author James Parton notes that “there’s a clear trend right now that lots of companies are either implementing developer programs or experimenting with developer programs. We have a term ‘developer plus’ for companies whose primary product is not aimed at developers.”

Different companies divide the developer relations in different ways, but Lewko and Parton note some of the standard components include:

  • Developer marketing includes outreach activities from a company’s website to its presence on Stack Overflow and SEO and paid advertising
  • Developer experience defines how developers are “on-boarded” to using a product. On-boarding includes everything from the documentation, to the tools, to FAQs. For a typical API-based interaction, developer experience emphasises self-service
  • Developer success focuses on ensuring that developers are successful with the tools and then expanding their use to multiple projects or requirements. Success is measured by developers looking at your product, activation, engagement, and retention

These activities support a community of developers that the company hopes to nurture, grow, and engage.

Am I in developer relations?

Not every company calls “DevRel” the same thing. According to Lewko, “The pieces of this may sit in different departments. Sometimes it is more marketing, sometimes it is more product, and sometimes more sales and sales support.”

Parton suggests a three-point test:

  • Is your target audience exclusively developers? Because if it is not, then already you are doing something that is not pure DevRel
  • Are your strategy and tactics designed to change developer behaviour? Meaning the focus is on getting developers to discover, adopt, and use your company’s product to develop and deploy software
  • Is the internal definition of success predicated on developers? According to Parton, “that’s obvious for a developer-first company, but not so much for a developer-plus company. If you’re not being measured on the success of developers and you’re being measured on something else, that’s a red flag.”

Why are companies investing in developer relations?

A lot of companies still spend much of their time targeting the C-suite or director/VP level. However, this thinking is almost certainly wrong. If you think about it, the “shoot for the top” approach seems a bit more widespread in technology than in other industries. A flooring manufacturer or plumber probably knows that the CEO of a Fortune 500 does not care which materials are used.

To a large degree, the C-suite is the economic buyer that comes in at the end and just asks why this one costs more than the other. Indeed, the cost question needs to be answered, but the bulk of a company’s efforts should go towards the people who ultimately use the thing. According to Lewko, studies from Evans Data Corporation (EDC) and others have reported that between 60 per cent and 80 per cent of developers either make or influence purchasing decisions.

What is the difference between developer relations and developer advocacy?

Everyone in developer advocacy is in developer relations, but not everyone in developer relations is in developer advocacy. Developer advocates, who embolise themselves with the avocado, vary significantly in tasks and focus. Not long ago, one developer described them to me as “those people who always try and talk to me at conferences.”

However, 2020 has seen a transformation of the role of the developer advocate just like everything else. The developer advocate position’s mission is to market to developers and explain developer concerns inside the organisation, especially to the product team.

How does developer relations differ from marketing?

Developer relations is marketing - to developers. Many companies have structured DevRel in a way that creates tension with the marketing department. Many developer relations or advocates feel that they are not in marketing, but activities, not titles, determine whether you are in marketing. Are you making webinars and videos, writing blogs, and going to events to influence people? Welcome to marketing.

According to Lewko, “The principals are the same. The piece that is different from the regular marketing process is developer experience. The other part is that there is more persona development.” It is crucial to understand and segment developer personas.

“That’s one mistake a lot of people make,” Lewko said. “We just need developers. They’re all the same, right? Well, no, they’re not, and whether there’s 20 million or 50 million of them out there, how many are actually the ones that you’re looking for.”

Developers differ on the types of companies they work for, cloud-based or not, languages or tools that they know and work with, and human demographics like their spoken language. Marketing to them requires understanding precisely who the audience is and messaging in terms they understand.

Who makes a good developer relations person?

According to Parton, “I think they self-identify quite easily. If they start spending a lot of time at conferences or meetups and self-financing their own trips, they’ve already kind of demonstrated a curiosity to meet other people in their community to learn.” Beyond that, giving talks, doing demos, and other activities to educate others is a good indicator.

“Certainly before and even more now online,” Lewko said. “If somebody does apply for a job, it’s like, okay, so how active are they on GitHub? How active are they on Stack Overflow? Are they actually answering questions and in whatever group it is that your company might be following. So it’s people that are actively engaged in supporting other developers already.”

Finally, Parton notes that good DevRel people have another important trait: “It’s easy to teach someone an API or a product. Everyone can learn that stuff. But it’s very hard to teach people empathy—to get enjoyment out of educating other people, be a natural kind of community person, and help other people.

That stuff is hard to teach if you want it to be authentic. So we’ve always looked for the softer skills. Obviously, these people have got the technical skills, and we believe they can be trained on the technical side, but it’s very hard to do the other way around and train the soft skills.”

Is developer relations a dead-end career?

Like software development itself, the DevRel path is a murky one. According to Parton, the book is necessary to help better document and professionalize DevRel for two reasons. “Number one is the field is quite transient. People come into it, study a couple of years, and then move on to get progression,” he said.

“Secondly, we want to help the practice get recognition and to be seen as a distinct thing from marketing. It allows those opportunities to kind of grow for people in these roles, rather than feel they have to move on to progress.”

I started out doing many of the tasks now considered “developer relations” before it was a dedicated field. I moved to the marketing side of organisations because I enjoy strategy as much as tactics and messaging as much as technology.

I also moved because there is a clear career progression path from manager to director to VP and CMO. Each step has implications on salary and on one’s focus (strategy versus tactics). Developer relations is definitely a job in high demand, but it remains to be seen whether it turns into a career in which one can progress.