Developer Relations: Writing for Developers
by Reena Leone
“Developers as a group have proven immune to the majority of traditional software-marketing approaches. Marketing to developers requires a very different approach, and in many cases marketing as it has traditionally been known is simply impossible.” - Stephen O’Grady, The New Kingmakers
As a content marketer, a key part of my job is understanding the various audiences that come to Acquia with different informational needs. The challenge is more than how to write for them, but understanding their interests. What tone do they prefer? Would they rather read a 500-word blog post or a 20-page technical whitepaper? One area I’ve seen fellow marketers struggle with (and one I’ve only just started to learn about since the beginning of the year) is writing for the developer audience. Over the next few weeks I’d like to share some lessons I’ve learned first-hand as well as reading how it’s done by the experts.
The conflict begins with the concept of “developer marketing” versus “developer relations.” It’s a clash of cultures coming from two totally different schools of thought on what content should be.
In the eyes of a typical tech marketer, content exists to generate leads, attract traffic through search, build brand awareness, and ultimately help drive revenue. Yet those pipeline and lead-generating tactics used to meet those goals simply does not work on developers. They want facts and how to’s, not theory or hyperbole. They want to hear the perspective of their peers, not “thought leadership” about the “rise of innovation networks” or “Seven Tricks for Writing Emails That Will Get Opened.” They see through the hype, and they don’t take the bait. They don’t want to be spammed by emails and hate gated content, but like email newsletter digests with relevant developer news, and will sign up for a webinar that promises to teach them some new technical technique. If you want to create content that developers care about, you need to abandon your bag of marketing tricks entirely and think like a developer.
Go To The Source
The only way to write content for developers is to work with developers on that content. If you’re working on a piece about a Drupal module, reach out to the maintainer. Talk to the community of contributors, gain real insight from people who are using the module or have contributed to it.
This is how I got my start a few months ago. When Acquia announced its Drupal 8 Module Acceleration Program (MAP), I began contributing to the Drupal 8 Module of the Week blog series that was launched in conjunction on the Acquia Developer Center. Having only used Drupal in a content author capacity, the only way to tackle this project was to work directly with the maintainers. My fellow content team colleagues and I put together a list of interview questions and created a template that could be used over and over. To date, the Module of the Week series has been considered a success; not just because it provides information on modules that were migrated to Drupal 8 but because it also highlighted the work and success of the maintainers.
If you have multiple people creating developer-centric content, the key is consistency. Work with developers to create guidelines around tone that ensure you’re writing for them in the way they want. Ask them what topics they are interested and ask them what they’re sick of. Be open to feedback and constructive criticism and make sure to circle back with questions or changes. Finally, always fact check drafts with a developer, especially when “translating” a very technical concept for a less technical, non-developer audience.
Be a Human Being, Not a Hype Machine
Nearly every developer and engineer I spoke to while researching this series was sick of the “marketing hype machine.” They don’t want to read posts chock full of buzzwords and adjectives. They can’t stand hyperbole; for everyone’s sake, just skip phrases like "This is the best" or "This incredible blah…”. They don’t want to read, they want to try. Developers want to try things on their own first and when they have a question, they want an answer.
Be specific and informative and get to the point quickly. If you’re highlighting a product for example, explain what it does in specific terms, providing the technical details and specifications. Talk about its benefits — and weaknesses — in a frank way that lets developers know how it works and more importantly, how it will make their lives easier.
If you’re going to hype anything, promote the developer you’re working with on the content. Highlight their contributions and commits, acknowledge them and the work they’ve done.
How To vs. Theory
Developers want to know how to do things, not just read about things. Theory and “thought leadership” (or as I like to call it, an informed opinion piece) doesn’t resonate.
To remedy this at Acquia, we worked with our former head of engineering to create a style guide for the developer audience, or as he put it, how to “not set off a developer's BS detector.” This has been heavily vetted internally by our own engineering department and serves as our go-to whenever we’re approaching new developer content. It includes tone guidelines, key messages, links to best practices for documentation, and other companies who do it well. Here’s an excerpt:
Key Messages To Reinforce
- More: How does this benefit developers? How does this make developers more powerful? How does this allow developers to get more done with less?
- Fast: How does this get it done faster? How does this help to meet the needs of the business quicker?
- Relevant: How is this a current / relevant skill that models trends in web development? Tell interesting stories to back this up.
- Focus: How does this help developers think less about stuff that is noise and allow them to focus on building sites?
- Relax, we got you covered: Acquia is doing hard work (ops, QA, building new tools, qualifying new stacks, etc) so you can just focus on what you need to do to build reliable and awesome sites.
- Solid: This isn't a hack, this will scale, this is something they can count on.
- Defensible: Here’s an opinionated position that can be proved to be better
- Building on the shoulders of giants: Build on the open source ethos and how as a community we can accomplish anything
- Plays nice with others: This thing fits into your workflow and here’s how.
But what do you do if you have to cater to both developer and marketing audiences? Content for one can easily alienate the other. This was a struggle we faced with the acquia.com blog. Our developer content was performing well but we were also trying to build a marketing audience. Instead of trying to be everything to everyone, we decided to give developers their own space and the Acquia Developer Center born. All developer- focused blog content from acquia.com was moved there and this is where all new developer content is posted. Segmenting your audience between two websites is always a risk but in this case, it’s paid off; we’ve seen a 15% increase in unique visitors (acquia.com and dev.acquia.com combined) in it’s first year.
Write it Verbatim
If you’re not a highly technical person, if you’ve never written a line of code in your entire life, you can still write content for developers. The best way to do this is to use their words verbatim. Do a Q&A session and use that as your content. After completing a draft, share it with the person you worked with to ensure it’s accurate. This is super important.
Above all else, do not change their words to make it sound better or for optimization purposes. Trust me, just don’t.
Stay tuned for more including best practices for working with developers on content, how to build relationships in the developer community and more.
Anything I missed? Add it in the comments.