Shifting out of being a developer myself, I’ve worked in developer marketing for a few years now, and in that time I’ve learned quite a bit about how to engage developer audiences. More than anything, I’ve learned how to effectively communicate with developers and give them the right content in the right places — and that’s what developer relations (DevRel) is all about.
—
I’m often asked, “what is DevRel?” At its core, DevRel is a series of programs that are designed to create and nurture a qualitative relationship with the developers that use your products and solutions.
For me, the qualitative part is extremely important because many people like to see DevRel as a part of marketing, where your goal is to talk to as many developers as possible to generate as many product users as possible. Building an honest and mutually beneficial relationship with developers might not dramatically impact your short-term metrics but it can have a lasting, positive effect on your long-term goals of advocacy and influence.
When I think about the lessons I’ve learned first-hand (through a lot of trial and error), it really boils down to certain pieces that are absolutely needed for a DevRel strategy to actually work. Plenty of marketers simply post about products and solutions in community spaces like StackOverflow and think they’re doing developer relations—they’re not. Whatever goals you have for marketing to developers, it REALLY matters what developers are saying and how they’re feeling. Marketers will never get that information if all they’re doing is broadcasting.
What are the components of a successful DevRel strategy?
In my years working in this field, interacting with developers, and engaging whole communities, I’ve learned there are seven key components to successful DevRel campaigns.
Create an end-to-end information pipeline.
Driving awareness is one of the biggest goals in developer relations—and to support that goal, marketers should create an information pipeline. Think of this as a single hub for content. This is where developers with different levels of experience and varying interests in your product can find the information they can use to troubleshoot code, optimize their latest project, learn a new skill, or help make a buying decision.
When I say that developers have varying interests in your product, I’m referring to three specific interest levels.
- Surface level. These are the “lurkers” within your audience. They’re not going to make any commitments or engage with your product too deeply or at all. Although they won’t likely invest in posting replies, they may respond to the bigger, more broadcast messages.
- Absorption level. Developers at this level are wanting to learn. They’ll see your social media and interact, follow links, read articles, watch tutorials, and download code samples. However, they’re not really looking to have a conversation at this stage.
- Response level. This is the ideal level that all marketers and sales reps want to reach. Here is where developers are interested; they’ve become knowledgeable, and now they want to join the conversation. At this level, you can expect them to engage with other community members, provide their feedback, showcase their projects, and start their own discussions.
Connecting with all three of these interest levels at once doesn’t have to be difficult. For example, a business can post an announcement to social media (i.e. Twitter) to spread the initial awareness to developers at the surface level, while linking to the full length article to funnel those in the absorption level. Then, they can offer that content up for discussion on a forum, allowing people at the response level to voice their opinions and ask questions.
Use multiple channels to engage with developers.
Participating in multiple channels can help a brand target developers at different interest levels and find out how they’re talking about a product. However, it’s important to first learn where these conversations are taking place and determine how your brand should join, spread awareness, and generate advocacy.
There are many channels to choose from, each offering something different to both developers and brands, but they all fall into the following categories:
- Broad channels. StackOverflow, Reddit and other social media platforms are prime examples here. These are large communities where developers from all walks of life are roaming vast fields of content and discussions.
- Niche channels. These communities are a little harder to find and are hyper-focused in terms of topics and solutions. Developers that are active in niche communities have more in-depth conversations and are more likely to be highly receptive to and follow up on recommendations made by their peers there.
- Brand-made channels. These are content hubs created by a brand itself. Although developers tend to be more wary of non-organic channels, a brand-made channel can be effective for highly specific project needs. These channels allow product experts to offer helpful advice, work-arounds, and solutions to developers that are struggling or feeling stuck.
Don’t be afraid to test out engaging developers in a variety of developer channels to see what works and what’s not worth your efforts. Your goal should be to keep conversations flowing and see if your brand is able to gather more interest and attract more people to your content and discussions. For example, if you find developers talking about your product on a Reddit thread, try creating more topic discussions like that and see what happens. If you can keep your commentary informative without feeling like you’re peddling a product, more and more threads might spawn, and maybe down the road someone will create a subreddit for your product.
Inspire developers through work showcases.
Showcasing developers’ work using your products is a great way to inspire others to build something too. Be advised, though: this is not “fluff” content, so do not treat it as such. When you showcase, make sure the developers are the star of the show and put the focus on them—what did they do, how did they do it, and why does it matter? An easy way to keep focus on the developer is to eliminate any messaging like, “Here’s what this developer was able to do with our product,” and replace it with, “check out how this developer did XYZ.”
If your messaging around a showcase does not celebrate the developer and their work, it needs to be revised. Developers care about their peers more than your brand, and good products speak for themselves through such creations.
“Developers want to feel like what they do with your product matters.”
Maintain a strong level of transparency with product users.
In my experience, nothing frustrates developers more than when a company makes changes to a product without a clear, straightforward explanation. Developers use different solutions to streamline the building, testing, and optimization of different projects. So, changing something, even if it’s a small thing, can throw a wrench in their entire development process, slowing them down.
Brands sometimes have legitimate reasons to not be able to talk about the changes they’re making—a pending lawsuit, for example. But avoiding the conversation altogether is a mistake. Being clear and direct about what is changing, why (to the extent that you are able), and how you help developers adjust to new features goes a long way here.
Keep in mind, that your tone and presentation matter — developers do NOT want to hear any legal or marketing jargon. They don’t want to feel like they are a part of a faceless mass of people. They want to feel like what they do with your product matters. Let them know they matter, their work matters, and your brand is prepared to help them accomplish their goals. Above all, craft messaging as if you’re speaking directly to each individual developer who will read it.
Set qualitative objectives for developer relations program and campaign success.
Yes, DevRel is qualitative but that doesn’t mean you can’t set goals and objectives for your team to reach. Without any in place, you’re essentially just performing customer service with no purpose other than answering questions. But your goals for a qualitative function can’t be entirely numbers-based; they need to be qualitative as well.
For example:
- Don’t: Set an objective for “getting 10,000 new developers in your database.”
- Do: Set an objective for “getting a certain percentage of my developer community producing something with our product.”
- Don’t: Set an objective for “getting 1,000 developers to purchase your product.
- Do: Set an objective for “getting a certain percentage of your developer community to show examples of what they’re building using your product.”
When you’re setting qualitative objectives, it all boils down to answering this question: what are we trying to get the developer to feel and do?
Implement product tracking for user insights and use cases.
While your engagement objectives should be qualitative it’s still important to have some telemetry built into your solution so you can understand how your products are being used. Companies will often find out that features prioritized by the company for development and promotion are not actually being used. On the flip side, tracking might show that people are using a product to build, optimize, or accomplish an unforeseen and unintended task that the company should investigate supporting better. Keeping tabs on this information helps a brand to better understand the evolving needs of developers, how the brand can help, and where to best allocate resources to meet demands.
An example of a qualitative objective here with a quantitative KPI could be, “getting a certain percentage of developers to use X amount of product features.” You’re still qualitatively measuring user happiness and engagement but basing that on a quantitative number that marketing can use and view as tangible. It’s pretty common for companies to set goals around community size, which is a mistake because it doesn’t tell you anything about how products are being used or even if the product is being used at all.
Tip:
Go a step further here by directly asking users for feedback about products. If you let developers know their opinions matter and will help shape the best version of your product, they’ll want to help move that along and give you whatever feedback you need because it will directly improve their development projects.
Build an internal DevRel team with expert knowledge about developers.
People resources are not to be overlooked here. It’s necessary to have a team of people who understand the product, what it’s used for, and why it’s important to developers. Moreover, your team needs to understand how the development process works. That could mean they have a developer background or they have a lot of experience marketing to and communicating with developers.
There are three key roles that need to be performed by 1 or more (preferably more) people:
- Developer marketing manager. This is your project lead and the person that fully understands the goals of both the brand and the developers, as well as the relationship between the two. Then, based on that knowledge, they build out the strategy, set goals and KPIs, and structure on-going and one-off campaigns.
- Developer evangelist/community moderator. This role is essentially the voice of your brand. Someone needs to be in the community listening, interacting and reporting back with the latest trends, questions, and issues being discussed within your brand’s different communities.
- Subject matter expert (SME). Having an expert is vital to gaining trust in the developer community because they can sniff out BS and they’re not interested in taking advice or learning from non-developers who do not truly understand the work they’re doing. A SME will ensure your brand is properly conveying technical information and providing accurate solutions and optimizations.
It’s important to note that this can all technically be done by one person, but more people amount to better input quality. For example, monitoring and engaging multiple channels requires multiple people, otherwise, promising conversations can be cut short or lost. No matter what your goals are, not engaging fully with developers that are willing to talk to you is a huge missed opportunity.
Is it time to hire a developer marketing manager? Learn more about what your internal team needs.
The Iron Horse insight.
Many of the clients we’ve talked to do not have any marketing functions in place yet and instead only have a developer relations team with no clear or set goals. In this case, selling their products usually happens at an organic level within a community before anything else happens on the market. This is not DevRel. Your efforts should be measurable and nurture a community until, eventually, it can run autonomously. But without a marketing function, there’s not much that’s going to help bring in new developers and drive initiatives. While having a developer relations team is necessary for longevity, a developer marketing function is vital for growth. Knowing how to do both is necessary and knowing how to combine them is powerful.
