I'd Rather Be Writing » hiring

Tough Situations for Technical Communication Managers: Saul Carliner at the STC Summit in Dallas, #stc10

Tom Johnson — Mon, 10 May 2010 04:18:14 +0000

In this video interview, I ask Saul Carliner to give practical tips for handling some of the toughest situations that technical communication managers face, including firing, metrics, frank conversations with underperforming employees, and more. Saul gave a two-day workshop at the STC Summit for technical communication managers.

Blog Sponsors

Managing Writers: Interview with Richard Hamilton (podcast)

Tom Johnson — Tue, 24 Mar 2009 03:13:38 +0000

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

Richard Hamilton is the author of Managing Writers: A Real World Guide to Managing Technical Documentation. His book, published in 2009, is one of the few books written specifically for managers that addresses the diversity of issues that managers face today – everything from hiring and firing to motivating, metrics, outsourcing, localization, content management, and more.

Managing Writers

Richard describes the book as follows:

Managing Writers is a practical guide to managing technical documentation projects in the real world. It is informal, but concise, using examples from the author’s experience working with and managing technical writers. It looks beyond big project, big team methodologies to the issues faced by smaller, less well-funded projects.

I actually met Richard Hamilton at Doc Train West 2008. At the time, he was still writing his book, but he handed me a brochure describing the book title and its contents. I’m glad to see that some months after our conversation, he published it.

A few weeks ago, Richard sent me a review copy, so I decided to interview him for a podcast. In our conversation, we cover the following:

Hiring and firing employees
What to look for in resumes
Danger points in interviews
Motivating your team
Rating and ranking
Overcoming differences about tools
Measuring success with metrics
The importance of documentation plans
Getting involved early in the software development process
Ensuring proper allocation and balance across your team
Evaluating whether writers need managers

For more information, see Richard Hamilton’s book, Managing Writers. You can also read Richard Hamilton’s blog. He has made a sample chapter available here: What Doc Managers Look for in a Resume.

Blog Sponsors

What To Do When You’re Not Picked to Be America’s Next Top Tech Writer

Tom Johnson — Fri, 20 Mar 2009 15:10:49 +0000

This is a guest post by Thomas Curnyn, a technical writer in Dublin, Ireland. He currently works for a software company specializing in school administration and scheduling software. He’s been at his job for the last 5 years and has been a writer for 10 years altogether.

Tom wrote quite a while back about writing tests (10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers) and he mentioned some things that should set off the alarm bells if you’re evaluating the work of a potential new writer for your team:

The writer doesn’t use numbered steps.
The procedure had 20+ steps without being broken into separate tasks.
The writing is unclear.
The writing is poorly organized.
The formatting is sloppy.
The writer doesn’t structure the content with styles.
The steps are inaccurate.
Field definitions aren’t illuminating.
You can spot misspellings and grammar errors.

I’d have to agree with all these and I think writing tests are a great tool to spot someone who’s maybe done some testing or worked on a support desk and thinks, hey, how hard can it be to do documentation? But what happens when you take one of these tests and you know how to write? What happens if you know what a gerund is and when to use a semicolon? What happens when your writing is clear, well organised, well formatted, when you’ve 10 years’ experience, when you KNOW you’re a good writer, when you’ve taken a writing test, feel that you’ve aced it, and one week later you’re told that you’ve failed?

Well I think you have maybe three basic options. You:

Can accept that you had a bad day and move on
May decide that you don’t cut it and maybe admit that you don’t know how to use a semicolon after all!
Have the good sense to realise that you are a good writer and the reason you failed has nothing to do with you or your writing

I recently failed a writing test set by a multinational software company. Obviously I was a little surprised and upset to fail a writing test – a test that I thought would be a formality. I felt like I was an experienced doctor who’d been asked to perform a routine procedure (to remove an appendix, for example) something I could do in my sleep, and then being told a week later that I’d killed the patient.

After my initial shock I tried to figure out where I went wrong. The test had three parts: two separate grammar tests and a third “Tech Writing” test. Looking back now on the grammar sections of the test, I should have realised that the testers didn’t know what they were doing when I got questions like this:

What is the right word is in the following sentence?

You _____ a moron if you don’t know this.

(a) are

(b) is

This company, being the real morons in this story, wasted 30 minutes of my life by giving me not one but two of these asinine tests. By the way, the example above was probably one of the trickier questions!

The third test was a more typical Tech Writing test: describe how to use a calculator, explain to your grandmother what a computer virus is – that sort of thing. These tests can be challenging – what calculator functions do you describe in 30 minutes? Should I telly grandma the difference between a Trojan and a Worm or is that too much detail? Anyway, unlike the basic grammar tests, I could see the point in this – it allowed me to show that I can write well, organise my thoughts, and work under time pressure. I did pretty well, I thought – certainly well enough to get a passing grade.

So why did I fail?

I believe that tests are a useful tool for evaluating a potential writer but this belief is predicated on the idea that the people setting and marking the test know what to ask in the quiz and what to look for in the answers. In my case I don’t think the people correcting my paper knew what was good or bad writing. In fact, I have a feeling that the people correcting my work weren’t even technical writers.

