I’ve always been a jack of all trades: I know a little about a lot of things, and a lot about a few things. I have an easily triggered sense of curiosity (which makes the internet a wonderful and dangerous thing), and I’ve always enjoyed the pursuit of knowledge. Plus, I enjoy writing.
This is the sort of personality that leads you to become a tech writer. But once you’ve decided to do that, or, in my case, fallen into it in an amazing stroke of luck, how do you actually get things done?
Starting to learn
In my last post (again), I mentioned that:
I don’t want to look like I’m not pulling my weight (which is a common issue that I’ve seen with tech writers), so I’ll research the content, write the docs, edit them, build the documentation architecture, design the online documentation site, take care of links and metadata and other useful features, publish the docs, track and respond to comments, track doc requests, take on special projects, test the procedures, validate the API, edit the UI text, attend meetings for every project I’m working on…all without complaining, because isn’t that what I was hired to do?
This isn’t true for all writers, and hasn’t always been true for me. In my first job as a tech writer, I was responsible for writing reference and user guides. But I just had to type the content into the tool (Framemaker), and try not to screw things up too badly. We had an editor and a production team: I would research the info (meeting with engineers and QA, mostly), write the manual, then send it to the editor. After that, I’d fix the problems, go back to the engineers if I had more questions, and then send it to the production team. They would do everything required to turn the doc into a nice-looking, printable manual. Then it would go off to the printer and be turned into an actual book.
Today, the thought of an actual, printed software manual feels like a throwback to an ancient time, when dinosaurs ruled the earth and you’d have to go to Egghead to buy software. On the other hand, some things don’t change: Printers are still used as containment devices for malevolent spirits.
Entering the 21st century
But things did change for me when two things happened: I changed jobs, and the dot-com bubble burst.
When I changed jobs, I went to a much smaller company and became the second person on the doc team. There were no editors, and no production department. We still delivered printable manuals, but we delivered them in PDF format. Fortunately, I had learned a lot from the production team at the previous company, and I knew how to turn a manual into a decent-looking PDF. I wasn’t an expert, but I had enough knowledge to build on and I was interested in learning more.
Similarly, that pesky bubble burst had a huge impact on doc teams. The teams got smaller, and I saw fewer teams with editors or dedicated production groups. Most teams relied on the writers to do those jobs. If they didn’t do the jobs quite as well, they at least did them for less money. And I’m not sure that too many hiring CFOs worried about the cost of typos in the documentation.
The curse of the easily bored
Another characteristic that I have that’s both good and bad: I’m easily bored, so I need a fairly constant flow of new challenges. This is good because I always want to learn more. It’s bad because I can get bored, and then frustrated, and that’s when I start looking around at other options (first, other projects; ultimately, a new job).
This is why I’ve been happier at startups. There’s always too much to do, new things to try, and never enough time to learn them all. I spent a few years reading nothing but books on information architecture, web content design, content strategy, and search engine optimization (SEO) techniques.
Is this something that all tech writers need to learn? Er…it helps. The real answer is No, not all tech writers, because in some cases you just won’t be using those skills. When I was working for large companies, I was purely a content creator. I’d do the research, write the docs, get them reviewed…and my job stopped there. In a small writing group, we’d do peer edits of each other’s docs, but I wasn’t building a doc set, creating the doc architecture, figuring out how to deliver it to the customer, or working on any docs beyond the one or two I was responsible for.
Indulging your curiosity and differentiating yourself
And that bored the heck out of me. Some writers love that consistency, and I’m glad that they exist. I use their documentation, and I certainly appreciate when those docs are written well. It’s just my personal problem that I like to take on too many tasks, and want to know how to do everything.
And although that way madness lies, but it also leads to job security and the ability to move into other roles. And madness is relative, right?
I’ve seen writers move into UI design or user experience roles. It’s not a huge jump, and while a great user interface should reduce the need for supporting documentation, being able to create both is a huge advantage.
Similarly, focusing on information architecture (designing how the documentation is structured and presented) or content strategy (figuring out the complete content creation and delivery for an organization or entire company) is also a short leap.
And at some point I finally realized that everything customer-facing is marketing. Moving from technical writing to marketing writing is another possibility. I find it difficult to write marketing-style documentation, and I always end up adding too much detail. But I’m willing to admit that some skills elude me.
But I like being a tech writer!
I’m definitely not telling you to abandon ship and the field of tech writing. I’ve seen a lot of negative stories about tech writing dying as a career, or being commodified and send overseas. Which certainly happens, but I think it’s dying as a career as we know it. Meaning: It’s changing! So it’s time to adapt and broaden your skill set. Learn about API documentation, or web design, or content architecture.
I’ve interviewed a lot of writer candidates, and any of those skills would have (and did) set candidates apart. Even, “I’m no expert, but I’ve written a couple of API docs, and I’ve been researching video presentation techniques” will put you a step ahead of many candidates. Tech writers are supposed to be fast and eager learners. And good writers. And good at organization. And probably understand a bit of a programming language or two. And know how to edit and caption screenshots.
So in a field of jacks of all trades, what are the skills that set you apart?