Have you ever wondered what the difference is between developer marketing and developer relations? Or asked yourself, “What is the difference between an advocate and evangelist?”. Just who is behind those developer portals you use for the developer documentation, and who answers your queries on official forums? Read on to find out!
SlashData’s Developer Program Benchmarking shows that developers visit the top developer portals at least once per week and, on average, they report being involved with 3.1 different developer communities. So your outreach team is likely to have a huge bearing on your success.
Without further digression, let’s dive into the structure of a typical developer outreach team.
Developer Product Engineering
Whether your company’s product is a Github repo to clone or an installable tool; a downloadable zip file, an API, or a package, it’s something a developer uses. And somebody made it. That person, or group of people, sit in the developer product team.
The developer product team can range from a handful of developers to hundreds of people in big organizations. This team is responsible for developing the product strategy and translating that into a roadmap. They develop the product and craft supporting documentation, sample code, tooling, libraries, and IDE integration, where relevant. This is the group that will provide support services with the technical know-how.
This group’s goal is to develop the best product in terms of usability and relevance and continually work to improve it.
Product teams shouldn’t be measured on marketing metrics such as “who read our blog?” or “how many Twitter followers do we have?” In Developer Marketing: The Essential Guide, Arm’s Pablo Fraile, Director of Developer Ecosystems, and Rex St. John, Senior IoT Ecosystem Manager, wrote that their goal is to help developers’ code run better on Arm products. What gets measured is their success at making that happen.
Pablo and Rex educated themselves on their developer audience to find unique ways to serve them and make their lives better. That raises awareness of their company’s products. In their contribution to the book, they describe meeting developers and listening to woes about a particular development workflow. They set out to build a tool to smooth out the experience for developers with this goal: A developer should be able to get the product up and running in under five minutes.
Now that we’ve met the team building the developer product, let’s turn to the main interface between that team and developers using their output: The developer relations group. Their goal is to build credibility, trust, and influence with developers.
Pinning down the role of developer relations can be tricky. Within that group, you might have community managers, developer evangelists, or advocates. The role incorporates some marketing, but it also fits alongside the product group and often within engineering. We’ve described previously that developers don’t always trust marketing, so developer relations is often seen as the bridge or connector between the two. Developer relations is about field work: working with developers to help them understand how to use the developer product. Some of the activities you may find developer relations working on include:
- Public speaking
- Attending hackathons and contests
- Writing sample code and running demos
- Social media posts
- Attending events and meetups
- Hosting office hours
Need an Evangelist, Advocate, or Both?
It isn’t a matter of what you call the job. Instead, think of those terms (evangelist and advocate) as two tasks that need to be addressed. Whether they are handled by separate people on your team, by one person, or by multiple people assuming both roles, it’s two tasks. Part of their responsibility is evangelism: Communicate the company’s message to external developers. They may find themselves explaining feature availability, for instance.
Conversely, the other part of their job is advocacy on behalf of developers using or considering using the product. With the advocate hat on, they convey the developers’ views back to the product team. Developer relations practitioners are familiar with saying “I’m getting very strong feedback from people who use X that we should actually include feature Y and not Z” and defend specific feature requests to the product team.
It’s a very important role, advocating on behalf of the developers to the company and evangelizing the company to the developers. It’s also something of a balancing act at times. In our recent podcast with Mary Thengvall, a community builder and developer relations’ book author, she said:
“… you’re constantly going back to the company with feedback from the community or turning around and explaining to the community why a product roadmap looks the way that it does and why those are the decisions you’ve made. You find that you’re explaining why we’ve made decisions or what best practices we have decided to follow. There’s a lot of storytelling in there, fitting your knowledge to the perspective of the person that you are talking to. Taking the feedback from the developer audience and the technical audience and communicating that in a way that the product team and the stakeholders and the company are going to understand and vice versa, taking the business speak from your stakeholders and communicating that back out into the community in a way that they understand…”.
Developer relations professionals are responsible for building connections, then stepping back and letting other people do their jobs. For example, they make an introduction between a community member and a recruiter, or they connect an active community member to someone on the marketing team to write a blog post.
The developer relations team is not responsible for hiring the person or publishing the blog. But the connection is made and it can bring value to the company. It isn’t measurable in terms of sales numbers or marketing numbers or traditional business metrics.
Developer marketers focus on encouraging developers to learn about, try out, adopt, use, and contribute to a software product. This is the team that defines the target audience by building a model of developer segmentation and personas. They also create the developer marketing strategy and product go-to-market plans and work on social media outreach channels, content marketing, email campaigns, and blogs. Some developer marketers will be in teams that establish developer rewards programs and early access programs for software or hardware. Other, smaller teams, will be focused on growing an audience via sponsored events and meetups.
Summing it Up
This is a really handy table for understanding each group’s roles and goals.
We have covered the high-level differences between roles that market to developers, those that advocate for them and ‘speak their language’ to explain what their company offers. We’ve also described how the technical team fit in when it comes to delivering a product for developers to use.
In reality, of course, the lines are often blurred, depending on those working in the team, their strengths, interests, and availability. What are your thoughts? Have you worked in a team that follows these lines, or do you have a different experience? Does it depend on the stage of maturity of your developer marketing team? It’s a great subject to ponder.