The project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.

It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

The idea that “no one reads the manual” is certainly not new. But despite this accepted truism, most of us don’t entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.

I need this fantasy about the way my manuals are used because without it, there’s no motivation to write.

Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,

Early on in my tech writer career I had the eye-opening experience of walking into an engineer’s office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It’s like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It’s Official–Nobody Reads the Manual)

In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don’t read the manual before calling support (Gadget Problems Divide the Sexes).

It’s not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, “Your customer hates big manuals. He has shelves and boxes full of them just like you do.” (Manuals in Extreme Programming).

I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.

Joel Spolsky, a programmer and web entrepreneur, says,

Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)

When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don’t actually use help.

Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: “When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.” (If no-one reads the manual, then why bother?)

Looking at help this way is seeing the help as an emergency kit in a car. People won’t normally need the emergency kit, but when you’re stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.

Flipping Sides

Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.

No One Knows

Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it’s distributed in print, you can’t really know.

For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?

At one point, just as she and other family members were getting frustrated, one person jeered, I can’t figure it out, and there’s no manual at all!

More people get frustrated assembling things on Christmas than on any other day of the entire year. It’s a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We’re often in the same position of ignorance about our users.

If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you’re on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you’re needed.

Conclusion

As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I’m pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don’t have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.

If I find out, through feedback or on-site visits or other means, that they don’t ever read the manual, that they have never actually opened the manual beyond the table of contents, that’s okay. I hope they never have to.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Although Gladwell’s Outliers has been criticized for drawing generalizations from a “flimsy selection of colorful anecdotes and stories,” and his argument borders “social predestination,” according to the New York Times, Gladwell’s conclusions do provoke a lot of thought and self-reflection. If you look at the reasons why you’re a successful writer, you may find it was due more to circumstance, practice, and upbringing than any gift you were imbued with from birth.

For example, rather than this model of success:

Common misconception about how success happens

This is really what’s going on:

The real story of success

Practice

Gladwell says most experts accrue about 10,000 hours of practice before they develop their talent. For example, the Beatles spent two years in Germany playing long hours each day (8 hours a day, 7 days a week, for a good chunk of the year) before they became famous. Bill Gates spent hours and hours programming (20 to 30 hours a week), skipping athletics and even sneaking out at night to get in computer time. Although Mozart was skilled at the piano, he didn’t start writing his own compositions until he reached 21 years of age (prior to that, he mostly played compositions that others wrote). If you add up all the hours of practice from those who possess talent, and compare them to those who lack talent, the numbers explain a lot.

Timing

Gladwell relates several examples of people who were successful because they had the right skills at the right time. For example, William Joy (who wrote Unix) learned programming before it became popular. Just about the time he accrued 10,000 hours of programming practice, personal computing arrived, making the scene perfect for someone with his skillset to exploit the market.

As another example, in the 1940s and 50s, lawyers skilled in dealing with hostile takeovers and litigation suddenly became highly sought after, whereas years earlier the practice was considered shady. Those lawyers who accrued the practice before the skills were valued after became wildly successful.

Culture

To illustrate the importance of culture in success, Gladwell relates a story of a Colombian pilot who most likely crashed a plane because, even with diminishing fuel, he wasn’t assertive enough to stand up to the intimidating control tower agents and demand to land. Cultures that encourage passive submission to hierarchy, or who phrase their questions in subtle, vague euphemisms, may find themselves at a disadvantage in some situations, such as the airplane cockpit.

Other times, your culture works for you. For example, Gladwell explains that Asians who spent centuries working in rice paddies, a type of farming that requires meticulous care all year long, passed on this work ethic to their posterity. Many of the inheritors of the rice-paddy culture apply the same diligence in their schoolwork. This diligence, of course, brings more success.

Upbringing

The way you were raised, namely with wealthy or less fortunate parents, also plays a role. Gladwell explains that when wealthy parents drive their children to the doctor, they tell their children things like, “Johnny, now if you have any questions, be sure to ask the doctor. This is your opportunity to talk to him about any health problems you’re having….” And so on.

In contrast, the children of poor parents may feel less entitled to this same questioning. Instead, they accept what the doctor tells them straight out, without surfacing concerns or criticisms. Gladwell then uses Chris Langan, a genius with a 195 IQ who wasn’t able to succeed in college, as an example. Langan failed to get a PhD (his goal) not because he lacked intelligence, but because he had a mentality to passively accept the conditions and limitations others imposed on him. Langan ended up dropping out of college because he couldn’t convince his teachers to accommodate a simple change in his schedule (a change he needed because his truck broke and he could no longer get to campus early in the morning).

