Turning Your Rants into Raves: Putting Your Best Self Forward in a Challenging Marketplace

1. Turning Your Rants into Raves:  Putting Your Best Self Forward in a Challenging Marketplace Barbara Giammona San Diego Chapter April 8, 2009

2. Goals of this session • To examine some of the negatives we all find in Tech Writing and turn them into positives • To use those positives to help advance your career (or find your next job)

3. Rants and Raves • Rant: to speak or declaim extravagantly or violently; talk in a wild or vehement way • Rave: to talk or write with extravagant enthusiasm http://dictionary.reference.com/

4. Have you heard of Waiter Rant? 50 Signs You’re Working in a Bad Restaurant March 17th, 2008 by Waiter Anyone who’s ever waited tables knows how hard it is to transition from one restaurant job to another. To help make the process a little smoother I’ve compiled a list of warning signs to help waiters avoid working in dysfunctional [places]. 1) They hire you the moment you say, “I’m looking for a job.” 2) You start working Friday and Saturday nights the first week. (That’s because waiters quit with alarming regularity.) 3) Your boss doesn’t ask you to fill out a W-2 or ask for ID of any kind. 4) Training consists of a cursory tour of the restaurant and the head waiter telling you “sink or swim.” 5) The restaurant doesn’t pay new hires a training wage. Trainees often get used as unpaid slave labor and are told after their “probationary period” that “things aren’t working out.” 6) There are porn screensavers on the owner’s computer. 7) There are porn screen savers on the POS computer. http://waiterrant.net/?p=359

5. Waiter Rant – the Book

6. What would be in our blog/book? • Technical Writer Rants • Spend the next 10 minutes at your table coming up with a list of the rants you think are most common among Tech Writers • Horror Stories • Things we are most likely to complain about • Poignant observations about our chosen profession

7. (Possible Rants) • Enter here

8. (Possible Rants) • Enter here

9. I hate it when engineers think that nobody else’s profession comes remotely close to the honor and prestige of engineering. Here’s my story … When I go to pick up a manual out for review, the technical support engineer says to me, “Here’s your review back. I only had a few comments. You know, you understand this product so well, I really think of you as … an engineer.” He’s looking at me as though he’s just given me an Academy Award. I’m rather happy to be making a living as a writer, so I say, “Thanks, but I’m a writer, not an engineer.” He repeats it loudly and slowly, as if I’ve now fallen from the pinnacle of engineering understanding and am too stupid to comprehend the complement he thinks he’s giving me, “Yes, but I think of you as … an E-N-G-I-N-E-E-R.” “But I’m not an engineer. I’m a writer. I consider it part of my job to understand what I’m writing about.” “Wouldn’t you rather be called an engineer?” he asks, completely astounded that anyone on the planet would turn down such a label of greatness. “No, I would rather be called a good technical writer. I’m proud to be a writer. Don’t you think a good writer is just as valuable as a good engineer?” He squints up at the ceiling as this foreign notion attempts to fight its way into his mind for the first time. After a long pause, he finally leans toward me and winks. “OK,” he says, “I’ll call you a writer if that’s what you want. But I’ll always think of you as an engineer.” I give up and leave with my manual. So I’ve always tried to turn that rant into a rave by writing the best manuals I can. If a customer reads my manual and thinks the product’s easy because of it, that’s my sneaky way of getting back at engineering hubris!!!   

10. For some reason, it seems like technical writers are always placed near the Support department. Despite our experience (you know, writing), we tend to get grouped in with easily the LOUDEST group in the entire organization. As a writer, I need time to resolve issues and determine the best method to convey complex processes in a concise way. Unfortunately, hearing an individual say “Click the Start menu. Yes, the Start menu; it’s near the bottom of you monitor. NO, your monitor is the thing you look at!” get’s old very, very fast.

11. Documentation is an afterthought and so are we. I can’t tell you how many times I hear “Oh, I’m sorry, I forgot to <include you on the email / invite you to the meeting / ask for your estimates>. I’ve been “forgotten” more times than I can count! • Everyone comes to us if they have a MS Word problem, hoping we can fix their problem and not make them actually try using the Word Help to solve it themselves (ooohhh…there’s a concept!). Because we are writers, we must be Word experts, right?

12. When developers/programmers/engineers attempt to edit my grammar. I don’t tell them how to program, don’t tell me how to write. If I’m not taking your writing for non-technical reasons, it’s because it’s WRONG. • When no one remembers documentation/Tech Pubs until the 11th hour. “Oh…wait…we need to update the guide by…tomorrow.” • The usual “it’s just a quick update” or “it’s just one small change” or “it’s not a big deal”…if you have to convince me, then it probably IS a big deal! • Not getting recognition after the product is released…Tech Pubs deserves a pat on the back for getting a product out the door as well.

