In the interview I talk about Managing Writers and answer Tom’s questions about the book.

Most of the discussion was about managing people, including questions about hiring, evaluating writing samples, motivation, planning, and lots more. If you are interested in the book, the interview is a good way to get more information about its content and about my approach to management.

Thanks, Tom, for taking the time to read the book (and it is clear from the interview that he did read the book in detail), and to speak with me about it.

There are plenty of sources for information about how to write a résumé, but less on what doc managers are looking for. My book, Managing Writers: A Real World Guide to Managing Technical Documentation, contains a chapter that discusses hiring in detail. I have included an excerpt below that discusses how I evaluate a résumé.  I hope you find it useful.

Evaluating a résumé

Most hiring managers, and I am no exception, take a couple of passes when reviewing résumés. The first pass eliminates people who are clearly not what I am looking for. I try to answer two questions: first, are this person’s qualifications even in the ballpark for the job, and second, can he or she write at least well enough to create a competent résumé?

Answering the first of these questions is not hard, but it does require that you understand the job requirements thoroughly and read the résumé closely. The former should be easy, but I have seen cases where a manager hired someone because he or she was a whiz at task A, when skill at task B was what was really required. I suggest that you document the job requirements in writing.

Read the résumé closely. A few years ago I needed to hire a tools person. A contract house I had worked with before said they had just the person I needed. I did not have much time, so I just glanced at the résumé before the interview. About five minutes in, the candidate stopped me and said, “Why are you interviewing me for this job, I’m not a tools expert”?

The contract house had obviously skimmed her résumé, seen the names of a few tools, and assumed, either honestly or possibly shaving the facts, that I might hire her as a tools person. Fortunately for her, I was also looking for writers, and I was so impressed with her honesty and outspoken manner that I kept interviewing her and ultimately hired her as a writer.

While that situation turned out well for everyone, I have found over the years that it is not at all uncommon to get a résumé with a job objective of “Technical Writer” when it is clear the person has no writing experience. In the worst cases, it can look like the objective was just slapped onto an otherwise unrelated résumé. Sometimes it is wishful thinking and sometimes it is a misunderstanding of what skills and experience are needed to be a technical writer, but either way it raises a red flag.

Whenever I see a résumé like that, it goes into the discard pile unless there is some indication that the person can write, and just as important, wants to write. While I have hired engineers with no prior technical writing experience, it was only after I became convinced that they were good writers who had solid reasons for a career change, and just as important, that they were not looking for an “easy” job after failing as an engineer.

The second thing I look at in that first pass is the way the résumé reads; after all, it is the first writing sample you will see from this person. If a candidate cannot communicate clearly and concisely in a résumé, there is no point in going further. Some managers will reject a résumé that contains even a single typo. I do not go quite that far, but I will reject a résumé that is badly written or contains blatant mistakes that a good copy-edit should catch.

I do not worry too much about the visual look of a résumé unless I am hiring for a job that requires design skills. At the same time, an unattractive visual design is at least a warning flag. There are plenty of attractive styles available in the standard word processors, so any résumé should be legible and look professional. I also do not care too much about whether the résumé is in chronological order or some other order, as long as all the information is there.

If the résumé is not eliminated by this point, I go back and look for the following things:

• Writing experience:  It is surprisingly common to get résumés for technical writers who have no experience writing documentation. This is sometimes obvious, as for people who are moving from some other career into technical writing, but sometimes it can be covered up. Unless you are looking for an entry level writer, make sure you see real technical writing experience.

• Subject matter familiarity:  The type of experience a writer has is at least as important as the amount of experience. Generally, I am looking for experience that shows an ability to understand similar concepts with a similar level of technical complexity. I do not expect a perfect match; I will consider someone who only has experience with Windows software for a project based on Linux software. However, I would be reluctant to hire someone whose sole experience has been with software to write the hardware maintenance manual for an aircraft, unless there are other indications – maybe a pilot’s licence – that point to subject matter expertise.

• Deliverable type experience:  The types of deliverables – books, web pages, online help, and so forth – a writer has worked with can also be a useful indicator, especially if you are working with one of the newer technologies, like XML. But most experienced writers have worked with several different kinds of deliverables, so I consider this less important than subject matter familiarity.

• Tools experience:  Tools familiarity is another thing I look for, though I place less importance on it than some. In particular, unless I need someone with specific tools knowledge – for example, a FrameMaker guru – I am less concerned with the specific tools and more concerned with the type of content the tools work with. For example, if I am hiring someone for a team that is writing XML, I will give extra points to someone who has XML experience over someone who only has WYSIWYG experience, even if the person with XML experience has not used the same tools that my team uses.

  One thing to be cautious about, and to explore when you get to an interview, is the level of skill people have with particular tools. Candidates know that recruiters will mechanically search résumés for the names of the tools their clients use, and if a résumé does not contain a reference to a desired tool it may be rejected. So, candidates will list tools they barely know, or that they hope they can learn in the weekend before a job interview. My rule of thumb is that if someone has not done a real project with the tools you are using or a tool in the same category, there will be a learning curve.

• Education:  I do not worry too much about what degree a writer has, but I like to see a college degree of some kind. If not, there needs to be some strong experience in lieu of a degree. I am less concerned about where the degree was obtained or the GPA, though a degree from a diploma mill or a poor GPA will raise a red flag.

• Leadership:  I like to see examples of leadership. This does not need to be formal or work related, it might be leading a small project, managing a budget, leading a Girl Scout troop, or organizing a fund drive. Even if you are not looking for a manager, I prefer people who can take the initiative and lead when necessary.

• Other things to look for:  If the résumé has a section like “Other Qualifications,” “Community Activities,” or something similar, look at it closely. Skills and activities are included on a résumé because the candidate thinks they are important. Therefore, I always ask about them during the interview.

  I also look for overlaps or gaps in experience, unusually short periods of employment, or unusual claims – for example, a technical writer who claims to have brought in $10 million in new business. That does not mean that any of these things are automatically disqualifying, but you need to explore them in the interview and the reference check.

There is a real dilemma to rewarding employees. If you don’t reward exceptional performance, you risk losing the employee, but if you do, pretty much everyone will be unhappy. The employee is likely to think the reward is smaller than he or she considers fair, and peers are likely to think it is too large or undeserved compared to their own performance. (That’s one reason companies tend to keep salaries and bonuses confidential).

There is a similar problem when it comes to performance evaluation. Most companies (at least the large ones) like to assign every employee a rating (you know, categories like: exceeds objectives, meets objectives, meets some objectives, and the dreaded needs improvement). However, unlike salaries and bonuses, when you rate employees, by definition you give them enough information to know where they stand.

For those in the top category there’s no problem, they are almost always happy. Those in the bottom category get a strong message, though it should be a message that is no surprise (if you are doing your job as a manager).

The problem is for everyone in between; at best their rating is a no-op, at worst, it is a strong de-motivator. Quite possibly, they will come away with the idea that they should have been rated higher. It’s also likely they will have no clear idea of how to improve their rating (you can give them all sorts of suggestions, but they will know they’ve got to claw their way past at least some of the folks in the higher categories, so just doing better is not a guarantee of a higher rating).

To make things worse, most companies severely restrict the number of people you can put in that top category. Therefore, as many as 90% of your team may live in limbo between the top and bottom.

I discussed this problem in one of the most troublesome to write chapters in Managing Writers. This chapter was previewed in a four part posting (The full chapter begins here, but Part 4 is where I discuss the pathologies of rating and ranking; beware that this particular chapter was significantly re-written between the preview and the book, but the section on problems with rating and ranking is still pertinent).

However, don’t expect too much from the book or from Spolsky’s excellent article; the truth is that rewarding employees, whether through bonuses or the normal PE process, is one of those intractable problems that you really can’t fully solve. You will sometimes over-reward and sometimes under-reward (there is no “perfect” reward; read Spolsky’s article if you don’t believe that), and whichever you do, you will make someone unhappy. The best you can do is strive for fairness and avoid placing too much emphasis on external rewards; you will be much better off in the long run if your team is internally motivated.

Shameless plug: the Performance Evaluation chapter in Managing Writers goes into this topic in depth and is much improved over the previewed version.

I’m pleased with the result and hope it will be interesting and useful.

Thanks to everyone who posted comments on this blog while I was working on the book, I appreciate your taking the time to comment.

Now that the book is complete, I plan to turn this into a more traditional blog, covering a variety of topics of interest. That said, I will continue to post news about future publishing ventures.

The other news is that the end is in sight; there are still a few sections left to go, plus some serious editing, but the basics are in place, and I’m pleased with the result (if not the speed with which I’ve gotten there:).

Over the last few years, the big technical book publishers have pared back their offerings to books they believe will have a large audience. That has left a niche for a publisher that can produce books and electronic content with a smaller, but still vital, audience. XML Press is pursuing that audience with a streamlined, low-overhead approach to publishing.

While I’d be glad to sit down with Oprah or Stephen Colbert to discuss Managing Writers, I am realistic about the size of its audience, and am glad that it will be published by this imprint.

I’m still targeting the end of the year for publication, with a tentative date of November 15th. That’s ambitious, but just barely possible. I’ll post updates here as I get closer.

Here’s a link: Hiring: Part 1

Part of my time away was spent editing previous sections, which I’ll update on line as I get the chance, and part of it was spent working on new sections that I’ll begin posting over the next few weeks.

As always, comments are welcome.

I’m not sure where this one belongs, if it belongs at all. Right now it’s under “Motivation,” but it may need to go somewhere else. Mostly, it’s an excuse to tell the story about my adventures in coin collecting, but I hope it makes a useful point.

As always, your comments are welcome.

New chapter: Managing Change

This chapter is not part of the original outline, but that was an oversight. Clearly managing change is an important part of any manager’s job.

As always, comments are welcome.

I also updated the outline to add two new chapters: Using the Web and Content Re-Use, Single-Sourcing, and Modular Documentation. These chapters will be part of Managing Technology.