40 years in the making

The IBM Kingston lab

40 years ago — on May 29, 1979 — I walked into the IBM programming lab in Kingston, New York, for my first day of work as a technical writer.

I’ve seen a lot in those 40 years. Some things about the profession have changed a lot; some haven’t changed at all.

Audience

The audience has always been the focal point for everything we do. 40 years ago, we paid lip service to that fact. Today we understood that we’re here to serve our readers, but we often struggle with how to do that. Soon it’ll be non-negotiable: If we don’t satisfy our readers, they’ll go elsewhere to get information, and they might even choose our competitors’ products over ours.

Tools

Since 1979, tech writing tools have evolved from literally nothing to the jangle of options we have today. (And the interval, from the first tool to the first job posting requiring that tool, was about 5 minutes.)

But eventually the basic principles behind text editors and graphics programs became well enough established that a writer could move easily from tool to tool.

Are we driving or being driven?

On my first or second day in my new technical writing job my manager told me, “The CS [customer support] guys have put together a ‘cheat sheet’ for setting up hardware redundancy. They’d just started working with Pat [my predecessor] to get it published as a user guide.”

Image source: Scriptorium

I looked at the cheat sheet: a 40-page Word file describing what works with what (and what doesn’t), the basic setup process, and several “gotchas” to watch out for. Good, useful stuff. Yeah, our customers would like to have this. I can massage it into a user guide.

But when I investigated further, I found a surprise: about half of the cheat sheet consisted of content already in the product documentation. The CS guys were surprised when I pointed that out to them.

So now we have two things going on: the organization has good information that it wants to deliver to its customers. At the same time we’re already delivering good information, but people don’t know it’s there.

My situation exemplifies two of Scriptorium’s Six Trends of 2016 — two trends that at first sound contradictory but actually are closely related in yin-and-yang fashion.

We’re in DITA – now what?

Every year my talented friends at Scriptorium roll out a list of trends in content strategy and technical communication. This year’s list is thought-provoking as always: it contains some trends that are spot-on and some that I wasn’t expecting.

And one that’s flat-out brilliant: We’re in DITA – now what?

Muscle car (1969 Pontiac GTO – source: Wikimedia Commons, Gtoman)

During the webinar in which Scriptorium unveiled its trends for 2016, Gretyl Kinsey described a “second wave” of DITA adoption: a technical writing team has decided to switch to DITA  — either for the right reasons (as part of a carefully planned strategy) or for the wrong reasons (DITA sounded cool and trendy, or they had some extra money in the budget).

Having gone through the process of converting its content. the team is now finding that DITA isn’t a panacea. The 400-horsepower DITA muscle car is parked in the driveway. Now what do we do with it?

This is when some teams throw up their hands, or when buyer’s remorse sets in. The team, especially if they didn’t have sound reasons for switching to DITA in the first place, might want to return to its old tool set. Or, realizing that they’ve sunk a lot of treasure and talent into the DITA implementation, they’re inclined to limp along — driving the car but never getting out of second gear.

Even when the team made the switch for the right reasons, they might feel overwhelmed. All of the reasons for switching, like cost savings through reuse and greater efficiency in translation, didn’t just magically fall into place. A lot of work is still needed. In this situation, again, some teams content themselves with driving the car to the grocery store and back, never taking it out on the freeway.

What’s the right thing to do?

Halfway there: Technical communication trends in the 2010s

In a couple of weeks we’ll have reached the midpoint of a decade. Five years ago we turned our calendars to 2010, and five years from now we’ll stand at the threshold of 2020.

It’s fun to look back five years (which is, of course, an eternity in Internet time) and see what people were predicting for the new decade. What changes, and what new opportunities, would the 2010s bring for technical communicators?

One pundit predicted that we’d see credentialing or certification: “As technical communicators vie to prove their value, I expect increased interest in finding ways to differentiate ourselves in the job market….Perhaps there’ll be a PMP-like course for content strategists or information architects.”

Oops. While STC did launch a certification program a couple of years ago, they put it on ice when demand didn’t match expectations. Now nobody is talking about certification, as far as I can tell.

So what knucklehead made that prediction? That would be me.

Fortunately, I did better at spotting some other trends.

What Will You Be Doing in 10 Years?

50 years ago, we were told the future would look like this (source: Wikipedia Commons)

We’ve all heard about how much the technical communication profession is changing. I’d like to hear your thoughts on what it means to you, personally.

Take my 5- to 10-minute survey and share your confidential answers to any or all of the following questions.

If you’re a practicing technical communicator…

• What will you be doing 10 years from now?
• Why?
• What are you doing today to prepare?

The survey is anonymous, so you won’t be found out if you tell me that you hope to take over your boss’s job. Or that you dream of hacking into poorly-designed websites to insert Tech Comm-themed banners.

I’ll post the results on this blog in a couple of weeks.

If you’re in need of inspiration, here are some resources that might help.

• Hot lead to hot technology: Whither technical communication?
• This is the future we talked about
• Scriptorium’s annual trends article

Hot Lead to Hot Technology: Whither Technical Communication?

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?

1. 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.
2. In light of #1, how will we buck the trend toward recruiters who seek candidates based on the tools they know?
3. 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.)
4. 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.