What is Developer Relations?

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

But how does that really break down? Sometimes it is easier to think 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 things on a spectrum, Developer Relations 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 are motivated to ensure developers have a great experience and can build with your product or platform. Developer Relations teams are the conduit between awareness (Product Marketing) and usage/enablement/adoption (Product Management). In this way, Developer Relations are uniquely positioned to other parts of your organization. Aligning Developer Relations too closely with Product Marketing can result in sales/revenue oriented activities, and the inverse with aligning too closely with Product Management - not being aware of product and market fit, competitors, or failing to grow brand awareness.

I frequently get asked, should developer relations roll up to Marketing or Product? In my experience, despite what you 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, webinars, 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.

Summary

Building great Developer Relations teams is not easy. I’ve spent over 10 years building teams with some of the best Developer Brands in the world: Salesforce, Heroku, BEA Systems, Twilio. My best advice is know as much about who your developers are: their background, motivations, and what they are doing on and with your products, and engage early. Listen more. You’ll learn something new, and gain more insight every day. No matter what size or phase your company is at, I’d love to help you build your community. Let me know how I can I help.