As a little epilogue to my story, I recently asked my friend who works in this company, and who recommended me for the role in the first place, whether they’d ever hired someone and he told me that they’d not even got to the interview stage because NOBODY had passed the test! Why, you may ask, could there be such an appalling failure rate for what sounds like a pretty simple writing test? Apparently it’s because the test was designed and graded by non-native English speakers based in the company’s HQ in Germany! What exactly they were looking for (and how I and all the other applicants went so horribly wrong) I do not know. They certainly hadn’t read Tom’s post on the subject. For them, and I’m just guessing here, maybe a numbered list looked all wrong. They may have thought, Hey why is this idiot using the active voice? We were always told in school to use the passive voice. What’s all this white space about? Where are the big chunks of text that show this guy can churn out the text?

I have to admit that hearing that I was not the only one to fail this writing test was reassuring but I think it’s important to be confident in your own abilities too and not depend on a test for validation of your skills. I think (at the risk of sounding like Dr. Phil) that it’s important not to automatically assume that you are a failure when you fail. If you ever feel like you’re the doctor who’s just been told he’s killed the patient be sure that the person who’s giving you the bad news is also a doctor and, more importantly, knows how to take a pulse!

Blog Sponsors

10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers

Tom Johnson — Fri, 14 Mar 2008 05:46:43 +0000

I received an email the other day from a hiring manager who asked me what tests they should give to their technical writing candidates. She writes,

We are hiring two new technical writers and are trying to come up with a practical for the candidates to complete. We had been asking the applicants to write a quick how to (e.g make a pb&j, withdraw cash from an ATM, etc.) followed by a longer writing sample, but our HR rep isn’t sure if this is the best qualifier. Any ideas? What test have you completed in the past when applying for tech writing
positions.

Although I’ve taken various tests before for job interviews, such as documenting how a small company widget works, or finding all the spelling and grammar errors in a document, or actually taking an IQ test, I’m not a fan of tests. Do you ever give doctors a test when you interview them? See now, go into the next room and try to figure out what kind of disease the guy has. You’ll have 30 minutes to write a diagnostic report. Or to a lawyer — we want to see if you’re actually qualified for the position. Please write and deliver and 3 page court presentation arguing a case of insanity for the unabomber…

If I were hiring a technical writer, rather than administering tests, here are 10 things I would do to evaluate the candidate:

Ask for writing samples. Writing samples are by far the best indicator of ability. The only problem is that often writing samples are proprietary and confidential to the former company, and if the writer is seeking a job without the current employer’s knowledge, it’s hard to acquire these samples legitimately.
Ask the candidate to evaluate your company’s existing documentation. What would he or she change? How would he or she approach the same material?
Ask for evidence of enthusiasm. My favorite interview question is, “What have you done in the past 6 months to demonstrate your enthusiasm for the profession?”
Check out the candidate’s blog to see if he or she is an interesting person. If there is no blog, Google the candidate. If you can’t find anything anywhere, be skeptical about the answer in #3.
Ask the candidate to explain his or her strategy for single sourcing. This is a great way to gauge the candidate’s awareness of current trends.
Talk with the candidate about random things. Ask yourself if you would enjoy having the person as a co-worker.
Have other technical writers meet with the writer, especially if you’re not a writer yourself. Writers can sometimes quickly sense whether someone knows what they’re talking about, similar to how developers or designers can judge the same about people in their fields.
Ask the technical writer what his or her favorite manual is and why. This will get the writer talking about best practices.
If you must give a test, ask the writer to create a video tutorial describing how to do something software related. Hiring managers often give writing tests, but hey, technical writers don’t just live in the written word. You want someone who can do video too. In fact, I just received a comment today on a quick Dokuwiki video I made last year. Sarah writes, “I just finished watching your video on setting up Dokuwiki (http://www.idratherbewriting.com/video/dokuwiki.html). This is not only a very useful video, it’s the future of tech “writing.” Thanks for sharing it.”
Check to see whether the writer formatted his or her resume with styles. This is my friend Mark Hanigan‘s pet peeve. Whenever he evaluates resumes, he first looks to see whether the content is structured with styles. It’s subtle and anyone who isn’t familiar with structured authoring will completely miss it. But you don’t want to hire someone who doesn’t understand the concept of styles.

Finally, if you are determined to administer a writing test, please make it software related (unless your company doesn’t make software). And also make it difficult. For example, provide instructions on how to speed up your Firefox browser.

April 6, 2008 Update: I have officially changed my mind about writing tests. While I initially thought they were insulting, I now think they are essential. I guess I had to experience for myself an interaction with someone whose writing I felt to be subpar. It lacked thoroughness, wasn’t easy to follow, was poorly organized, sometimes unclear, and was overall not something I’d want my department name attached to.

Many candidates pose as technical writers but really lack the skills. Writing tests can help weed these candidates out. I guess I’ve come full circle on this. I now would also encourage a writing test, and require that candidates provide instructions on how to document a typical company widget. When you get that writing sample, here are some obvious signs that you shouldn’t hire them:

The writer doesn’t use numbered steps.
The procedure had 20+ steps without being broken into separate tasks.
The writing is unclear.
The writing is poorly organized.
The formatting is sloppy.
The writer doesn’t structure the content with styles.
The steps are inaccurate.
Field definitions aren’t illuminating.
You can spot misspellings and grammar errors.

My alternate tests are still valid. I’m just now endorsing the standard writing test.

As an added bonus, requiring writing tests will drastically reduce the number of candidates who apply.