Hav e you ever attended a developer conference? Or maybe you’ve taken a software product tutorial? Perhaps you’ve listened to a tech podcast, or you follow someone with an avocado emoji 🥑 on Twitter? Chances are that the folks behind lots of that content are involved in Developer Relations.
Many software companies run Developer Relations (or “DevRel”) practices these days. They might go by different names, such as Developer Advocacy, Developer Experience, or Developer Evangelism, but what do folks in DevRel actually do? There’s a lot going on behind the posts and public appearances. In this article, I want to share insights I’ve gained from my time as a Developer Advocate for Applitools.
What’s the main purpose?
The main purpose of Developer Relations is to bridge company and community:
- It helps the community understand the value of the company’s technology and how to start using it.
- It helps the company understand the community’s needs and facilitates the community’s feedback.
More specifically, DevRel focuses on the community of developers – the practitioners who will actually use the technology. In fact, many DevRel folks like me are developers ourselves. We seek to serve our own communities. Our job is not to sell the C-suite on buying products and services, but rather to help developers get the most value out of what the company offers. DevRel’s goal could be restated as “making life better for developers.”
With that in mind, it is important for DevRel folks to be authentic. If members of the community feel like DevRel is merely sales in disguise, then they will flatly ignore DevRel. Any work DevRel attempts to do will be in vain.
How’s it done?
Saying that DevRel “bridges company and community” sounds very abstract. DevRel encompasses several activities to accomplish that purpose. For example, in my job as a Developer Advocate:
- I speak at public conferences and company events.
- I write articles about software testing, automation, and quality.
- I develop tutorials for my company’s SDKs.
- I deliver workshops on test automation and on visual testing.
- I talk with customers to learn the challenges they face with testing.
The types of duties done by DevRel naturally cluster around distinct roles. DevRel is a team sport, and it is rare that one person will be highly skilled at all the different roles, let alone have enough time to fulfill them. There are five primary roles that make up a DevRel team.
The Evangelist
The evangelist popularizes the technology in an authentic, helpful way. Their job is to make sure people in the community know the big picture. Thus, the evangelist is a very outwardly-focused role. They make many public appearances at events, and they develop loads of content, like videos, articles, and online courses. Travel and strong social media presence are practically required for the job. Since they are on the “front lines,” they also keep their ears open for any feedback they might hear about the technology or the company. Evangelists may be called advocates, thought leaders, and influencers.
Since evangelists are so active in their communities, it’s common for them to have large followings on Twitter, LinkedIn, and YouTube. They may even become somewhat of celebrities in their spaces. More attention on them brings more attention to the companies they represent. Celebrity status must be handled carefully, though. One bad tweet can ruin a reputation. Or, if a company builds their entire DevRel program on one evangelist’s high profile, then the program could collapse if that person ever leaves the company.
The Educator
The educator teaches members of the community how to use the technology. While the evangelist may give introductions and demos, the educator teaches the finer details. Typically, they write product documentation, quickstart guides, and tutorials. They may even teach courses online or in person. The educator must have strong skills in technical writing and education. In fact, in many DevRel practices, educators transitioned into tech from academia! The educator does not need a high profile like the evangelist. They can be more behind-the-scenes if they choose.
The Community Builder
The community builder fosters scalable relationships with those using the technology. They drive and sustain engagement with the community. A good community builder creates an environment where everyone feels a sense of belonging. They provide a space for organic interactions, vulnerable questions, and helpful camaraderie. For example, folks should be able to ask basic product questions in a Slack room or product forum and get helpful answers from others in the community.
The “scalability” of those relationships is rooted in the programs the community builder runs, such as:
- Building a public communication forum (like Slack, Discord, or Discourse)
- Hosting events and spaces for folks to gather
- Providing newsletters or product updates
- Connecting folks together for cool opportunities
Furthermore, the community builder provides front-row seats to what’s happening with the technology. They get folks excited for upcoming features, new releases, and the possibilities for the future. They could provide early access to beta versions of features or hold release parties. In doing so, the community builder also solicits feedback from the community to help make the technology even better.
The Platform Builder
The platform builder creates the systems and infrastructure that maintain DevRel programs. They are essentially developers whose customers are other DevRel folks. For example, the platform builder could:
- Create example projects for demos and educational material
- Build, deploy, and administer documentation websites
- Keep package versions for tutorials and example projects up to date
- Implement the infrastructure needed for big events like a hackathon
The platform builder is very much behind-the-scenes and oftentimes the unsung hero.
The Visionary
The visionary casts the vision for the company’s Developer Relations practice. They lead with big ideas, set goals, and guide the team to success. Usually, the visionary carries a title like “director” or “head.” Since a DevRel practice could encompass so many different kinds of activities, they need to be wise in how they align resources to meet their goals. For example, if the company is a startup that’s just starting to roll out early releases, then the visionary should probably focus most on evangelism and community building. Different companies will have different needs.
How do these roles work together?
As I stated previously, DevRel is a team sport! Here’s an example of how these five roles could work together for a program like Test Automation University:
- The visionary notices that folks are struggling to use the company’s technology, so they decide to create an online learning platform with free courses about the technology.
- The platform builder develops the web app for the learning platform and deploys it to cloud resources.
- The educator creates training courses and uploads them to the learning platform.
- The evangelist promotes the learning platform when they speak at events and post on social media.
- The community builder welcomes new students to the learning platform, sets up a Slack room for them to ask questions, and makes announcements when new courses are published.
These roles have some overlapping responsibilities, but they clearly represent distinct areas of responsibility.
Where does this team belong?
From what I’ve seen, most Developer Relations teams fall under one of two organizations: Product or Marketing. Indeed, DevRel has responsibilities to both. DevRel activities happen at the top of the marketing funnel. The team should work close with marketing folks on messaging. At the same time, DevRel folks must be somewhat independent of sales and marketing in order to be authentic in the community. They should focus on good, valuable content that supports the product and genuinely helps their users. Ultimately, the parent organization will ultimately determine how a DevRel team’s performance is measured.
How should success be measured?
The impact of Developer Relations is tough to measure because it benefits so many aspects of a company. It teaches folks about the company’s technology. It draws them into the marketing funnel. It provides helpful guides to get them started. In many instances, though, it’s hard to measure how one particular conference talk encouraged someone to sign up for a free account, or how one piece of vital documentation prevented a user from rage-quitting.
Overall, the best measure of success is engagement. The more engaged people are in the products and in the community, the more likely they are to pay for more. Here are a few engagement metrics to consider:
- How many active users the products have and how they use them
- How many people sign up for an account after an event
- How many people visit certain blog articles or documentation pages
- How many stars, forks, and watchers a GitHub project has
- The completion rate for tutorials and courses
There are many other things that could be measured. Just remember that no single metric tells the full story.
Does DevRel really matter?
YES! Developer Relations matters as a practice because developer experience (DX) matters for the consumption of technology. It’s the 2020s. People don’t want to use lousy products. Developers expect tools and services to work well while solving their problems. DevRel is critical for building bridges with developers. It helps them understand why your fancy new tech is worth their consideration, and it helps you as a company understand what they need and what delights them.
Source link