Almost 17 years ago, I had my last annual review at my first job as a technical writer. My manager was on maternity leave, and months of bad news about the company (caused by illegal financial manipulation) led to poor morale and attrition. But this post isn’t about that.
The acting team manager read off the list of what I’d accomplished in the last year, and what I needed to improve on. I don’t remember the details. What I do remember is her conclusion:
“You won’t make a good technical writer. You should consider another career.”
At this point, the supervising manager, from a different team, made it clear that this comment was way the hell inappropriate and out of line. But it was already out there, weighing down the room.
So I did the sensible thing: I quit, had an awkward going away lunch, then started my next job as a technical writer.
But that festering cloud has stuck around: am I really qualified to do this? Do I really know what I’m doing? When will everyone figure out that I’m faking it because I don’t know how to use every documentation tool and every graphics program and I’m not a database expert or a brilliant programmer and I needed help to set up the product and I really didn’t do that much work on those code samples…
I thought that I had to be great at everything. That’s how I would become a great technical writer and make sure I did have a career. And, of course, how I would prove that person wrong.
Fortunately, when you put enough work into something you’re likely to get pretty good at it. Because I actually do enjoy technical writing, I also wanted to learn about related areas, tools, and ideas. I took some programming classes so I could have intelligent conversations with developers. I learned how to create good screenshots. I dove into information architecture and got pretty good at building documentation sites.
Then I discovered that there is STILL a lot that I don’t know! It’s like I’ve climbed a bunch of mountains only to find more, taller mountains on the other sides. So I tighten the laces on my metaphorical hiking boots and climb that next metaphorical mountain.
And I have finally learned something: I wasn’t doing technical writing wrong 17 years ago, I was doing it differently.
I was working with writers who were assigned a manual or two for each product release, and then spent the next 12 to 18 months writing that manual. Then you print a dozen copies, hand it to various people to review, and fixed the problems they noticed while they flipped through the pages.
And I did that. I stayed at work late cursing printers that always failed 3/4 of the way through the manual and then decide to print the whole thing again until the inevitable paper jam.
(I’ve got a computer on my wrist, but printers are still lumbering-yet-delicate trash technology that are no more reliable or predictable then they were 20 years ago. Office Space came out in 1999 and that printer scene is every bit as true and satisfying today. Now back to the story…)
But I also wanted to try something else. I worked with two other writers to build the company’s first help set that used HTML instead of WinHelp. I loved that we were trying something new. The other writers in the department wondered why we were bothering. After all, most of our customers used Windows, so why waste time building a new process? (Everyone knows people running UNIX are self-sufficient and don’t need help.)
As nice as it is to hold a copy of a book that you wrote, it’s not so nice to tell your customers that they MUST read that book before they can use your product. Or, more likely, that shelf full of books. This is the opposite of “just in time” help: it’s “become an expert on this product before you ever think about touching the UI.”
And then there were tutorials, with examples that were actually useful. Building on the idea that a set of books wasn’t the only way to learn how to use a product. Oh, and maybe we should try this topic-based authoring thing? How about writing smaller pieces, faster, and getting feedback more often? Seems like it might be helpful?
Then the other members of that team left, and those ideas left with them. And that’s how I ended up with a senior writer telling me to consider a career change. Because I didn’t write like she wrote; I wasn’t satisfied spending a year turning a spec into a manual and then, maybe, getting some feedback on my work.
I’ve spent years trying to prove that I am, too, a good tech writer, only to realize that I just needed to understand what they meant when they told me I was doing it wrong. Motivation can come from odd places, and not all of them are positive.
So, fellow technical writers, documentarians, or other people who have been told that you need to create some sort of user guide by next Tuesday: go forth and write the hell out of it! (Or illustrate, video, semaphore, whatever!) The only question is this: is this content helpful to my customers? Will this help them use our product, and use it more, and more efficiently?
If anyone tells you that you’re doing it wrong, challenge them. Challenge them politely, but make them explain why it’s wrong in terms of business value. Never accept “that’s not the way it’s done,” or “we don’t do it that way here.”
They might be right, they might be holding onto outdated ideas, or they might resent you because you’re a pain in the ass and keep asking annoying questions. I’ve found that last one can be pretty good for your career.
(Did I mention that I write another column, where I talk more about these ideas? I do!)
(Also! I’ll be speaking at the Write the Docs conference in Portland this year! I’ll be talking about why documentation and support teams need to work together, and how to do it.)