13. When people don’t proofread your documentation when you ask them during review time, but then when it’s ready to ship they find a billion things they suddenly want changed. • When people proofreading decide that’s a good time to make design changes, but leave it open-ended. “Maybe we should have a field for user’s to change the password here as well??”…GREAT THEN TELL THE DEVELOPERS THAT…I can’t tell them to do more work and change a field because of something scrawled in my user guide a few days before it’s due! • Reviewers not addressing any of the questions scattered throughout the draft and then just emailing back “looks great! I would just change the line on page 10”. Uhhh what about the 20-odd questions I told you I needed answered throughout the document?! • The feature is in, the feature is out, the feature is in, the feature is out… (You get the idea.) • Writing a status report takes as much time as writing an actual document. The best part is, nobody reads either one of them! 

14. My conclusions: What we needed to succeed in late 2003 • Become Part of the Development Process • Launch a Public Relations Campaign for Our Profession • Improve Our Professional Societies • Become Better Business People and Managers • Repackage Ourselves for the Future

15. My conclusions: What we needed to succeed in late 2008 • See them in May Intercom • Hint: Not a lot has changed! • Think about: • Information Gratification • Value • Solutions • Advocacy

16. What Hiring Managers Look For • Writing Skills • Verbal Skills • Presentation Skills • Technical Skills • People who won’t embarrass them or who will be tough to manage • Your fit for the culture of the department and the company • To “fall in love” – “chemistry”

17. What do you bring to the table? • Resume – the document itself! • Job history • Education • Awards • Outside Interests • Technical Skills • Technical Writing Skills • Industry Expertise

18. What do you bring to the table? • Baggage • Your last bad company or boss • Health issues • Reputation • Relationships at home and office • Successes and Failures • Self-Image

19. Rants to Raves • Technical Writer Raves • Spend the next 10 minutes at your table coming up with a ways to turn your assigned rant into a rave

20. Rants to Raves • Share the findings

21. How to apply this to your work/job search? • Discussion and Application • Remember: • Become Part of the Development Process • Become Better Business People and Managers • Repackage Ourselves for the Future

22. What I hope people will walk away with…. • A chance to do some self-assessment around the core skills of our profession • A realization of negativity can be your downfall • Some guidance on how to keep a current job or impress to get a new one • A chance to laugh at ourselves a little

23. By the way…. • It’s not all negative. • Some “real” Technical Writing Blogs….

24. The Art of Technical Communication • This blog is devoted to what we at YEDA call “the art of technical communication“. By that we refer to the fact that Technical Communication is that unique activity that provides a bridge between two very human worlds: the world of technology, the world that is continually created through man’s capacity to produce tools and methods to achieve certain ends; and the humanistic world of understanding, of comprehension, of knowledge - the world that can only truly be experienced on an individual level on the part of each particular human being. • Both of these worlds - the brute technological and the “human” world of understanding - truly define Man and his uniqueness. The art of technical communication is none other than the art of being able to bridge these worlds through explanation and instruction. To successfully fulfill its task, it requires many skills - ability to express oneself in writing, graphic ability, psychology, and information handling, to name the most obvious. But more than that, like any art, it requires devotion and enthusiasm. Only these last two can motivate the “artist” to continually search for new ways to coax the maximum meaning out of the technology itself - for the technical communicator, in a sense, bestows meaning on the work of technology by explaining it. http://www.yedacenter.com/wordpress/?p=3 (Israel)

25. How to Fix Technical Writing Wednesday September 27, 2006 12:44PMby chromatic in Technical Most technical writing I’ve read isn’t very good. One of the reasons the Head First series works is because applying a little cognitive science to the process of writing forces writers and editors to think from the audience’s point of view now and then. The mini-rant How Not to Teach Database Design uses an existing article to show mistakes common to much technical writing. Even if you don’t know or care about databases, read and think about the post if you might someday write documentation, an article, a tutorial, or even a set of instructions in your weblog or a wiki or an e-mail somewhere. Don’t worry; they’re not grammatical rules you’ll never remember. They’re just five tips that will help you craft better prose. http://www.oreillynet.com/onlamp/blog/2006/09/how_to_fix_technical_writing.html

26. Can Products Be So Good They Need No User Documentation? I pose these questions to a candid world: 1.  Do you know any product, software or otherwise, that is so bloody good it does not need set-up instructions, a manual, user guide, training DVD, or other hand-holding support? Nominations, please, in your posted comments. (You should see the manual for the electric bread maker I just bought). My HP laptop came  without a manual, and I still can't figure out what half the LCDs tell me.  I'm not an Apple user, but I'm told Apple doesn't include user documentation in their packaging. (I'm also told you don't need them. Anyone agree?) 2. Do you know any engineers, subject matter experts, software developers, or otherwise guru-level professionals whose command of the English language and sense for teaching are as good as their engineering, such that no manuals for their products are required?  I'm talking consumer-level products here, not complicated B2B enterprise products or systems. In short, are there living legends of documentation out there who walk on two legs, are more likely to use a napkin  than their sleeve, and don't scribble math formulas on bathroom walls? Keep those nominations coming.  The nominee would have won some award or other for software simplicity. 3.  Do you know any consumer products companies that have their product documentation system so perfected that they really are specially recognized for it? Seriously, are such awards or recognitions available to compete for?  If not, who should hold the contest?  Perhaps the Society for Technical Communication? http://www.timrosablog.com/ (Nov 20, 2008)

