You are currently viewing Technical Writers: WHO are we? WHAT are we?

Technical Writers: WHO are we? WHAT are we?

WHO are we, as technical writers? What are we? And, WHAT do we do. These are the questions that regularly come up when discussing technical writing and technical writers. Ironically, as our field becomes more widely known, our identity crisis has led to even more confusion than ever.

We represent ourselves as Technical Writers and Technical Communicators. Others say we are Information Designers or Information Developers. Sometimes, we are called Content Developers or  Content Managers. The WHO we are or WHAT we are is obviously dictated by the WHAT we do. It seems that technical writing is one of the most easily misunderstood careers.

Ironically, just about the time the hi-tech industry began to understand and value what we do, many seasoned technical writers got tired of the old realities and decided to re-identify themselves with grander names that they hoped would introduce many of the other tasks that are inherent in being a technical writer. Yes, we do design how our organization’s information is designed and presented to our users. Of course, we develop that information based on endless meetings and hands-on learning. We ARE the first users outside the developers and QA. Each title helps define a part of the whole. None entirely define the endless tasks that fall within our responsibilities.

In the past, one would describe a technical writer as the person responsible for explaining what your product does, how it works, and why the consumer would benefit from using it. Missing from that, of course, are all the times we proof the interface and help eradicate some of the most amazing error messages DevOps created. “Houston, We Have a Problem” is no more. Congratulating a user for creating a policy with a bottle of champagne and dropping confetti is gone. We are the gatekeepers, protecting our users from the whim and madness of non-native English speakers who really want to get the message across.

Missing from that are so many other WHAT responses. What about all the training materials technical writers create, the graphics we design? And, what about all the other departments we interact with regularly? In a single week at work, I am likely to be involved with the Product team, Front End team, Support team, Professional Services team, Sales and Marketing, Human Resources and a few others I haven’t yet identified. People stop by my office for help in English. Error message, UI terms, training materials, writing a script. It all comes into my office and stops at my desk.

In a single week, I will work with Confluence and JIRA, RoboHelp or ClickHelp or whatever, Google docs, Word, Figma or InVision, and countless other tools. Similarly, I will work on an endless steam of documents simultaneously.

In many ways, the more we insist on searching for the right term to describe what we do, the more confusion we bring. Unlike many of my colleagues who do much of the same things that I do, I have resisted the urge to change what I am called. Technical Communicator may sound more impressive, but if you look carefully, you will most likely not find any job offerings for a Technical Communicator, nor are you likely to find anyone outside our industry who understands the terms.

For the good and the bad, the terms technical writing and technical writer are well known and established in the industry. Yes, we communicate; yes, we develop information. If it helps your career to use another title, go for it.

But ultimately, the sum total of what we do is so much more than any single title can convey. For clients that know me and the skills my company offers, we are communicators, writers, proof-readers, editors. We are documentation managers and planners, product experts and the reason behind many customer success stories. What we are, most of all, can simply be summed up as part of the team.

For those who do not yet know us, I’m fine with them hiring us as technical writers and then being pleasantly surprised when we correct their UI enough that we become tasked with writing it. I’m good with them running all error messages before us and trusting us to be the first real eyes on the solution they are developing.

I care less about WHO we are, than WHAT we are. The best measure of our success is when we are not called this title or that title but rather invited, as part of the team, to bring their product to the next level using all the expertise and knowledge we have gained throughout the years.