Developer Relations: More than Traveling the World and Buying People Beer
Developer relations is one of those roles that has different names and meanings that vary depending on the person talking about it. At DevRelCon in London on December 8, presenters referred to this job as “developer relations,” “technical evangelism,” “developer advocacy,” and “community management.” But, regardless of what you call it, most companies throughout the stack have someone or a team of people doing this job and acting as an interface with the developers using their products.
While the actual work varies drastically, developer relations is usually some combination of participating in events, coding, writing technical articles, and engaging with communities. Michael Ludden, a program director and senior product manager responsible for IBM’s Watson developer product strategy, described this as a hybrid role that requires something of a unicorn to fill because of the unique combination of software engineering, public speaking, and online community participation skills required along with wanting someone who already has a great reputation in the community.
Caroline Lewko, founder of the WIPFactory marketing agency, had a quick preview of some developer relations survey results that will be released shortly, on the WIP Factory site.
It was a small survey of 79 people, which isn’t particularly surprising since there aren’t that many developer relations roles. Some of the top skills needed to be successful in developer relations include communication, technical, and empathy. They also travel to a lot of events, 50 percent attend more than 15 events per year and 55 percent of them plan to attend even more next year.
Events, direct one-to-one communications, content marketing, and social media are seen as the most effective channels for developer outreach. Developer relations is a fairly new field. Almost 50 percent of developer relations programs where these people work are 2-4 years old and just over 25 percent were less than a year old, which is similar to the experience of developer relations professionals with just under 45 percent of them in the field for 2-4 years. There are also a lot of lone wolves with 30 percent of people surveyed being the only person in their company doing developer relations, and just over 30 percent have teams of 2-5 people.
Online participation provides a bigger reach, is more measurable, requires no travel, and can be much less expensive. However, face to face interactions have better engagement, more opportunities for relationship building, and better feedback.
Developer relations isn’t just about flying around the world, going to events, and buying people beer. Having a strategy for your developer relations program that meets the needs of your company is also important. Baruch Sadogursky, a JFrog developer advocate, talked about starting with “why” when building a developer relations strategy: On the one hand, there are outbound activities, like technology awareness, education and recruitment, but technology feedback should also be coming back into your company to provide feedback to sales, marketing and product teams to share what the developer relations team is learning from developers.
The challenge is that from a day to day perspective, activities tend to be more focused on outbound communications. Sadogursky mentioned that the biggest tradeoff is in deciding how much of the strategy should be online interactions vs. in person with budget and resource implications for each option. Online participation provides a bigger reach, is more measurable, requires no travel, and can be much less expensive. However, face to face interactions have better engagement, more opportunities for relationship building, and better feedback. This isn’t a binary, one that requires developer advocates one or the other choice. Sadogursky stressed that it’s important to decide where to draw the line depending on what is most important for you and your company.
The Written Word
Whatever direction you take with your developer relations strategy, writing content is likely to be one component of the work. IBM developer advocate Lorna Mitchell talked about how writing things down is powerful. The written word transcends space and time to reach anyone, anywhere in the world, at any time, across all possible boundaries. You can open up communities and reach individuals anywhere.
When faced with a blank canvas, however, even the most prolific writers can struggle to come up with ideas. So Mitchell has a few practical tips for writing great content. First, practice ABCs: Always Be Capturing ideas about what to write so that you can remember them later. You’ll almost never have those good ideas on the days that you have time to write, so keeping a list of ideas can really help you get started.
“Humans can’t scale and retain authenticity” — Jess Rose
Also keep in mind that ideas do not always need to be groundbreaking or rocket science. The goal should be to help people who don’t know as much as you do about the topic. Mitchell also stressed the importance of having a plan and an outline, rather than just jumping in and writing. Think about the audience that will read it and what they will learn.
The next step is the one that Mitchell says is the hardest: You need to write the words. Don’t wait for inspiration to start, just start writing and worry about editing, word counts and everything else later. Include some variety and avoid a wall of text by using subheadings, code snippets, tables, pictures, and lists. After you’ve written it, then you should take out everything that isn’t essential (flowery language, diversions, etc.), and if it’s too long, nobody will read it, so if you can’t be more concise, you might need to break it down into a series of several posts. Mitchell also says that reviews are a gift and making a fool of yourself for a much smaller audience (the reviewer) can save you from your biggest mistakes.
“Developer relations is like the force — you can’t see it and can’t feel it — you just have to believe it.” — Phil Leggetter, Nexmo.
Jess Rose, developer relationship advocate for Crate.io, talked about the duty to be authentic for people working in developer relations with authenticity defined as “interactions with people that feel real and hold value,” both for developer relations and for existing or potential users.
The challenge is that many managers are concerned about things like: Does it scale? How can we measure it? However, authenticity is warm, fluffy, and not easy to measure. Rose points out that “humans can’t scale and retain authenticity.” She goes on to say that part of the issue with measurement is that you can only measure authenticity by documenting the failures since you only get feedback about whether something feels real when it goes horribly wrong and didn’t feel authentic.
Despite not scaling and being difficult to measure, authenticity matters. One challenge with maintaining authenticity is that developer relations is a tough job with quite a bit of burnout coming from the frequent travel and pressure of participating in global communities of developers. Rose stressed that in order to help developers and give them the time they deserve, it’s important to take time to take care of yourself, slow down, and focus on the things that really matter.
IBM is a sponsor of The New Stack
Feature image by Travel Junction, CC BY-SA 2.0.
