What I Learned About Tech Comm During 2011

by Tom Johnson on Dec 28, 2011
categories: technical-writing • wikis

This past year I learned a few things. As I approach 2012, I'd like to note what 2011 taught me:

1. Writing documentation in a wiki suits me for the same reasons I enjoy interacting on the web. The web is interactive, alive, dynamic, collaborative, fresh, and unlimited in potential. A wiki, being online, allows me to partake in the same game-like, community-rich environment that I thrive in.
2. It's much better to focus on just a few key projects rather than spread myself too thin. I made the mistake of extending my reach into too many projects this year, sometimes taking them upon myself because the applications needed help. As a result, I wasn't as informed as I usually am about the most important projects, and it showed. Later I pulled back and ignored everything but my two main projects, and I felt much better with this strategy.
3. I need to set goals to write at work. It's astonishing how non-writing tasks can eat up the day. Lately I've set a goal to write for 4 hours a day at work. I rarely achieve this, though really this goal has caused me to reflect on what writing actually is. If I'm reviewing forum threads to detect issues to write about, or experimenting with a test system to determine steps for documenting a task, isn't that writing? The typing part comes at the end and is fairly minimal. Regardless, just setting a timer on my iPhone prompts me to dig into the documentation topics and produce something tangible.
4. Content marketing, played out in the form of corporate blogging, is kind of boring. Corporate blogging isn't what I thought it would be. Mostly the corporate scenario is stifled by lack of creativity and freedom to explore. You're expected to toe the line, to avoid controversy, to vet each post through five levels of approval. Comments from readers are usually brief, unenlightening, and often don't match the topic of the post. I find technical writing more engaging.
5. A centralized help authoring system is a neat idea, but I hate the lack of control. The idea with a centralized help authoring system is that you install the system on a server with all your styles defined in one central location; an administrator sets up everything to be a push-button publishing solution, and then everyone else just "focuses on content." However, when you're used to designing your own help solution, learning to rely on one (often remote) person is discomforting. I like having some control over the design, layout, style, and publication of my help material.
6. Community collaboration is extremely tough to pull off. I can't just assign a volunteer writer a topic and let them run with it. I usually have to either gather the information from a subject matter expert or connect the volunteer with a subject matter expert -- and then see them through the process with more hand-holding than I want to provide. Still, community volunteers can generate momentum by the sheer number of assignments I have to follow through with. Overall, I have no idea how to engage community volunteers in an effective way, but I think I can eventually figure a strategy out.
7. Sit*ting embedded with my project team is more effective than sitting with other technical writers. Sitting with my technical writing team, I end up collaborating a lot on standards, goals, styles, and other issues -- which can be useful and important. However, the core substance a technical writer relies on is project-related information. No matter how many IRC meetings, scrums, iteration reviews, and other interactions, nothing replaces the information and rapport you get through proximity to the project team. However, proximity to the project team is just one element. Proximity to end-users is even more important. (See my post on The Proximity Problem for more analysis.)
8. Just because my job involves sitting at a desk all day with little movement, it doesn't mean I'm fated to become a couch potato. By counting calories and following a whole-foods, mostly plant/fruit/grain diet, I can actually lose weight while improving my overall health. I'm not becoming a vegan or anything, but I had no idea how poor my eating habits were. The My Fitness Pal iPhone app gave me a wakeup call. The Forks Over Knives documentary on Netflix also made me question the integrity of the traditional food pyramid.
9. I'm not that interested in fiction. In the fall, I went through a fiction phase that lasted a good three months. During that time, I read and wrote more fiction than I have for the past 10 years. I eventually lost interest and realized I was more attracted to non-fiction for reasons I can't entirely explain. I like the immersion in ideas (not that fiction is idea-less, but the ideas are shown rather than explained). I enjoy the sense of being "on top of the game" when I'm immersed in non-fiction (such as findability topics) and blogging about these same ideas. It infuses me with a lot of enthusiasm for my job, this blog, and my overall career.
10. Metadata is the most compelling strategy for findability, but I don't know how to harness it yet. I experimented with the Semantic Mediawiki extension in a help system, and I liked the ability to tag and query topics in new ways, but I didn't explore this strategy enough to be successful with it. I feel that I've only scratched the surface. There is so much more to discover. David Weinberger's book Everything Is Miscellaneous, which explores metadata in depth, was the best book I read in 2011.

Based on what I've learned, as I go into 2012, I plan to do the following:

• Use Mediawiki more.
• Set goals to write more at work.
• Focus on fewer projects.
• Possibly hire an intern to help with the corporate blog.
• Leverage community volunteers for non-writing tasks.
• Eat smarter.
• Read more non-fiction books.
• Figure out metadata and findability.

Note: I do change my mind frequently, so no doubt this list will evolve as the months in 2012 pass by.