Managing Writers

Update on Reference Checking

Wed, 04 Nov 2009 18:06:02 +0000

After complaining about a perceived lack of reference check calls, I received the second in a week, after a long dry spell. Probably not a trend, but it was heartening to see another company checking references.

The call brought up a few additional thoughts:

I’ve noticed that when someone who worked for me years ago needs a reference, I sometimes find it harder to remember the specific assignment than to remember how well he or she did the job. I know who I can give a good recommendation to, but once or twice, I’ve fumbled the supposedly “easy” question, “what did he/she do for you?” even when I knew without a doubt that he or she did a good job on the now-forgotten assignment.
The most recent call came from a company that does contract services in the IT area. While I’m not currently in the market for such services, the fact that they demonstrated at least a degree of due diligence in hiring is a plus that I would consider in evaluating the company for possible work.
The same company send a thank you note, which in addition to being a nice gesture, provided them with an opportunity to sell their services. It’s rare that an advertisement comes across as a plus, but I admire companies that recognize the importance of spreading a wide net, as long as they don’t overdo it.

Checking References

Wed, 28 Oct 2009 22:14:31 +0000

I just got a call asking for a reference for someone who worked in my group a few years ago. I was glad to give a reference, and happy that I could give this person a good one.

Surprisingly, this is the first call I’ve received to check a reference in over a year. During that same year, I’ve had half a dozen people ask me if I would be a reference, and in the years before, I’ve agreed to give references to many more. Some of those requests were generic, like: “if I need a reference would you give me one?” But others were clearly specific, with the company identified. Yet, this is the first time in ages that anyone has bothered to call me to check a reference.

In my book, Managing Writers, I stated that I only got called about half of the time. That’s clearly an overestimate at this point.

So why don’t more managers check references? Here’s my shot at enumerating the top reasons:

The applicant has obviously chosen references who will say good things, so why waste time listening to someone describe how wonderful the applicant is?
Once you’ve decided to hire someone, you just want to get on with things and not slow down the process.
You don’t want to take the chance of receiving information that conflicts with a decision you have already made.
The hiring process always seems to happen when you’re under pressure; you need someone right now, your “real” job is waiting, and you really don’t want to go out and find more people to interview if you unearth a problem with this person.

Regarding the first point, yes, you’re going to get someone that the applicant thinks will say good things about him or her. But, having called a lot of people to check references, I think it is still possible to learn important information, even from a “pre-screened” person. For example, you can check facts; what did the applicant work on? when did he or she work there? and so forth. In addition, you can often learn a lot from the way someone responds to questions. Even those who are restricted by their company to “name, rank, and serial number” answers may reveal their opinion in the way they respond.

The hiring manager I spoke with today didn’t ask anything out of the ordinary, and there was nothing out of the ordinary in my responses, but I think I made it clear that my evaluation of the candidate as an excellent technical writer was sincere and well-founded. I’m pretty sure that if I had thought otherwise, my meaning would have come through, even if I had used similar words.

The other three points, frankly, just add up to laziness. As strong as the urge may be to skip this step, there’s really no good reason for not calling references when you’re hiring. The call today took about five minutes, was cordial, and confirmed the likely perceptions of the caller. But, if it hadn’t, that one call could have saved him the trouble of hiring, and potentially firing, the wrong person. Since I like to call only when I’m ready to hire, it’s no more than a few phone calls about that one candidate. But if you don’t call, you are losing important information about one of the most important things you do as a manager (and one of the hardest things to undo).

Does DITA Make You Dumb?

Tue, 06 Oct 2009 15:26:19 +0000

I had a twitter exchange a while back that got me thinking about DITA, structured writing, and the impact of tools on the perception of technical communicators. The basic question was whether structured writing in general and DITA specifically are “dumbing down” technical communication, leading to a devaluation of the field.

I end up straddling the fence here. The short answer is “no, I don’t think DITA is dumbing down technical communication.” However, introduction of technologies like DITA, if not handled well, could lead to a devaluation of the field. The danger I see is that if managers misunderstand DITA and modular technology, they may conclude that DITA will allow them to hire less-experienced, less-skilled, and less-expensive writers, which could lead to a de facto dumbing down (or a train wreck, depending on your point of view).

