Developer Relations vs. the Volcano
In a recent post I shared my perspective on Developer Relations including the various activities one might observe from a DevRel organization. A few years ago I participated in a developer marketing campaign that helps illustrate how these various activities come together in practice. First though, somebody had to jump into a volcano.
A Showcase Project
DevRel builds interesting projects, prototypes, and demonstrations by using the company’s products and APIs to understand what an external developer’s experience is. (link)
As a Developer Evangelist with General Electric, I was often on the lookout for what I referred to as a showcase or hero project. Writing a tutorial, how-to, or other short demonstration can be done in a few days and can quickly validate that a service or API does what it says it does. Those are important, but to get a deeper understanding of what a developer’s experience is can come from using the product to build and support something of a larger scope that more closely resembles a production application or purpose.
In 2017, I learned about a collaboration that was beginning as part of a marketing campaign. A team was being assembled to go on an expedition to Nicaragua and install industrial IoT sensors in a volcano. It was a purpose-based mission to investigate the potential for outcomes like early-warning systems, preventative maintenance, and just a better understanding of our world. I’m not going to rehash it all here so to learn more about the story, project, and people involved — enjoy the website for an engaging scientific exploration (https://ge.com/digitalvolcano) but come back, I have more to tell about DevRel below.
Inspiring Others
It sounded like a fascinating project when I heard the pitch so immediately asked how I could help. Ultimately, GE was not looking for any commercial viability in profiting from volcanoes, so this was an ideal project for DevRel to contribute software engineering resources to help develop. The data and source-code would not require any intellectual property protection so could be freely shared and talked about in public.
My involvement grew over time from initially just providing technical support to taking on an analytics dashboard. As an evangelist I didn’t have an engineering team to leverage, but it was an interesting enough project that I was able to persuade and recruit a half-dozen engineers from across the organization that were excited enough about the concept to contribute their personal time and energy to building the dashboard as a side-project of their regular jobs.
SDKs and Reference Apps
DevRel develops tools and SDKs that help enable developers to onboard and have success faster and with less pain. (link)
Once the industrial sensors were deployed from the expedition we were able to get a stream of data coming from the sensors to analyze. We wanted to store, query, and analyze this data so we chose Python as our development language to build a dashboard. One of our first observations was that there were no resources to help a Python developer get started. Every developer would benefit from some tools so we added that to our list of deliverables:
- Develop an SDK that can be downloaded and used in the client language. While postman and
curlexamples that were published by engineering and documentation teams were fine, they are a least common denominator. Every developer needs to write some client code to build an application, so why not make it easier for everybody by providing it directly so that authentication, orchestration, and error-handling were handled. - Develop a Reference Application that can be downloaded and used to deploy an application quickly. Every developer is capable of standing up an app, but is that the best use of their time in evaluating a new product? If somebody can get a prototype up and running in an hour rather than a week — that gives a much better impression of the platform.
We felt the pain ourselves, built the resources, and made them available on GitHub.
Getting Started Guides
DevRel creates technical documentation such as formal getting started guides and tutorials as well as informal blog posts. (link)
Well written code is great but not everybody can learn from reading code alone. Often, the why and context must be explained. In DevRel, we want to help all developers with a variety of skill levels, so it’s important to explain things for both somebody who’s a beginner and for advanced cookbook recipes for solving specific technical challenges. The SDK and reference app for the volcano project were delivered with complete documentation to help others learn.
Getting the Word Out
DevRel attends, speaks, and sponsors developer events like meetups, conferences, and hackathons delivering content through a variety of modalities like presentations, webinars, live coding, recorded videos, podcasts, workshops, etc. (link)
It is considered taboo to sell a product with Developer Relations. Ultimately, an organization exists to make a profit though so if the product is priced correctly and the value exceeds its cost then anybody whether developer or not would consider buying. Therefore, DevRel does exist to “sell” but achieves this result indirectly.
- DevRel focuses on a long-term relationships rather than short-term transactions
- DevRel focuses on providing something of immediate value for free whether somebody is buying or not
That value frequently comes from the transfer of knowledge and access. To accomplish this, content is developed and delivered to wherever an audience exists that might benefit. The volcano project resulted in a lot of learning that can be shared with no strings attached.
- what our services were good for
- what our services were not good for
- what we learned from using those services in combination with other related technologies
- what we learned about those related technologies
- the tools we created that might make it easier for others trying to use any of our services or related technologies
We had a new SDK and Reference App that we thought would be useful to others. Some developers might stumble upon them if they looked, but it was time to get the word out more proactively. We believed others might be interested in engaging with us long-term and could benefit from what we learned.
What did that campaign look like?
We released blog posts on multiple sites telling the story in different ways.
We engaged Media Relations and journalists covered the story in CNET, Live Science, Observer, etc..
We posted to aggregators like HackerNews, Reddit, and Product Hunt.
We created videos, podcasts, and webinars so that others could listen at the time, place, and format they preferred.
We wanted to answer questions both live at events and through online support forums.
DevRel should avoid the bad rep that comes from a “sales pitch” by providing value through knowledge. To accomplish that requires a lot of engagement both online and in-person. It’s a job where functions like engineering, product, marketing, etc. should participate but as the commitment becomes a full-time job that’s why Developer Relations exists as an organization.
Summary
What does DevRel do? Installing sensors in a volcano is not your typical project. Most projects don’t need to be at this scope or scale to be effective (was this the most expensive SDK launch ever?) but it does illustrate a few best practices for doing developer relations:
- build something with your product, the experience first-hand is a good learning opportunity
- provide tools like SDKs, reference apps, etc. that would have helped you because they’ll also help others
- document the journey, the mistakes and learning you had along the way can help others save time
- spread the word in as many places and ways as possible
This was a project that got a high level of return for the engineering investment that went into it. Without DevRel this project would not have happened or had as much of an impact in helping other developers.
