Mentoring a New Writer

A new writer (we’ll call her “Julie”) joined our group recently. Having worked for CheckFree for many years in a variety of positions, her latest stint being a product designer, she was a perfect fit for the leadership rôle our team needed. As a team lead, in addition to administrative and management duties, Julie would have to write and participate in projects. Management would get her up to speed on the administration duties; I gladly took on the task of turning her into a world class technical communicator.
What characterizes a world-class technical communicator?  How about one who:
  • Understands that users, business concerns, and technology must always be in balance. One of the main values in user-centered design is being able to get the user’s point of view treated as important as the business and technology points of view.
  • Realizes that traditionally this hasn’t been the case, and so constant, gentle, confident, and well-informed persuasion is more important (as always) than pouting, complaining, and despair.
  • Can apply the concepts of user-centered design in everything she does in her daily work environment:
      • Understand the audience.
      • Observe users. Realize they tend to think they know what they want, but usually are more able to tell you what they don’t want, once you’ve shown them what they asked for.
      • Use active listening skills.
      • Iterate the interaction plans based on feedback.
  • Comes to grips with making mistakes. "Fail early, fail often" can lead to great things.
  • Wants to learn more about the profession, her roles in it, and her audiences.
  • Is gracious and accommodating in her interactions without losing respect for anyone, including herself.
  • Wants to learn which battles are the right ones to pick.
  • Realizes that when she’s done her job right, users won’t notice. They’ll just get their work done and their tasks.

It’s probably obvious why the interview/hiring process is so important. If you’re going to spend time helping develop someone you’ll be proud to work with, you want to make sure your new team member is going to let you take them where they need to go! (For more information on the future for technical communicators and what we should be thinking about, I highly recommend Barbara Giammona’s excellent article “The Future of Technical Communications: How Innovation, Technology, Information Management, and Other Focuses Are Shaping the Future of the Profession” in Technical Communication 51:3, August 2004.)

The Strategic Side of Mentoring a New Writer
I spent a couple of hours over a week or so looking up college-level technical communications course syllabi. What the heck were people teaching folks interested in technical writing? At the same time, I jotted down my thoughts about what technical writers should be learning. Here’s a snippet: training should minimize tool focus. Instead of teaching someone Microsoft® PowerPoint®, I wanted to make sure they knew how to analyze the audience’s communication needs, get a solid grasp of what needed to be communicated, understood SME interviews and reviews, could chunk and assemble information according to the audience’s needs, and present clearly what the audience needed in the way the audience wanted. Because Julie and I had worked together when she worked in the Product Design team, I found interactions we’d had that I could turn into “teachable moments,” showing her the technical communications point of view for something she’d seen me do in the context of her design point of view.
The Tactical Side of Developing a Professional
I felt I could help Julie see that she had made a professional, career move, not just a job change. (I actually am semantically oriented!) To that end, I moved away from the company- and project-specific references into the realm of published literature, guides, articles, and other resources (such as Web sites). I assembled a list of criteria that I would judge all books, articles, and other information against when selecting things for Julie to read and us to talk about. To get on the list, items had to do these things:
  • Practice what they preached.
    Books about writing had to be examples of what they were talking about. They had to be engaging, informative, easy to read, and fun.
  • Be funny. Be happy about the field!
    The information had to match my sense of humor. (I never said this was an objective undertaking!) In other words, it had to be funny, fun, and a pleasure to read.
  • Be pertinent to how we do things where Julie and I work.
    The information needed to match (as much as it could) what we do at CheckFree (technically and socially). There’s nothing wrong with information that spells out where we should be going or how we should be planning on getting “there,” but that topic’s a bit too theoretical for the on-the-job-training I was setting up.
  • If a cost was involved, make sure it was extremely reasonable.
    I planned to provide as much of the information as I could in PDF form (articles captured from the Web; book chapters downloaded from the publishers’ sites marketing whatever book I was interested in). There were some books she needed to pick up, but these couldn’t cost an arm and a leg. (Sticker shock sets in quickly at your favorite online bookseller: have you seen the prices of Gerson’s well-received fifth edition (2006) text Technical Writing: Process and Product or Markel’s highly-recommended eighth edition (2006) Technical Communication? Yikes!)
  • Fit the realities of learning this on the job.
    The information had to lend itself to 30-minute to 1-hour meetings at most twice a week. Heck, we had enough work for our team that we had to hire a new writer!  We can’t spend the entire time with theory. The information I shared had to match (and usually was brought to her because of) project issues and teachable moments.
List of Books for a Beginning Technical Writer (current as of May 2007)
Here’s the list I am currently putting into play. So far, the feedback leads me to believe it’s been helpful. Right now our new writer is experiencing the STC conference getting her TechComm 101 certificate. I’m really curious as to how what she and I have been doing since last October has prepared her for what she’s encountering at the conference. I’ll use her feedback (and my continued interest in this topic) to keep this list updated. What would you add or change?
  • Developing Quality Technical Information: A Handbook for Writers and Editors by Gretchen Hargis et alii.
    Chapter 2 is available online as a PDF. This is one of the most helpful and stunningly written books I have encountered. This is a gold mine of information. Pick this up. It will serve you for years to come.
  • The Microsoft Manual of Style by Microsoft Press
    The book comes with a CD that holds manual in PDF format. What can I say. You gotta have it. "Choose or select?" "Mice or mouse devices?" It’ll come up sometime.
  • Technical Writing 101: A Real-World Guide to Planning and Writing Technical Documentation by Alan Pringle and Sarah O’Keefe
    Chapter 14 and pieces of chapters 3 and 8 are online. Generally quite good, extremely readable, and wonderfully laid out and chunked. Careful with the section on what format to choose for a screen shot and such. It’s just plain wrong. It also fails to mention that ALT+Print Screen is OK for popping screen shots into non image-editing programs. But the moment you move it from the clipboard into Microsoft Paint, for example, you’re working with something at 96 dpi, way too few dpi for printing.
  • Untechnical Writing: How to Write About Technical Subjects and Products So Anyone Can Understand by Michael Bremer
    Amazing work. He knows what he’s talking about, writes clearly with great humor, and presents his information such that you can’t wait to read the next chapter. Really!
  • Is the Help Helpful? How to Create Online Help That Meets Your Users’ Needs by Jean Weber 
    Wow. Talk about a superb book. Weber obviously cares about her audiences. She’s like a confident, knowledgeable, gentle, and comfortable friend. When you purchase this, you get access to it (at the publisher’s Web site) in PDF format.
  • Hot Text: Web Writing that Works by Jonathon and Lisa Price
    Much of the text (not all, but almost all) is available as separate PDFs at the Price’s Web site. Absolutely outstanding and immediately useful and helpful.
  • The Art of Project Management by Scott Berkun
    This is definitely as good as you’ve heard. Its real title should probably make you realize more quickly that it’s about leading projects where you have to manage a group of folks designing something who haven’t typically taken users into account and who’ve never noticed that their efforts lead to something greater than the sum of its parts. A charming and quite hilarious introduction to leading software development projects.
  • Single Sourcing: Building Modular Documentation by Kurt Ament
    The title is somewhat misleading. This deceptively small tome hides a wealth of information you’ll be surprised didn’t take up 10x the room. At once a style guide, a theory of what modularity means, and an example of what it talks about.
As Julie and I have worked through various issues, topics, and strategies that our projects have brought up, I’ve appealed to various online sources including: