A question that comes up regularly on Linked in forums is “What are the most important skills for a technical communicator to have?” I used to have a quick answer for that, but I realize it was based on how I learned to technical writing. But now many people in techcomm won’t be using a complex desktop publishing program to write manuals designed for print. They won’t be relying on the work of editors, illustrators, and a production team.
What I used to say
I used to think the answer was a strong sense of organization. Because that’s what technical writers did: They collected information from multiple sources (documents, interviews, hallway conversations) and turned that information, section by section and chapter by chapter, into manuals. Large, boring manuals.
It’s still not a bad answer, although I’d rephrase it. A technical communicator needs to know how to organize content, but that comes from understanding their audience and the context of the content. We build content as topics, or even smaller chunks, and then organize those into usable online help and knowledge bases. And sometimes even printable output.
What I would say now
I like to say “curiosity,” but that really doesn’t cover much. You can be very curious but have no interest in sharing that knowledge. But there is a combination of curiosity, willingness to do research, and the very, very important ability to turn that information into concise, readable content.
There’s something else: the constant drive to poke at things, to find out how they work, and to try to fix things that might not be broken.
If it ain’t broke…it can probably be improved
There are no perfect documentation tools. There are no perfect documentation processes. There’s always something that can be improved.
It’s probably not easy to improve the tools (without source code and a few years of programming experience), but I’ve never heard anyone say that they have a perfect process.
Maybe they’re just very quiet.
It feels like we’re finally getting serious about creating usable online content (and not just doing PDF-to-HTML conversions). And there’s this mobile stuff that looks like it might hang on for a while.
It just occurred to me that the techcomm industry has to love the fact that phones are getting larger. Although maybe for the wrong reasons, because it will allow us to waste space again. (Tri-pane help is bad; nested TOCs are worse.)
What’s this skill?
I guess I would call this “dissatisfaction.” Specifically, the opposite of complacency.
“Dissatisfaction” might not be the best thing to put on a resume. A better idea is something like: “I work to improve processes and tools, such as…”
If it’s good for engineers to spend 20% of their time working on side projects, it’s good for us, too.
How I’m applying this
That’s one of my goals for the next few months: critically analyze what I’m doing now, identify both where it’s failing and where it’s succeeding, and start fixing the weak points.
(And in an ideal world, hire someone with similar goals and compatible skills.)
I’ll let you know how it goes.