What is Developer Relations?

The simple answer is that Developer Relations is a discipline focused on ensuring developers have a great experience using and building with your product. From the moment that they hear about your offering, through the sign-up process, learning, building, deploying, and all the way through to support and a sense of belonging to a community, being heard, recognized, and accomplishment of their goal.

That’s great, but how does it really break down? Sometimes it is easier to thing of Developer Relations as it relates to other parts of your organization that are involved in bringing a product to market. If you think of Developer Relations on a spectrum, it might sit somewhere like this.

I believe great Developer Relations teams are more closely aligned with Product Management than traditional Product Marketing. Why is this? It comes down to motivations: Developer Relations is motived to ensure developers have a great experience and can build with your product or platform; Effectively, they are the conduit between awareness (Product Marketing) and usage/enablement/adoption (Product Management). In this way, Developer Relations are uniquely positioned within your organization. Aligning Developer Relations too closely with Product Marketing can result in too heavy a focus in sales/revenue orientated activities, and the inverse with aligning too closely with Product Management can result in not being aware of product/market fit, competitors, or the importance of growing brand awareness.

I frequently get asked the question whether Developer Relations should roll up to Marketing or Product. In my experience, despite what I just said about aligning more closely with Product, I believe the best place for Developer Relations to live is within Marketing. The reason for this is that no matter how much, or how good, your content is, without Marketing’s ability to amplify your message and reach developers across channels: blogs, events, websites, etc, your community will not grow. Being part of Marketing doesn’t mean you should adopt a sales/revenue mindset though. Take the time to define your own KPIs and ensure that the CMO recognizes these as important drivers for the business.

Developer Relations Team Structure

An ideal structure to your Developer Relations team consists of three focus areas:

1. Developer Advocates

   1. The Developer Adocates are the technical professionals responsibile for direct interaction with developers. They write blog posts, code samples, respond to questiosn on discussion forums, and present at conferences and webinars. In addition, Developer Advocates work closely with Product Management to provide very early product feedback, conduct firstlook hackathons, and provide a conduit for feedback from developers in the community. Very often I see job listings for Developer Evangelists rather than Advocates. To me, an Evangelist is a one-way interaction: go out and preach your product in an effort to convert (increase signups) developers. An advocate on the the hand is much more bi-directional: they focus on helping developers be successful beyond signups to include enablemennt, retention and advocacy.

2. Community Managers

   1. Community managers are critical in ensuring a vibrant developer community. They are responsible for moderating discussion forums, identifying champions in the community and rewarding them, organizing meetups and user groups, and being the first-line of support. A great Community Manager is worth their weight in gold as they can turn a static, disconnected group of developers into a community that supports one another and grows organically.

3. Developer Marketing

   1. Developer Marketers are all about reach and expanding awareness. Whilst they are very similar to Product Marketing in activities - demand gen, retargetting, running webinar series, web site assets etc - Developer Marketers use more action orientated approaches. By this I mean content can be used to help developers use a new feature or product vs. awareness of a new feature of product. In addition, Developer Marketers have a much more deep understanding of the developer journney to enable them to create on-boarding nurture flows, learning paths and more. A good Developer Marketer may have been a Systems Engineer or other technical role previously.

Depending on the size of your company, your Developer Relations team may not be individual people in each role described above. I have often seen Developer Relations teams that rely on Product Marketing and Demand Gen teams. Where this structure has worked is when you have a dedicated person responsible for measuring the success of the developer experience. This can be achieved by clearly defining Developer KPIs across the developer journey and using this help prioritize requests of external Product Marketing and Demand Generation teams.