Tweets
BkwdGreenComet: @richardhamilton (1) Writers of DITA-based documents are filling in forms. Doc arch and org is already “solved.”
BkwdGreenComet: @richardhamilton (2) Web output from DITA will predominate, thus formatting options are limited vs traditional book output.
BkwdGreenComet: @richardhamilton (3) Prose for transitions and topic “context” is expunged to encourage content reuse.
BkwdGreenComet: @richardhamilton (4) TCer no longer need be expert on a complete sw product, only a piece. -> fragmentation of knowledge
BkwdGreenComet: @richardhamilton (5) Parts of sw product doc that gets most rewrite attention (the UI) requires least techn expertise.

The sidebar contains a set of tweets from Paul Sholar, better known on twitter as @BkwdGreenComet. Paul, who was kind enough to let me quote his tweets, is a thoughtful and careful commentator, so I take his thoughts seriously. He gives five reasons he sees DITA, and by implication structured writing, dumbing-down technical communication. My tweets, which in any case are not nearly as thoughtful as his, are lost in the twitter-verse because I waited too long to retrieve them, but I’ll do my best to recreate my thoughts here.

Overall, I agree with most of Paul’s specific comments, with a caveat. I think some of them work primarily as a statement of “what managers think.” Of course, since “what managers think” often leads to “how managers act,” his points are worth taking seriously. Let’s take a look at them one by one:

(1) Writers of DITA-based documents are filling in forms. Doc arch and org is already “solved.”

If you are “just the writer,” then you may end up in a job where it seems like you are just filling in forms, but someone still has to create a documentation architecture and organization, even if you are working in the DITA world. If you avoid being involved with the doc architecture, then you may get slotted into a position where you seem to be just filling in forms, but even the form filler needs to understand the information he or she is placing in the form.

(2) Web output from DITA will predominate, thus formatting options are limited vs traditional book output.

I agree that web output will predominate, along with help systems, but I don’t think print, or print analogs like PDFs, will disappear. Also, you can make a pretty good argument that web output has at least as wide a range of formatting options as print, even though those options don’t overlap 100%.

What really limits formatting options is that modular writing separates formatting from content, and often takes away the formatting job from the writers. While that may seem like a step backwards in terms of the skills writers need, I don’t believe it is. After all, in most corporate contexts the style is set and the job of the writer is simply to comply with that style. So, in practice formatting is often simply a rote exercise in force-fitting content into a corporate style using a WYSIWYG tool. Not by any means the most challenging skill for most technical communicators, and not one that will garner a lot of respect from managers.

Incidentally, that doesn’t mean there is no place for carefully designed and formatted content. Some content, for example quick reference cards or documents where you need to communicate complex ideas through graphic means, requires a high level of skill. However, that’s not the kind of content DITA is intended for.

(3) Prose for transitions and topic “context” is expunged to encourage content reuse.

Yup, though I would argue that this makes it harder to write in DITA, not easier. Sometimes you just need a transition, and even the DITA TC recognizes that as witnessed by the existence of the DITA publisher’s specialization, which contains some “connective tissue” for transitions.

(4) TCer no longer need be expert on a complete sw product, only a piece. -> fragmentation of knowledge

Here I have to disagree. You still need to be an expert on what you are writing about. If a technology like DITA makes you more productive (a debate I’ll leave for the future), then shouldn’t you be able to cover more territory, not less? Therefore, you might need to become expert in more areas, not fewer. Of course, a badly managed project may lead to writers being expected to cobble together documentation for some part of a product with little or no understanding of the whole, but I wouldn’t let the pathological case make the rule.

(5) Parts of sw product doc that gets most rewrite attention (the UI) requires least techn expertise.

This is a very interesting point that I’ve never fully considered, and which has merit. However, I don’t think that problem can be laid at the feet of DITA or modular documentation. That’s going to happen regardless of your methodology or tools.

So, what does it all add up to? I think the key is understanding what technology can and can’t do. There are at least two broad categories of technology that managers often confuse. The first is technology that replaces a particular skill. For example, the cash register at a McDonalds has technology that relieves cashiers from doing math, so they can hire people who are not skilled in math. The second is technology that allows a skilled practitioner to be more productive. For example, the computer makes it possible to write and edit text much more easily than a typewriter, but it won’t make a bad writer better.

