Off and on for awhile now, I’ve been reading Daniel H. Pink’s excellent A Whole New Mind: Why Right-Brainers Will Rule The Future.
Reading this book encourages me that many technical writers have the skills–and more importantly—the vision—to compete and lead, in what Pink calls the Conceptual Age.
Given the forces of abundance, outsourcing, and automation, the central thesis of Pink’s book is that “L-Directed Thinking remains necessary, but no longer sufficient…
…we must become proficient in R-Directed Thinking and master aptitudes that are high concept and high touch. We must perform work that overseas knowledge workers can’t do cheaper, that computers can’t do faster, and that satisfies the aesthetic, emotional, and spiritual demands of a prosperous time (p. 61).”
Pink’s book–with its right-over-left brain slant–is mistitled in a way, because overall he acknowledges the need for both approaches “in order to craft fulfilling lives and build productive, just societies” (p. 27). The book’s opening quotation from Coleridge further underscores the importance of both left and right brain thinking: “The truth is, a great mind must be androgynous.”
The Importance of Whole-Brain Thinking to Technical Writing
I hadn’t thought of Pink’s book in a few weeks, but I did after a recent post, when I asked if it’s ever possible for an individual (or organization) to perceive “both ways”–that is, through our intuitive, creative minds (what Pink calls R-Directed Thinking), and through our more rational, analytic minds (what Pink calls L-Directed Thinking).
This question occupies me a lot, as my role as a technical writer often requires me to seamlessly move back and forth, between both L-Directed and R-Directed parts of the organization.
Technical Writing, Creativity, and Problem-Solving
I’ve read or heard other technical writers speak about the creativity our profession requires…not so much in our procedural writing, but as Tom Johnson notes in his Creativity in the Workplace post, in the problem-solving tasks that are the greater part of our day-to-day activities.
How do we as technical writers draw more attention to the problem-solving, that is, the creative tasks that constitute the greater part of our work days, than the procedural writing that other parts of the organization may sometimes perceive as the extent of our expertise?
Do non-technical disciplines sometimes dismiss too quickly the creative problem-solving of technical professionals?
About This Blog: Copyright Information
Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog
Peg Mulligan's Blog 
Nice post, Peg! I not a good prognosticator, but I can tell you this: the image spins both ways for me: If I want to see it spin right, it does. If left, it does. I can pretty much see it in either direction, whenever I want.
As far as creativity in the profession, I’ve always found it to be an extremely creative discipline. Formulas and theories inspire part of what we do, but I don’t think it’s fair to say that it’s not creative.
Again, nice post! Thanks for putting in the time to write it!
Thanks for dropping by, Michael…I’ve known lots of technical writers, who started in English or journalism…so, the creativity part makes sense.
I think what lots of non-technical folks probably don’t understand is how much else besides writing our jobs involve…especially the problem-solving…I remember my first tech writing mentor telling me how he created screen captures for a product U.I that didn’t even exist yet, creating doctored screenshots, from the existing UI…now, if that isn’t problem-solving, I’m not sure what is…
The very act of writing cohesively about something that often doesn’t exist yet, except in pieces, in several developers’ & product managers’ minds, is an act of imagination.
Thanks again for sharing and for your kind words.
~Peg
I think many technical writers use both sides of their brains, not necessarily at the same time, but may shift back and forth, depending on the task, or their environment.
I find that when I start new projects, I follow an L-brain process: research, read, collect information, make lists and outlines. When the information I’ve assembled does not slip easily into the desired format, I get frustrated. What do I do with all the pieces that don’t fit? If I distract myself, or consciously work on another project, my R-brain keeps working on the original problem. At some point, I’ll get an inspiration, or figure out what is missing to give the document a structure that makes sense, and then I’ll be able to use my previously assembled information to finish producing something useful to the user.
For those challenging projects that are not just plugging a set of facts into a simple format like Release Notes or Installation Instructions, the right brain design synthesis that is necessary to conceptualize a whole document or set of user assistance documents is what makes a good technical communicator invaluable to an organization.
Hi Margaret,
Thanks for your insights, on a way of working, which resonates for me, and I suspect by the nature of our deliverables, a lot of technical writers. Switching back and forth between left and right brain thinking, in the manner you describe, is what I meant by androgynous or “whole brain” thinking.
Learning to harness the respective sides in our own potential and to recognize the characteristics (along with the strengths & weaknesses of thinking entirely to the left or right) is important in not only the deliverables we produce, but in the teams we assemble and the way we lead them.
Thanks so much for your recent comments…Your feedback has really helped validate and clarify a lot of my ideas…
~Peg
However I look at it, and however I think, whether I pause it and restart or go away and do something else for a bit, I can only see her rotate anti-clockwise. I hope this is no more accurate than a horoscope, because if not, I am rather disappointed to be SO uncreative.
The ‘right brain vs left brain’ test has been comprehensively debunked:
http://scienceblogs.com/neurophilosophy/2007/10/the_left_brain_right_brain_myt.php
The rest of your post makes a lot of sense though.