My Story

I found it impossible to read Outliers: The Story of Success without looking more closely at my own story of “success.” Obviously I’m not a success like the people mentioned in his book, but I am a professional technical writer with a well-known blog and podcast. How did I manage that?

First, I wrote extensively in junior high, high school, and college. My father, a lover of literature, frequently put books in my hand, established a model of reading, and shared his passion for literature and ideas. My mother made every effort to open opportunities for me, sometimes working two jobs to help pay for my undergraduate education.

After college, I continued writing daily through a three-year MFA program at Columbia. Rather than study fiction or poetry, I studied literary nonfiction, particularly the personal essay. It was my good fortune that I graduated with the degree I did at the time I did. When I graduated in 2002, the blogosphere erupted. It was the perfect time for someone with skills in short personal essays to flourish.

My foray into podcasting follows a similar pattern. Although I don’t have an audio engineering background, much of my success in podcasting comes from my interviewing skills, from my ability to find people and get them to open up. From 1994 to 1996, I spent two years as an LDS missionary in Venezuela, interacting with strangers ten hours a day. Each morning we ventured out into unknown barrios, knocking on doors, talking with people in the streets, talking with people in their homes, befriending members and anyone we came in contact with. It was a social immersion in another culture, but it was also training ground for podcasting, because although I’m generally shy and will keep to myself, I feel completely comfortable approaching strangers and interviewing them in a conversational, natural style. I developed a skill that became extremely useful at the right time.

My facility with WordPress also fits into the equation. I’m comfortable with WordPress and can create websites fairly easily, but it wasn’t always this way. As a composition instructor at Columbia, I created a website for my students because I saw the value of student-to-student interaction. I then created an elaborate website teaching at the American University in Cairo. I spent months painstakingly figuring out how to do technical things. I also had a sister in graphic design and a brother-in-law in interaction design that I could occasionally rely upon for information.

More valuable than specific technical knowledge, though, I learned how to solve technical problems. I learned patience to search forums, persistence to query search engines, and a trial-and-error mentality that encouraged experimentation as a solution. This ability to continue plugging away at a problem, especially when the answer isn’t easy, is a skill incredibly useful for IT (and it’s what enables people to excel at math, according to a study Gladwell cites). When I stumbled upon WordPress, I already had hundreds of hours working with websites, and I brought that skillset to the existing scene and combined it with my writing and interviewing skills.

Besides timing and practice, I also attribute some of my success to lucky opportunities. When I applied for my first job in technical writing, the writing portfolio I submitted included an article about protein, which I’d written as a copywriter for a health company (a job I got through a connection from my techie sister and brother-in law). The hiring manager had a PhD in biology and could see that what I wrote about protein was, in fact, clear and accurate. Not only that, she knew it was a difficult concept to write about. It was precisely because of this article on protein that I was hired, even though I had no experience in technical writing. It was a lucky connection that opened up an opportunity for me.

I’ve also been fortunate to never have technical writing jobs that required more than 40-hour work weeks. I frequently hear about people routinely working 60-hour weeks, which would preclude any spare time for blogging and podcasting. Instead, even with three kids, a wife, and other commitments (such as being a scout leader), I manage to have most evenings and weekends free.

And speaking of that wife, she turns out to be another huge factor in my writing, since she not only writes in an engaging way that motivates and inspires me but also helps create a safe writing environment in our home. When I turn on my computer, she doesn’t pull me away to mop the floor (not usually, anyway). Instead, she joins me and we write together on the couch, sharing thoughts and experiences with each other. When I married her, I never anticipated that our lives would be this way, but it did and has made a significant difference in finding time to write.

Not all of my background, however, works positively toward success. If there’s one thing I’m conflicted about, it’s my lack of a sense of entitlement. For example, I’ve always felt hesitant about returning items to stores, about raising my hand to offer criticisms or complaints in large groups. I sometimes devalue my contributions at work. Frequently I’m content to accept my surrounding conditions and the status quo because either I don’t think I can change it, it requires too much effort, or I don’t care.

After reading Outliers, I find myself acting more assertively. I catch myself when I’m being passive, or when I don’t feel qualified or entitled to something.

