What I Learned About Tech Comm During 2011
December 28th, 2011 | Posted in blog 23 Comments »
This past year I learned a few things. As I approach 2012, I’d like to note what 2011 taught me:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Sitting 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.)
- 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.
- 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.
- 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.
Sponsors
Tags: 2012 planning, centralization, collaboration, corporate, corporate blogs, david weinberger, fiction, goals, Mediawiki, metadata, projects, proximity, sedentary lifestyle, Wikis
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
3847 Subscribers
Mark Baker (9)
Jim Reardan (5)
Jonatan Lundin (5)
VS (5)
Greg DeVore (4)
bg (3)
Caroline Jarrett (3)
Aneesha (2)
Craig (2)
DiSc (2)
I was thinking along the same lines this week but I never got to writing it down. The part about “non-writing tasks” eating up your day is SO true when you have your hands in 10 different pies. I was really stretched thin this year and you are very blessed to have so much influence on your work load.
I love your blog. Thanks for inspiring me!
Christina, thanks for the note. It’s good to know that I’m not the only one who struggles to find time to write in a writing job.
Here’s one of the many, many things I like about your blog, Tom: the great amount of self-awareness you evidence. This year you’ve learned about your preferred way of writing, your disinclination toward multitasking, your nutritional needs, and your preference for non-fiction. A very good year, I’d say.
Regarding nos. 5 & 6: I hope you’ll keep writing about these topics. I listen a lot to “DITA evangelists” who tell us that the future is all about collaboration and content-over-format — and, to be honest, I tend toward these views myself. Some writers are very comfortable with the idea of giving up control of the format, but many are not. Those of us in the former group need to hear from those of you in the latter group, so that we can better understand the issues involved and work to accommodate your preferences. Similarly, some writers are more comfortable than others with opening things up to the crowd and “letting them run with it.” On this one I think that my view is much closer to yours, but again we need to sustain a dialog so that one side doesn’t feel like it’s being dragged kicking and screaming into what looks to them like a very scary future of tech comm.
Larry, thanks for your comment. I will definitely keep writing about topics 5 and 6. The wiki is actually a centralized help authoring system, right? So I’m somewhat contradicting myself here. I am also going to keep writing about findability. My thought is that after writing 100 posts on the topic, I’ll have enough information and awareness to put together a book of some kind about it.
Thanks for sharing this list, Tom. I share many similar observations and a similar list. I also tend to read many of the same books that you read. The biggest difference is, you’re more brave than I am about sharing your goals. Maybe I’m afraid that someone will hold me to them.
Happy Holidays to you and your family.
Thanks Eddie. Re sharing goals and transparency, I think I’ve become more accustomed to this being a blogger for the past 5 years. Of course a tech comm blog is still in the professional rather than personal sphere, so it’s not that transparent.
If you want to read a relevant non-fiction book that’ll knock your socks off, try “Thinking, Fast and Slow” by Daniel Kahneman.
Thanks for the recommendation. I’ll check it out.
Corporate blogging is the most boring thing to do on earth. Period.
I am a vegan, but still find it difficult to keep up good health as I am working for a long time from my desk. I guess we need to do some form of rigorous exercise for at least one hour a day. Right now, I am walking for half an hour and resting for the remaining half
Raj, your point about corporate blogging being boring hit home with me. I’m glad to know I’m not alone with this sentiment.
Loved it!
Tom,
Regarding number 5, I suspect your experience here illustrates the fundamental problem with the way such tools are designed and implemented today. You say that you rely on a single, ususally remote, person for publishing. This suggests that you either still feel, or still acutally have, end to end responsibility for the help system, including its publication. If not, you would not depend on that person, thought they might depend on you.
I’m having a really interesting conversation with Laura Palmer in the comments on Scot Abel’s blog post http://thecontentwrangler.com/2011/12/13/technical-communication-2012-our-biggest-challenge-is-thinking-differently-about-being-different/. We are talking about technological determinism — the way that our tools shape how we think about our tasks.
One of the ways that desktop publishing tools shaped how we think about the tech writing task was that it gave authors end-to-end responsibity for a document, right throught the publishing process. When we move to a centralized publishing system, we still keep that DTP model of the task, still making authors responsible for publishing while taking from them the ability to control it. Responsibility without control is always frustrating.
If publishing is part of your responsiblities, then naturally you want to have control of it yourself. These systems are never going to be comfortable for writers to use until the writer’s responsibility ends with the submission of valid content and publishing is entirely the responsibility of someone else.
But the way the current tools are designed acutally makes this very difficult, because they still tend to have WYSIWYG interfaces, which encourage the author to think in publishing terms, and because they don’t capture or verify content structure rigorously enough to ensure that if the author submits valid content so that the content will always publish correctly.
These tools are, in short, bastard hybrids of a desktop publishing system and a structured writing/database publishing system, and they are frustrating to use because they are neither one thing nor the other.
“Responsibility without control is always frustrating.” Insightful comment. You captured the frustration perfectly. Part of the problem is that the system is still being developed and implemented, so it’s not yet finished. Also, it works best for certain types of documentation projects, not necessarily mine. If all I had to deliver was content, and not publish it, that might alleviate concerns. But I have never worked in such an environment. Tech writers have always been publishers too.
Relatively few tech writers have worked in a properly constructed structured writing systems with a proper and effective segregation of roles. Many of the structured writing tools/implementations out there do not do a good job of this segregation.
What I have seen, over many years of helping people adjust to properly segregated structured writing systems, is that it takes a while for them to get over the need to see what the output is going to look like. There comes a certain point after a few weeks where they suddenly let go and begin to trust the system and the process. You can almost see the their shoulders rise as they shrug off the weight of publishing responsibility. At that point I have had more than one person say to me that they never want to go back to FrameMaker again.
What I have come to realize is that it is actually much easier to persuade someone to take on a new responsibility than to give up an old one. Savvy vendors realize this and layer new functionality on top of the old, rather than making something new and simple and easy. Writers have become so used to complexity that they don’t trust simplicity.
It is the reason, I suppose, why tech writer’s jobs seem to be becoming ever more fragmented. The irony is that while tech writers are devoting most of their energy to learning new media and new media tools, companies are putting an ever-greater emphasis on specific domain knowledge in their hiring criteria. I worry that writers are becoming so focused on where media are going that they are losing sight of where content is going.
Short version: “Me, too!”
About five years ago, I got the chance to work for a company that used a wiki to deliver documentation. I came from the FrameMaker-to-PDF (or online help) world, and I was happy to leave it behind. I do like Frame, but I love the immediacy of wiki documentation.
I’m now the entire tech writing department for a small company, and I while enjoy being the content creator/standards setter/publisher/wiki admin/etc., I miss being able to bounce ideas around with other tech writers. Thanks for sharing your ideas, since I’m using your blog (and Mark Baker’s) as something of a surrogate team.
I’m glad to connect with another wiki administrator. The immediacy of the content online is a huge step forward, in my opinion. There are shortcomings, for sure, but just having the information be online and stay online seems like the way to go.
Hi Tom. Your blog is one of the reasons why I started blogging. I also heard you speak on social media in the past. I always love reading what you are learning about and exploring through your blog. For this reason, I have chosen you for the Versatile Blogger Award. I was chosen (http://techeditors.wordpress.com/2012/01/14/someones-actually-reading-my-blog/), and I have in turn chosen you as one of my most inspiring and useful blogs that I read on a regular basis. Congratulations and keep on blogging! See my post for the rules and links about this award.
Michelle, thanks for the Versatile Blogger Award. I really appreciate the feedback and am glad you find my blog useful. In looking over the award, I see that I’m supposed to identify 15 blogs I read that would also fit the same category? That seems a bit extreme, if it gets passed on to 15 people, and then the award would be distributed 15X15, or 225, on every iteration. At any rate, it made me feel good about my blog.
I understand. I listed 15 in my blog post, but only “awarded” 5 or so I think…. It definitely started to feel like too much. Thanks for writing your blog!
Good blog post, Tom.
A few follow-ups: As noted by many of the other commenters, the post identifies some of the challenges of writing in the team-based, open environments that many advocate. The lack of control over formatting has been mentioned a lot by other commenters, so I won’t belabor the issue.
But the challenges of working with “volunteers,” is one that is rarely mentioned when discussing SME-authored and user-generated documentation. Having had worked with volunteers in a number of sectors over the years–from work-related ones to community ones–the issue of volunteer management is one that still challenges all of them. Incentives and clarity help, but not always in the way intended. Even in areas that have years of experience with volunteers, it’s more of an art than a science. Just because we’ve moved to community-based approaches to documentation and the wikipedia has been successful doesn’t mean that other ventures don’t involve nurturing.
As far as meta-data goes, some recent research presented by John Killoran at the STC Online Conference on Research to Practice suggests that, despite its potential, it’s not playing the central role in cataloging the Internet that we have been led to assume. You might familiarize yourself with that presentation; although understanding meta-data might still be a good goal for the year, following the Search Engine Optimization discussions and understanding how Google and other search engines currently catalog content might yield better strategies.
Last, to understand the cognitive reasons why focusing tightly on 2 projects has provided better results than focusing on many, check out Decisions: We’re maxed out say Montreal reearchers at http://www.montrealgazette.com/technology/Decisions+maxed+Montreal+researchers/6030734/story.html.
Saul, thanks for commenting. I value your insight. I’m intrigued by your note about the challenges of working with volunteers. I haven’t run across too much literature that discusses strategies and challenges about working with volunteers, yet it seems extremely important in my own role, as I work in a non-profit organization with a lot of volunteers. I think I may reflect on this more in a new post.
Also, it’s good to hear my fascination and later disappointment with metadata wasn’t misguided or isolated. I wanted to make it work, but either I don’t have the right tools, approach, strategy, or something.
Tom,
Much of the material about working with volunteers comes from 2 places. The first is the practical literature for working with volunteers and volunteer boards. There’s a lot of how-to articles, most focusing on how to clarify expectations. The second is actual experience of people who work with volunteers–and following which tasks they leave to volunteers and which ones they leave to staff. One of my students research volunteer leaders for her masters thesis and one of her cases was of a volunteer who ultimately failed on the job–but mostly because she realized through volunteering that she wasn’t all that interested in the organization. She only volunteered because she thought it would make her parents happy.
The metadata research was surprising but it’s typical in the technology field. Ideas, technologies and stuff that we think should work don’t always work the way that people intend or want. That’s why my appreciation for empirical research grows each year–because it kind of tells us what’s really happening.
Tom – I’m a bit late seeing this post – excellent ideas as usual!!
I especially like the idea of Tech. Writers sitting/working in their project teams instead of having all the Tech. Writers in a separate area.
Melanie