Latest posts by techwriter (see all)
- BOOK REVIEW: “Design for How People Learn” by Julie Dirksen - July 10, 2017
- 12 Top Characteristics of a Good Technical Writer - July 3, 2017
- What Are the Qualities of a Good Technical Writer? - June 28, 2017
© Ugur Akinci
Tom Johnson is a well-known technical writer who works for the LDS Church in Utah, USA. Tom has ranked #1 on MindTouch’s 2011 list of 400 Most Influential Technical Communicators.
QUESTION (1): How long you’ve been a technical writer? Where do you work right now? How would you characterize a typical day at work?
I’ve been a technical writer for about seven years. I currently work for the LDS Church in Utah. A typical day at work depends on what project I’m working on, but it might include updating help information on the wiki for LDS.org applications and working on content for the LDSTech blog. For more detail about my typical days, see this post or this one.
QUESTION (2): How did you become a technical writer? Did you start out as one or did you switch to it from something else? What was the reason?
I started out as an English teacher in Egypt, teaching writing to college students. I then worked as a copywriter for a time, but then switched to technical writing for better pay. I found out that I enjoyed technical writing more than I imagined. I enjoy the combination of writing and technology. I wrote about this with more detail in Becoming a Writer: Reflections on a Trip to Idaho.
I think as a whole, we’ve seen some changes in the industry, such as the increase of content management systems, the implementation of DITA, and the increased use of web platforms for help. But overall, I don’t think the tech comm field has been that full of innovation. Part of the problem is that technical writers are mainly writers, not tool creators, so our innovations may be less tool-dependent and more content-centric. Some tech comm professionals have piggybacked onto the innovation of the web, but documentation requirements around content re-use and translation don’t often find their way into web tools.
I wish I could point to something and say, oh, definitely structured authoring. Or definitely the use of videos. But at the end of the day, these are little branches from the main tree, not a huge shift in the whole field itself. Of course, I’m still young by comparison. You’d probably get a better response from someone who has been a technical writer since the 1970s, like Neil Perlin.
Still, the question intrigues me, so I will expand on what I think the greatest transformation in technical communication should be. The greatest transformation yet to come is to drop the single-author paradigm of technical writing and to embrace the way information flows on the web.
Let me expand. For years help authoring has consisted of one person (or just a few people) writing help material. When content comes from one person, the content is usually limited in perspective, accuracy, and applicability. Writing needs to become much more collaborative, and not just from inside the corporation, but outside as well. Documentation is never finished. When I log off for the day, someone out there may be contributing to the documentation, making it evolve, adding sections, correcting errors, expanding on special cases, and so on.
It’s engaging to come into the office in the morning and review the latest changes to the wiki, to find that someone added a new section, or a new page. We no longer have documentation as static, standalone files that are written in haste by one technical writer and then “finished” as he or she moves to the next project. Documentation is a living, breathing body of information – like the web. The web is in constant flux. It’s full of a whole landscape of people – trolls, spammers, forum champions, lurkers, relentless volunteers, bloggers, programming whizzes. All of these people, like characters in a circus, come together on the same stage, interacting with each other in rich, multifaceted ways. Sometimes these interactions are exciting, other times they’re frustrating. But either way, documentation evolves to become more web-like in the ebb and flow of information.
This ebb and flow of information is what I find most rewarding about technical communication. Information no longer emanates from one source but rather connects into a greater body of people. This is the genius of the web. The web thrives because of this content interaction — one person building on the ideas of another in collaborative, interactive ways.
QUESTION (4): In your judgment, what is the best and worst thing about working as a technical writer?
The best thing about being a technical writer? I like a lot of little things — figuring things out, writing, involvement in project teams, exploring ways to deliver help content, participating in usability, studying, findability, and web writing. But probably the best thing about being a technical communicator is to be a player in the web information landscape I described above. This is partly why I like blogging so much – it’s the same interactive web space.
As for the worst thing about tech comm., it’s being assigned so many projects that I can’t dig deeply enough to provide solid help material. I dislike knowing that I can do a better job but just don’t have the time.
QUESTION (5): What’s your advice for those who are just starting out their careers as technical writers today?
Find what you love to do and focus on that. There are plenty of specialties within the field – usability, eLearning, social media, structured authoring, findability, collaborative authoring, etc. Find what you enjoy doing and focus on it.
Also, don’t be afraid to experiment and take risks. Try different approaches, even if your department seems to restrict it.
Finally, maintaining a technical writing blog is a great way to spur innovation, since it encourages you to analyze your professional experiences.
“Don’t be afraid to experiment and take risks…”
QUESTION (6): What are your views on globalization, out-sourcing, and the way it affects technical writers in the USA, and abroad?
I have not had to deal with globalization and out-sourcing within tech comm in a direct way, so I don’t have strong opinions on this. Certainly these trends could completely disrupt the U.S. tech comm. job market, forcing technical writers to compete on a global scale with people who can do our jobs more cheaply. But good help material truly requires someone with a command of the language, and not just language, but command of other skills as well, such as video, illustration, and web publishing. It’s hard to get that level of quality when the writers aren’t located next to the development teams. However, if the development teams are outsourced, then it makes sense to outsource the tech writing as well.
QUESTION (7): Ask yourself a question that we didn’t ask and answer it please.
“Why aren’t wikis more common among technical writing departments?”
When it comes to translation and content-reuse, wikis have some shortcomings. But here’s the real reason more people aren’t using wikis: Almost no one has figured out how to harness the wisdom of the crowd and crowdsourcing in productive ways within technical communication.
By the way, “wisdom of the crowd” and “crowdsourcing” are not synonyms. Wisdom of the crowd refers to the collective wisdom that you glean from so many independent minds contributing towards a decision or judgment. Crowdsourcing is how you harness the labor of the crowd through thousands of micro-contributions to accomplish large projects. Figuring out how to harness either is tough.
I have a lot of interest in this subject because, in the environment I’m in, willing volunteers practically surround me. But I’ve found that simply inviting volunteers to write does not work. Writing tasks suitable for the crowd must be simple, easy to complete, and chunked so they can be completed in any order.
I have a community project that has about 70 volunteer writers on it. In the past I’ve had them write articles for the LDSTech technology blog. It worked all right, and it was great to get so many volunteers writing, but the management cost was significant. I didn’t feel I had a system working in an efficient, machine-like way. Eventually, I’d like to figure out how to apply crowdsourcing and the wisdom of the crowd to technical communication in an effective way.