On Saturday, I attended DevRelCon. A one day, single track conference for developer relations managers/ technical evangelists/ developer advocates/ whatever you prefer to call the people who help others be effective users of a particular technology, stack, or product. The event, which brought together 15 speakers, 15 sponsors, and 100+ attendees from 10 different countries, is unique in providing the DevRel community with a forum to discuss the topics that matter most to our profession.
Below you will find my takeaways from the day’s most pervasive themes: Participation & Inclusion, Content, and Measuring Success.
Participation & Inclusion
A key aspect of Developer Relations is scaling community, or as Jade Wang from Sandstorm.io describes it, Power Law: strength of community != body count. The role of a Developer Relations Manager is not just to practice developer evangelism, but to inspire and train other evangelists – both internally and externally.
Internally, it’s essential that everyone is involved. Developer Relations will act as a bone structure, but it’s up to the rest of the team to provide the muscle. In order to effectively scale our dev community outreach, DevRel needs contributions of all kinds. Consider this an open call for participation, because a successful developer community requires a variety of strengths mapped to different roles.
Writers: Compose blog posts, articles, and other online content
Speakers: Present at conferences, meetups, and webinars
Coders: Write code samples, attend and provide guidance to others at hackathons
Connectors: Talk to members of the online video community & make introductions
Helpers: Assist in planning and executing the DevRel strategy
If the team self-identifies their strengths and interests, it allows Developer Relations to ask for contributions in ways that we know our team members would be good at contributing. The Developer Relations Manager can be a more proactive “Developer Agent” (ex: finding Calls for Proposals (CFPs), submitting proposals, and facilitating cost approvals for conferences).
Content
“Content” can be delivered to the developer community in many forms. Digestible online content, for example, is as important, if not more important, than conferences, while top notch documentation can decrease Time to Hello World (TTHW) – arguably the most significant developer community metric.
Presentations
Conferences, meetups, and webinars are an ideal opportunity to communicate what you do and why you do it. The goal of all presentations should be to explain something well enough that someone can understand and communicate the idea to someone else. This helps to scale the reach of your topic.
In addition to providing an outlet for face-to-face interaction and communication, conferences are also a great opportunity for internal knowledge sharing (present what you learn there to the team), online content creation (write a blog post on your presentation topic), and connection (follow up with people you met at the conference, provide them with resources/documentation, or intro them to developer relations as applicable).
Developer Relations should (and in JW Player’s case, will) define a conference playbook with guidelines for your talk, preparation, delivery, and follow up in order to extend the impact of a presentation well beyond the time spent on stage.
Blogging
Blogs are the ultimate place to cultivate SEO juice from high quality content. It’s important to stay consistent – Adam DuVander from CTL.io suggests two blog posts per the timeframe of one’s choosing. For JW Player’s use-case, I would frame that as two developer-focused blog posts per month. For others it might be two per day, per week, or per year.
Adam emphasized multiple times, “share knowledge, not features.” This means posting about new technology, thought leadership, and product use-cases that plant the seed for creativity – not just product releases, and not all specific to the company. This is where Developer Relations will call on the self-identified writers on the team + outside sources, if necessary, to generate relevant content.
Documentation
Documentation quality can make or break a developer’s experience, with TTHW being the most agreed-upon measure of success. Everyone across the organization should be helping to write, monitor, and maintain documentation.
Bear Douglas from Twitter advocates for three levels of documentation, particularly for mobile developers:
Beginner: Step-by-step tutorials
Intermediate: “What is it and how should you use it?”
Advanced: References & application code
Note the suggestion for application code versus (or in addition to) code samples. Having a complete open-source application allows developers to learn new information in context, whether they clone the entire application to tinker with it or look at individual functions for inspiration or trouble-shooting.
Measuring Success
One thing was incredibly clear throughout the day – Developer Relations is NOT marketing. Marketing is a push, while evangelism/advocacy is a pull – it’s about creating a community of developers and providing them with the resources they need to be effective users. But how do you measure the success of this community?
If the people using the software aren’t the ones buying it, sales leads are likely an inaccurate measurement of success. Instead, it’s important to measure traffic and engagement from traffic. Additionally, you can start to track engagement via content written by the community itself (rather than the internal team).
Rob Spectre from Twilio outlined a pyramid of understanding with “The Force” (or gut feeling) at the base. Next up was data, followed by information, then knowledge, then wisdom. Rob encouraged everyone to asses their current situation and buy visibility into the next level of insight with tools such as Mixpanel, Heap, or Google Analytics Premium.
This information can help determine which events provide the best ROI, which content has the greatest reach, and more. While “best practices” are hard to pin down since every industry is different and each company serves as a unique use case, the most important takeaway is to measure something and use that to make smarter decisions moving forward. Developer Relations programs relying on “The Force” likely won’t be around for long.
About JW Player’s Developer Community
Developers have been a fundamental ingredient in JW Player’s success. We’re launching a lot of exciting new products, APIs, and tools, and we want our user base to be involved. We’re fostering a community of developers, designers, video experts, & thought leaders using JW Player so we can better understand your needs and give you the information and tools you need to maximize the value of JW Player’s video technology.
You can join the JW Developer Community and follow us on Twitter @JWDevelopers to be among the first to know about beta test opportunities, new developer documentation and toolkits, developer community events, and more.