This month I was called in to assist on a technical-writing project that uses old technology. Really old technology. Which got me to thinking: the variety of output formats for our content, the number of tools for developing that content, and the range of skills needed to master all of the above, have never been greater. What does that mean for the people in our profession?
I began working in technical communication around the time that disco died (thank heaven) and Jimmy Carter was wearing cardigan sweaters. Everything we produced took the form of printed documents. At IBM we used a relatively new markup language called SCRIPT/VS, with which we could control indentation and vertical spacing. The U.S. Government, then as now one of the most prolific publishers on the planet, had embraced MilSpecs (military specifications).
Most technical communicators at that time were still in the “hot lead” world, composing on a typewriter (usually) and than handing their content over to be typeset and printed on a literal printing press.
1980: Print, print, print
I’ve drawn a pyramid to represent the output formats and tools we worked with then. There weren’t very many of them, and the distance from the bottom of the pyramid to the top — in terms of training and skill set — was pretty small.
1995: Brave new online world
By the time I’d settled into mid-career, desktop publishing was all the rage. Microsoft Word (introduced in the mid ’80s) was already a staple of most Tech Comm departments. The World Wide Web, as it was then known, introduced many technical communicators to a new kind of writing: semantic-based tagging, in the form of HTML. We were excited to see our content displayed on computer screens and not just on printed pages.
The old formats and tools were still in place — although “hot lead” was fast fading from the scene. But the pyramid had become more crowded. The distance had increased from the top, where the cool kids got to play, to the bottom.
2014: Publishing everywhere
Nearly 20 years later, the pyramid has grown again. Many Tech Comm projects are still done in Word — probably more than with any other single tool. MilSpecs are still in common use. Hard-copy (or at least PDF) still predominates.
I used to tell my students they could do practically any job if they knew an authoring tool (besides Word), a help-authoring tool, and a graphics tool. But today’s jobs increasingly require new skills like structured authoring and mobile-app development.
But we’re also creating content that’s integrated with the technology, and content that displays on tablets and smartphones, using new tools that are both text-based and graphical. Today, there’s a sizable leap from the skills needed to work with the old technology to those needed to work with the new.
2020: To infinity and beyond
In the not-so-distant future, I see us making use of even more new formats and tools. Augmented reality. Wearable technology. Things we don’t yet have a name for. Yet the demand for Word, for PDF, for the older technologies, won’t go away. The pyramid continues to go higher.
So what will our profession look like?
- Are we evolving to a place where everyone is a specialist and no one is a generalist? After all, while anyone can master a few technologies, it’s impossible to be proficient in them all.
- In light of #1, how will we buck the trend toward recruiters who seek candidates based on the tools they know?
- Will certain parts of the Tech Comm business — particularly the parts that rely on the older technology — become commoditized? (For that matter, there’s significant support for the idea that the whole profession is becoming commoditized, and I can’t say for sure that it isn’t.)
- What’s the best way to train people who are entering the profession? People who are already in the profession and who want to burnish their skills?
I very much want to hear what you think. So please drop me a line (or several lines) in the comments area.
Leading Technical Communication 
Pingback: Hot Lead to Hot Technology: Whither Technical Communication? | TechCommGeekMom
Hi, Larry. Great visual analogies of how tools have evolved. Personally, I think any good technical writer can learn any technology. After all, the process of learning something is largely the same across tools. Here’s an example: I, with no technical background, have learned to write and document XML, simply because I had to to do my job, And I think any technical writer who isn’t drawn to technology should probably not be in this field to begin with.
What many technical writers lack, of course, is good writing skills. But that’s another rant. 🙂
Thanks for the great post.
Thanks for the compliment, Karen. I agree that good technical writers must be (and are) adept at learning new technologies. But do you think it’s becoming harder to learn the technologies, simply because there are so many of them and so many kinds of them? That’s what I’m wondering.
I think it’s a question of keeping up with all the new technologies. That’s what I struggle with. I’m confident I can learn any tool or technology, once I decide to adopt it, but I do feel overwhelmed when faced with the numbers of tools in use in tech comm today. How can we know which ones are most relevant to our current and potentially future projects–since we obviously can’t adopt all of them?
As a matter of fact, if anyone can answer the question of “how to choose which ones,” I’d like to buy them lunch. And dinner. And flowers once a week for the rest of the year.
Larry,
I would recast the question slightly. I don’t think technical communication is in the least bit of trouble. But technical communication (as an activity) is very broad-based. Almost everyone in the corporation communicates about technology and process as whole or part of their job, particularly roles like tech support and sales engineering, which are full-time technical communication roles. That is not going away.
What may be in trouble is technical publishing. Technical communication may not be going away, but conventional publications as a vehicle for technical communication may well be going away, and are certainly diminishing. The Web has created a grand colloquium of technical communication in which the traditional model of publication — the delivery of stand-alone static tomes — does not fit well at all.
Most of the tools you mention are publishing tools. (I would except structured writing, but what many people mean when they say structured writing today is in fact a publishing tool). If technical communication is becoming commoditized (by which I take it you mean that it has become price-driven) is is because the editing/production/binding/distribution functions of technical publication are commodity skills.
We need to change our focus from technical publishing to technical communication. That is a career with a future.
Thanks, Mark. You make a useful distinction between technical communication and technical publishing. But you might be using “publishing” in a narrower sense than I would. Whether content displays on a printed page, a traditional website, an iPad; whether it’s static or dynamic; each instance involves a “publishing” action.
Yes, editing/production/binding/distribution are commodity skills. But (except for binding) they’re also processes that affect the way we design and develop content. As we style ourselves technical communicators rather than technical publishers, we ignore those things at our peril.
Hi Larry,
Yes, there is certainly a broader definition of publishing we could refer to. In a sense, any time we make content public, we publish. You and I are publishing right now. In fact, this is why I like to say that the Web is a colloquium, rather than simply a conversation. It combines the interaction of a conversation with the persistence of a publication.
In this connection, we should note that our colleagues in tech support have been operating in this mode for years. Whenever a tech support person makes a post on a forum or a mailing list, or writes a KB article in response to a case, they are both conversing and publishing at the same time. This is how things work on the Web. But is is not how we work.
Where I think tech comm is stuck is that is still tends to focus on non-interactive publishing, in long form stand alone works such as manuals and help systems that get a grand wedding-day style publishing effort and are then largely abandoned as the writers move on to a new project.
And yes, these are processes that affect the way we design and develop content. That, I would suggest, is exactly where our peril lies. It is not just that we are perpetuating an old-fashioned publishing style (one determined by the physics and economics of paper), but that it is profoundly affecting how we design and develop content.
We talk a lot about reuse, single sourcing, and future-proofing content, but it tends to be all within the context of this monolithic uni-directional non-responsive publishing model. Is the content we are creating prepared at all for the world of the shared colloquium of the Web, for a world of dynamic semantic clusters consisting of (to use David Weinberger’s phrase) small pieces loosely joined?
To put it in more abstract terms, we have traditionally practiced a tightly-coupled model of publishing. But the world is moving very rapidly to a loosely-coupled model of information access and sharing. Are we ready to design and write content for a loosely-coupled information environment?.
TOMORROW’S WORLD: A GUIDE TO THE NEXT 150 YEARS
check this post, you may like it http://quintilluspollux.wordpress.com/
Disco is alive and well, Larry! It is in my house anyway.
On “while anyone can master a few technologies, it’s impossible to be proficient in them all”:
The range of tools out there, especially free, low cost, highly accessible, cloud-based tools, is proliferating and evolving at a rapid rate. I think it’s less about mastering, and more about finding the right mix and match that works for you and your organisation at any given time, with as much of an eye on the future as possible. Our role – whatever the tool or technology – is in the value-add of crafting content that works for users and customers so that they “get” what it is that your organisation does and how your products can help them to do their job. Then pair-up, collaborate, delegate with whoever you think is the master for a particular medium, in order to achieve your goal.
Diana, you make a great point about finding the right mix and then matching it to the requirements for each project. That gives us a way to navigate the tools thicket, and it also answers the question of how we buck the trend toward recruiters who only want to know about tools.
First off, thanks for the link to my little rant about tools. In a way, that article bolsters Mark’s point about the publishing end of the business. IMHO, the most important part of the job is being effective in communicating and that a person in this business should be flexible enough to learn the tooling needed to feed the publication chain readily quickly. (By the way, my dad was a linotype operator so I have first-hand experience of the older publishing paradigm.)
Do we need to be masters of all of these tools? No. However, because of our field, we should be able to adapt quickly to keep our career moving forward. Will there be hiccups along the way? Sure. But if there are requirements for us to be able to feed the publication chain with our content, then it does behoove us to be effective users of the tooling that supports that chain but not become slaves to any particular technology.
Content comes first. Feeding the publishing monster comes next. Whether that monster be King Kong or Godzilla.
Hmmm….There it is again. Diana talks about finding the right mix, you talk about flexibility and adaptability. Mark talks about how content is paramount, and you say the same thing. I’m sensing a couple of themes here. And I like them both.
Hmmm….WordPress won’t let me reply to a reply to a reply. But to Mark Baker’s second comment (May 29 at 7:50 pm) I can only say Bravo. I agree with every word. Thank you, Mark.
Personally I don’t worry about whether I know everything there is to know about our profession. In fact I’d go further and say it is impossible to do so. I am well aware of my strengths and weaknesses inside the industry and am perfectly happy with them. If I need to make one of my weaknesses a strength, I know I can do so. As others have rightly pointed out, we are capable of learning if we need to. The main point here is that our capacity for knowledge has its limits. The chances are if I do learn a new tool and use it, some of the knowledge we learnt on other tools will diminish. This is not because we can’t cope with storing the available information, just that it becomes out of date. The speed with which things change is astonishing, making it incredibly difficult to keep up with everything.
Thanks, Colum. Would you agree that, like all who work in technology related fields, we need to be in a state of continual learning? Even if we work in a place where they use really old technology, we need to be learning new things all the time.
I think Diana is spot on. You will never master all the tools and if you do, they’ll change. Recruiters (and most employers) are at a short term role, not a long term career path. As far as commoditization, tool-specific skills are commodities.
Our value is in focusing on the user/customer/reason and choosing the right strategy (tools, tactics, content) for effective communication. The key word here is “effective” — as in meeting a business need. Analysis and problem solving transcend tools. We need to sell the value of those skills up the chain.
Well said!
Part of our job as technical communicators is to keep up with tools and processes, to maintain a list of those that look interesting and might be useful to us. We need to be willing to learn to use new tools, but it’s good to have a list of options that we can refer to when necessary. We can’t always use the same tool for every job. Sometimes we need to create an online knowledge base, sometimes in-product help, maybe someone wants a PDF.
We just have to remember that we’re the only people who look at a help site and immediately try to figure out which tools were used to create it!
While there’s a huge change from printing press to WordPress, from our perspective those have been improvements to the speed of the publication process. But as Mark pointed out, one of the biggest changes for techcomm is the ability to engage directly with our users via comments and even chat with them (I’ve seen a couple of help centers with integrated chat).
Pingback: Learning, unlearning, and relearning | Leading Technical Communication
Pingback: What will you be doing in 10 years? | Leading Technical Communication
Pingback: Here comes the future: got your superpowers ready? | Leading Technical Communication