I’m a writer, that much I know. My core talent is the ability to quickly and easily put ideas/activities/feelings/etc. into words. I enjoy writing and people tell me they enjoy reading what I’ve written, so by those measures I think I’m on the right track in my career. Of course “writing” can be applied in many ways, as it comes into play at any level of communications or planning, let alone writing as an art form. To make a living as a writer, to have a career that matches what I’m best at, one avenue is that of a “Technical Writer.” However, even this job function changes from company to company, and from person to person depending on needs, so I’m not sure that clarifies things much.
That has been my job title for the past seven years. I’ve written things about software applications, and about software development approaches and processes. I’ve documented graphical and application programmer interfaces, provided overviews of database exports, and reported testing results. While I’ve never once developed an application of any size or complexity, I can clearly write about a complete Software Development Lifecycle (SDLC) from project planning, to the phases of Requirements Definition, Development (Agile? Waterfall?), Quality Control, and Implementation. After working with technical subject matter experts to relay this sort of information over and again, it all seems so obvious.
Does my role exist because the technical staff I work with lack the ability to write? Or is their work so nebulous and innate to their nature that they’re unable to explain what they do? I don’t think so. People who develop custom software are quite smart and typically have completed college or other advanced training. They’ve written before, they’ll write again; they possess that basic skill. Also if you start to question their favored process approaches and technologies, you’ll find yourself under attack from someone extremely capable of telling you exactly why the way they do things is best. So where do I come in as a Technical Writer then? I’m certainly not technical in my own right. The software development experts I work with combine the halves of “technical” and “writing” so maybe they should be doing my job. It makes me wonder if I’m not wasting my time as a writer, toiling day by day in subject matter that is a challenge to understand, when instead I could be writing poems about the quirky bluebirds that live in my garden. Of course, the easier path is also not a career path.
In my determination to prove that I possess value in a tech company, I must then offer up a true definition of technical writing that goes deeper than the surface. A technical writer is a liaison between a technical expert and consumers of their technical expertise. It is a person who has the ability to ride shotgun with the specialized knowledge of a developer or architect and quickly and efficiently translate that to an audience that is less familiar with it, or that doesn’t have the time or ability to become a deep subject matter expert in their own right. The Technical Writer doesn’t solely communicate to an audience of laymen, but they generally do communicate to people who don’t need the science behind the key points. Basically technical writing is capturing and relaying the gist of the information.
I’m a “gister”. I take the key points of a detailed technical synopsis and map them to what the audience wants, or to what they asked. I don’t even do this through writing all of the time. Sometimes a sweet graphic can tell the story much more efficiently than pages and pages of text. An example of the ultimate gist for me is using a cycle based graphic to summarize how an application will be developed. Instead of details on each step, a curved arrow says basically the same thing. The key is finding the right informational snapshot (text or image) for the audience; understanding the depth of their technical knowledge, knowing what they want to know, and delivering it how they want it. Being successful in this goal is what can save people and organizations tremendous amounts of time and ensure clear understanding among the disparate parties to “IT Solutions”. (Hmm, speaking of vague titles…)