I realize that a sense of entitlement is usually looked at negatively (certainly it can lead to arrogance and pride), but not having any sense of entitlement can be stifling. People who don’t feel entitled to anything lack confidence and self-esteem. They accept their conditions. They do what their superiors tell them. They lack ambition and don’t challenge the status quo. They second-guess their worth, attributing any modicum of competence to other people and circumstantial factors. It’s a self-defeating, trapping mentality that limits your ability to succeed because you don’t feel entitled to success.

My point is not to give a biography of my life, but rather to illustrate Gladwell’s point: if you start looking at the underpinnings behind your success, you can start connecting the dots to see how you arrived where you did. It usually isn’t that you have a knack for a certain profession, but that you acquired the necessary skills through practice, upbringing, environment, culture, and lucky opportunities.

Outliers reminds me of a scene from the movie Good Will Hunting, where Matt Damon, playing a poor teen from the South side of Boston confronts a rich MIT student. Damon tells him, You were born on third base and you think you hit a triple. In other words, we often over-attribute our writing successes to our natural talents. But really, those talents and abilities came about through a series of explainable, fortunate circumstances that we should recognize and be grateful for.

Resources

Buy Outliers: The Story of Success from Amazon

See Malcolm Gladwell’s blog

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Download MP3 (to download, right-click and select Save Target As)
Duration: 32 min.

Deborah (Shapiro) Hemstreet

In this podcast, I talk with Deborah (Shapiro) Hemstreet about the personalities of technical communicators, based on research she conducted as part of her masters degree. I got the idea of interviewing Deborah from on a discussion on the Techwr-L listserv about a movie called The Technical Writer. In the discussion, Deborah wrote,

I read the reviews… And it sounds to me (without having watched) that it is a caricature of the stereotypical idea of a technical writer (introverted, neurotic and a geek)… But just the reviews are enough to turn me off to the movie.

Having said that, it made me think of my own research a few years back when I was doing my MA in technical communication… My thesis was on the personality characteristics of technical communicators. It surveyed over 220 technical communicators from around the world. I used a validated personality test based on the five-factor model of personality along with a questionnaire about each person’s professional practice, and a demographics section.

I mention this, because of the whole issue of the stereotypical introverted technical writer. My findings were the exact opposite of what we would expect to see. The majority of writers were extroverted. When I correlated professional practice to the personality characteristics, it appeared that effectiveness improved with extroversion, with managers being the most extroverted. The majority of introverts were editors (made sense to me), and only a few rated negatively with regards to what the five-factor model called neuroticism. Interestingly, those few writers ranked low in professional practice.

I find the topic of personalities extremely relevant in our field. At times, technical writers spend much of their day isolated in their cubes writing documentation. They have little interaction with others. Other days, technical writers are constantly interacting with project managers, designers, and other subject matter experts (SMEs). Technical writers are almost investigative journalists, tracking down reluctant SMEs to extract information, influencing product design change, training groups of users on new releases, and voicing opinion during conference-room-packed meetings.

I’m fascinated by Deborah’s conclusion about extroversion (which she defines as being open, friendly, and outgoing). Those who are more extroverted tend to be more effective in their careers. In this podcast, we talk about how she measure effectiveness, as well as strategies for personality change. We also discuss neuroticism, and how tendencies toward perfectionism can be detrimental to one’s success.

Additional Resources from Deborah

The following links are additional resources from Deborah.

Center for Applied Cognitive Studies

The above link provides information for practical applications of the Five Factor Model of personality. They redefine the OCEAN scores into terminology that is a lot easier to follow and more applicable to technical communicators.

Five Factor Personality Test

This is a link to the original site where she discovered the test. Anyone can take this test and get their score immediately. The answers will be used for ongoing research. The author of this test gave me permission to use it and felt it would meet my research purposes. I could not provide self-testing with scores, however, as I did not have the use of the scripts that this website provides.

Introversion Turned Inside Out (.ppt)

This is the presentation that she gave with a colleague at the STC Conference two years ago. It provides more information about introversion versus extraversion.

The Secrets of Effective Technical Communicators

Other investigators are now finding support for Deborah’s findings.

Contacting Deborah

People are welcome to correspond with Deborah at deborah.hemstreet@gmail.com and to visit her site (currently under development) at www.tech-challenged.com.

Audio Note

I was hoping the audio would be crisper and clearer, but Skype gave me a little trouble. I amplified and balanced the audio as best I could.