And so do I. Our skills aren’t they same, but they are equally valuable. This is what I’d like people I work with to understand.
Part of being a technical writer or editor means being invisible and vastly underappreciated. We don’t get a byline or an author credit anywhere. People often toss our creations aside, preferring to figure out how the product works on their own. And for the most part, we don’t mind. We wouldn’t do what we do otherwise. But being devalued by your own co-workers and collaborators, the people who do the “real” work—the subject matter experts (SMEs), the engineers—can really get under our skin.
Many people believe that because they speak and understand English, they can write well, and they don’t see what people like me do as a skill. This is an understandable mistake…up to a point. If you can’t code but you try, you don’t get any usable software. If you don’t understand electricity and try to wire a new house, you’ll probably kill yourself. But if you can’t write, you don’t know when you are looking at mediocre, or even terrible, writing. It all looks good enough.
But I said up to a point.
Eventually, you really should realize that writers and editors have valuable talents that others do not, have worked hard to develop those talents, and are professionals deserving of respect. In the past month, two people in my company have offered unsolicited advice on how my technical publications team should do our job. This advice has been based on “this is how we did it in my last job” and “I read this article over the weekend that said…”. As if we don’t have rules, processes, and a style guide. As if we haven’t thought out and discussed and researched the best approach for presenting our information to users. As if we are just kids off the street instead of career writers who care about our work and reputations.
I would never presume to tell the engineers how to code based on a two-hour Udemy course I took on Java Script, or tell the PMs how to run Agile product development based on something I read in Project Management for Dummies. I’m happy to get feedback about legitimate inaccuracies because I’m not an engineer and don’t have 100 percent confidence in my knowledge of how the product works. I’m happy to get feedback from customer service reps who can relate specific details from customers about what is confusing or lacking in our documentation. This kind of information is beneficial to everyone and an example of great collaboration. But when someone comes up to me to share their formatting or word choice preferences or to suggest best practices for me to create a new piece of documentation, it’s not OK.
In my freelance job as well, this can be a problem. I work on standardized test prep development. We need content experts in all sorts of subjects, including ones I sometimes know nothing about. But being a content expert doesn’t make you a good assessment question writer. I am an assessment expert. I am there to guarantee reliability, validity, and consistency. This is a skill. Writers will tell me “that’s how we do it in my classroom,” disregarding the fact that they are writing for a specific test, the specifications of which are unrelated to anything they do in their day jobs. That’s why I was hired. I may not know anything about the second Napoleonic War or Bohr’s model of the atom, but I know assessment items. I can tell you when items about these topics can be interpreted two different ways, when they can’t be answered with the information provided, when they are written in a style that differs from that of the other items on the test, and when their readability level is better suited for a sixth grader than a twelfth grader. These are skills.
Most people I work with are fantastic. They recognize that I am there to fill the gaps in their lack of knowledge on how best to present information. They recognize we are all working toward the same goal and should help each other. They recognize that hiring professional writers and editors for the documentation is essential to being a top industry performer in any field. We collaborate well, respect each other, and work toward a common goal with no ego in the way.
But if you aren’t that enlightened person, I’m asking you to think twice before you devalue the contributions of a writer or editor. You may not understand what we do, but I can promise you that if you want to take the time to ask why we make specific changes or follow certain rules, we’re happy to explain. I’m thrilled whenever people take an interest. If you don’t see how what I did made your piece better, it doesn’t mean what I did has no value. It means I have knowledge you don’t and you could learn something. So, let’s talk about it!