Can Others Do Your Job?

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:

Can others do your job?

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.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

15 thoughts on “Can Others Do Your Job?

  1. ivan walsh

    <If people do have time, they often lack the talent to communicate clearly.

    I’d second that and add that if you have to justify your existence as a tech writer in a company – for whatever reason – then it’s time to look at other options.

    Companies that value the role of tech docs are always worth seeking out, both from a personal and career perspective.



  2. Marijana

    Have you been inspired by yesterday’s Dilbert ( 😉

    The fact that everybody thinks he / she can write doesn’t make me afraid of losing my job (I hardly no anyone in another profession that wants to take over my job…). But it makes me more frustrated of how much I always need to argue about how long good documentation takes (“Oh, come on, you copy & paste that all in MS Word. It can’t take you THAT long.”). What a developer does is so abstract and magical to most of the people that they would never argue that much about working hours and pages. But writing is something that everybody can understand and therefore it must be easy.

  3. Joe

    Similar threads have come up before on this subject. The Unvarnished Truth (the name of one of them) is, to some extent, a lot of it is true.

    First of all, everybody thinks they can write. Not only write, but write well. The higher up the corporate ladder they are, they better they think they can write. Unfortunately, the opposite is usually the case. The better they think they can write, the worse they usually are. And the higher up the chain they go, the worse their writing usually is. I cannot believe some of the emails I get from Directors, Senior VPs, even the President. I’ve seen better communication (not to mention grammar) in text messages from my kids when they were in high school.

    Second, most people have no idea what a technical writer is, or what one does. Some have an idea – and it usually involves us “prettying up” or “wordsmithing” something somebody else wrote (like an engineer who doesn’t have time for such trivialities). Others, who do have a clue, think “how hard can it be? You write stuff like ‘click this, type that’. I told one person once that I was a technical writer, and she thought I wrote articles for computer magazines. When I explained what I actually did, she was amazed. I asked her who she thought wrote what was in the online help she used, and she said she thought the computer just wote it!

    Third, RTFM. How many people actually do that? For my mother, and a lot of my friends, I’m the “gadget guy.” Whenever they can’t set up their new cell phone, or (back in the day) their VCR, they call me. My first question, “Did you look at the manual?” “Huh?” And most of the time, when I did get it working for them, and they looked at me like I was the digital God, it wasn’t my superior technical savvy that enabled me to get it working where they couldn’t, it was because I took five minutes to sit down and read the instructions. Granted, some of them were extremely poorly written, but in some cases they were easy to follow and included graphics. My mother’s DVD player even came with a quick-start guide that included basic setup instructions (all she needed).

    But, as I said, in the real world, most people never even look at the manual. Even the software we sell – high-end EMR systems that support hospitals. The last time I went on a site visit, one of the Sysadmins had a question about error messages. She said it would be really nice if there were someplace she could look to see what the error messages mean. My reply, “Did you look in the System Administrator manual (one of mine)?” “Huh?” So, we went into a server room where all the manuals were in a box behind one of the server. After searching through the box, finding the manual and blowing the dust off it, I turned to the section where there was a table documenting each error message (over 500): the number, the definition, and a description of what it meant. She was awestruck, and thanked me profusely. I was awestruck that it never even occurred to her to look in the manual.

    Finally, there seems to be an attitude emerging that with this new generation that grew up with computers, video games, and gadgets, it’s taken for granted that everyone just knows how to use software, and nothing more than a perfunctory help system, if that, is necessary. That, and the “economy” has led to a lot of cost-cutting, and you know who gets cut first.

    The “unvarnished truth” is, no matter how important you perceive yourself or your job to be, it’s not important at all unless somebody else (clients, upper management, etc.)perceives it as important. If nobody reads your manuals, and the CFO thinks they can trim costs by getting rid of “dead wood” you’re gone. I don’t care how many times you’ve been president of your STC chapter or how many awards your manuals have won.

    Yes, anybody could do my job. However, that could reasonably be said about probably anybody in my organization. The question is, could they do it as well as I do? I guess if they could, I wouldn’t be getting paid what I am.

    Happy Friday,


    1. Kelly Riley

      Thank you Joe. Your post is well said. I wish I could have everyone at every company read this article and your post so I wouldn’t have to repeat myself, defend myself (or what I do), and constantly show my value.

      1. Jasmine

        While I agree whole-heartedly, I have to point out that tech writers are certainly not alone when it comes to defending their positions and justifying their existence. I used to be a trainer and when a staff member or team can’t or won’t do something the right way despite training, fingers point to Training. And when budgets are cut, training is up there for taking the earliest and biggest cuts. I had to go a whole year on a zero dollar budget, then had to explain why I wasn’t running any courses but spending my time updating the manuals.

  4. Craig

    A long time ago, in a galaxy far, far away, I had a converstion like this with my dad. It was the mid-1970s, and I had an inkling that I wanted to be a writer.

    I caught him in the kitchen, and told him. He was scribbling a grocery list. He said something like this: “Look at me, I’m writing the grocery list. I’m a writer, too. This makes me a writer. Anyone can be a writer. No one is going to pay you for this.”

    We never talked about it again, but I eventually became, some 30 years later, a technical writer. I think he would have been proud and rather surprised that we CAN make a living at this stuff.

  5. Katie

    I love hearing that “anyone” can write. The truth is that people *think* they are good writers and that writing is easy. Writing is an underappreciated skill. I spend a significant portion of my time corresponding with people in order to make sense of the documentation they sent me because they are poor writers, and what they wrote isn’t clear at all.

    Another misconception is that technical writers spend most of their time writing, which they do not, as Tom outlines so well here.

  6. Raj

    People also think that good oral communication skills can translate to good writing. This is not the case. Most of them write terrible user documentation, that too in substandard English.

  7. site update service

    thus one must see to it that the person whom you want to write for you must understand and know the standards of your company. professionalism and keeping your articles readable for your niche is the key.

  8. Janie

    I presume it was also John who complained in the other thread that no one read manuals.

    John, that’s because not everyone can write them.

    People assume that because they can write letters and lists, they can write professionally.

    That’s like thinking that because you can walk and skip and dance at a wedding you can dance professionally.

    My first question for these amateurs is: Do you know what to leave out?

  9. Josh

    I think one problem is that many of our collegues are so unfamiliar with reading and writing that they aren’t literate enough to tell the difference between good documentation and bad documentation. To them, the world of words is a strange, foreign place they’ve never quite figured out.

    As a result, they don’t know why one draft of a manual might be better than another. They don’t know which of two possible sensences might be more clear. If you showed them two magazines and asked them which one was designed more effectively, they’d meet your question with a blank stare.

    So, without basic analytical skills, these people assume all writing is equal — including the lousy writing they might do themselves.

    Thus, in the eyes of these semi-literates, anyone can write.

    1. Tom

      Josh, thanks for stopping by my blog and leaving a comment. I like knowing that you read it from time to time. I agree with your point, and must confess to be guilty of the same when it comes to design and other fields. To me, although I have gut reactions about good and bad design, I don’t have the discriminating taste of a professional interaction designer. But even without professional training, I like to think that more often than not I can pick out a good interface design from a poor one. Same with non-writers and writing. Although they may lack the analytical skills and ability to discern good documentation from poor documentation, I’m betting that at least three quarters of the time their gut reaction guides them correctly.

  10. Ivan Walsh

    Hi Josh,

    <in the eyes of these semi-literates, anyone can write

    I think you’re a little harsh on your collegues here. I doubt if they are semi-literate. They are probably v well educated but may not have the same vested interest you and I have in the std of documentation.

    FWIW: someone once reminded me, “if developers could write good user guides, you’d (ie little ol Ivan) would be out of a job.”

    and of course they can do things I can never do.

    maybe a little repect is due here. just a thought.



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>