I'd Rather Be Writing » career

Students Contemplate Whether a Technical Writing Career Will Be Fulfilling

Tom Johnson — Thu, 30 Sep 2010 14:41:47 +0000

For the past couple of years in October, I’ve gone up to Brigham Young University Idaho to talk to students at their professional writing conference. I’m going up there again this year. In preparation, I asked my colleague who teaches there whether students still think of technical writing as a sellout/fallback career, or whether they’re more seriously preparing for an actual career in technical writing. My colleague responded:

They’ve chosen professional writing as a career because doing so is prudent (or at least more prudent than choosing creative writing or college teaching). They may wonder, however, whether they can really be happy in a career as a technical writer. The professional world is a bit of a mystery to them, and they wonder whether they’ll really end up content as professional writers. They sort of feel that they’ll never know this until they try it, but that after they try it, it’ll be too late to go back and do something else. There’s a sense of entering a career path sort of half blind. Anything you could do to answer whether they could really be happy in a career as a tech writer would help them out a lot.

I’m at a loss for how to respond to this student dilemma. How do you know whether technical writing is the right career path for you? I’m really hoping you can shed some light as to how I could help students resolve this dilemma.

A student contemplates whether a career in technical writing will lead to a fulfilled/content professional career

In previous collaborative posts, I created a Google doc to collect the responses, but in the last collaborative post, most people just added comments below the post itself. The latter method seems more practical. I appreciate any insights you may have.

Blog Sponsors

Quoted in Technical Writing Careers Blurb in U.S. News & World Report

Tom Johnson — Thu, 29 Apr 2010 19:52:49 +0000

U.S. News & World Report article

Today a reader said he found me through an article in the May issue of U.S. News & World Report. I couldn’t find the link to the article online yet. But if you click the image on the right, you can read a scanned copy in PDF format that the reader sent me.

I don’t say anything that interesting or revelatory in the short blurb, but it’s cool to see journalists turning to bloggers for information like this. The reporter could have called the STC, and I did refer her to the STC as well, but I gave her something a little more quotable.

Blog Sponsors

From Overlooked to Center Stage [9]

Tom Johnson — Sun, 18 Apr 2010 06:38:48 +0000

Crisis Point: Problems with Multiple Roles

As my attempt to fill the wiki role failed, I started to realize how busy I had become wearing all of these hats. It seemed that I was always logging bugs, answering phone calls or responding to emails, or attending this and that meeting, championing for a redesign of a page, or coordinating with projects. The core help I was supposed to deliver wasn’t getting done.

I knew that I had been sloppy and careless in a lot of the help topics, and I just hadn’t had the time to go back and carefully review all the content for the upcoming releases like I wanted to. I was being stretched in so many directions, it was hard for me to do what I was initially hired to do: create help material. At times I would refuse to answer simple emails because I knew it would take me out of my rhythm and make it harder for me to get my work done.

I started to reach my limit when one frazzled user put me on speed dial. He called me what seemed like several times a day over the course of a couple of weeks, and each time he called he would ask questions and ramble and complain.

I realized that if just three or four more users were like this also decided to put me on speed dial, I wouldn’t be able to get anything done. Our user base was expanding with the new release, and the project manager was now asking me to creating marketing slicks and big picture workflow diagrams that they could pass out to users. I just didn’t have time to get to all of this.

When people made these requests, I would kind of nod and say okay, I’ll do it, but as the release date approached, I was so busy setting up my online help file and adjusting the style sheet and the targets and integrating the videos and putting everything else into place, the days ended before I could dive into the actual content.

It wasn’t just a matter of time, though. I also started to question the appropriateness of filling so many different roles. Although I have good common sense, I don’t know a lot about usability, quality assurance, project management, e-learning, or even live training. I do know documentation well, and I keep up with the latest trends and best practices in this field. Was I doing a disservice to my organization by filling roles about which I had little professional expertise?

I started to think back to a conversation I had had with another QA engineer when we used to drive in together to work. We must have had this conversation at least half a dozen times while driving at six in the morning. I would complain that there weren’t enough technical writers working in our organization. I said a ratio of about 4 technical writers for 600 IT people was ridiculous.

My QA friend kept wondering why, given our limited technical writing resources, I would spend time filling other roles — especially if we already had people designated to fill those roles. If I truly wanted to expand my influence and provide documentation for all of these applications and sites that lacked help material, I wouldn’t try so hard to do QA. I would let QA do QA. I wouldn’t try so hard to do design. I would let interaction designers do design. I wouldn’t try to provide support. I would let the service desk provide support. And so on.

