DevRel vs. Developer Marketing
The goals for tech content in a developer relations context may be different from the goals in a developer marketing context. So shouldn’t the content itself be different, too? Developer relations, also known as DevRel, is fundamentally about building and supporting relationships that grow and sustain a developer community. Developer marketing, by contrast, is more transactional. It’s about finding good product-market fit, and moving target individuals and organizations to a decision point. And while DevRel activities can translate into more sales, the goals are community-focused — not transactional.
Should the technical content created to support DevRel and marketing engagements be distinct from each other? The answer here is “It depends.”
In marketing, technical content can be used to establish and support a relationship with a market, prospects, customers, and others. Developer relations, on the other hand, builds and supports a developer community formed around a brand’s products. Technical content supports the relationships between the brand and the developer community. It also supports the relationships between community members.
Could the technical content for developer marketing and DevRel be the same? Certainly. The difference may be in how it is cast, organized, and deployed. Or depending on the support needs of the developer-to-developer technical communication a DevRel team is fostering, the technical content for DevRel may be different in tone, style, information, and organization.
There May Be Role Blur
Role definition is ideal, but for a lean team it can be a luxury. Developer relations and developer marketing often sit in the same organization (usually marketing), and may draw on the same resources and share some responsibilities. However, with the lens focusing on developer community support, it may be more clear what resources DevRel needs, and specifically, the requirements that the DevRel content must meet to succeed.
What Might Differ?
Paid vs. Open Source
Some brands offer paid products and open source products. They use their open source community as a way to build relationships with developers who don’t necessarily pay for their products. By necessity, the technical content for each community may differ, as what is available at a cost is not necessarily available to the open source community.
Abandon your open source community support with technical documentation, blogs, tutorials, and how-to’s at your own risk. Maybe you can expect your open source community to answer questions for each other, and even contribute content, but to get that kind of commitment you have to help your community rapidly understand and use your tools so they have a positive experience.
Read vs. Write Communities
Read vs. write communities vary in composition and goals. A “read” community is comprised of fans of a product who do not provide code or content to the community. Read communities can be a good choice for brands creating communities around a product where the time-to-value is short by design. Technical content supporting these communities may be minimal if the product design is intuitive and easy to use.
On the other hand, a “write” community must have support content to get started. Write communities do expect individual contribution of code and content as part of community interaction.The community management and technical content requirements to support a “write” community will be substantially higher than for a “read” community.
Community leaders in DevRel are often tasked with setting the narrative for their communities. This is technical storytelling. Do you want to encourage people to talk about questions, failures, gaps, and bugs? Then your technical narrative must discuss these things. Your technical content (among other things) sets the tone and offers examples of the storylines you want to see the community create.
Developer Empathy at Scale
All useful technical content should be written with empathy for its intended audience. But for community building, this is even more necessary. Remember that your technical content is supporting a community, and your community is more than people –– it’s a set of behaviors. You’ll find that different author communities are needed to address those behaviors and interests.
For instance, content written by product engineers for your developer community can provide canonical guidance and authoritative insight. But the perspective of developers new to your product can be vitally important, as they help new users navigate issues and challenges that may not have been considered by internal developers. It’s exactly this diversity of insight that can fill gaps and address assumptions often made by product engineers.
Developers in the field are also more likely to deliver content with empathy for the developer outside your company because they are closer to your user. By widening your technical content author pool to include the developers in the field you can provide technically strong, empathetic content at the scale needed to support your community.
Connect Developers With Experts
According to Thomas Grassl, Vice President of Developer and Community Relations at SAP, “Serving up expert access from your company’s workforce alone won’t be sufficient. You’ll need to encourage a network that provides expert advice from external sources.” He goes on to describe how to build an expert developer program in Chapter Seven of “Developer Marketing and Relations: The Essential Guide.”
In our experience, nothing attracts experts more than expert-written technical content that is high-quality and offers a technical opinion. For this, you need to lean on developers in the field to seed the content you need to attract these expert members and contributors.
We like to tell our clients that “Blogs Announce.” In a developer community, blog posts may announce something different than the blog on the company site. For example, a blog might be used to help your community index the documentation and how-to’s that are useful for the developer community, by providing links to this content within blog posts about specific technical topics, applications, or points of view.
Tutorials may be offered strategically, based on fundamental knowledge gaps that are tripping up a community as they try and implement. Maybe a logical application of your tools requires knowledge of a specific library that most of your members are new to. Go ahead and offer a more in-depth tutorial — or break out your content into a how-to series that offers multiple points of entry while providing tutorial-level depth.
Documentation to Prime the Pump
The public documentation may be different for a DevRel community, particularly if you have a different tools as part of your paid product and your open source community. Successfully supporting both means providing documentation that is accurate and useful for both sets of tools. Having a “prime the pump” mentality means that you are always offering content to support the community so members can support each other.
Content at Scale
Depending on your communities’ needs, you may find you need both deep and wide content. That is technical content that can go from novice to expert, and content that can cover a wide variety of applications. As your community grows, you may be able to source it from the community. But at the outset, you’ll have to provide it. The scale will be hard to reach with developers from the product team or the DevRel team alone. And it may go beyond the product marketing content that the marketing team is providing.
The developer marketing world often talks about technical content as a way of establishing a give-get relationship (e.g. give valuable technical content, get a prospect’s email address). Developer relations is more about give-give. Developer community managers are tasked with giving their community the support they need to succeed. In return, the community gives support back to each other and to the brand behind the community. Technical content for DevRel supports a different storyline than developer marketing, and this partnership results in overall brand success.