The data-driven approach to writing developer content is wrong
Did you watch Nexmo’s Martyn Davies DevRelCon London talk “Design your content strategy with data”? Well I did. And while there’s a lot of lessons to be learned from his talk, identifying what post will “take off” is (sadly) still largely gut feels.
I don’t want to spend my time writing a ton of content, and then digging into analytics with scientifically irrelevant sample sizes, to see what performed best and then write a bunch of more posts like it — regardless how strongly I feel about the topic. I would much rather delight a few readers, and leave the generic posts that semi-engages a mass audience to other people. This isn’t me being bitter (really). I have written page 1, Hacker News, “viral” stuff. But clickbait-y articles attract an audience susceptible of clickbait-y content, and that’s not the reader-following I’m after.
The best indicator for future following is past following — if and when you limit yourself to data-driven content creation. Consistency in topics is something you’d expect from online marketing media, like newsletters. While a fantastic tool for retention, developer relations folks develop in terms of interests and talking points, much like the people they’re connecting with. I dare you to point me to one person in tech that isn’t continuously updating her knowledge. The data-driven approach banks on the belief that we can churn out content that is useful and interesting for our target audience indefinitely, without experimenting with new themes. I am convinced that notion is false. What’s more, that approach won’t grow your audience, nor add diversity to your database.
That’s why I’ll look at analytics, but only because that’s what I’m expected to do / because we pay for some service (👋 boss). Instead have some three go-to heuristics that I have found to guarantee technical content that is interesting, and helpful to my target audience. These include buddying up with support, summarizing events that I attend, and sitting in on daily scrum events to find out about upcoming features and releases, among other things.
Support is a gold mine
I periodically check Stack Overflow to analyse support requests. Chances are that if someone took the time to report an issue, there are others (“others” totally being a scientifically valid quantity) experiencing the same thing. Then I’ll write articles with the aim to ‘unstuck’ and delight community members researching the issue. For me, a central part of developer relations is empowering people, which means removing roadblocks and making the product work better for our developers.
To the same end, one could also type the company’s name in a search engine and analyse the search queries.
Summarize community events
I’ll also do a lot of recaps of community events, like conferences, webinars and meetups / user groups. Especially the latter is relatively low effort. I’ll walk you through how I approach this kind of content creation, from preparing for a meetup, to note taking, and ultimately promotion.
As to the why: I feel like summarizing conferences and meetups is a service to the community. Effectively you’re unlocking content, and making it more accessible. As a side effect, my own learning process accelerates by summarizing, and I like to think I get better (and quicker) at distilling a talk’s message with every event. I’m creating a knowledge base of topics and speakers, as well as audience questions that I can use for my “own” events.
Also: nobody else is doing it, so you’d be hard pressed to find competing articles. Monopoly y’all.
Preparation is everything
Ahead of a conference I’ll have a look at the schedule. If it’s single track I’ll just copy the schedule into a markdown file. But I guess you could use HTML, or a plain text file as well, depending on your CMS. I just like the easy syntax highlighting markdown gives me.
If there’s more than one track, I’ll carefully select the talks I will want to see, and create my itinerary (including info on the starting times and rooms). Next I’ll copy in speakers’ bio’s, along with Twitter and GitHub handle. I might even look these people up on LinkedIn to see what their background is like. Sometimes I’ll create a (public) List on Twitter, with all the speakers in it, as well as the event’s account.
Hot tip: conference and meetup schedules are subject to change. Hence I’ll only start this process a few days prior to the event. And I always check Day 0 if my information is still correct.
Note taking
I’ve read all the talk descriptions, so I know when the talk “starts”. Until that point I’ll know if this is a talk where I’ll need to take notes, or where I can take pictures of slides, judging by the presentation style. Some speakers will tell you in advance when they plan to share their slides. If they don’t, and the talk was too high level for me, I’ll often just ask for a link to the slides, in person, or on Twitter.
After the conference I’ll upload the pictures to some cloud storage, and fill in the gaps in my notes.
Promotion
In case I’m covering a meetup I’ll ask the speakers if I correctly summarized their sessions before sharing the post. I genuinly want to get it right. But usually that also means they’ll share my post once I do. In a tweet about the post I’ll @-mention the speakers, the meetup’s account, and relevant hashtags.
A conference will have more speakers, meaning more opportunity for likes and retweets. But I’ll take the intimacy, improv and authenticity of meetups over fancy big conferences any day.
I’ll also privately share the link with people that are subject matter experts for the topics covered, or that know the people speaking. They’re bound to share as well.
Attending stand-ups for content discovery
I work in small teams where I can easily sit in on the daily stand-up meetings. There I’d hear about:
- Upcoming features and releases
- Challenges engineers faced and how they solved those
- Engineers’ take on trends
- Find projects to cooperate on / that could use gathering of community input
- Contributions to open source projects, whether our own or by other community members
- Working with other/new technology which might have DevRel people advocating for it, whom I can partner up with for content
I’ll then send the engineer owning the topic a list of questions that at the same time is the outline of the post already. For example:
With her answers — and a lot of search queries and Docs-reading — I’ll write a draft, which I’ll send back to check if what I wrote makes sense. Whenever I work on something with an engineer, her name will ultimately end up on the post.
From what I’ve seen, over time people expect you to want to write something about the stuff that surfaces in these meetings. And to my pleasant surprise will sometimes have prepared something already. When that happens I could just burst of joy. All I want to do is empower these people that are all so much smarter than me, as in the end they are the people behind the product.
This isn’t a best practices post, but rather my personal approach to writing developer content. I’d love to hear what you think, and what your go-to strategy entails, in the comments below👇
Huge thanks to Don Goodman-Wilson for proofreading this article.