He even said I shouldn’t try so hard to write comprehensive documentation. I could just create quick reference guides and jump from project to project to project, providing only as much help as 80 percent of the users would actually need. But regardless of my approach, overall he said that it wasn’t efficient for me to do the roles that other people had been assigned to do. Doing so created unnecessary overlap.

I thought about this, and wondered if in fact wearing multiple hats wasn’t a good idea after all. Perhaps I should have just remained in my cube and quietly created help materials in the most efficient way possible. Unless I knew something about these other roles, these other hats I was wearing, I perhaps shouldn’t wear them. After all, ultimately it wouldn’t be that helpful to the team if i were exerting my influence in areas that I knew nothing about.

Finally, what did playing these other roles ultimately do for me? It seemed that at the end of the day, I was still evaluated on the help material I produced, not the number of bugs I logged, not on the number of design suggestions I championed, not on the number of users I helped. Those seemed to be invisible efforts that, although appreciated, ultimately remained somewhat invisible. But you could hold a manual in your hand. You could see an online help system. You could watch an instructional video. And you know who produced the material, and you can evaluate the employee based on those products.

I asked my colleague what he thought about playing multiple roles. Was it a good idea?

Paul Person (“doc guy” in the Flare forums), said it’s good to fill other roles as long as you’re able. But you can’t really keep up your own knowledge about how to be a good technical communicator if you’re spread so thin in other areas. If you’re constantly moving into other areas, you suddenly don’t have time to keep up on the latest trends and best practices in your own field, let alone in the other fields.

Blog Sponsors

From Overlooked to Center Stage [7]

Tom Johnson — Sun, 18 Apr 2010 06:26:09 +0000

Catalyst 6: QA Testing

As if I hadn’t already been wearing enough hats, participating in both design, support, training, and help, I soon started to wear another hat: quality assurance (QA). We use JIRA as our bug tracking tool. It’s mostly used by QA and developers to log bugs, enhancements, and user stories. I always knew it would be good practice to keep abreast of the items added to JIRA, so I could know if the application was in sync with the help, or if bugs were leaving gaps in the accuracy of my instructions. But that was the extent of how I perceived JIRA to be relevant to me.

As I was testing my instructions (one of the most important ways to review documentation), I kept running into bugs in the application. At first I forwarded them to the QA developers through email. I wasn’t sure if they were already logged in JIRA or not, and I felt it wasn’t my role to log bugs anyway.

But soon QA started asking me to simply log the bugs. They gave me the appropriate rights in the JIRA. Okay, I thought. I’ll do it as a convenience to them. So I started to figure out JIRA, and I kept more up to date with the information and comments there. I started to log a few bugs, and then a few more. In a somewhat sadistic way, logging bugs felt therapeutic. Pretty soon I felt no fear at all and logged 25 bugs in one day. This got the attention of the developers and the project team in an astounding way.

Everyone was surprised at the degree of bugs I was finding. The QA lead had developed an extensive number of automated scripts, but he wasn’t finding all the bugs I was finding. I was finding a surprising amount of bugs precisely because I was simply going through topic by topic in my help documentation and testing everything (really testing my instructions but also the application at the same time).

I realized that I had literally written a book on the application — something no one else on the project had done. I knew the application as intimately and thoroughly as anyone else on the team, if not more. With this knowledge, especially combined with the user knowledge, I could see bugs in places QA never thought to look. Over the course of a week of heavy review of my help, I logged about 65 bugs.

One thing I was also doing was using SnagIt and Jing to show the bugs. All the other QA members just described the bugs with text. It quickly became clear that pictures were the preferred mode for developers to see bugs. They soon joked that unless the JIRA item included a screenshot, they wouldn’t review it. After a few weeks, the QA team also started to include screenshots.

QA considered me an addition to their team and said I would make a great QA tester. I thought they might be upset at the QA spotlight I was taking, because I was logging three times as many bugs as they were, but instead they thanked me for logging the bugs and genuinely appreciated it. (It would save them face later to not have bugs found in the production release.)

Pretty soon in meetings I was no longer someone they passed over quickly at the end. I was a key voice in bug triage, scrum, and other meetings, where developers and project managers would need to evaluate the bugs they were going to fix. I wasn’t just sitting there listening to others talk. Instead I was explaining the bugs I found, and evaluating the seriousness of the problems.

I noticed another thing — if I logged a bug in JIRA, someone usually fixed it. Not always, but it was the secret passage way into influencing the application. Even small fixes involving textual changes were something I could sneak in and get done. Soon one of the new developers on the team starting coming to me to ask if his planned fix was all right with me. I already owned all the text in the interface, but now that domain was blending into functionality.

On one occasion, I found a screen to be particularly problematic. I had a tough time describing how it worked, and the video I created was even more problematic. I also logged about five bugs against that screen alone. I made such a big deal of it that I convinced the project manager that, despite the time crunch and our lack of resources to fix it, we couldn’t skimp on this. He told me to get with the developers to redesign the page.

It wasn’t easy. I sat there thinking for a while, somewhat stumped on how to fix and clarify the process. I brainstormed together with a QA person and developer, and within 15 minutes we came up with a solution. We, not I. Not a single person, but we.

This was another experience where I wasn’t just documenting what is, or what had been coded. I was actually driving the design. I was determining what developers would work on through the JIRA items I submitted. I had zeroed in on the most problematic screen in the application and redesigned it.

We often come across problematic screens, but it isn’t until you start logging bugs that it actually forces project managers and developers to formally evaluate the problems and make a decision. Logging bugs makes you extremely visible on the team, because it forces an intersection point between the developers, project manager, QA testers, and you.

At this point I realized that I was much more than a simple technical writer on the team. I was actually part of a team. I was an integral player, contributing everything from help materials to customer support and training to user interface design and quality assurance and the product roadmap.

My main role was still to deliver help materials. Of course that’s one of my main contributions on the team, but it certainly wasn’t the only thing I did anymore. I had moved from overlooked to one of the main actors on the project stage.

When I would travel with the product manager to introduce the application to new groups of people, he had a hard time describing my role. He didn’t just say, this is Tom, he’s a technical writer on the team. At times he would say, Tom is our director of user education. Other times he would say Tom is our usability specialist. Other times he would say that Tom is one of our team members. Other times he would just look at me and pause before trying to figure out how to describe my role. The role he pinned on me corresponded with the purpose of the meeting.

The need to expand our roles, to move beyond what our company pigeonholes us into doing, is one of the encouragements I received from Mark Hanigan, former STC president. In one podcast, Mark told me,

It’s up to the technical communicator to market him or herself to the other individuals, the project managers, the appropriate departments within the company, saying hey, wait a minute, why do we have this separate entity of business analyst and technical communicator. I can help you with both. And we can provide deliverables that are faster, better, cheaper. And here’s why. And then you go on to explain to them what you can bring to the table.

It is up to us. We can create the opportunities that transform our role, but it has to be a conscious action. No one will magically change our jobs for us.

Blog Sponsors

From Overlooked to Center Stage [4]

Tom Johnson — Sun, 18 Apr 2010 05:39:47 +0000

The Yearning: Career Trajectory

Although my chief interest in life is writing, more literary writing than technical writing, not surprisingly I wanted something more from my career. I wanted my career to be fulfilling and worthwhile. At this time, I had been blogging for a couple of years and had recorded dozens of podcasts. I had talked to professionals in the field who had said things like, if all you do is write, you’ll soon be fired.

In the trends panels at the STC Summit, I remember listening to Andrea Ames, former STC president, talk about how her role at her company was not just a tech writer. She was like an indefinable, a strategic innovator who solved problems, not just someone who wrote documents. She was enthusiastic and engaged. I wanted to move in a direction like this rather than sit quietly writing manuals that no one was going to read, or drawing little Visio diagrams.

I later spoke with Bogo Vatovec for a podcast and asked him to expand on the issue of roles. He explained,

Doing what you’re told to do and what you’re expected to do is nowadays simply not enough anymore. You always have to do something more than what you’re basically supposed to be doing.

I also talked with Jack Molisani, who said all writers needed to become hybrids in order to make their professions take off. In a podcast interview I recorded, Jack explained the essential career path technical writers needed to follow:

To be successful over the next 10-15 years, tech comm people are going to have to become hyphenated. You can’t just be a technical writer. You have to be a technical writer-usability expert. Or a technical writer-accessibility expert. Or a technical writer-project manager.

It was clear to me that in order to be successful, to avoid sinking into oblivion and dissatisfaction, I would need to do something more than what I was doing. But it wasn’t just a strategic career move. Inside I wanted to do something more. I felt I could do a lot more.

Blog Sponsors

A Creative Way to Become a Technical Writer

Tom Johnson — Wed, 30 Dec 2009 16:25:31 +0000