To the extent that DITA works as a technology, it clearly works in the second category. But, if managers think it also works in the first category, they will naturally try to hire less skilled writers, with bad results for both their companies and the field of technical communication. That’s where I think Paul is headed in his points, and it’s where I agree with him. Our challenge as technical communicators is to make sure our managers understand the distinction and help them see how DITA, while a potentially useful technology and methodology, is not the equivalent of a MacDonalds cash register for writers.

Thanks, Paul, for letting me deconstruct your tweets.

WebWorks RoundUp ‘09

Fri, 18 Sep 2009 20:22:41 +0000

I am looking forward to attending WebWorks RoundUp 09 next month (Oct. 19-21, 2009) in Austin, TX. I will be participating in a panel titled, “Content Development Best Practices” with Alan J. Porter, Berry Braster, and Paul Mueller, fast company indeed.

XML Press is partnering with WebWorks to provide complementary copies of Anne Gentle’s Conversation and Community: The Social Web for Documentation and my Managing Writers: A Real-World Guide to Managing Technical Documentation for attendees. XML Press will also be giving away a copy of Alan Porter’s forthcoming book, WIKI: Grow Your Own for Fun and Profit. Plus, we will have an XML Press booth with information about our upcoming releases, book signings, and other goodies.

Overall, it looks like a great conference both for ePublisher users and anyone interested in the latest trends in technical communication and publishing. There will be keynotes by WebWorks execs Tony McDow and Alan Porter, featured talks by Stewart Mader and Tom Johnson, and panels with several groups of industry exporters. XML Press authors Anne Gentle and Alan Porter will both be speaking, and Anne and I will be available to sign our books.

Performance Evaluation Checklist

Wed, 10 Jun 2009 23:20:40 +0000

At the STC 2009 Summit, I participated in the Management Progression. For those who aren’t familiar with a progression, it’s a bit like speed-dating, with a somewhat smaller chance of rejection. You have a large room with several big round tables. At each table is a presenter with a sign for his or her topic (My topic was Employee Performance Evaluation, a real barn-burner!). Attendees choose a table and join a conversation. After about 20 minutes, the moderator blows a virtual whistle and everyone except the presenters chooses a new table. You continue until you run out of time (our session was 90 minutes, so we got several rounds in).

That’s about it; it’s simple, but seems to work pretty well. The presenters typically do a little preparation, but mostly go with whatever the people at their table are interested in discussing. For my topic, I prepared a checklist for the performance evaluation process. I thought it turned out pretty well, so I’ve posted the checklist in PDF form. Feel free to use it as you wish for non-commercial purposes and please post any comments you have.

I found the progression to be a great deal of fun. There were a lot of good attendees, ranging in management experience from a non-manager who has to mentor one person, to long-time managers with years of experience. The nice thing about that range is that we got new ideas, great questions, and a lot more good advice than I could have provided alone. The pattern that seemed to work best was for each person to introduce him or herself and say what he or she wanted to get out of the session. Many attendees had specific issues to discuss, and we probably spent 70%-80% of the time on those issues.

There were a lot of great ideas batted around. One of my favorites, which is an oldie but goody, answers the question, “How do you handle a situation where someone who is a friend, and formerly a peer in the organization, now reports to you?” There’s no question there will be a change in the relationship, and it can be an uncomfortable one. One attendee said that she prefaces management conversations with the reminder that she is wearing her “management” hat, not her friend hat. In other words, she makes it clear that she has new responsibilities, and that to fulfill those responsibilities, she must take on a different role than before, at least in the office. If she doesn’t, she is not doing her job, and of course, a friend wouldn’t want her to fail at her job.

That won’t disarm everyone, but it does make the important point that as a manager you have a role to play, and responsibilities to meet, and that friendship and prior relationships have to bend to fit that new role (and sometimes they break). It also implies that you can put the friend hat back on when you’re outside of the business context, though in my experience once you have that management hat, former relationships, even if they remain strong, will never be the same. I’ve had the good fortune to keep as friends some who have reported to me and others that I’ve reported to, but it’s not 100%.

