Hiring–Part 1

For most managers, hiring causes nearly as much dread as firing. It isn’t the process itself, after all, most managers like to meet new people and talk with them. The problem is that among the decisions managers need to make, hiring is the one that can lead to the nastiest, longest lasting, and most painful mistakes. Of course, a good hiring decision can make a huge positive impact on your organization, but it’s the bad decisions that haunt most managers.

Hiring technical writers can be especially challenging. Technical writers frequently come from unusual academic backgrounds that tell you next to nothing about their level of skill. Many also have had careers that bounced all over the map; I’ve hired former carpenters, musicians, mathmeticians, and sociologists, all of them now successful technical writers. In fact, over ten years of hiring technical writers, I’ve hired only a handful who had a degree in technical communication.

This chapter looks at the qualities that make a great technical writer and how to evaluate those qualities when hiring. It also looks at the broader questions of staffing including: how to evaluate your staffing needs and how to balance your staff among employees, contractors, and service providers.

What makes a Great Technical Writer?

The qualities that make a great technical writer mostly boil down to the ability to understand and the ability to communicate. A writer first needs to understand whatever he or she is writing about. That doesn’t mean that technical writers need to be able to write computer software or design a widget, but it does mean that they need to understand how that software or widget is supposed to work for the user. No amount of skill with FrameMaker or Microsoft Word can compensate for an inability to understand the subject being described. I’ve never had to fire a writer for lack of tools skills, but I have had to for an inability to understand what was being written about.

A great technical writer will understand a product or service from the user’s point of view. Often, product developers don’t fully understand how people will use their products. They are simply too close to the product and understand the internal workings too well to ever have the same perspective as the people who actually buy and use the product. Good technical writers have the detachment needed to see a product or service from the user’s perspective and understand what that user needs to know to take full advantage of it.

In addition to understanding the product or service they’re writing about, technical writers need to be able to communicate. This breaks down into two broad categories, communicating with the engineering team or product developers, usually verbally, and communicating with the end user, usually through writing.

We normally think first about writing ability, but the ability to communicate verbally with engineers is equally important. Since engineers are not usually hired for their ability to work with others and are rarely rewarded or punished for how well they cooperate with the documentation team, this can be a real challenge. But if a technical writer cannot extract the needed information from the engineering team, he or she will fail, no matter how well he or she can write.

Technical writers should be able to discuss a product or service with the developer and extract the information that a user will need to know. They should be able to do this without taking too much time, which to most developers is nearly any amount of time, and without going over the same information more than once. They should also be able to ask the right questions to get to the core of what they need with the least amount of effort.

Writing ability is of course central. The best technical writing empowers users and makes them feel smart. It also gives users a good impression about your product or service and your company. This is not easy to do, and it’s become more difficult as writing teams adopt modular and single-source methodologies that require writers to structure information so that it can be combined in multiple ways and delivered in multiple media.

The best technical writers have the same knack that good journalists have; they get to the point and deliver what the reader needs to know concisely and directly. A good technical writer is not necessarily a skilled prose stylist; in fact, the wrong kind of style can be distracting. Instead, his or her writing is characterised by its directness, clarity, and conciseness. In addition, larger structures—books or large websites—will be clear and easy to navigate.

Overall, the best technical writers I’ve worked with are direct, but polite, people who are quick to understand a product or service, can work well with busy, distracted engineers, and can clearly and concisely communicate useful information in writing. The best of them always have good work habits, are assertive, and have a sense of humor. The latter is maybe not essential for their work, but a good sense of humor makes everything go a little more smoothly.


  1. There’s a background issue not covered here: seeking permission from senior management to add to your team.

    That’s the issue I’m confronting now. I’m trying to work out the best approach to ensure I make the most convincing and relevant case.

    Any tips?

    • Melvyn,

      You’re right that the background issue is not handled in this article. I do discuss it somewhat in a section on building a business case, which is what you essentially need to do. Unfortunately, that section was not one that I posted on my blog, though I may post an entry related to business cases at some point.

      In my experience, senior level managers are most likely to be moved by arguments related to the bottom line. So, the best way to get permission to add to your team is to show how that would let you do something that would bring in revenue.

      Of course, the more likely case is that you need to justify the additional staff to handle work that has increased. In that case, I would do my best to quantify the increase in work, and make the case that the volume of work has passed the point where you can handle it with the current staff. You will almost always be expected to show them that you have considered, and maybe already implemented, other options for handling the extra work (for example, adjusting schedules or reducing coverage), but that the best option going forward is to add staff.

      Hope that helps.

  2. […] Here’s a link: Hiring: Part 1 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: