Let’s look at Instructional Design:

-Technical Writing skills transfer easily
-Web-based training is huge
-Online Synchronous training is a major trend these days
-Learning Management Systems (Moodle/Blackboard) are huge
-Training material development
-e-learning is huge (Adobe Captivate/Camtasia)

I think it is time for many Technical Communicators to reinvent themselves!

I personally think the profession of technical writing is in trouble, because organizations like STC have not made the R.O.I case for us, that any well-run professional group should make for its membership. As a consequence, good writers have a business problem with MBAs; not a technology problem with Engineers.

I thought Mr. Spoole’s article was shallow, misunderstands technical writing tasks, and pretty much ignores every major problem that working writers have today. It is not a helpful article. Has Mr. Spool ever had to write a Manual or Help System describing a high tech product from scratch?

milt brewster

Sure, technical writers are branching out into other areas and producing fewer manuals. However, that’s only because our skills are becoming more valued, and technology is making paper documents obsolete. However, scripts for video tutorials, IT whitepapers, API documentation, help content, and button labels for intuitive interfaces all require clearly written communication.

I’ve been doing this for about ten years now, and I’m seeing a definite increase in the amount of technical writing my job requires. The deliverables have changed, but clarifying technical concepts and putting them in writing is still the central focus.

This is a natural progression. The idea that technical writing is only applicable to printed manuals is archaic, and I’m happy to see the boundaries falling so that technical writers can move into a more far-reaching role.

Only a UI person could make this comment. It’s very naive.

There will always be a need for documentation. Even the most popular products on the market today, like the ipod and blackberry, require user guides. these are v popular downloads as users like to explore the app by reading. people will always like to read.

Ivan

I have been a technical writer for more than three years, it is a decent paid job but our skills and job profiles are not clearly defined. we are expected to be masters of many areas. I hope we remain strong and essential even in the time of recession, as times are changing with market slow-down. One thing for sure, if developers are replaced as tech writers, fro sure end users will have difficulty in understanding the product usage. I feel technical writers are indispensable for a software industry. I hope rather

In my years of tech writing I’ve moved from writing manuals to accompany large task-oriented packages used by government agencies (and delivering the training classes that the manuals were supposed to substitute for) to writing API documentation.

If there’s no need for technical writing, where are all those aftermarket computer books coming from? Who’s buying them? Are they just some form of techno-jewelry?

For the past 28+ years, I have been employed by Lockheed Martin, the largest aerospace contractor in the world. For about 25 of those years, I have been a technical writer/communicator. Following are phases in the evolution of my job.

1. As a technical writer, I began 25 years ago with (literally!) a pad of paper and a pencil. Some of the other 17 employees in my department (called Technical Information Services) had the responsibility of (1) keying what I wrote using the Script programming language, (2) creating [crude] graphics, (3) coordinating hard-copy output and tracking revisions, and (4) supervising the whole process.

2. In 1985, the department was disbanded. Having earlier seen the writing on the wall, I was able to secure a technical writing position in the data center operations area. I recall that I had one of the first two Macintosh computers in the company. (Macs were introduced in 1984.) About 25% of the projects that were produced by my previous department of 17 were eliminated, while I was able to easily accommodate the remaining 75% in this brave new world of desktop publishing. Even as early as 1985, it was easy to see that I would have to be more than “just” a technical writer. I had to learn the new Microsoft Office suite, including page layout and design. I found myself doing less writing and more creative design work. More importantly, the new technology provided me the means of using my creativity to develop entirely new communications tools and processes. As I have been a member of STC since 1984, the Society publications told me that, indeed things were changing, exactly how they were changing, and that I was on the right track in evolving my job functions. I had the confidence to move on.

3. In terms of “macro” trends, the next one that hit me the hardest became obvious just after the beginning of the new millenium. My business area (Enterprise Information Systems) supplies the information technology products, services, and support for all of Lockheed Martin Corporation. The Corporation’s business areas and business units are our customers. My department develops and delivers marketing collateral for all of these products and services. As the department grew and employees came on board with marketing experience, my manager ensured in advance that they would also have some solid writing experience. They do the majority of their own writing today. In addition, by the nature of their jobs, these marketers have direct contact with our customers. This contact means that they are free to use their creativity in best serving these customers, which has resulted in several new creative communications processes (e.g., seting up SharePoint sites that have the look and feel of a Web page). They have, in fact, BECOME technical communicators!

