What makes a good technical writer great?

If you perform a Google search for “what to look for in a technical writer” (a.k.a. technical communicator, information developer, documentation specialist or the person you hire to create and maintain technical documentation) the results will give you an overabundance of qualities to consider. A handful of articles even warn how difficult it is to hire and work with technical writers. Most recommend that recruiters/hiring managers take a variety of steps to vet technical writers in the application process.

What We Traditionally Look for in a Technical Writer

Some suggest requiring applicants design an example document that looks good on paper and online and is thoughtfully and professionally organized and prepared. Others recommend looking for a writer with a technical writing degree or certification and/or a professional website. Still others discuss the need for characteristics like curiosity, good listener, innovation, creativity, desire to learn, etc.

I don’t take exception to any of these suggestions per se (well, except maybe the technical writing degree requirement, having learned on the job myself). But I do think all of these characteristics and vetting strategies are for naught if you don’t give the new hire the time to learn the tool they are documenting, as well as, how your audience experiences and uses it.

Good Technical Writers Need Time to Become Great

When I interviewed for the technical writer position at SurveyGizmo I was re-inventing myself. My background was in statistics and survey design and methodology. I just so happened to do a lot of documentation in my role at the time.

After interviewing with Marybeth, my to-be manager, I was pretty intimidated by the difficulty of what I might be taking on. Don’t get me wrong, I was up to the challenge. In fact, there’s nothing I like more than learning new things, but I knew that in order to be successful in the role I would need time. When I say time, I mean time not writing technical documentation. I told Marybeth that in order to succeed in the role I would want to spend a few months working in support in order to learn both the tool and the customers.

I think this is what she was looking to hear (I’ve never asked her), though, at the time, I felt like I was taking a big gamble that I might lose my chance at the job.  Fast forward and here I am SurveyGizmo Documentation Coordinator. I think I’m pretty good at my job. I attribute much of my success to my being allowed to take the time to learn.

For my first 2 months at SurveyGizmo I worked on the support team taking calls and email tickets. This gave me a good jump on learning both the tool and our customers. For the remainder of my first year here I was allowed to perform a sort of dual role. I was a Customer Advocate, Technical Writer, Documentation Specialist or CATWDS affectionately pronounced \’kat-wåds\. (Never mind that “technical writer” and “documentation specialist” are redundant; how the heck would you pronounce CATW?) In this role I processed customer requests from the support team while also writing documentation. I learned a lot and, after my first year, I became the Documentation Coordinator (no more funny acronym).

As Documentation Coordinator I continue to remain plugged in to the support team. I regularly take calls and I pop into the email ticket queue at least once a day to get an idea of what questions customers are asking. I cannot say enough for the value that talking to customers brings to my writing.

Rethinking Expectations of Technical Writers

My position at SurveyGizmo is my first official “technical writer” position. I am sincerely grateful for the patience and room SurveyGizmo has given me to learn. Given what’s online about how difficult it is to hire and work with technical writers, I suspect that what’s operating here is that few organizations allow for similar opportunities for their writers to be their best.

I did find one article that acknowledged that a technical writer should “bridge the gap between product and user.”^[1] And another that very succinctly stated, “Ignorance of technology or audience is never an asset for a technical writer.”^[2] I couldn’t agree more, however, neither article mentioned the time it surely takes to “bridge the gap” and overcome “ignorance.” In fact, one article is titled “When Should You Hire a Contract Writer.” While I’ve never done contract writing, I suspect that the average contract does not allot time for “bridging the gap.”

I’ve been lucky here at SurveyGizmo. I hope I’ve made the case that we should change the expectations of our technical writers and that, in the future, more of their experiences look like mine.  Documentation can make or break your product, so it makes sense to give your technical writer/s the time needed to truly help your users understand what your product can do for them.