Hello there, I'm in DevRel, nice to meet you! I used to do dev for a lot of years, and I liked blogging on the side and writing about things I was learning. I didn't even know that could be a job, it was just something I did for fun because I liked writing and I liked coding and building web apps.
Eventually I found a team that would let me do that full time. So my company would pay me to check out new releases, provide feedback, and try to find a way to explain what was good about the product for other developers. Let's say a release had a new API, I could build an example and make a video about it or a blog to help somebody understand how they could use it to do something for their work.
Anybody could do that, but people that aren't a DevRel for the company have to have the skills and the time to figure out the thing and then show others.
Over time, like Vera said, there have been a lot of specializations. At one point, myself and my other team members were helping sales people understand the products, helping product marketing understand how to position the product to a technical audience, helping developers understand how to use the product, filming and editing videos, writing blogs, running events, presenting at meetups... It was a lot!
To your point, anybody can do advocacy for a product. If you've ever written a blog article that helped somebody understand working around a common issue in installing something, or answered questions on StackOverflow, or presented at a meetup, then you are doing the things somebody in DevRel might do. Somebody with that role just gets paid to do that. Not all DevRel folks used to be devs, or have dev backgrounds, but it's pretty common.
Sometimes DevRel is:
Education/Enablement (helping people do things)
Marketing/Company advocacy (telling others how great something is)
Community building (bringing devs that use a thing together)
Product feedback (being the first customer)
Developer Advocacy (telling the company product team what devs are saying and need)
[Probably many other things]
DevRel roles are not meant to stop other people from doing things. It's to give people who want to do those things a pay check to do what they love doing already. For me, that's focused primarily on helping others with whatever they happen to struggling with!
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Thanks for that. I think what I lack in clarity is the idea of "helping other developers". I'd always seen this as meaning, helping other developers in your team or company, and devrel seems to be more about helping customers whose interfact with your company is through an API or similar.
There are also people who focus on internal developer experience (how do devs inside the company work, what are their pain points, what can be done to make their workdays easier). I have somebody on my team that is focused on the strategy for that, and they work with the various teams in the company to help identify how they can help the teams.
So, in general, a given person in a Developer Relations role usually has a focus (an audience, if you want to use a marketing term). Your goal is usually to understand the problems that developer faces, and then figure out how you can best help them.
If I use my own company as an example... there are a bunch of developers that work at agencies. Companies buy our software, and those agencies implement it for them. Building websites, apps, marketing automation stuff, integrations... whatever it happens to be. So those developers have to know how to use our APIs, how to use the platform, sometimes how to host or install software. So if we are trying to help those people, the helping would look like how do we make their jobs easier to do? How do we show them common things they'll run across when building? How do we help connect them to each other so they can help each other with their experiences?
Other companies might be different. They might only have developers that are in fact the end customers themselves. Vercel and Next.js is a good example. Nobody is buying Next.js as a framework, but the 'customers' are the developers using the framework. The Next.js DevRel folks can help developers understand how to use Next.js features.
I think, by and large, a lot of DevRel teams are primarily external facing because that is seen by companies as the most beneficial investment towards the bottom line. It's not the only thing, though. Each company has their 'need' at a given time. It might be making the experience better, or building starter kits, or writing documentation, or building tutorials, or making videos, or helping internal staff to do their engineering more efficiently. It's often a role that is heavy on communication skills and being able to learn things very quickly and then explain them to others.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello there, I'm in DevRel, nice to meet you! I used to do dev for a lot of years, and I liked blogging on the side and writing about things I was learning. I didn't even know that could be a job, it was just something I did for fun because I liked writing and I liked coding and building web apps.
Eventually I found a team that would let me do that full time. So my company would pay me to check out new releases, provide feedback, and try to find a way to explain what was good about the product for other developers. Let's say a release had a new API, I could build an example and make a video about it or a blog to help somebody understand how they could use it to do something for their work.
Anybody could do that, but people that aren't a DevRel for the company have to have the skills and the time to figure out the thing and then show others.
Over time, like Vera said, there have been a lot of specializations. At one point, myself and my other team members were helping sales people understand the products, helping product marketing understand how to position the product to a technical audience, helping developers understand how to use the product, filming and editing videos, writing blogs, running events, presenting at meetups... It was a lot!
To your point, anybody can do advocacy for a product. If you've ever written a blog article that helped somebody understand working around a common issue in installing something, or answered questions on StackOverflow, or presented at a meetup, then you are doing the things somebody in DevRel might do. Somebody with that role just gets paid to do that. Not all DevRel folks used to be devs, or have dev backgrounds, but it's pretty common.
Sometimes DevRel is:
DevRel roles are not meant to stop other people from doing things. It's to give people who want to do those things a pay check to do what they love doing already. For me, that's focused primarily on helping others with whatever they happen to struggling with!
Thanks for that. I think what I lack in clarity is the idea of "helping other developers". I'd always seen this as meaning, helping other developers in your team or company, and devrel seems to be more about helping customers whose interfact with your company is through an API or similar.
There are also people who focus on internal developer experience (how do devs inside the company work, what are their pain points, what can be done to make their workdays easier). I have somebody on my team that is focused on the strategy for that, and they work with the various teams in the company to help identify how they can help the teams.
So, in general, a given person in a Developer Relations role usually has a focus (an audience, if you want to use a marketing term). Your goal is usually to understand the problems that developer faces, and then figure out how you can best help them.
If I use my own company as an example... there are a bunch of developers that work at agencies. Companies buy our software, and those agencies implement it for them. Building websites, apps, marketing automation stuff, integrations... whatever it happens to be. So those developers have to know how to use our APIs, how to use the platform, sometimes how to host or install software. So if we are trying to help those people, the helping would look like how do we make their jobs easier to do? How do we show them common things they'll run across when building? How do we help connect them to each other so they can help each other with their experiences?
Other companies might be different. They might only have developers that are in fact the end customers themselves. Vercel and Next.js is a good example. Nobody is buying Next.js as a framework, but the 'customers' are the developers using the framework. The Next.js DevRel folks can help developers understand how to use Next.js features.
I think, by and large, a lot of DevRel teams are primarily external facing because that is seen by companies as the most beneficial investment towards the bottom line. It's not the only thing, though. Each company has their 'need' at a given time. It might be making the experience better, or building starter kits, or writing documentation, or building tutorials, or making videos, or helping internal staff to do their engineering more efficiently. It's often a role that is heavy on communication skills and being able to learn things very quickly and then explain them to others.