Guest Post on Firehead Blog -- "Finding a Content Strategy for Your Blog"
Today I have a guest post on the Firehead blog, run by CJ Walker. It's called Finding a Content Strategy for your Blog. Here's an excerpt:
To have a successful blog, you have to push out content on a regular basis – several posts a week, if not more. Not only do you need frequency of content, but also consistency in the topic. Basically, you have to pick a focus for your blog and stick with it every week.
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.
Phew, I got to all six of the articles in this series in one go. But you've got the advice spot-on, be it a large enterprise with tons of writers, or a small startup where you are the jack-of-all trades - you need to prioritize strategic projects, and you need to work on developing relationships with your sponsor in leadership.
I think this should be mandatory reading for every technical writer, especially advice point #2. It rings alarmingly true for me as I look back on my career so far.
The times I've added the most value were when I dedicated myself to single process or product. Over time, I built targeted knowledge of that product and began to act on a higher level than the proofreader/spell-checker function so many SMEs expected me to fill. This focus allowed me to show my peers two things: 1) that a technical writer can contribute to the direction of a product instead of simply describing it; and 2) that a technical writer's primary output (the docs) noticeably improves with domain knowledge - to the point that it actually makes sense to have a writer doing the work instead of an engineer.
When you consider that many writers report being outnumbered by developers in an IT company, it's no wonder if managers have trouble recognizing what a high-performing technical writer looks like. They are probably used to seeing us in a watered-down, clerical state.
Thanks Joe! I love the way you've articulated your comment. I agree that many people have trouble recognizing what a high-performing technical writer looks like due to the ubiquity of the watered-down, clerical state that so many operate in.