One of the tough paradoxes of the technical writing field is that you can’t get a job without experience, but you can’t get experience without a job. Or so it seems.

A reader recently wrote to me explaining how she decided to write manuals for her existing job as an account maintenance clerk, even though the task of writing documentation wasn’t in her list of required duties. Doing so transformed her role. After learning more about her experience, I asked her to write a guest post, so here it is.

Post by Sarah Pruitt

Deciding to become a technical writer was easy. But finding the experience and the time has proven unforgiving. My job is not based on writing; in fact, writing is rarely needed. Between working full-time at a bank doing account maintenance (which is equivalent to data entry and entry-level coding) and going to school part-time in the evenings, I don’t find much time to create writing samples for a portfolio.

Writing is based on critical thinking and organization, but how do you measure proficiency in brain activity? Most employers tend to measure it through experience, which they often view through writing samples that you submit to them. But by the time I get home at 9:00 pm, I’m burned out from the day, and any hope of writing is gone. I have even attempted a blog, but without a focus it jumped from creative writing to personal dilemmas to sporadic quotes.

In contrast, my place of work is where I spend the most time and where I probably have the most chance of getting experience. When I realized there was some documentation that needed to be written, I took the initiative and created it for my department. I produced a schedule for the work that needed to be processed by whom and when, and I made it the most detailed and organized as possible. Cheat sheets, logs, descriptions of duties, duty assignments, birthday announcements, and anything else that I could possibly add I produced, often without request, but always with review and approval.

Noting the need for a manual for our policies and procedures, I undertook another writing project, this one more massive. The notes we had been using were old, outdated, and at odds with other notes — a manual would be invaluable. So during my spare time at work, I conjured up a 100-page manual in a month and gave it to my manager for review.

My supervisors and fellow supervisors were impressed enough to allow me to write the manuals for seven other departments in our area. If this works out well, I may be documenting policies and procedures for my entire building full-time. Being at the bottom proved helpful because even though I bear the brunt of the work as an account maintenance clerk, I also have the right information to produce the documents.

Granted, my supervisors wanted a few things changed in the manual, such as some terminology and the table of contents, but the meat was there. I demonstrated that I could organize and articulate information in a way that was valuable and useful to my company. I opened my work up to criticism and other feedback for the chance of improvement and reward.

I do not have the schooling of a technical writer (yet!) nor the experience, and there were probably a 101 ways to write the documents better. But I’m willing to learn, and the documents I’ve created, while showing that I have plenty of room for improvement, are enough to help me get my foot in the door and transform my job towards the career I want.

You can follow Sarah Pruitt at Roslanche.com.

Blog Sponsors

Technical Writer Ranks #5 in Least Stressful Jobs; Also, CNN Money Total Jobs Count Screwy

Tom Johnson — Mon, 12 Oct 2009 05:19:13 +0000

CNN Money.com said technical writing is the #28 best job in the U.S., with an average salary of $67k and a projected job growth rate of 20% over ten years. Best is determined by “great pay and superior growth prospects. Work that’s meaningful.”

Interestingly, 56.4% of technical writers say their job is “low-stress,” which makes technical writing the fifth least stressful job in the U.S. Software developers are slightly more mellow, with 59% saying their job is low stress.

Technical writers are among the least stressed out, apparently

In 2006, CNN Money ranked technical writing as #13 best job with an average salary of $57k and 23% job growth. The job growth has dropped 3% but the salary shot up 10k. Somehow this made tech writing fall in their best job rankings from 13 to 28.

Compare CNN Money’s salary findings of $67k a year with the 2008 STC Salary Database report, which estimated $61,620 a year (about 5k less). The salary estimates seem to be on target. However, when you look at the total jobs, the CNN Money report falls apart.

The STC Salary Database found that “U.S. businesses employed 47,460 technical writers.” In 2006, CNN Money said there were only 50,354 technical writing jobs, and they estimated 62,000 by 2014. However, the 2009 CNN Money survey reports that there are 84,000 total jobs. They define the total jobs as the “estimated number of people working in each specific job” (which seems a normal definition).

Something is screwy here. How is it that CNN Money’s estimate of technical writer jobs is 30,000 more than their 2006 estimate and the 2008 STC Salary Database?

Maybe they defined technical writing differently?

In 2006, they defined technical writing as

Write technical materials, such as equipment manuals, appendices, or operating and maintenance instructions. May assist in layout work.

In 2009, they defined technical writing as

Write technical materials, such as equipment manuals, online help documentation, operating directions and maintenance instructions.

Not much difference here except for the addition of online help.

