What is Developer Relations?

I've been in Developer Relations (DevRel) for nearly two years and recently I've been doing some thinking, career planning, reflection and such. And as part of that I've been doing some research on what others within the DevRel community do as part of their roles and their career paths etc. But I've also been doing some research with a wider audience and I found that some folks weren't sure what Developer Relations or had never heard of it. So I thought it would be good to give you my definition of it.

Especially as I'm not a developer, but an IT Pro! 😉

So what is it?

Developer Relations or DevRel as you'll sometimes hear it referred to is the department or umbrella term within a company that is responsible for helping to build a community and help that community. Under this department you'll find Advocacy, Events, Community Management, Content, Documentation and a lot more... And obviously every company will define their Developer Relations department differently, so it might not include all those things. 😉

Developer Relations is something that's relatively new, but when we think of technical community engagement it's been around since like the 50s or 60s. Developer Relations isn't trying to reinvent the wheel in that space, it's just trying to make it better. And as things evolve terminology has changed as well.

Again every company will have their own definition and goals for Developer Relations, but ultimately that department within the company should help to represent the external community, helping to give the feedback, concerns, suggestions that that community has back into the company to help make things better or understand where the education/content gaps are and improve them.

Connecting the dots essentially.

For me there are four key principles that Developer Relations should revolve around, and this is what drives me. Others in the Developer Relations space might be different.

Community - being involved, helping organise conferences etc

Awareness - helping to show the companies' product(s), mission and how those products can be used

Feedback - taking feedback from the audience back to the engineering team and vice versa

Education - helping audiences understand the companies' product(s) or even just understanding the industry and answering their questions

It's not sales or marketing

For me it's not about selling or about being a marketer. It's about helping people to solve their problems or understand the use cases of a product or technology. Developer Relations shouldn't be an extension of the company's sales team or marketing team.

Yes you can work with these departments within your company to help each other and offer suggestions to make everything better.
Again for me for a Developer Relations department to be truly successful, and trusted by the community it needs to sit separately from the sales and marketing departments.

Only for developers?

One misconception I've seen is that Developer Relations is only for developers and for me that's definitely not the case. Developer Relations is the industry term but it doesn't mean it's only about talking to developers. It's about talking to the community, the audience.

For each organisation that audience will be different. At some organisations it's only developers that they will talk to because the product they have is only aimed at developers. For an organisation like Microsoft though, which is where I work, the audience is quite extensive, covering developers, IT Pros, business decision makers, database administrators, and well everyone else within the IT department. 👍

It's ultimately about helping those that need help, regardless of their job title.

Advocacy

I've also seen a lot of confusion over what job titles look like in Developer Relations. Now there are a lot of different roles within Developer Relations, but you'll often see folks on Social Media and LinkedIn call themselves Cloud Advocate, Developer Advocate, Cloud Developer Advocate. Those to me, are all the same role but with different word combinations. 😊

These are often the folk that are most visible from a Developer Relations point of view, they'll be the people speaking at events, active on Social Media etc.

At Microsoft we have a lot of Cloud Advocates that are geographically spread out and cover a variety of subject matters.

Technical

Again another thing that has to happen for the Developer Relations department to be successful is to have people who have been there and done it, who are technical, who have experience of what they are talking about.

Some of the best Advocates I've seen help the community and be successful at their role are folks who have been in the IT industry for years and have experience of implementing IT systems, running them, building software etc. They know what they are talking about. They aren't just talking heads who are pushed out onto stage when the company want, they are they because they have the skills, experience and passion to be out on that stage.

But they also have to have the "soft skills" in their toolset as well. Being able to relate to people, talk to them and understand how to communicate the knowledge across. You don't need to be an extrovert but you do have to be able to interact with people.

Me as an Advocate

For me as an Advocate within a Developer Relations team, it can be hard sometimes as I'm not a Developer, I'm a Sys Admin/IT Pro/Operations person so it can be tricky trying to explain to people what my role and why I'm under that Developer Relations umbrella. But for me I do this role because I want to help people, make their lives easier if I can, even if that means taking hard feedback back to our engineering teams. My job isn't to sell, it's to help.

It can be a LOT of work to create content, people don't see the hours spent in meetings, Camtasia, PowerPoint, Word, Photoshop, Premiere Pro that are required to write that blog, create that video, or create that Twitter thread. Some weeks I do spend more time within PowerPoint than within Azure or doing anything "technical". But it's part and parcel of the job, and it's no less important than the technical parts.

If you are setting up a Developer Relations program, looking to make a career move, or need to do some research to achieve corporate buy-in for Developer Relations department inside your organization, pick up a copy of DevRel for Beginners: What to Know and How to get Started.