27. Technical Writers May Be the Future of American Literature A professor argues that technical writers are the future of American literature. Utah Valley State College English professor Scott Hatch says that the great American literature of the early 20th century was penned by journalists such as Ernest Hemingway, but in the future it is the technical writers who have the best training to be novelists. Technical writing didn't exist 50 years ago, but like journalism or copy writing, it provides a "great, practical, roll-up-your-sleeves" practice to creative writing, said Scott Hatch Tuesday night to a dozen members of the Intermountain Chapter of the Society of Technical Communicators. Before becoming an academic, Hatch was a technical writer in the software industry. He also writes poetry. Signature Books this year published his collection of poems, "Mapping the Bones of the World." http://www.writerswrite.com/wblog.php?wblog=814071

28. “Read rage” over manuals Yelling and throwing things.These may be behaviors of cranky preschoolers and temperamental Hollywood divas. They are also reactions of readers to bad documentation, according to a survey conducted by "The TechGuys", a UK-based technology support provider, and reported by the BBC's Channel 4. The TechGuys survey of more than 1,500 consumers revealed that nearly 40% of the respondents became so irate that they yelled with frustration due to the over-complicated nature of instructions. And one in five even threw the offending manual across the room. http://www.janetswisher.com/

29. Closing Thoughts • The Best Reason NOT to Rant: “Today’s crisis becomes tomorrow’s forgotten issue.” Barbara Giammona

30. Questions Barbara Giammona Manager, Technical Publications IPS/Wonderware 26561 Rancho Parkway South Lake Forest CA 92630 barbara.giammona@wonderware.com bgiammonacomms@gmail.com

31. APPENDIX:San Diego Chapter’s Own Rants to Raves

32. From Mark Fogg • After many years of ranting about technicians and engineers’ inability to write, I decided to turn it around. I put on my old economist hat. Although I might like the engineers to write better, frankly, it’s not their job to write. They’re specialized labor. It’s their job to do engineering. That’s where our firm makes its money — custom-engineered industrial power systems, each worth millions of dollars.… No longer do I dread the manuscript that thuds onto my desk or surfaces with an ominous electronic beep as an attachment to my email. Nowadays I think of it as an opportunity to not only help that particular engineer, but also as an opportunity to help the company make better use of its labor dollars…. Has it paid off? Yes. Our technical documentation department is now brought in earlier on projects, sometimes even during the development phase when we can make input into the design….. We’re seen as part of the parade nowadays, not just the group who sweeps up after the parade. And that’s a good feeling.

33. From Catherine Welch-Eckey’s Table

34. Eben Brooks Table Common rants of Tech Writers: * Companies don't know where to put us * Asking for "innovation" and then pigeonholing * Last to know, first to go * Job is nothing like the job description * "Can you print me out a..." * Treated like a glorified secretary * Deadlines changes on a whim by executives * Dropped on a project after release * Treated as glorified proofreaders * "Do something, and I'll see if I like it" * Inability to clearly define what they want from us * Talking down to us, because we're not "engineers" or "won't understand it" * Asking for knowledge of X number of technologies, then when you're hired you never use them * Asking for irrelevant knowledge Change a rant into a rave! * "Do something, and I'll see if I like it" --> Re-frame the problem as 'how to most benefit the customer' and work together to meet those needs. Treat documentation as 'controlled documents' with equal importance as drawings, plans, etc. Work with engineers on a peer level, exchanging information for mutual benefit. Be up front with needs and requirements.

35. From Pamela Blyth’s Table • Companies don’t know where to put us • Nobody reads the documentation, or that’s what people think • It’s hard to show our value – we are a cost center not a profit center • We get no respect from the engineers • We are outside the loop – the last to get the info • Project managers and marketing don’t factor time for documentation into projects • They think that writers are here to “make it pretty” • Engineers write badly • It’s hard to document bad products! • We are dismissed rudely by other project team members • We are valued only for the tools we know • Bad document control • No training in our roles • It’s hard to get information about how something works vs. how to work it • SMEs don’t know how to use the product • Lack of a career path • How to show our value: • Give the engineers a copy of the finished manual so they can see the final product • Publicize positive feedback you receive – forward emails to key people • Show our value: • Focus group testing usability of a manual written by engineers vs one written by a TW. • Volunteer for things outside your job that help others • Keep global audiences in mind when writing materials that will be localized • Show customer time savings from good docs • Offer docs in more formats for customer ease of access • Make it Pretty: • Show before and after examples of writing and format. Ask for feedback on how well you did explaining the features, not just making it pretty