Imagine a room full of developers, ready to hear your conference talk. How many are in the audience—50? 100? 500? As awesome as web development is, there’s a natural cap to who can hear your message in person.
A blog post can garner the same attention month after month. If you are strategic about what you publish, your content will attract even more developers. It’s like a stadium full of coders attending your talk. In this post, we’ll show how to reach more developers with your technical content—no soundcheck or tour bus required.
You Already Have Your Content
During the pandemic, content has been an important part of the developer relations arsenal. With minimal live events, we’ve turned to videos, streaming, and blogging. Even as people congregate in person again, the most successful teams will keep their content engines humming. To be one, create an intentional, strategic plan built on top of content you already have.
When I joined SendGrid in 2013, our goal was to scale the DevRel team’s content. Eventually, there would be a dozen evangelists traveling the globe helping developers out. Whatever their message and audience, we worked together to also put it in blog form.
Once you recognize the content within your activities, you’ll see ideas everywhere you look. If you need motivation, look to this tweet:
As for inspiration, consider these common places where you already have the start of something:
- GitHub repos (your own, or your team’s)
- Demo apps, especially those solving real developer problems
- Presentations and slide decks
- Videos of talks or streams
- Discussions with developers in Slack, Discord, email… or anywhere else
- Support tickets, Stack Overflow, Twitter, or anywhere developers are asking questions
Gather ideas from these locations and create systems for flagging new concepts as they come up. Not every topic will be a winner, but there’s value in volume: it will help good stuff rise to the top. You’ll also increase your confidence when you realize more ideas are right around the corner.
How do you decide which to write and which to back burner? You can follow your highest energy, which could be the difference between something published and nothing written. But the most successful teams follow developer energy, not their own.
Write From the Developer Perspective
Working in Developer Relations, you likely have a good idea of what developers want. Through events, forums, chat, and other channels, you hear directly from developers. Despite this access to your audience, developer advocates and evangelists may still make the two most common mistakes in developer content. To avoid them, you can balance the focus of your developer product with the right developer problems.
Sometimes companies will confuse whether developer content should be in documentation or elsewhere, such as your blog. If you’re having trouble deciding where content belongs, it’s likely too focused on your product. With the goal to attract developers, they won’t necessarily know your product yet. Rather than show them how your product works, you want to engage them with content they’re seeking before they know your product.
To find the right topics, make sure you’re staying in the space between the two most common mistakes in developer content:
- Too much focus on your product
- Too little connection to your product
In the first case, the most frequent developer content error, your concepts are too inward. It’s tough because DevRel knows its products well. You can point to where it excels and where the sharp edges can snag you. Yet, that’s not the sort of content that will attract developers in the first place.
On the other hand, developer relations is very aware of developer tools and trends. Sometimes we overcorrect from the product focus and cover topics that aren’t as likely to lead to developers using our product. This developer content mistake is less common than the first and has a less negative impact. In fact, to expand your audience, you may want to cover topics that are less connected to your product. Yet, taken to the extreme, you can attract plenty of traffic—even developer traffic—that will never stick around to learn more about your product.
While it’s important to find a developer perspective that attracts readers, you’ll keep them with the substance of your content. Sharing your technical knowledge with fellow coders can be a great way to flex your developer relations skills with written content.
Put on Your Developer Education Hat
In Developer Marketing Does Not Exist, I write that to reach more developers, you need education—not promotion. Help developers solve their problems and they’ll remember you. When it comes to teaching with content, developer relations shines.
If you choose the right topics (based on understanding the developer perspective), you’ll prove yourself a trustworthy guide. That’s why a problem-focus, rather than product-focus is so important. Show you care about helping a developer more than repping your company. Again, this perspective comes naturally to most in developer relations.
For example, let’s say your product provides API access to a valuable dataset. You know developers want to integrate it into their applications. You can help them solve their problem! One way to approach educational content would be a tutorial that shows how easy it is to use your API. That may attract a few devs, but to many, it will come across as promotional.
Also, once you’ve written that post, what will you write next? The same thing in a different programming language, maybe?
That’s starting to seem like documentation, which is less likely to attract developers who haven’t discovered you.
A better approach might be to teach developers the alternative to your API. This Developer Content Mind Trick acknowledges where their mind is already headed. Developers like to solve problems, so they may already be exploring their own solutions.
In the data API example, there may be alternative sources to gather data in bulk. Your post could show what’s required to do one part of that process, such as merge multiple sources into a single database. That will give you many additional topics: de-duplication, reading in large CSV files, Cron jobs to harvest new data, and many more skills needed to reproduce your API.
In fact, the topics you cover could go beyond the data you provide to include anything about data ingestion or data quality. After you teach a lesson and build some trust, share your product. And it’s not hype to mention that it helps avoid the pain you’ve explained in detail earlier in the post.
In order to get your developer reader to the end of your post, it needs to be interesting. That’s the final element of DevRel writing.
Don’t Be Boring
With funny hats or memorable demos, many in developer relations naturally attract attention. However, the persona does not always translate to content, especially written content. To capture and maintain attention, you’ll want to avoid bland content.
Interesting content starts with speaking to developer problems and helping them without ulterior motives. Even when those are done well, as shown in previous sections, the rest may fall flat. You may get developer attention, but your post won’t stand out from any other on a similar topic.
First, remember blog posts and similar content are different from documentation. While docs don’t have to be bland, either, they do need to be factual. Content that is meant to attract developers should have personality and opinion.
For example, Optic is a tool to track API changes. It helps developers improve overall API quality. So, why would they encourage breaking APIs? For one, it’s counter to most advice, which grabs readers’ attention. Even better, this opinion is at the heart of the company’s product, which can capture these breaking changes before they’re deployed.
Your product is also built on opinions. There’s something your company believes that competitors don’t. It’s the reason the founders started the business and it’s hopefully present in your positioning and messaging. You can tap into these opinions to create better developer content.
Developer relations may be better equipped than anyone in the company to succeed with developer content. With a mix of technical and communication skills, you can put these pieces together and reach more developers.
To increase your chances of success, follow a proven process. EveryDeveloper has worked with dozens of dev-focused companies to reach millions of developers. We can help you figure out what will work for your technical audience, so you can do more of it, via our Technical Content Accelerator.