Maybe the data is corrupt. The footnote for the data source says, “All pay data from PayScale.com.” If you go to Payscale.com, you’ll discover that to learn any information of value, you have to register for an account and walk through a semi-long wizard of questions. My guess is that people lose their password or register multiple times at Payscale.com, creating redundancies that would throw the number of technical writer jobs askew.

But if CNN Money’s total jobs numbers are off, how can they possibly calculate job growth? Don’t they correlate their numbers with 2006 data? And if the job growth is based on incorrect information, and job growth is a factor in the “best jobs,” how can they determine the best job? In fact, why isn’t the job growth calculated astronomically here? The change from 50,000 in 2006 to 80,000 in 2009 indicates a more than 50% job growth increase. Is this just a typo? CNN Money needs to address this discrepancy if their surveys are to have any credibility.

Blog Sponsors

Creativity in the Workplace

Tom Johnson — Tue, 01 Sep 2009 13:57:05 +0000

In previous posts, I’ve explored whether technical writing is boring. Penelope Trunk’s latest post, All advice on how to manage creative people is awful, made me see the topic of workplace boredom in a different light.

Citing research in sociology, Penelope explains that “people who work are happier than people who don’t because people who are employed spend more of their time being creative.” Creativity, then, is an important factor in personal happiness and fulfillment. Most of us know that. But here’s how you measure the degree of creativity in your work. Penelope says,

Mirowskfinds that people who work are happier than people who don’t because people who are employed spend more of their time being creative

How can you tell if you are creative at work? You could just ask yourself if you like your job. It is nearly impossible to like a job if you are not solving problems that are challenging. And if you are doing that, well, that is creative.

For a more scientific gauge, you can look at your cell phone call log. If you routinely call your friends from work, you’re probably not happy at work, according to research from Nathan Eagle, at the Santa Fe Institute.

How can you tell if you are creative at work? You could just ask yourself if you like your job. It is nearly impossible to like a job if you are not solving problems that are challenging. And if you are doing that, well, that is creative.

For a more scientific gauge, you can look at your cell phone call log. If you routinely call your friends from work, you’re probably not happy at work, according to research from Nathan Eagle, at the Santa Fe Institute.

In other words, one measure of creativity at your job is whether you’re solving challenging problems all day. If you’re not presented with these problems, then most likely you’re talking on the phone instead. (Keeping yourself busy with e-mail, Twitter, IM, and other online chatter is the equivalent of talking on the phone.)

Most people consider writing to be a creative endeavor, and in some situations, it certainly is. But creativity is not just associated with writing, art, and the humanities. Penelope broadens creativity to include problem solving too.

In many ways, even though technical writing involves writing, the writing can be less creative than coding a program or creating a user interface. Technical writing can even be less creative than designing the look and feel of the online help that will house the writing. Many times writing procedural information is not creative at all, in fact. Sure, there’s a need to figure out how the application works, but once you’ve done that, merely transcribing how to do tasks in the system can make you start yawning. There are no more problems to solve. It’s mere knowledge transfer. When knowledge transfer is what you spend your day doing, technical writing loses the power of creative fulfillment.

On the flip side, because technical writing poses numerous technical challenges outside of writing, with solutions not always apparent or easy, technical writing can also be engaging. The technical side of our profession is actually what engages me more than the writing, even though I was initially attracted to the idea of writing.

I’ve been thinking about this unexpected reversal a lot lately because I’ve noticed how consuming I find technical challenges in contrast to writing. I’m drawn to problem solving with web issues, especially WordPress sites, to an almost addictive degree. When I’m working on a WordPress project, it consumes me entirely. I can easily sit at the computer for an entire afternoon or evening working on problem after problem, ignoring everything else. Building websites often includes an almost endless supply of problems to solve.

Changing how something looks is only one part of the game. Finding the additional functionality you need, figuring out the best way to organize the content, designing the navigation with usability in mind, configuring new plugins — all of these questions and problems provide engagement with the mind. For me, coming up with solutions is a creative act that surpasses the writing of technical procedures.

Fortunately, writing only takes up a small part of the technical writer’s day, as Shanghai tech writer notes. Once you’ve finished the writing layer of a project, there are countless other technical issues to address, everything from single sourcing the content to designing the online help skin to figuring out relationship tables in Flare. I used to think these tasks were ancillary to the core task of the written content. But now I realize that as far as engagement goes, it’s the other way around. The technical challenges are the rewarding, creative part.

Blog Sponsors

Apple blogger makes living from blog

