The problem
I’ve never been able to make what I do sound macho. I’ve never been able to make it sound cool.
If I tell you that “I capture and arrange technical content in ways that help businesses make good decisions,” does that make your head spin? If I say “I work on processes and procedures,” does that make me sound about as interesting as a rock?
People ask me what I do. What do I tell them?
What LinkedIn says
I recently asked the Technical Writer LinkedIn group how they explained what they did.
By my rough calculation, 54% defined what they did in terms of deliverables (example: I write the manuals that no one reads.) Another 17% focused on how they make information clear, while another 15% focused on how they translate information from one group (say, engineers) to another (say, the general public). About 6% had some other response (yes, I know this doesn’t add up to 100%, but I’m rounding numbers here).
Three respondents said they introduce themselves as a tech writer, but that when they get the inevitable glazed stare, they explain what they do in some other way.
So, most tech writers seem to define themselves in terms of the deliverables they produce. Is that healthy? It’s simple. But is it how I should define my own work?
The key
What first attracted me to technical communication was the challenge. When someone uses your document, do they get the information they need? Do they know how to complete the procedure? Do they understand how you do business? Do they get what your business can do for them?
Over the years, I’ve learned that there’s a lot more to good technical communication than just writing good documents. What good is your document if no one winds up reading it? A document can be well-written, but if it’s buried someplace where no one will see it, then you’ve wasted money. If you don’t begin with the end in mind, you will write junk.
Here’s the real question you have to answer: When clients, employees, or regulators need some specific information about your business, can they find it? If so, that’s good technical communication, whether that information is in a procedure, a brochure, or any other medium. How do I convey to people that what I really do is make that communication clear?
What it’s not
One of the most important things to realize is that technical communication isn’t a tech writer sitting off in a corner, writing stuff. And it’s not just fixing typos and formatting the words in a certain way. People who do that are important. But doing those things doesn’t make them a technical communicator.
A true technical communicator must be able to:
· Understand the problem that the business is facing
· Come up with the best ways to measure whether the documentation works
· Extract the information they need
· Communicate the right information to solve that problem
· Be able to see the big picture, and decide whether or not the way they are handling the content will be effective down the line
Why I love it
Even if it’s hard to explain, and even if no one ever hands me a medal or retires my jersey, what I and other (good) technical communicators do is still amazing.
When we do what we do, a company’s clients understand what the company does for them. When we do what we do, the other CPAs suddenly get what the first CPA was talking about. When we do what we do, businesses that were spending too much time training and hunting down information can focus on growing their business.
That’s why we’ll keep doing this, helping more and more businesses be understood.
Help!
If you have any advice on making my profession sound cool, or if you need help solving a technical communication problem, contact us!
Elite Documentation Inc. 