You might have come across the term developer relations already, if not, you’re likely to encounter it sometime soon, especially if you work on a software product aimed at developers. Although the core disciplines in developer relations are not entirely new, as technology products whose users are developers become more widespread, a range of new specialisms is growing around the variety of touchpoints those users are accessing. From Developer Experience to Community Engineering, the tech industry is becoming more intentional about how we engage with developer users.
Who “does” developer relations (dev rel)?
Job titles such as Developer Evangelist and Developer Advocate are among the most common specialties in this emerging field, however many more roles are involved—some entirely embedded within developer relations, and some overlapping with other activities such as product management, marketing, sales engineering, and so on. With no real established standard for delivering these services, you’ll find some people in dev rel are doing the same job with a different title, or have the same title but do different jobs.
People in dev rel roles carry out a lot of tasks you might associate with other more well established roles: they write documentation, create code samples, run webinars, give talks, capture feedback, handle support requests, moderate forums, etc. Some larger tech companies such as Google, SAP, and IBM have whole teams of developer relations people.
Dev Rel roles tend to fall at the intersection of a few traditionally disparate skillsets—part developer, part something else. As Developer Educator at Dropsource, this tendency has mirrored my experience throughout my career in tech—I enjoy coding, but have always been more interested in the learning process associated with it. In this post I’m hoping to outline some of what I’ve learned about developer relations over the past few months, and share our current thinking around what relevance this field has to our user base and the future of our product.
In December 2017 I attended DevRelCon in London—a conference for people working on developer experiences and communities. I learned a load of practical tips on creating learning resources, developing community relations, building effective documentation, and much more. Here are couple of key takeaways I found particularly interesting:
- Developer relations started from people helping others to learn and collaborate around a tool.
- Dev Rel can be seen as bidirectional advocacy (representing the customer view in product decisions as “customer zero”, and of course representing the product to your customers).
If you’re interested in learning more about developer relations, DevRel.net is a great place to start.
How this relates to Dropsource
So what does all this have to do with Dropsource, it’s a visual app builder right? Dropsource does differ from the typical product with a developer relations focus—most commonly these are products exposing APIs or SDKs—you could describe them as programming resources. On the face of it Dropsource consumes these resources rather than exposing them, and is therefore fundamentally different. However, the Dropsource editor is a development environment—the syntax you use may be clicks and drags, but the platform facilitates a development task. Additionally, in the future we hope to develop the ability for our users to create and share new plugins that will extend the range of functionality you can implement in your Dropsource apps.
When I fed what I’d learned at DevRelCon back to the Dropsource team, one key discussion point related to the Developer Relations Bill of Rights. We’ve already made a couple of changes to our process to better serve a developer relations mindset within the team, specifically around supporting advocacy by being more intentional about maintaining a dialogue with our community—and building the understanding gained from that into product decisions. One move we’ve made in that direction is to reframe my role as Developer Educator by introducing advocacy as a key element in what I do—to that end we’ve made a few adjustments to product planning to allow me to represent the user perspective as I understand it from the communication I have with our community.
We’ve also been delighted to see the beginnings of an active community start to emerge on our forum, with members frequently jumping in to help other members figure out issues and talk through how to achieve their use cases. Our team recently conducted user interviews with some of our early adopters to learn more from their experiences and feed that information into future planning. We’re also currently hiring a Developer Support Specialist who we hope will similarly drive the development of those relationships with our users through our support channels.
Although we’re still at a very early stage in our developer relations strategy, we intend to keep a close eye on the field and any emerging best practices within it, and will be on the lookout for opportunities to apply these competencies across our product engagement channels.
In future we hope to see an even more active community of Dropsource users who are able to contribute to their app development platform of choice, collaborate with others, and ultimately succeed within (and around) the Dropsource ecosystem by making great apps. We plan to continue adopting the practices in developer relations, initially through education, community development, and advocacy, and in the longer term through evangelism and other outreach methods. We hope to see you getting involved!
Have thoughts on developer relations or have you seen it executed properly? Let us know in the comment section below.