Technical Communication Poll: Mastering Critical Thinking Skills

After we published last week’s poll, we received several comments that indicated we had a few large gaps in the list of “soft skills” technical communication professionals need to “survive and thrive.”  Kell C noted that “analytical thinking” is crucial, and encompasses inquisitiveness, skepticism and being business-minded.  Indeed, we’ve seen numerous threads on the email discussion list and a number of good blog posts and articles decrying the apparent loss of critical thinking skills, not only in technical communication, but in business generally. Some critical thinking abilities are pretty obviously important if you plan a career in the field—gathering information, interpreting data, identifying problems and workarounds—but others seem at first glance to anathema to our daily work. For instance, is it appropriate to draw conclusions in technical writing, or do we really function more as objective journalists?

Wikipedia, always a great place to start (emphasis on the concept of start) research, describes critical thinking as “thinking about thinking.”  It then goes on to list a number of critical thinking abilities that bring back fond (well, maybe not “fond”) memories of undergraduate classes in rhetoric and Socratic theory. So we’ve compiled that list into this week’s poll to get a sense of which skills practicing technical communicators really use—or want to use—in their daily work.

Do you find that you’re lacking in any of these abilities? How would mastery of the ones you’re not strong in impact your career development, or the project you’re working on now? Sometimes going back to the basics, whether it’s a review of grammar and syntax rules, proofreader’s marks,  or HTML tags, gives us a fresh perspective and the chance to make measurable improvements in our work. We can’t help but wonder if a refresher course in critical thinking would also improve our performance, both in terms of our profession and of our ability to contribute to the organizations that employ us.  Or maybe it’s all overrated philosophical gobbledygook? Do we need to sacrifice critical thought for speed in order to make the latest deadline?  Share your opinions with us, by posting a comment or starting a thread on the email discussion list.

Which critical thinking skills should be mastered to be an effective technical communicator?

View Results

Loading ... Loading ...

John Cahill

10 years ago

Greetings. I am an accidental “technical re-writer”. As such, I am untrained, unskilled and relatively ignorant in many areas that are vital for the people I re-write for e.g., calculus (my “clients” work in IT interface research). I have to say to them, “I have no idea what this equation means, so you will have to double check it some other way. I am only fixing the English into which this data is embedded.” Thus I see a very clear and deep line (ravine) separating myself from those experts and I make sure that they understand that I take no responsibility at all for their data, their reporting of the data and their conclusions. I imagine it is easy for technical writers to overstep their role and perhaps their sense of expertise in the field. The relevance is this: the degree to which I think I (should) become an expert in my client’s field determines the priority I give to the various critical thinking skills in your list. This understanding of my role (and of the technical writer’s role) also makes some of the items in your list quite ambiguous (for me, at least). For example, does the #1 item in the survey {“Identifying problems and potential workarounds”} apply to the client’s product/research or does it apply to my rewriting? At my amateur level, I must assume that it applies only to my rewriting, not to the research (and I would think, not to the product design or marketing). For me, going beyond this point to a position where I consider myself competent to judge the research (product/design) itself is not my province at all and puts technical (re)writing in a position of dangerous arrogance. Nevertheless, I do find that by clarifying or by seeking clarification on points passed to me by engineers and researchers, improvements to design etc., do sometimes emerge, but not because the discovery of “problems and potential workarounds” in the product/research itself are any of my business. Thus, this item {identifying problems…} was not a priority for me at all. I do, of course, understand that this might simply reflect my ignorance!

Subscribe to TechWhirl via Email