Quick thoughts on useful skills for technical communicators

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.

5 thoughts on “Quick thoughts on useful skills for technical communicators

    1. It’s very likely that I read it on your blog and it stuck with me.

      The opposite would be complacency, which is deadly to a technical communicator. It’s true that at some point you need to step away and say that the deliverable is good enough, but I think the key point is that a successful techcomm professional really says, “It’s good enough…for now.”

  1. The ability to empathise with SMEs (and not just the audience) is an important skill to add to the list. We often need to be able to get technical information out of SMEs who may be very busy and/or lacking social skills themselves. Being able to figure out how to get them to respond to you as openly as possible is a skill in its own right.

    Interesting that Mark brings up what drives him. A client asked me that the other day and I had no answer. I really don’t know why…maybe it is dissatisfaction and I hadn’t recognised it?

    1. I call it dissatisfaction because it’s the feeling I get when I look at my docs, or my tools, or my processes in general and think: “I know that could be better.”

      The difficult part is figuring out where to start, how much I can do, and to define an end point (or at least an end point for now).

      Empathizing with SMEs: That’s a great point. Oddly enough that’s exactly what I was starting to write as another post before I switched to this one! (Although I didn’t think of it as “empathy,” which is a really nice way to consider it.)

  2. We’ve developed a four-question test to help evaluate whether a job applicant would make good technical writer. The first question consists of two typical extracts from some of our older documentation: “Based on what you have read, list some questions that you would want to ask to start to understand and improve this description.” The answers (or lack thereof) are very revealing about the candidate’s curiosity, systematic thinking, and ability/willingness to engage with and analyze complex material.

Comments are closed.