Is it true that only giants should invest in a DevRel team? The answer is becoming clearer than ever that it is "no".
And the reason for this is that smaller companies, startups, and medium-sized businesses, more than large corporations, need to connect with their user base and partner with them.
But, what exactly is DevRel?
Developer Relations (DevRel) is a mindset that aims to get developers to adopt a platform or technology and succeed in their professional lives or side projects.
To ensure the success of Developers with your product, you need:
- Existence of market fit
- Developers know how to use it
- Developers enjoy using it
So, if you have a ten-person startup, why should one of them be a DevRel expert? First and foremost, because you are most likely still developing your product and want to shape it to meet the demands of developers, you should have someone form relationships with that audience, solicit input, and influence your product roadmap. Aside from that, receiving feedback from the field and demonstrating market fit will help you** gain investor confidence**.
After you've established market fit and made your product stand out from the crowd, you'll want to make sure you give your developers an exceptional Developer Experience. So, in addition to the product's usability, it's critical to develop tools that help your Developer be more productive with your product - how-tos, tutorials, sample code, training, and so on. tutorials, sample code, training, and so on.
However, productivity isn't always enough to keep developers on board. They must also like using your product and be able to brag about their achievements to their peers. With that in mind, "Community" is another pillar DevRel provides that can help a Startup succeed.
Building a sustained and vibrant community can help developers form an emotional connection with you and provide the resources they need to succeed, such as a network of like-minded individuals who can help them unblock when they get stuck. When they become fans, they will tell the world how they feel about you and your product, and they will help you raise awareness among the developer community throughout the world.
In conclusion, DevRel can assist with the following high-level business objectives:
- Confirm Market fit
- Shape product roadmap
- Raise awareness and drive adoption of the product
- Decrease time-to-deployment/time-to-revenue (productivity)
- Expand your support efforts
Finally, DevRel stands for intensive relationship management and should not be viewed as a sprint but rather an endurance race. The successful build-up of Community and networking in the developer scene requires a long-term, sustainable strategy and a great deal of energy and repetition. Winning over depends on good ideas, suitable content, holistic support, and follow-through.
Top comments (9)
I have no idea what devrel is, despite talking to various people about it over the years.
Some have resorted to calling me an idiot for not understanding.
Do you mean it's something like a company trying to sell you (the developer) on using their great new piece of software? That sounds more like an advert to me!
I believe many developers feel Developer Relations professionals are "sales" people, but I have a different opinion. I see them more like enablers or educators.
Can you give me an example? Like, who are they employed by, what do they actually do? Every example I've heard is better described with a different job title - like "educator"? That's really vague.
If it's technical education, then that's the job of a training company, and the "devrel" person would need to be an expert in whatever field they were teaching - e.g. they'd be a React tutor or something. If it means "educating people about the market", they'd be some sort of business person. If it means some kind of social education, they'd be... I don't know, some kind of social expert.
But those are established jobs, why would they need a new name? And if the idea of devrel is that they're people who can hop between a lot of differnet things, like teach ettiquette one day, Redux the next and how to use your timesheet software the next, wouldn't that mean they were spread so thin they'd be, like, a master of none? Why would you want your React course taught by someone who didn't fully understand it?
So a DevRel professional is usually known as someone who plays the role of public relations for the company, bringing the developer closer to the product/service.
But they also perform activities common to any developer, such as coding and testing (being the customer zero), writing documentation, sample code, etc.
And, on top of that, the same person can also give workshops and talks to educate developers on how to use a specific tool.
This is a lot for a single person, that is why I'm seeing the evolution of specializations in DevRel. This is a slide I presented at DevRelCon last year:
Thanks for the response
So I guess I see those slides and understand "dev marketing" as maybe writing a blog post about how nice your company's new API is.
I don't really get the other cards, though. Evangelism? As in advertising your company? Developer advocacy doesn't mean anything to me - is it about maybe saying to your company, "we got a lot of complaints from users of our API, maybe we should update it?"
Developer experience - is that internal to the company, as in, asking management for better monitors on our behalf?
Community management implies there's a community, but communities of developers are all external to the company (unless you're the size of Microsoft or similar), so that's all done with places like DEV, or local meetups back when local meetups were a thing. You wouldn't look at a team of five and call it a "community" so it's not going to be in-house.
I guess what stumps me is that all of these things are things that developers and project managers and anyone in tech does already. I don't see the benefit to making it one person's job - you're not going to stop people going to their own meetups, for example.
Could you give me an example of something a DevRel might do on a normal day, like, "interact with someone in this company and proxy their problems to someone in this other company"? Do DevRels even interact with developers or is it the equivalent of tech companies' social media accounts which are run by people employed to run social media accounts but who otherwise aren't involved in any of the tech?
I'm the Dev part of DevRel and I've never (knowingly) met a DevRel in real life!
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.
I try to answer this in dev.to/jpoehnelt/what-is-devrel-lcp based upon my role as "Developer Relations Engineer" at Google.