Tom Johnson — Wed, 12 Aug 2009 05:41:49 +0000

When I read about guys like John Gruber, who make their living from their blog, it fills me with envy. I want to do that. Not sure if tech comm’s audience is large enough, but perhaps someday.

Blog Sponsors

Can Others Do Your Job?

Tom Johnson — Fri, 24 Apr 2009 04:48:07 +0000

John from Delaware, who has a job in technical support, asked my advice about whether he should become a technical writer. He expressed some concern about the field, explaining that since almost everyone can write, the skill of technical writing must be decreasing in value. For example, technical writing can be easily outsourced. In an economy of doing more with less, is it really a good idea to base your career in a skill that is increasingly done by others who are not technical writers?

A graphical representation of John’s question might look like this:

It seems that if everyone can write, the value of technical writing decreases. But actually, this is not true, for reasons I explain in this post.

Even though an engineer may be able to write well, there’s a lot of supporting tasks one must do prior to writing so that the content will be worthwhile. It’s not just composing a graceful e-mail and clicking send. You have to metaphorically build a foundation and erect the walls before you can finally put the roof (the writing) on.

To be more specific, Shanghai Tech Writer says she spends just 10% of her time actually writing. This disproportion surprises most people. If only 10% of your time is taken up with writing, what happens to the other 90%? Your other time is consumed with the following:

Designing the look and feel of the manuals
Designing the look and feel of the online help
Single sourcing the content to produce both online help and manuals from one source
Finding out what tasks you should document, based on the tasks users perform
Conditionalizing text for role-based guides
Researching the user’s terminology, environment, and behavior
Anticipating pain points and user questions in the application
Understanding how the application works (and when and how it doesn’t work)
Organizing all the information you collect
Discovering non-obvious application information from subject matter experts
Fixing dreadful wording on the user interface and pointing out bugs or quirks
Figuring out how to work advanced page layout and help authoring tools
Making sure what you’ve written is accurate and up to date
Making sure your content conforms to your company’s style
Learning or defining your company’s style
Creating diagrams and illustrations to communicate complex concepts
Manipulating screenshots to be the correct dimensions, proportion, and file type for your help
Doctoring screenshots to hide sensitive data and overlaying generic information
Getting business and subject matter experts to review what you’ve written
Attending project, department, and team meetings to stay updated about the application

Sometime during all of this, you actually get a few minutes to write the help text.

It takes 90% of your time to do all of these other tasks. These tasks are necessary for your writing to be relevant, accurate, attractive, organized, and so on. For example, unless you know your help authoring tool and company style and how the application is supposed to work, you can’t write intelligently about it. Unless someone has time to do an extra job — namely all the tasks in the bullets listed above — most likely he or she won’t be writing help content that approximates the quality of your own.

You may find someone willing to pitch in 10% of his or her time to do some technical writing, but not someone willing and able to complete the other 90% while also doing his or her regular job. Technical writing is a time commitment that takes nearly all your time to do it well.

Beyond time, though, explaining some technical concepts does require above-average literary skill. If the product you’re documenting is complicated (for example, if you’re trying to explain how a storage array functions for a non-engineer), it will require exceptional writing skills to communicate it clearly.

Not everyone possesses these skills, and the majority of writing from engineers I’ve seen reinforces this point. Being clear can require you to supplement your explanations with visual diagrams; it requires you to simplify your sentences, dumb-down your vocabulary, and spin the topic so it makes sense from the reader’s point of view. Few people have the skill and patience for this.

Finally, many non-technical writers doing technical writing have illusions about the standards for help. The technical writing profession has been black-eyed by all the less-than-literate developers attempting to write help, which then appears to lower the standard for help content overall. User manuals have an incontrovertibly infamous reputation for sucking. As such, it shouldn’t come as much surprise to find engineers or interns who feel confident they can at least match, if not do better than, the last user manual they read.

Reversing that assumption is nearly possible. Even half-way decent manuals still fail. Overall, help just needs to be better — it needs to be more user friendly, more accurate, more relevant, and more convenient. It needs to be context-sensitive, full of visual illustrations, broken down into simple steps, accompanied by video tutorials, and more. If help were at the standard it should be, you wouldn’t find so many people convinced that they can create help content.

To conclude, don’t let the idea that “anyone can write help” deter you from the profession. Almost no one has time to write help while fulfilling his or her regular responsibilities. If people do have time, they often lack the talent to communicate clearly. And if they feel they have talent, show them an example of good help (rather than their VCR manual), and let them compare.