Here’s an interesting contraction: The work of software engineering produces a lot of interesting text — as a matter of procedure — but developer content marketing tends to be mediocre. 🤔
Think about all the text that emerges from widely accepted software development practices: PR reviews, retrospectives, stand-up meeting notes, hackathon presentation decks, RFCs. The list goes on.
The problem is that much of this content is internal and the people producing it either aren’t aware of how interesting it actually is or don’t know how to translate this work into appealing, approachable content for outsiders.
One solution is to bring on a writer who’s as interested in reporting as writing. I’ve incorporated reporting into my content work both as an employee and as a freelancer and the results always surprise me.
When I worked full-time for the dev tool company Sourcegraph, I was almost overwhelmed with possibilities.
Slack was bursting with channels I could snoop on; there were multiple internal newsletters that could keep me in the loop on new experiments and projects; there were endless sales call recordings to listen to; and, of course, there was GitHub, where I could find the traces and the results of enormous, fascinating efforts. 📚
I embraced my inner reporter (as well as my inner busybody) and read as much as I possibly could. And it really was like reporting because no single finding was sufficient for an article but plenty of findings formed leads that I could follow up on via Slack DMs or Zoom calls. 🕵️
As reporters well know, some of these leads went cold. Some leads were exciting but the work being done was still in progress; some leads looked interesting to me but not to an experienced developer; and some leads were only compelling seeds that needed more cultivation.
The trick is being confident good content will emerge but humble enough to know that you won’t always be able to guess where and when it comes from. 🌱
You can predict, however, that if the development work is interesting, then the results of reporting on it will be interesting to other developers.
But you can’t predict how or whether the stories you find will be easily recognizable. Here, it’s best to ditch inherited categories and familiar patterns like “thought leadership” and “blog post.”
Instead, embrace your inner reporter, immerse yourself in the work and the text that emerges from that work, develop a nose for interesting leads, and pursue those leads through more direct methods (or ask a freelance writer for help 😉).
The initial result won’t always be fully-fledged content but it will almost always lead to or inform content down the line. Most importantly, you will take one of the hardest problems in developer marketing — how can non-technical marketers come up with enough (good) ideas to fuel a developer-first content strategy? — and solve it in one fell swoop.
If you listen well enough, you’ll have more ideas than you can choose from. 👂
Top comments (0)