Today’s Technical Writer

Today’s technical writer needs to be so much more than he or she once was. When I first started on the path to becoming a technical writer 19 years ago, the tools were more basic and infinitely more limited. WinHelp was about as cutting edge as there was.  The first company to hire me, Scitex, was a huge Israeli hi-tech company that broke tasks into tiny pieces and hired people to do them. My skills included: the fundamentals of WordPress, WordStar and, I think, Word 2. I also knew Paint and was able to manipulate graphics quite well.

I was drawing connectors – squares and circles and lines, to imitate…I don’t remember what. My first boss was an incredible woman who recognized raw talent and assessed people not according to what they had done, but what they could do. She hired a friend of mine because she figured if someone could be intelligent, creative, and manage a house with 5 children, she could easily handle documentation.

She hired me – well, I’m not sure why – but one of the things that impressed her, of all things, was that I had been selected to donate bone marrow to a cancer patient and somehow was trying to balance that donation with having just made aliyah (weeks before), three children, and learning to live in a new country.

She handed me a manual and told me to teach myself a program called Guide. The manual was wrong. Not all of it, but a critical procedure was not written correctly. I tried it and failed. I tried it again and again. Finally, more embarrassed than anything, I went to my boss and explained that I had failed. She came to show me how to do it and right away I saw that what she was showing me didn’t match what was written – we reviewed the procedure in the manual…she had that much patience, and she agreed – bad technical writing.

After learning Guide, she introduced me to a new tool on the market and told me to learn it. That was the first version of RoboHelp and in many ways, the rest is history. In that first job, I was an information manipulator. I found errors in the way the documentation was written – and had to beg them to let me correct them. I was allowed to correct spelling mistakes and blatant grammar errors, but awkward and long sentences remained. About 8 months after I started at Scitex, there was a revolutionary new product that we began to use – it was called Acrobat and it created this format called PDF.

I don’t remember what other tools I learned at Scitex, but within two years, I branched out and founded WritePoint. I understood that if I wanted to be a good technical writer, I needed to combine writing skills with many technical skills. It was all about learning, trying, clicking and figuring it out.

Years later, I am amazed at how much new technical writers are expected to know – so much more than when I started. But even more, the role of the technical writer in many companies has undergone a significant change. Once we were handed information. I had an engineer once say “I’ll tell you what to write.” The product was simply too complex, he assured me. “I barely understand it.”

“Try me,” I asked him. “Explain one section to me and let me write it and if I don’t get it, I’ll write whatever you tell me to.”

To this day, his response remains one of my greatest achievements. I gave him the document. He read it, smiled and said, “you really made that sound simple.”

“That’s what we do,” I told him with such pride. It is. Really. We take complex things that engineers say or develop and we make them simple for our end user.

And today, as never before, we are often part of the development team, the QA team, even the marketing team. We are asked questions of culture and how to address our message to a particular audience. We are expected to be innovative and challenge ourselves constantly to learn new skills and take documentation forward. For a long time, documentation was stuck at the level of PDFs. I’m not ready to say that PDF is dead, as some senior writers have, but certainly its role has significantly declined as the world moves more to the visual, unwritten word. We have a role here too – even without words, we are information developers. We stand between the user and the developer.

My latest documentation project is about to begin and I am as excited about this challenge as all of the challenges that have come before it. It is for a new family of products in the Cloud and they want interactive tutorials to be part of the documentation set, YouTube videos, and more. I’ve done this before and yet the excitement at this company is palpable. They are more excited about entering this  “new” world of documentation than me. They did their research before they came to us – and at the first meeting they began explaining. As I added more information, they began to realize that the brave new world they envisioned, is already here for many other companies.

The deliverables are very different than what I once created for Scitex engineers and yet the concept is the same. For its time, the Scitex information projects were innovative while still being comprehensive knowledge bases. Today’s information is often delivered in a different format but the goal remains the same – both on the part of the user and on the part of the technical writer.

What I love about being a technical writer is that there is always a challenge; always something new to learn. And best of all – they pay us to do it! You can’t beat that!

17 thoughts on “Today’s Technical Writer”

  1. Very nicely worded article Paula. The basic premise is that we have to bridge the gap between software producers and users. That’s essentially our role. To do that, we have to constantly be on our toes and develop new skills to keep pace with technological advances.

    1. Hi Anu, Absolutely – that is our role – to “translate” what the engineers say in their language to something our users can understand – in tone, in content, and even in format.

  2. Hi Paula, great article!! My chapter is writing a piece for employers on “why hire a tech writer” and I’d like to use a few quotes from it. Can we borrow a few words and run the copy by you before doing so?
    I love my job too and it’s so true: love what you do and you won’t have to work a day in your life.

    1. Sure, Mellissa – I’d be happy for you to use quotes from the article. Please let me know which ones and the final link if it’s posted online!

    1. Thanks, Rahul. If you’d asked me 10 years ago if I loved technical writing, I don’t think I would have answered as I would today. The longer I do it – and the more students I teach, the more I realize what an incredible industry it is – and yes, how much it does contribute to others. Thanks for taking the time to comment.

  3. Good Article.Somehow it relates to me also. When i started my carrier, I have no clue of what is it.In my first job, my boss told me each and every concept of writing, the usage of tool and from there the journey began. The whole credit of what I’m today goes to him.
    I totally agree with you, where you said that today Technical writer have to be more than what it is required. Apart from vast knowledge of product needs to have good hands on to the tools. Earlier we get to work on a single tool, but now industry demands us to know each tool such as Framemaker, doctohelp..and so on.
    But surely it is a commendable job. I’m proud to be what I’m today and a part of this big industry.

    1. Hi Shagun, Thanks for your comments. And I agree – the market is constantly introducing new tools and we have to experiment, learn, and expand our skill set.

  4. You raise several interesting points but two stand out for me: translation and tools.

    One of the challenges is convincing engineers that, even when they are writing for other engineers, the content must be edited for the knowledge level of the audience. In my company, college grads are a big part of the audience and designers tend to dismiss this. Our standard reply is “if they knew as much as you, they wouldn’t need the training.”

    Tools change frequently as publishing demands become more complex. In the 80s, Wordstar and Lotus123 handled most of the output. In the 90s, MS Office and PageMaker produced more professional results and, often, in larger volumes. By 2000, RoboHelp and DocToHelp were the help systems leaders, FrameMaker began its rise in popularity, and Office put powerful publishing tools on nearly every corporate desktop.

    Today, XML-based DITA authoring, content management systems, and the widespread use of instructional design principles, is once again forcing new skill sets on technical writers and editors.

    The constantly changing environment helps keep our minds and perspectives sharp. New ways to author and display information, along with more sophisticated distribution, present a constant challenge.

    For my part, I wouldn’t have it any other way.

  5. Thanks for sharing your journey and experiences. A lot of us can relate with this, because we may have entered this world of technical writing purely by chance! And we are loving it!!!

Leave a Reply

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