So where does this leave me – the guy who was once THE department technical communicator? It simply means that I have to accept the situation and rethink and refocus my place in the department. In essence, I have to reinvent myself. While there is certainly some stress/emotional pain involved in having to rejustify my position, at the same time it is strangely exciting and invigorating. Just think of the possibilities! As cancer survivor and Olympic cyclist Lance Armstrong once said, “Cancer taught me a plan for more purposeful living, and that in turn taught me how to trainand win more purposefully. It taught me that pain has a reason, and that sometimes the experience of losing things – whether health or a car or an old sense of self – has it’s own value in the scheme of life. Pain and loss are great enhancers.”

Technical writing has never gone away, it has simply become part of something bigger. It has evolved, and we must evolve with it.

Mike Murray
Director, 2006-2009

The skills have improved, the scope has increased, only the name “technical writing” no longer seems relevant.

Hardware, particularly complex hardware (of which there is a lot), is likely to continue to need extensive “documentation”. This applies both to usage—where embedded interfaces have technically limited capabilities to be self-describing—and to troubleshooting and maintenance. In this arena, well-constructed, accurate writing is going to continue to be a key requirement, whatever the medium used to convey the information.

In the world of software, the ideal is that no recourse to documentation is required. An exception to this is information for developers and integrators who need to learn how to interface with a system. Within the UI though, the focus of people with technical writing skills must evolve to support the user as they work. The keys here are in the areas of consistent labelling, high-value on-screen content at the point of need, meaningful messages, and so on.

Technical writers who do not take their existing skills and apply them to user assistance—keeping the user productive, and enabling them to enhance their expertise—are likely to find themselves in a dwindling employment market.

Yes there is plenty of bad writing out there, but that is not new. And yes, I have seen software GUI and design improve significantly. So far, however, I haven’t worked for any companies whose software was so simple that no documentation was needed.

I think there are still lots of opportunities for technical writers as long as the writers are flexible and willing to learn new skills as they grow in the field.

Most companies I’ve worked for in the past 10 years want a rubber-stamp approval of what their engineers are writing … not a critical evaluation of content or usability, not an ordered sequence of procedural steps, not a validation of completeness and accuracy (much less precision!) of the information. I have been dismissed or had contracts unrenewed because of my professional abilities, not my lack of them.

Two cultural circumstances seem to drive the gap between what companies say they want and the seemingly fraudulent hiring of yours truly to become a convenient scapegoat, should a negligence lawsuit materialize or an outsider chuckle over the ironies of 5 different names for the same valve.

The first is the dumbing down of the industry to the level of management comprehension of the product. The focus is on sales, not repeat sales nor efficient use of the product. Everything is assumed to be a throwaway, never repaired or maintained, so why bother with anything but a bulleted list of features, prettily presented, of course.

The second is more profound. The engineering disciplines themselves are being dumbed down to accommodate the H-1B visa or green card holder who (a) has an inflated degree from a diploma mill in India or Russia OR (b) has a valid degree but insufficient English to communicate what they’ve designed, implemented, or tested.

Documentation becomes useless because there are so many lapses in communication. This phenomenon, of course, may be self-correcting as foreign engineers become more proficient in English. But by that time technical writers will have forgotten how to ask the right questions.

A technical education was supposed to guarantee a lifetime of employment. This is no longer the case in the U.S., and the technical writer is an obvious bellweather.

However, STC needs to embrace UX stuff even more and bring it front and center. Rebrand themselves, essetially.

But like my fellow commenters, I too feel like we are witnessing “the maturing of technical communication” (nice one, Michael). The tech writers were the usability experts before user experience and information architects became all the rage a few years ago. We’ve been putting users first since the first time a tech writer was given the opportunity to design a manual themselves. And the more people listen to us, the more they will know that we’re part of UX and always will be.

This year I’m telling people that my goal is to get everything the user needs to know into the UI, and never write another help topic. To those who ask what I’ll do for work if I’m successful I say “Don’t worry, there’s plenty for me to do.” And those who grin and get it are my allies.

The truth is that written communication is gradually being lost as a skill, being replaced but verbal and text speak. How many people write letters these days? Technical writing just isn’t fashionable. Companies would rather get their developers to write the documentation because they think it saves money, but it’s a false economy; support costs increase becuase no one can understand the documentation and developers are frustrated because they hate writing.

While it’s true that writing duties have increasingly become distributed across the development organization, those who are doing the writing lack, in my experience, the writing skills to do the job. Everywhere I’ve worked, job descriptions call for “excellent written communication skills,” but that requirement is seldom met. At my last company, I was pressed into service to teach effective writing to our technical folks as a way of shoring up the skill shortfall.

I claim that writing is a different skill from coding, testing, and designing. I spent years getting good at it! There is still a need for talented and experienced writers in our industry, although I have no great insight into how to place such writers in your average software development shop.