- Image via Wikipedia
The whole certification thread on TechWr-L has me thinking that much of the certification opposition is unfounded. That is, most voicing opposition are doing so from a very subjective if not emotional standpoint. I’m neither for nor against certification at this time. I want to see what STC comes up with. So far, I think they’re on a pretty good path.
Rather than drone on about certification (you can read about that elsewhere), I’d like to focus on some of the myths about technical communication that tend to be touted as truth.
- You can’t define what a technical writer does. This is flat out laughable. Look at your job description. If it’s not accurate, fix it. Look at the BLS job definitions. Look at any resume.
- It’s impossible to objectively evaluate a technical writer. This is also laughable. My management experience says otherwise. I worked very hard to develop objective criteria for evaluating both hard and soft skills surrounding a technical writer’s performance. It’s possible, and it’s a worthwhile exercise. And for those tech writers out there who haven’t experienced an objective review, let me know how I can help you and your manager remedy this.
- Technical writers get no respect. Ah, what I like to call Rodney Dangerfield Syndrome. Respect doesn’t come with a title, folks. It’s earned. Come to the plate ready to play ball. Not all pitches will be easy lobs down the middle. Adjust your stance and swing only at the good pitches.
- The technical writing field is too broad for certification. I have my doubts about that. Colleges somehow have degree programs for it. And I can’t imagine project management being any less broad, yet PMI somehow is able to settle on tried and true criteria for success.
- Technical writing tools and practices change too frequently. Well, yes, in part they do, and this is a good thing. Would you prefer a stagnant career? Aspects will change, but fundamentals will not. People will always need to know what something is, how to use it, why to use it, etc. There will always be a core need of providing the right people with the right information in the right manner at the right time. That you use RoboFrame 2056 or MadWorks ePublisher-It X8 to create your documentation, or that you do so using the Socratic method or rhythmic breathing is fairly irrelevant in the grand scheme of things if you fail to deliver quality information.
I’m sure I’ve missed a bunch. Feel free to add more myths in your comments!
{ 1 trackback }
{ 17 comments… read them below or add one }
Well said!
Great points, Bill.
On myth #5, I’m not sure why people are talking about tools changing. It’s an irrelevant issue. From what I’ve seen of the STC certification plan, there isn’t talk of evaluating based on your expertise with tools. It’s an evaluation of your competencies in process and delivery, not what tool you use. Maybe your reasons for choosing the tools you did would be part of the evaluation, but I don’t think STC is going to have some bias toward certain tools and say you should use them in all cases. Such a thing would be outright wrong. It’s not a software or programming certification.
As you said, basic tech comm principles don’t change. Modes of communication and delivery may change, but core principles of good communication apply across them. So I believe you can evaluate based on those core principles.
“Socratic method or rhythmic breathing” would be a great name for a rock band.
I think “Rhythmic Breathing” would make a great title for a blog too.
Myth 6: Technical writers are commodities, not professionals. They provide no tangible value to the organization.
I wish people wouldn’t jump on their horse and ride off in all directions before the program even starts. Let’s wait and see how this works before we predict the dire and tragic end to life as we know it.
Good post, Bill.
Why focus on on technical “writers”… when so many of do much more? Technical *communication* instead?
Rick, that’s precisely the language they’re using. Technical communicator/communication.
Sharon, no kidding. I’m waiting for people to start shouting “Churches! Churches! Very small rocks!”
Larry, nice addition! Care to flesh it out, or shall I?
Ben, it was more of a general comment, but good commentary!
Well, it does save time to set your hair on fire and run around the room *now* instead of waiting for actual information.
I prefer to wait and see what this will be about. Call me silly!
Great post! Myth 7: Nobody leaves school saying, “I want to be a technical writer.” Ha ha, well that one is probably true. But if I’d known about the career I would have chosen it then, because I think it’s an awesome job. Certification may help make people aware of this choice sooner.
Cheers, Sarah
Myth #1:
The work of a technical writer is far too subjective to accurately explain exactly what a “technical writer” does. It’s such a vague title that carries several responsibilities and there is the global assumption that the documentation deliverables, in their many forms, will just appear when expected.
“Developing information” isn’t limited to entering text into an authoring tool and publishing the PDF or HTML files you were hired to develop. It starts with determining what needs to be developed, for whom, and then figuring out a way to actually develop it as accurately as possible on time. By “figuring out a way,” I’m eluding to all of the overhead that has zero to do with writing and everything to do with presenting some kind of substantial information, usually by any means necessary, on demand, that justifies one’s paycheck.
Online help is the perfect example. Online help is not limited to HTML files linked to Help buttons in the UI. Technical writers are expected to contribute to, or, in many cases own, all text that appears in the UI, which typically resides in code source files. You must now learn the process, and sometimes the tools, for getting text into the UI, or editing what’s already there. You’re now having to chase down UI developers to get the context-sensitive strings in place and ensure that they link up correctly. Is this technical writing or software development?
What about all of the usability testing we do? As we “write” about using a product, we also highlight inconsistencies or bad user experiences not picked up by developers, QA, etc. Is this technical writing or usability testing/design?
Tracking delivery dates, bugs/fixes, SMEs, scheduling meetings, and, more importantly, routinely becoming the bridge between the different groups that don’t communicate with each other. Is this technical writing or project management?
Recording videos or tutorials, embedded in PDF or help files to provide a richer user experience or more useful information to a user. Is this technical writing or tutorial development/training?
Don’t have the resources to produce a complete and accurate documentation set for the entire product? You’ll figure it out. After all, it’s just “writing” and anyone can do that.
Only a few examples above, as I could go on for several pages, but the primary problem with trying to define what a technical writer does is that there is are far too many aspects to “developing information” and far to many forms in which it can be “delivered” that have nothing to do with writing.
Myth #4:
Taking a college course taught by professors who teach you how they think technical writing should be done is far different than being certified by a Board that has created a framework of exactly how technical writing should be done. I’m certified in ITIL, for example, which required that I learn the ITIL framework for IT service management. It has its own terminology for every process, function, and a precise flow as to how one responds to, manages, and resolves IT service requests. I’ve not done the PMP certification, but I do know that it too has an extensive framework that defines how to manage a project, keeping it on budget, on time, and minimizing risks.
I have no idea how one would develop a framework for “developing information.”
> Care to flesh it out, or shall I?
Have at it, Bill.
Mike H: Would you boss agree with your take on #1? You really can’t define what you do as a technical writer? It seems you just laid out a nice outline in your comment, therefore disproving your very point. If you can’t define your job, there’s no way you can justify performing it. Plain and simple.
Mike H: regarding #4, I find that hard to believe if you work in technical writing. Whether you realize it or not, you DO use a framework for developing information every day.
It’s not so much that these things are undefinable, are great mysteries, or are some kind of mystical voodoo. It’s just that those who don’t have these things properly defined haven’t taken the time to do so.
Myth #1 is foshizzle dizzle. Maybe we couldn’t certify the entire portfolio of a tech writer/communicator/info developer/processing hacker but we could certify the output, much of which is similar between industries. We could also certify a general understanding of the basics, several of which I am sure I would fail unless I crammed using a book like “Technical Communication: The Missing Manual”—(Hey! The pages are all blank!)
In all seriousness, if we can’t describe our role and the value we bring to an organization, why do they keep us? We have to be really good at taking work off of someone else’s desk in order to justify earning a paycheque.
Personally I am excited at the changes to STC, of which certification and social media are only two. I also commend Steven Jong for stepping out and opening up the discussion on techwr-l. It’s great to see this much controversy and dicussion so early in the process—after all, it’s the agile way.
Bill, please do tech writer Mike H. a favour and correct his spelling of “alluding”? Thanks.
Enjoyable post, Bill. When a discussion invites analogies to Monty Python films (yours here, and the mention of the People’s Front of Judea in the TechWr-L list), it may be a sign that people are taking themselves too seriously.
There’s a philosophical purpose behind certification that most people seem to be overlooking. Certification says that technical communication is a profession, not a task. The basic principles of the profession apply across tasks. Proficiency in executing those principles is what makes us technical communicators — not the tasks we perform.
It’s absurd to say that good technical communication can’t be defined. As I wrote in a recent article for Carolina Communique (newsletter of the STC Carolina Chapter), good procedure writing is strongly influenced by the qualities of the verbs used. Generally speaking, procedures should be written in second person, imperative mood, present tense, and active voice. This is measurable. You can look at every verb in a procedure and ask whether the verb has those qualities, and if not, does this impair clarity? Now, obviously, writing isn’t mathematics. A technical writer can take a perfectly clear sentence and turn it into nonsense by changing it from passive voice to active voice if they misunderstand who or what is performing the action. But a savvy technical communicator understands the difference between rules and guidelines, and applies them judiciously. Any good manager or certifying body will recognize that as well.