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!