The right story for tech writers to tell in a corporate blog post
Despite the fact that I’ve been blogging for more than a decade, and in my spare time, I’d rather be writing, I have rarely engaged in any kind of writing on corporate blogs where I work. I have always found this a bit sad. I mean, while sure I’m a decent technical writer, I think I could hit a home run on a corporate blog if I applied myself to it.
While I was working on my latest post, Articulating the invisible stories that influence product adoption or rejection, I started reflecting more about my role in influencing product adoption, and I thought, you know, I really should be contributing more to my company blog. My closeness to the development scene gives me an awareness about the products, latest releases, user questions, developer interests and issues, and other details. I could easily use this knowledge to contribute more content. Why don’t I write a post?
So I started brainstorming the story I wanted to tell. In my first attempt at the blog post, I started out by quoting from a recent review in a third-party article, and then used the point the author made to springboard into a larger issue we were hoping to address.
That post didn’t even clear the first hurdle before it was rejected. I revised it and toned down a lot of things, submitted a second version, but it too failed the happy test.
I started to realize just how tricky corporate blogging is when it comes to story. In the story you want to tell on the corporate blog, you usually can’t start with anything negative about your company or products. Nothing even slightly negative — no objections users have raised, no market issues, no trending forum criticisms, etc. (Maybe there are some marketers with more open minds about transparency, but they’re rare.)
Given these constraints, what story could I tell? The very definition of story involves addressing some friction or challenge. And by definition, a friction is … negative, right? I mean, I don’t have too many “positive frictions” in my life. A friction is something that gives you resistance against what you’re trying to achieve.
I was about to give up and leave marketing to the marketers when it dawned on me what the right story is for a corporate technology blog: how to overcome technical challenges — the same how-to territory as docs. Tech how-to is the safe space for corporate blogs.
The cool thing about this angle is that, by focusing on technology challenges, you can still create a story arc (somewhat anyway). With this new perspective, I pivoted the post a bit and voila, everyone was happy with it. You can read it here: Voice-Enabling Your Media Transport Controls with Fire App Builder 1.0.7.
It’s not an exciting read, but I could push this kind of content out in my sleep. It’s essentially the same story that we tell in documentation — how to overcome technology challenges. And unsurprisingly, the “hero” that helps you overcome these technology challenges is usually your company’s product or service. It doesn’t have to be that way — maybe you could just write about general best practices for approaching difficult technical issues. But the connection to your company’s products is usually immediate and natural. That tends to make the corporation happy.
So if both tech docs and blogs focus on how to overcome technology hurdles, what’s the difference between blog posts and docs? One difference with blog posts is that they start off with a relevance hook. A documentation topic doesn’t have to establish why it’s relevant; it just gets right into exposition and instruction.
But with a blog post, readers want to know why you’re writing about this topic right now. What prompted it? So if you can find that hook, you’re set. Most hooks in the technology space are around product and feature releases. The release provides a perfect segue into some technical topic. And since tech writers are pretty much always working on some release, these topics are not hard to brainstorm. Other relevance hooks might be recent events, webinars, or industry news.
You might ask, what’s the point of writing corporate blog posts, especially if users can just find the same information in the documentation? Well, that’s a good point. Blog posts do contribute towards the larger effort to influence product adoption. But blogs also serve another purpose: they put you more squarely in the space of your audience. You don’t write a blog post without looking to see if it gets read, and how much, and whether it’s shared, and so on. This gives you awareness about the interest in topics, their popularity, etc., and this awareness spills into your doc direction as well. I find that tech docs are far too removed from the user space. Given that hundreds of people clicked my post about reconstructing the absent user, I assume that others feel disconnected to.
So I think I might experiment a bit more with regular contributions to the corporate blog and see what comes of it. If nothing else, the blogging might lead toward increased visibility for my tech writer role within the organization. Tech writers tend to stay in the shadows. Few people know we even exist, much less what we do. Blogging is about the most visible activity one can do, and who better to contribute to a corporate blog than … me?
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.