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.

In the life cycle of a technology, there is a moment when the discussion turns from technical nuts and bolts to useful applications. I think this conference was an early sign that for XML technology, as used for technical communication, that moment has come. You might say, “haven’t we been talking about applications for a long time?” and you would be right. However, too often the conversation has been dominated by technology and the cool stuff it can do, rather than opportunities to satisfy customer needs and contribute to an organization’s bottom line.

Day two’s talks focused on serving customer needs through information and moving technical communication from a “cost center” to a “profit center.” Bob Boiko got things started with a keynote that called on technical communicators to look at their content from a customer perspective, rather than an internal perspective. His point was most strongly made in his response to a question from the audience about how to deal with mandates from management to reduce costs. He turned the question around, pointing out that as long as technical communicators see themselves as a cost center, they put themselves in the position of having to continually shrink their budget. Instead, we should take the perspective of a profit center and look for ways to contribute to the bottom line. He conceded that this is hard to do, but that we need to move in that direction to remain viable.

Joe Gollner gave the featured presentation, which took a more historical perspective, starting from the earliest written information (on tablets). He carried that through to a view of the world with documents as the central “connector” that remains constant as the “device for communicating and retaining content as part of business transactions.” In his view, Intelligent Content is discoverable, processable, and informative, which makes it possible to create personalized documents and tailor content to customer needs.

Among the session tracks, I found the most interesting to be a session from James Michelson, who I also had the opportunity to speak with a couple of times during the day. His point, simple, but often ignored, is that everything a technical communicator does should be measured by how it contributes to a company’s bottom line.

His business is marketing, and his talk focused on how you can use even small amounts of information about customers or potential customers to create marketing that is much more likely to generate a response. At first, it seemed strange to have a marketer as a speaker at a conference for technical communicators, but in the end it made sense. Like it or not, technical information is part of your company’s marketing message, and therefore, it makes sense to tailor content for your customers, based on their interests and needs.

In his view, most companies focus way too much attention internally (85% in his view, which feels roughly accurate, though he did not back that number with hard data). He would reverse that number, paying 85% of your attention externally.

Overall, I took away several points from the conference:

• Intelligent Content is more than just well-marked up content; it is really the combination of content, information about the potential consumers of that content, and processing that gives that user the greatest possible value from that content.
• Technical communication as a discipline is too often relegated to being a cost center. To continue to be successful, the discipline needs to take charge of the value in its content and deliver that value in a way that contributes to the organization’s bottom line (that bottom line could be profit for a commercial entity, or some other value for a non-profit).
• The prevailing current technology is XML, but the technology is less important than its application.
• The application of technology needs to serve external needs; if it can’t be tied to an external need, then why should the organization spend money on it?

I found the conference to be valuable, and I hope The Rockley Group continues to sponsor it in coming years. I got a lot of interesting ideas, including the topic for my next book (more on that in future posts), from the conference, and I look forward to attending again in the future.

The conference started off with an introduction from Ann Rockley, whose company is the sponsor. Her objective is to provide a small, focused conference. To that end, her team worked with the speakers to make sure the talks were of high quality and focused on the objective. So far, most of what I have attended has done that. This entry will provide a few highlights from the first day of talks.

Salim Ismail gave the opening keynote. The question he addressed was “What makes content intelligent.” He defines intelligence as the ability to take patterns from one context and use them in another. In a sense, Intelligent Content boils down to the idea of using embedded information, along with information about the user (i.e., context), to deliver customized information. Although it wasn’t clear at that point, the rest of the day reinforced this as the central element of intelligent content.

Next up was Scott Abel, who provided examples, both good and bad, to illustrate the idea of intelligent content. His recent post on The Content Wrangler describes the “bad” in detail. Apple provided most of the “good” examples, with the central theme being that Apple uses all of the information available to the company about a customer to provide a personalized experience targeted at increasing sales. As always, Scott gave a spirited and informative talk.

This was followed by three parallel sessions. The first I attended described a system being developed for breastcancer.org, a site devoted to helping women who have been diagnosed with breast cancer and their families. Derek Olson and Ron Daniel discovered some interesting, and not immediately intuitive, things about personalization. The central problem they faced was how to gather accurate information from each user so they could select the most applicable information for that particular person. The obstacle was that users often incorrectly characterize the state of their illness, which makes it difficult to give them the right information. They built a flexible taxonomy, which helped considerably, but in the end, the most useful help to users was input from other users, who independently devised a reasonably standard way of describing the critical factors about their situation in signature lines. This ad hoc metadata helped users help themselves. Overall, a nice example of user created design.

Rober Lee, of Symantec, gave an excellent talk about optimizing search results. Unlike standard SEO, which seems to be primarily aimed at drawing the maximum number of hits, his objective is to analyze search results to make sure users get good answers for their searches. Here are a couple of key points:

• Look at search logs
• Look for top search terms
• Test those terms (and look for terms that yield no results)
• Optimize content, then re-test

Optimizing content involves getting the right content for the right search terms. Suggestions for doing this include placing search terms in titles, in the first 100 words of content, and in the filename. One counter-intuitive point is that minimalist writing might not be the most effective way to get search engine hits. Repetitive text early in the content, what he called “stupid text,” helps with this, even though it offends the best instincts of tech writer. Overall, an excellent talk.

There were a couple of other talks, but I needed to duck out early, though I did leave a copy of Managing Writers to be used as a door prize during the evening festivities.

More to follow tomorrow.

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.