How to Avoid Extinction as a Technical Communicator

In a career development workshop at the TransAlpine Conference in Vienna, Ellis Pratt, one of the founders of Cherryleaf, argued that technical communicators may eventually become extinct if they keep using the same methods and formats to deliver information.

Although there will always be a need for people to explain technical material non-technical people, Ellis said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it.

Ellis started by showing a thought-provoking video from Michael Wesch called “A Vision of Students Today.” In the video, students explain why the traditional educational model is outdated and at odds with the way they learn.

[youtube dGCJ46vyR9o]

Rather than reading textbooks, today students learn through text messages, virtual chats, Facebook updates, interactive media, blogs, wikis, virtual worlds, collaborative efforts, read/write behavior, forums, podcasts, videocasts, and Google searches. The old book-reading, classroom-lecture model of learning has fallen by the wayside. It’s just not how students get the answers they need.

Although students usually aren’t the target audiences of our applications, the same concept applies to software users. The long manual and online help are declining formats few want.

Ellis relayed an observation from Tony Self, a technical communicator who organizes conferences in Australia. Self says if you look at an online help file from 15 years ago, it looks about the same as a help file produced today. This stagnancy of innovation in the technical communication community is frightening.

Whereas Web technology continues to move forward with daily developments—from Web 2.0 to Bing to Google Wave to RFID technology that scans and displays information in real-time wherever you are—technical communicators are doing the equivalent of writing textbooks for people who no longer read them.

Ellis predicts that unless technical communicators make some changes, they’re not going to be around much longer. The role of teaching people how to use technology will be passed on to others delivering it in the formats the audience prefers, expects, and learns from.

But rather than postulating any kind of new media delivery of technology, such as wikifying all your content, or providing instant support through Twitter, or porting everything into Facebook, Ellis recommends that technical communicators solve a different but related problem: managing the diversity of information.

Because information is fragmented and scattered across a dozen different types of media and sources—RSS content, content management system content, training content, engineering content, support center content, user-generated content, web content, marketing content—a need is emerging for someone to manage it all.

Ellis thinks that if writers can evolve to fill more of a content strategy role, in which they manage the fragmented information, they will survive. Rather than being a “technical communicator,” their roles will more likely be content wrangler, information strategist, user-generated content editor, information assets director, and content use analyst.

Ellis said the idea of Content Strategy and the new role technical communicators must play is something he learned in part from Rahel Bailie and her Summit presentation, “The New Face of Documentation.”

My Thoughts

Ellis and Self are right about the lack of innovation among the formats for technical communication deliverables. We need to evolve. The problem is that there’s no compelling replacement for the traditional formats. A lot of good possibilities exist—wikis, blogs, interactive multimedia—but none seems to be the online help / manual killer.

Another problem is that many of the web technologies aren’t available behind the firewall, which is where much of technical communication occurs. PHP and MySQL (required for almost every Web 2.0 blog or wiki technology) are readily available online, but these open source technologies usually aren’t robust enough for large-scale companies who require MS SQL, Oracle, or other technologies. The Web 2.0 technologies available behind the firewall usually just include SharePoint 2007. You usually can’t take advantage of cool web technologies unless you’re actually on the world wide web.

Personally, I have been trending towards quick reference guides (anywhere from 1 to 8 pages) and short video tutorials (2 to 4 minutes) as my core deliverables. I also create an online help as a searchable repository of answers, but I create it with the idea that it will be searched, not necessarily navigated for information. Single sourcing the full online help to a printed manual is just another step, so I don’t omit it, but I don’t promote it much either.

Overall, I’m excited about the new DITA publishing capabilities of Flare 5, because it means you can push the content out to additional formats more easily. You can convert DITA to the Confluence Wiki format, DITA’s XHTML target to WordPress, DITA to InDesign, DITA to web pages, and other formats.

The key to solving the problem of information fragmentation is to get the content into a format that is versatile enough to be pushed to any format. If you can keep the original source in one location and just export to different formats for your audience, letting users choose based on their learning style and preferences, then you could perhaps solve some of the problems Wesch raises in his video. (The exception of course is video and multimedia, which you can’t simply output to.)

As for switching from content creators to content managers, I’m still a bit skeptical about this. Except for public, web-based, multi-author, open-source software models, I just don’t see a lot of users contributing help content to the corporate-grown applications (except for the big ones, such as Microsoft Office). Most companies want their help content to look attractive and be accurate, and few project managers believe users can and will fill that gap if you take away the technical writer.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

34 thoughts on “How to Avoid Extinction as a Technical Communicator

  1. Fabio Cevasco

    I agree that there’s no innovation regarding documentation format. Unfortunately, in so many professional context the CHM format is still the preferred format for online helps, mainly because it’s native in Windows and it’s familiar to both users and technical authors.

    Hopefully though, we’re (slowly) moving forward: DITA definitely offers more possibilities when it comes to output formats, but at least for now there’s no replacement for the standard Online Help.

    While I’m still VERY skeptical about non-textual media, like screencasts etc., as primary documentation format, I believe existing textual format should:

    * Allow readers to embed comments and feedback in documentation, which should then be sent to the authors
    * Improve accessiblity. Default search options in CHM and PDF are pathetic if compared even to traditional fulltext search. There’s also often no way to tag content effectively beyond a hierarchy
    * Be more integrated with the product (in case of software).

    Web content already offers all this, all we need is to bring it down to the client-side (maybe something similar to Google Gears?).

    Regarding the alleged incoming extinction of technical writers/communiators, well, no, it’s not happening anytime soon. Indeed we’ll evolve into information strategists and information architects, but that’s still part of the job, right? We’ll still be the ones making sense out of all fragmented information, feedback and how-tos and turning them into something more professional and useful, regardless of the output format.

    1. Tom

      Fabio, thanks for the comment. I didn’t give DITA enough attention in my original article. It is innovative and can help lube the gears, as my colleague said, to more efficient, consistent, and accurate documentation. But from the user’s point of view, it’s the same old thing.

      Regarding the ability to embed comments and feedback in documentation, I thought this would be a bigger hit than my experience has shown.

  2. Gordon

    I definitely think, as Ellis suggests, that our roles should be changing (should have been for quite a while). Partly I think we are too governed by the technology available in our own profession (we seem to tend to wait for the vendors) and partly because we still struggle to express the benefits of opening up information and embracing any/all new methods of communicating with the customer at a technical level.

    I’m in the midst of writing up my own blog post on this, and this is further good fuel for thought (as ever).

    1. Tom

      Hi Gordon, I agree that we tend to wait for vendors to supply the technology we need. If we technical writers were programmers, especially web developers, we would have much more innovation in our field. Because most of us don’t have programming skills, we often have to wait for others to do it for us. But this area is usually uninteresting to programmers.

  3. David Farbey

    Another reason why Help files today look pretty much like they did 15 years ago is the chronic problem of under-investment in technical communications. In most small to medium enterprises, and in many large enterprises too, tech comms staff struggle to get the budget to buy the minimum software tools they need, can’t get adequate tools training, and are rarely supported for trips to conferences and trade shows.

    So we end up doing the same old stuff with the same old tools. We’re not regarded as technical enough to be sent to learn the programming skills for DITA integration, nor creative enough to get to learn the tools for web design. We’re just expected to correct the spelling and grammar, preferably by yesterday.

    We can’t expect businesses to invest in us unless we show how we are adding value, and without investment in tools and training its difficult to demonstrate value. So we need to become more creative and more proactive in the ways we promote the business advantages of what we do.

    1. Gordon

      David, I disagree (partly). The ‘we don’t get the tools or training’ excuse is a thin one. Perhaps we need to focus more on our business skills first, so we can build the case to GET the tools and training (as you suggest, promoting the business advantages).

      That said, all of my web design skills are self taught, largely because I’m passionate about my profession/industry.

      And being expected to correct spelling and grammar is valid, we are the expert writers in the company. However I find a big dictionary, handed to people when they wander over, sets the tone nicely. I’ll happily edit documents though.

    2. Tom

      David, thanks for the comment. In responding to your comment and Gordon’s response, I think companies vary in terms of how much training and tool support they give to technical writers. Certainly tech writers who want to learn the skills can find a way, usually on their own time. But this extra effort isn’t something people usually do when they can get by doing the same old thing.

      When I’ve needed software that my company won’t buy, I usually barter a vendor to trade me a license for advertising. So far it’s worked almost every time.

  4. Fabio Cevasco

    I agree with you: it pretty much depends on the company you’re working for. Luckily, we (that’s 2-3 people out of the team) were allowed to allocate some time to research about DITA and come up with possible integration solutions. We’re basically ended up creating our own tool around the DITA Open Toolkit, and we’re now using it for some pilot project.

    Although I do not entirely agree with the whole DITA philosophy, at least it’s a standard and therefore compatible with many applications: if we decide to switch to FrameMaker, we could just import our custom-generated DITA topics into it, for example.

    Maybe you should point out to your boss the advantages of using DITA (the Open Toolkit in particular), namely costs: if you can *survive* the initial impact, then you could essentially produce documentation for free, without buying any expensive tools, and generate it in different formats (even if there are still quite a few quirks).

  5. Ellis Pratt

    It’s interesting getting feedback on what your audience took away from a presentation!

    For those that missed my presentation in Vienna, I’m presenting it again – in London on Monday 13th July. There’ll be lots of opportunity to discuss it, too.

    You’re right Tom – there’s no compelling replacement yet. What’s more, paper has been around for thousands of years, and it will still have its place. However, my fear is that technical communicators may not recognise the solution as and when it arrives. This is partly because, technical communicators seem to have been diverted into talking about productivity at the expense of looking at the value (of what they make).

    DITA offers a flexible tool for the future, The challenge is using that tool to fashion some useful objects now and in the future.

    The “behind the firewall” issue is an issue for large corporations, including banning of Twitter, YouTube etc. Perhaps the “move to the cloud” may be compelling in the future.

    1. Tom

      Ellis, thanks for giving such an awesome presentation. After reading your comment, I realized that my writeup didn’t discuss productivity (e.g., through DITA) at the expense of value. That’s an important point to emphasize.

      When you give your presentation in London, wouldn’t it be cool if you recorded it and then made it available on your website?

      Also, thanks for mentioning the behind-the-firewall issue. This is the second year in a row that I’ve petitioned our information architects to allow a PHP/MySQL solution. For all my expertise on WordPress, it goes largely unnoticed and unused at work. If it were available, you can bet I would be using it to deliver help, especially now that I’ve found a DITA to WordPress converter. I’m not sure WordPress would solve the problems Wesch raises in his video, but it might be a step in that direction.

  6. Larry Kollar

    Part of the problem with change is getting buy-in from everyone else who has a say in things. A single hidebound or fearful gatekeeper can pretty much block all progress. Meanwhile, you have work to do and it’s easy to just forget to pursue things when you’re underwater for several months. Something as user-transparent as moving from MS Word to something that actually works for technical documentation can raise all sorts of objections from the oddest quarters.

    Budgeting for new tools shouldn’t be a problem these days… it’s easier to adapt and deploy (and maintain) open-source tools than to adapt a complex DITA implementation. But making major changes to the way we deploy and present documentation can have all sorts of ripple effects, from development to manufacturing, and you have to get them all to catch your vision or call in a lot of favors.

    Sure, it’s worth the effort to move beyond what we’re doing now… but knowing how much resistance you’re going to get (and not just from your own department) is important.

    1. Tom

      Larry, you raise a good point. I hadn’t thought about the ripple effects and resistance from other groups. Usually people don’t care how I produce the documentation — they just want it. The uncomfortable part is when they ask for the original source to update or make edits themselves, and then realize they can’t edit InDesign or Flare. I suspect Word will always be around because it’s what everyone can update.

  7. Louis Marascio

    The winds of change are definitely blowing. As someone who is peering into this industry from the outside it’s very interesting to watch the change happen, especially following it on the various blogs and twitter streams. I wrote a similar but different set of thoughts recently on the LugIron blog, Old Media, Technical Writers, and the Evolution of Documentation (

    Thanks for the always insightful thoughts. Best regards,


  8. Arroxane

    The problem is not the technical communicator, but the organizations in which we work. The companies (and esp government) fail to think forward and allow their TW’s to experiment with publication and communication methods. They would rather their writers get pigeonholed into something familiar than set free to learn and apply new technologies. In the minds of the CxOs, technical writers are not technologists and therefore could not possibly contribute to new interesting ways of interacting with customers/users. Once companies realize that we’re not just Journalism and English majors without a clue, then we can expand our sphere of influence and be free to use the latest cool tools. Until then, we are forced to sit in our cubicles doing the same thing day in and day out to get our paycheck.

  9. Mike Starr

    We complain about help files looking like they did 15 years ago as if it’s awful. I’d suggest it’s only awful in the context of the design-oriented folks who feel that design must be overhauled on a regular basis. The questions I ask are:

    * does it provide the information the users need?
    * are users able to find what they need without tearing out their hair?

    I’ve also not drunk the Kool-Aid® with respect to DITA. From what I’ve gathered over the years reading various message traffic on various tech-writing email lists, I can pretty much accomplish the same things with my favored combination of Word, Acrobat and Doc-To-Help. I’m guessing with a little tinkering around I could also manage to output my content in a wiki format (or perhaps adapt a WordPress template to enable commenting on each topic). And why do I need wiki format? In order to return to the annotation capability that was built into WinHelp, graciously deprecated by Microsoft lo these many years ago in order to justify their attempt to throttle any web browser other than Internet Explorer.

    I’m far less worried about my personal extinction as a technical writer (yeah, yeah, yeah, I know I do so many things I should be titled a technical communicator or something even more impressive but I’m satisfied with technical writer) than I am about the extinction of technical writing as a profession. Meanwhile, we can continue to rearrange the deck chairs on the Titanic.

    1. Louis Marascio

      IMO, the biggest problem with the majority of help content designs is that they aren’t. The default web help output is taken from the authoring tool and plastered on the internet. Users aren’t able to find what they are looking for because more and more often the way users search for answers is orthogonal to how the the default help system is published. For example, much help content on the web is hidden behind javascript, frames, and non-semantic URIs. A lot of this comes from the fact that the authoring tools that produce much of the online help today are created for authors with the web help output not being designed properly for the modern way that users search, find, and interact with the answers contained within.


      1. Mike Starr

        If the search functionality embedded in the output from current authoring tools is broken, that’s an issue with the particular vendor. I’ve seen occasional complaints with respect to search functionality but I’m inclined to believe that the vendors are paying attention to those complaints and doing their best to make sure search works properly in order to stay competitive with other authoring tool vendors.

        However, we can mitigate that issue to a certain extent by creating a well-organized TOC and a comprehensive index (something many authors either neglect or have never learned). The authoring tools all allow the creation of these helpers for the user but if we don’t use them well it’s the users who suffer.

  10. Winston Thriller

    “Ellis relayed an observation from Tony Self, a technical communicator who organizes conferences in Australia. Self says if you look at an online help file from 15 years ago, it looks about the same as a help file produced today. This stagnancy of innovation in the technical communication community is frightening.”

    Then don’t let him near a book. Those things look about the same as they did hundreds of years ago.

  11. Paul Sholar

    The root cause of this problem is the relative lack of intelligence of the software applications that are being described. The idea that online user assistance can meaningfully and effectively guide the user in a context-sensitive manner to perform tasks mediated by the application is not actually feasible when the application itself is architected to be used in an “exploratory” manner, which paradigm was established way back in the days of Xerox PARC. Rather, the application should itself present a workflow of tasks and working data state to the user and also maintain the user’s “location” within that workflow, such that if at any point the user requires assistance, there is no uncertainty as to what the user is trying to accomplish, neither specifically nor as to end goals. The fact that there is no “framework” for user interfaces that provides a “micro” workflow model for an application is a major shortcoming in today’s software industry.

    Paul K. Sholar
    Twitter: @bkwdgreencomet

  12. brac

    I work for a large software company that takes pains to make documentation available in all kinds of different formats: blogs, wikis, webcasts, HTML, and so on.

    And time and time again, our customers tell us that they are primarily interested in receiving PDFs. Mind you, these people live on the Internet. They depend on blogs, wikis, webcasts, twitter and RSS feeds, and so on, for all kinds of information. But when it comes to reading in-depth technical documentation on challenging subjects, PDFs are still king.

    Where is Pratt getting the idea that people are favoring new formats for technical documentation? Just because blogs, wikis, and podcasts have taken off does not mean that books and PDFs are on their way to becoming obsolete.

    I’m all for making information available in other formats, but books and book-like formats (the Kindle, for example) will always be an important part of the mix.

    1. Mark in Canada

      I agree. I use several Web 2.0 technologies in my personal life but these same technologies have limited usefulness at work.

      I have to produce an output that satisfies all my customers, including those who may have firewalls, don’t let their users use the Internet, have old versions of Word, etc. I’m happy to produce any output, but most customers want PDFs.

      Our customers are also heavily regulated so they need electronic forms of our documentation for auditing purposes. This need simply can’t be met by blogs, wikis, webcasts, twitter and RSS feeds.

      Flogging technical communicators for not jumping on the latest bandwagon has become a tired subject. I can’t believe we’re still falling for it.

  13. Pingback: Lifelines to the STC | I'd Rather Be Writing - Tom Johnson

  14. Pingback: Identity and Authority. Why the Foundation of Documentation is Changing. | The LugIron Software Blog

  15. Milan Davidovic

    “Ellis predicts that unless technical communicators make some changes, they’re not going to be around much longer. The role of teaching people how to use technology will be passed on to others delivering it in the formats the audience prefers, expects, and learns from.”

    This is perhaps as it should be. Perhaps the role of teaching people how to use technology should pass to the people who create the technology. Perhaps those people should be building the “teaching” directly into the technology itself. Perhaps this is the best way for all of us to help those using the technology.

    There is a move afoot in the training and development world to change the role of training departments from delivering training to enabling knowledge to flow in organizations — in part, by having trainers step back from familiar roles and facilitating more self-directed, informal, and “on the go” learning by those who need it. It seems there’s something of this idea in Eliis’ prediction.

  16. Pingback: User Manuals In The New World « doQer

  17. Pingback: Miscellaneous Links For 2009-07-11 |

  18. Simon

    I’ve seen this video several times now. Yes it’s a good argument for a need to look how e-learning should be exploited amongst undergraduates. But Brace is right: in-depth technical instruction (not just ‘to do this, click this’ stuff) will always require ‘conventional’ documentation. Wikis, blogs, tweets, youtube etc. may be de rigueur at the moment, but none of these are suitable for conveying large amounts of *complex* information. If you doubt this, just check out the computer section of a large bookstore.

    My organisation is developing a suite of web-based applications that sit alongside our legacy products, and I’ve created ‘user assistance’ using all the above formats above since for some aspects, it’s the ideal medium. But 70% of what I write requires a level of detail, navigation, cross-referencing, and explanation that is best served in PDF or online help format.

    Let’s all remember what the most important aspect of being a technical author is: writing ability. Think about what you look for when recruiting an author; I always chose someone who’s writing skills are strong, as (IMO) it’s easier to teach a good writer about technology than it is to teach a technologist how to write. These emerging technologies should help us make decisions how to instruct our audiences, not define how we want to value our profession.

    Almost anyone can write a blog, tweet, create a screencast, and upload content to the web. If that’s how authors should market their abilities, I think we’re seriously underselling the value we can bring to an organisation. After all, does anyone else think that the ability to string sentences, paragraphs and pages together is a dying art? Not to mention indexing, information design, etc.? Good organisations know this, and ambitious authors can usually broaden their appeal by taking on other writing projects within an organisation. Company reports, marketing material, web sites, all require professionally written copy that not many people are good at. I certainly don’t want to avoid extinction/make my living by tweeting and the like, or moderating comments on a forum.

    Yes, let’s embrace these technologies, be aware of their benefits, and exploit them where necessary. But more importantly, let’s play to our strengths, and champion the need for professionally produced writing.


    1. Tom

      Simon, thanks for the detailed comment. Sorry for my slow reply here. I agree with you in principle but not in experience. Writing is often seen as a skill many people have. I was just in a meeting today in which we discussed communications for an internal conference. A developer and a PM are creating the trifold brochure, apparently. They don’t see writing as a skill, except for a grammar cleanup at the end. I’m curious to see what they produce. What people seem to value is the ability to design, to create multimedia, and to do the technical aspects of help that they cannot do. I’m not discounting the skills involved in writing, only saying that most people in the workplace don’t value it as they should.

    2. Tom

      One more response — I agree that wikis, blogs, tweets, and video can’t replace the core instruction that comprises the more traditional forms of documentation. But the other formats shouldn’t be neglected either, as they provide two-way communication with the users.

  19. Pingback: What Is It Like to Be A Student Today? ~ Generation Y, Social Learning, & User Assistance | Content for a Convergent World

  20. Pingback: Links of Note, June 2009: Technical Writing and Communication | Content for a Convergent World

  21. Pingback: The Seed of a User Community | Beyond Help

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>