Levels of difficulty and stress in a technical writer job

I have been thinking lately about how to measure the level of stress and difficulty you could expect from a particular technical writing job. Would it be the type of content you write? The output requirements? The deadlines? This post is a result of some ideas my coworkers and I discussed over lunch the other day.

There’s an article called “What Do Technical Writers Find Stressful?” on the techwr-l website. The author divides the stress into categories and then describes each one in detail. Here’s his list:

  • Work overload and time pressures
  • Last-minute changes
  • Difficulty with Subject Matter Experts (SMEs)
  • Problems with managers
  • Ongoing learning challenges and limited access to a product
  • Poorly defined and managed projects
  • Computer and tool problems
  • Workspace environment
  • Job security
  • Lack of control over the work environment
  • What categories would you add to the list? What brings you the most stress as a technical writer?

    My next question that I’ll try to answer is, how would you discover the stress level of a job while you’re still interviewing for it? Here are my suggested questions.

    • Tell me about the last product release, did the doc go out with errors or did it go out late? Give me a specific example of your choices between quality and deadlines.
    • Do you feel like you get enough information about release changes? How are changes typically communicated to the writers?
    • How many meetings do you attend each week? (Interpreting the answer might be tricky – more than 15 hours a week of meetings probably means there’s plenty of communication, but how will you get the actual work done in 25 hours a week?)
    • What processes are in place for product releases? How closely are the processes followed? Does the team use any Agile methodologies? Is it Waterfall method? Is there no method?
    • What platforms does your help support? Do you have any concerns about accessibility? How about multiple language requirements?
    • Give me an example of how you gather information from developers or business analysts when you need to write a new procedure.
    • What are the specs on your computer? Do you run the product on a separate computer or separate server? Do you have two monitors to run the product and to author the content?

    In your interview, also try to read the stress level of each writer and manager you talk to. There may be clues in the amount of preparation they had for the interview itself, and whether the writer needs to immediately go to another meeting. What other observations might offer clues to the stress levels there?

    I agree with the Brazen Careerist that one question not to ask is, “How many hours do you work per day?” This is a personal question that has to do with the individual’s work and life balance and may not reflect the department or the company at all.

    Let us know your personal favorite interview questions when you are a candidate for technical writing and related jobs in the comments below.

    Related links about asking questions as a job candidate:

    10 Comments

  • September 6, 2007 - 5:26 am | Permalink

    I remember being interviewed at one company where one of the interviewers didn’t show up, and I was interviewed by the person who was currently in the position. Without much prompting, he talked about how he put in late hours every day, and worked most weekends (but took Sunday afternoon off)! I said something to the effect that I could unerstand why they needed a second technical writer to ease the workload – and he said no that he was moving into writing marketing materials!!

  • September 6, 2007 - 8:35 am | Permalink

    Ha! Well I suppose you could interpret that situation a few different ways – the company must have been a good place to work if the writer chose to stay there. And it’s hard telling if the other writer was too busy or had another agenda, but boy, missing an interview is poor form and doesn’t reflect well on the company or the writer. Great story, thanks!

  • Mike
    September 7, 2007 - 8:52 am | Permalink

    I believe my job as a Manager is to plan well, judge abilities and schedule appropriately. My goal is to have my employees work as close to 40 hours/week as possible. In fact, I often tell people to stop working so much.

    Quality and quantity of work, and this is proven not just opinion, significantly after 50 hours. If you’re working 60 hour weeks, you’re introducing about as many errors as your documenting.

    Stop it!
    Mike

  • diane fleming
    September 12, 2007 - 1:41 pm | Permalink

    Most stress as a technical writer: The feeling that what I do isn’t valued by the company – that documentation is necessary, but not all that valuable. And the notion that anyone can write – it’s not a skill. Also, the requirement to report status to everyone and his brother. And the push to buy into the next new thing (single-sourcing, wiki, agile) when some of those new things are fairly old (they were doing information architecture at IBM in 1988 when I was there), and when some of those new things aren’t about writing at all, but are about technology. I haven’t been encouraged to improve my writing skills over the years, which seems very strange to me.

  • September 15, 2007 - 6:31 pm | Permalink

    Mike – I know first hand that you have a great gift of ensuring the quality of work going up as the stress level goes down. If only all managers had that same ability! And if only it were easy to figure out which managers have that skill.

    Diane – You have such great writing skills that it’s no wonder no one has asked you to improve them, although I’m sure your natural gift has been strengthened over the years.

    The funniest response I got to this post was from Penelope Trunk via email, and I just have to share it: “I used to be a technical writer. And then I realized that technical writing just made me want to kill everyone I work with because everyone thinks they are a better technical writer than the technical writer.”

    That urge to kill would certainly be stressful. :)

  • October 2, 2007 - 8:22 am | Permalink

    I must say that I agree with diane. It’s so stressful to put a lot of effort in a documentation project that it exists just to check some box on a list at a release date. The company I work for gets a lot of money from support, but they still want documentation finished on time. Anyway, nobody considers it valuable until a customer find some feature that does not work as the manual says :-). Then you get the attention you expect, though not the positive one.
    And another stressful thing is the whole mysterious information about the release, build dates, the project milestones, the deadlines that you may face and that you may find out if you are lucky… I know the situation is not common, but I only speak for the company I work for…
    and the release notes can become stressful when nobody is willing to approve them… although many PMs are more willing to “correct” your English than your technical information.

  • Lacey
    October 4, 2007 - 8:39 am | Permalink

    I would also say that a huge stress in this field, and in the medical writing field, is knowing what titles or keywords to search for when looking for a job. There is no consistent title, no way to know that what one calls technical writer, another calls documentation editor, another calls productions specialist, another calls communication officer. Though reading the descriptions and talking to someone at the company will eventually tell you these things, the actual searching process becomes quite frustrating and complicated. I’ve even seen what’s basically a technical writing job listed under “marketing associate.”

    Perhaps this issue is more of a frustration of someone just starting off in the field. Networking certainly makes the job search easier, but that only comes over time. In the meantime, I’ll continue to sift through hundreds of job ads that appear relevant, but aren’t.

    Anne, I also have to mention that I too am a Miami MTSC grad! I finished my course work in December 2006 (the internship report is yet to come). It’s been great reading your posts.

  • October 4, 2007 - 8:11 pm | Permalink

    Hi Lacey, I’m so glad to know MTSCs are reading my blog – thanks for commenting. I agree the job search is stressful especially if you’re searching when you don’t have a job already.

    I’d guess that some of the keyword explosion that you’re seeing is due to the changes in the career of technical writing. I have been reading so many blog entries lately on the changes in our field. If it were me, I’d just keyword search on everything I could think of in indeed.com and set it up as an RSS feed. You won’t be sifting through hundreds for long, you’d get a handful a day. Also, be sure to keyword search only on the things you actually want to do. :) I don’t think you’re missing too many jobs if your search is within 50 miles of a certain zip code like indeed.com lets you set up.

    Also, to turn the search around, make sure that you are findable. Get on LinkedIn (add me), start a blog (wordpress.com is great), get on Twitter (I’m annegentle), and FaceBook (we need to start a MTSC group on there) to start connecting.

    Penelope Trunk at the Brazen Careerist is my “continual click” blogger right now – her blog is like a book I can’t put down, but instead of turning pages I just keep clicking links. Do a search on her site for “job search” and see what you think of her ideas and links – some are innovative, some are tried and true classics.

    Keep me posted on how it goes!

  • luette arrowsmith
    August 8, 2012 - 11:05 am | Permalink

    I’m looking for metrics and ways to determine scope and how long a project should take. The expectations are not realistic but saying that without any data isn’t working. Please send templates, rules of thumb, anything.

    larrowsmith@email.phoenix.edu

  • August 11, 2012 - 10:27 am | Permalink

    Hi Luette –
    This is a tough one and often discussed at technical writing lists and lunches. You need to evaluate the maturity and complexity of the software/service/product itself as well as resources available to writers for interviews and testing the product.

    One of the best tools for estimating is from Joann Hackos’s book, Managing Documentation Projects. You can pull it up on the Internet Wayback machine at http://web.archive.org/web/20100929040821/http://www.comtech-serv.com/dependency_calculator.htm.

    However, one good point from a review of the Dr. Hackos book is this: “After 20 years as a technical writer and publications manager, I’ve come to believe that all publications lifecycle systems are doomed unless they map directly to the development methodology engineering management supports and uses.” I happen to agree with that sentiment. Get your writers and their processes as close to developers as possible. Be sure to quantify and measure as they quantify. Hope this helps!

  • Leave a Reply