DevRel: Marketing, Product Management, Or Neither?

How do you talk to a developer? Let’s say you are building a tool you’d like developers to use. For your tool to be successful, it must be widely adopted and it would be nice to build a community around it. So whose job is it to tell the target audience that the tool exists? Is it a marketing person? Do you just trust the GitHub community to carry the message? Do you just need to find the right Slack to hang out in?

The latest monthly Influence Marketing Council call was joined by Matthew (Brender) Broberg and Mary Thengvall. Our topic was developer relations, community and open source, and we veered onto an incredibly important topic: is developer relations a marketing function or a product development function. Where in the organization should it be, and why does it matter?

I had never given this a moment’s thought before, although I have at least three friends who actually hold the job titles of Developer Relations or Developer Program Manager. Their jobs, clearly, are to cultivate developers so they will be inclined to use a platform or tool, create value for the tool, or speak well of the organization. But where do these people reside in their organizations?

More than just about anything else I’ve heard lately, this question is answerable only by “it depends.” When you look at enterprise or startup org charts, DevRel can be anywhere.

Why is this important? Because if you are talking to developers, you will be questioned about it in accordance with where you falls on your organization chart. You see, developers really don’t enjoy being the targets of marketing, especially when done by non-technical people. They really would like to speak only to other engineers, who have difficulty getting themselves out in the community to talk to people; they’re too busy solving problems. Engineers are judged by code.

Most developer relations programs wrestle with where they belong inside the organization. Should they be in marketing? It could make sense to live alongside the marketing funnel for awareness and adoption. And after all, marketing already has a big budget for events and sponsorships and t-shirts. Or should developer relations live in the product organization, where the technical expertise lies, and where the dev experiences, feedback and questions sourced by DevRel are invaluable?

And does DevRel’s location in the org chart determine how we measure it’s impact? Can its work be measured at all? Executives need to understand how DevRel is connected to the rest of the business and what is its ROI if it is theoretically developing business but not developing leads.

On the call today one enthusiastic member threw a grenade into the discussion by saying that developer relations wasn’t its own thing, but was a temporary way station for organizations that needed to modernize their product development practices into a customer-focused operation.

His theory was that DevRel has been thrown into a temporary silo while it waits for the modernization of product development in the same way social media was tossed into a temporary silo while waiting for the organization to modernize its marketing practices.

I am old enough to remember the day when product development was considered part of marketing. Personally I’d like to see those disciplines come closer together again. Until then, DevRel will have no permanent home.