Have you ever wondered what the difference is between developer marketing and developer relations? And 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!
In this blog post, I’ll set out to disambiguate the roles within a company’s developer outreach team and explain what each person does and where they focus their attention.
If you are a developer, you have likely visited a number of portals and joined communities over the years, some successful and some less so. You’ll find it interesting to know the inside story on how they are put together and what happens behind the scenes.
If you work with developers, or are planning to, you’ll also find this post useful, particularly if you are considering building a developer community, or funding one. It’s also likely to be something that you need to consider if you already have a nascent community running already but want to push into the next level of the developer community maturity model.
Here at /Data, our Developer Program Benchmarking reports track how developers perceive individual developer programs. Twice per year, we measure developer adoption, engagement, and satisfaction across the industry, reaching over 40,000 developers in more than 165 countries. Our data shows that developers visit the top developer portals at least once per week and, on average, developers report to be involved with 3.1 different developer communities. These days, development uptake revolves around community, and your outreach team is likely to have a huge bearing on your success. So, without further digression, let’s dive in to the structure of a typical developer outreach team.
Developer product engineering
What is a company’s developer product? Well, it could be a Github repo that you clone, or an installable tool. it could be a zip file that you download, maybe it’s an API, maybe it’s a library or a package. It’s something you use if you are a developer — 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 organisations. This team is responsible for setting out their product strategy & roadmap, for developing the product and its supporting documentation & sample code, plus tooling, and libraries and IDE integration where relevant. They will be the know how behind the technical support provided when you need it.
Their goal is to develop the best product for you, the audience, in terms of its usability and relevance. They will want to know how to improve their offering to you, and also want to be able to demonstrate to their company that they are worthy of what has been invested in them.
Many product teams would agree that the marketing metrics of “who read our blog?” or “ how many twitter followers do we have?” don’t really apply to them. In our recent book, Developer Marketing: The Essential Guide, Pablo & Rex of Arm’s developer ecosystem team, made the point that their goal is to help developers’ code run better on Arm products, and their efforts in this direction is what they need to measure. Their approach is to educate themselves on their developer audience so well that they find a unique way to serve them and make their lives better, thus raising their awareness of the company. In the book, they describe how they spent time 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, and set themselves a target for the installation process to get a developer up and running in under 5 minutes.
Developer relations
Now we’ve seen into the team building the developer product, let’s turn to the main interface between that team and developers using their output: those working in developer relations. Their goal is to build credibility, trust and influence with developers for the company they represent.
Many people struggle with working out exactly how to pin down the role of developer relations, and those working in it may alternatively be labelled community manager, developer evangelists or advocate. The role incorporates some marketing, but it also fits alongside the product group and within engineering. We’ve described previously that developers don’t trust always 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 (including technical blogging)
– attending events and meetups
– hosting office hours
A role in two parts
The developer relations team has two distinct ways of working. Part of their responsibility is evangelism: to communicate the company’s message to external developers. They may find themselves explaining which features are available and which are not, yet.
Conversely, the other part of their job is advocacy: to 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 evangelising the company to the developers. It’s also something of a balancing act at times. In our recent podcast with Mary Thengvall, author of a recent book about developer relations and well-established community builder, 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 people 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 at the marketing team, to write a blog post. The developer relations team are not responsible for hiring the person or publishing the blog, and it may or may not happen. But the connection was made and it can bring value to the company, ultimately, so that’s the job. It isn’t measurable in terms of sales numbers or marketing numbers or traditional business metrics.
Developer marketing
Working in developer marketing, the focus is to encourage 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 outreach channels of social media, content marketing, email campaigns and blogs. Some developer marketeers will be in teams that establish developer rewards programs and early access programs for software or hardware; other, smaller teams, will be focussed on growing an audience via sponsored events and meetups.
There’s a great chapter in Developer Marketing: The Essential Guide, by Ana and Christine of Qualcomm, who talk about building a developer community around hardware. They describe the process of narrowing down the target audience for the community around their Snapdragon 410E processor. It was
‘…to let a thousand flowers bloom: to make it as easy as possible to use, to build up a broad community and channel, then see where biggest leads came from and tune the business approach along the way. That’s a difficult place for developer marketing to work.
“Who is our target audience?” we asked.
“Lots of people,” the product team told us.
“What will they make with the board?”
“Lots of things. You know, for the Internet of Things.”
“Can you identify a few key vertical segments to focus on for our initial campaigns?”
“Why would we do that? We need to position the product as broadly as possible.”…’
As they say in the book, it wasn’t exactly a well-defined target audience and clear direction, but that is as succinct a description of the place that a developer marketing team finds itself as I’ve ever seen!
And finally…
The following table illustrates the subdivision between roles as I’ve described them above. Please let me know in the comments if you think I missed anything about the roles, or if you have good (or bad!) examples of how they work together to allow the developer outreach team to engage with its community.