There was lots of other good interaction, most of it directed at specific questions related to performance management, rather than the formal, yearly performance evaluation process that my checklist is aimed at, but that didn’t matter, since the objective was to discuss the topics people cared about, not put forth a pre-determined agenda.

The checklist is derived from the Performance Evaluation chapter in Managing Writers. I posted a draft version of that chapter last year in four sections. You can find it starting here.

Headed to DocTrain/DITA and STC Summit

Thu, 16 Apr 2009 18:44:26 +0000

I will be at both the Society for Technical Communication (STC) Summit in Atlanta next month (May 2-6) and DocTrain/DITA in Indianapolis (June 2-5).

At the former, I will be talking about employee performance evaluation as part of a “Progression,” which is the conference version of speed dating. There are tables set up in a large room, with a presenter at each table. Each presenter has a topic related to the progression; in this case, the broad topic of the progression is management and my sub-topic is employee performance evaluation.

Attendees join whichever table has a topic of interest, then every 20 minutes or so, the moderator blows a whistle (metaphorically) and attendees move to another table. The progressions I’ve been to in the past were informal events where you could talk with presenter about pretty much anything related to their sub-topic (or not).

Should be fun; I plan to prepare a “checklist” for performance evaluation that attendees can take away with them, and I’ll be prepared to discuss whatever they are interested in. If you’ve read my book, Managing Writers or the excerpts published in the Managing Writers blog, you know I have strong opinions about the topic, which I’ll be glad to share with anyone who stops by my table.

DocTrain/DITA is a whole different game. I will give two presentations, DocBook in the 21st Century: Yes, Virginia, There is a DocBook, and it is Alive and Well, which talks about the latest version of DocBook, and Getting Started with DocBook, which is aimed at getting attendees up and running with the DocBook schema and stylesheets.

More information about the DocTrain/DITA conference and my talks at my personal blog.

Better Know a DITA

Sun, 12 Apr 2009 04:05:04 +0000

As a long time DocBook user and advocate, it seemed to me that it was time to learn more about DITA. To that end, I have started two activities on the XML Press website. The first is an ongoing series of articles titled, A DITA Adventure, which follows my attempt to set up and use the DITA Open Toolkit. So far, I have downloaded, installed, and run a rudimentary test. Next up will be to try and generate some different types of output.

I’ve also posted a DITA Information Needs Survey, which is looking for input on what information people are looking for to help them use DITA. XML Press will use the results of that survey to help plan a series of DITA-related publications.

As a thank you to participants, XML Press will send the results of the survey to all participants who choose to leave their email address and will select one participant at random to receive his or her choice of a free copy of my book, Managing Writers: A Real World Guide to Managing Technical Documentation, or XML Press’s first DITA publication (which this survey will help determine).

The survey will be open until May 15.

Practical DITA

Thu, 02 Apr 2009 00:25:51 +0000

I just posted a review of Julio Vazquez’s new book, Practical DITA at XML Press.

The short review is that if you are brand new to DITA, but understand at least a little bit about markup languages (basic HTML is probably enough), this is a good place to start. It is a short excursion through the DITA philosophy and basic usage. For my full review, go here.

Feeding on RSS

Sat, 28 Mar 2009 00:59:10 +0000

As part of moving the Managing Writers companion blog to its new URL (managingwriters.com), I have also moved the rss feeds, so that new information will go to anyone who was previously subscribed on either the old managingwriters.com site or the rlhamilton.wordpress.com blog. This should work transparently (knock on wood), but if you are reading the feeds and see any anomaly, please post a comment, and I’ll see what I can do to fix things.

The good news is that this should guarantee that no matter how you originally subscribed, you will get the latest information. And, if you haven’t subscribed, but want to get the latest information, go to the right hand side of the screen, scroll down a bit, and you will see links for rss directly or to add the feed to your Google or Yahoo pages.

Podcast Interview about Managing Writers

rlhamilton — Tue, 24 Mar 2009 20:26:10 +0000

Tom Johnson just posted a podcast of an interview with me at his website, http://idratherbewriting.com.

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.