Back To Basics: A Tech Writer's Core Skill Set

Here is a list of what I would consider represents the real core skills of a technical writer:

• Be an excellent communicator. One must have excellent interpersonal communication skills to work with subject matter experts. This means treading lightly on their time, and doing your homework.
• Be an excellent investigator. One must be able to dig up information, rather than rely on being fed information. Often this means putting yourself in the position of asking "dumb" questions of smart people, but the better tech writers know what's required in order to ask "smart" questions. (hint: it has to do with homework!)
• Be a quick learner. This is usually indicated by being well-connected and up-to-date in their broad field of study. For example, to be useful in the computer industry, a technical writer must not only understand computer technology, but be abreast of current trends
• Be well organized. One must know how to arrange and convert a body of knowledge into a useful context and flow. In another sense, one manage the workflow of producing content.
• Be customer-oriented. This is not just a catch phrase. Most people inside an organization are organization-oriented. The technical writer has the end-user in mind. This is partly why a good technical writer has the makings of a human factors engineer (HFE) or consultant. A good user interface is more than a pretty face or a big preferences panel.

A technical writer makes technological concepts accessible to readers.

The value generated by technical writers is most often the translation and access of information into a tool to get real work accomplished, such as understanding and using a complex software program. It's a method of conveying a product's value to your intended audience. Thus, the measure of a technical writer's work is not volumes of information, how well he or she has enabled an end-user (or the intended audience).

Why Bring In A Technical Writer?

In other words, what value does a technical writer bring to the game? You can easily find a general answer in a lot of other websites and blogs. Even the term "technical communicator" has been bantered around. But basically it defines the same broad set of skills.

A technical writer is a specialist in translating a complicated or technical concept into a body of knowledge that is easy to understand.

Basically a tech writer produces the kind of documentation that reflects the "fit and finish" of your product or service. Sure, a business could have a non-specialist do this work - like someone in marketing or engineering. But that's sort of like getting a inmate to run the asylum. Yes, it can be done, but the outcome may not be what you'd expect.

What kind of documentation do I specialize in? Well, take a look at my work history. Almost all been in high-tech, and Information Technology (IT). I produce everything from end-user quick reference cards to infrastructure architectural specifications.

A business may bring in a technical writer when their existing staff needs to offload the documentation work to someone who requires as little training as possible. Therefore, in addition to having some prior knowledge of the business culture and technology...

a technical writer must possess two critical skills:

1. Must be a quick learner.
2. Must have excellent communication skills.

Everything else can be acquired on the job.
But, of course, there is more to the picture than just this.

Customer Experience. The customer experience is a time line arc that spans first contact - e.g., a brochure or website - to post-sales support, and then re-sale/upgrade.
Since a technical writer produces content about your product, it influences the customer experience just as much as the sales experience and daily use. Therefore the technical writer becomes one of the most customer-oriented persons you can include in your technical staff.

Information Design. It sounds like a buzz term. This defines, at the technical level, how a body of information is presented to the intended audience. And this can be thought of in all sorts of dimensions, such as size and shape, presentation over time, gradation of information as the audience changes or matures, how the information architecture allows for re-use for different purposes or audiences, etc. If the technical writer specializes in content management databases, for example, the term "Information Architect" may justly apply.

Human Factors Engineering. In software development, the ease-of-use is often cited among the most important factors in the perception of your product's value. Since a technical writer is deeply involved in the customer experience of your product, and brings experience of product ergonomics, this could be the ideal person to help define the user interface, or perhaps even the overall work flow.

Graphics and Layout. Tech writers understand the flow of information, and the gestalt of information absorption by the audience. Human physiology, psychology, electronic displays, and regional culture have a lot to do with the decisions made for text layout, graphics, sequence, skimming and scanning aids, and general presentation. Thus, technical writers have taken on some of the tasks of graphic designers, and layout specialists.

Software Integration. When producing online help, technical writers will consult with application developers to seamlessly integrate the help system into the graphical user interface. This provides the mechanism for features like context-sensitive help.

Information Accessibility. Say you have a library of all kinds of technical documents, of varying age and usefulness, but they just aren't being used by your staff because it's so difficult for them to find what they need, or to trust what they find. A technical writer can help by establishing new ways of linking or organizing the information, or by scrubbing, updating or validating the content (refresh), or by creating new documents based on what is considered mission-critical (reflow). Sometimes the solution involves re-presenting the data in a whole new way, such as in a collaborative writing effort such as a wiki. Another solution is to set up a change management or revision control system, where document updates are controlled, structured and auditable. Finally another refresh would be to create an index or bibliography designed for skimming and scanning. Tech writers know a lot of these tricks.

Technical Reviews. A tech writer will also verify that the content is complete and correct. This usually happens in various forms of reviews and walkthroughs. A tech writer can establish phases, or gates, through which documents are moved and finalized. This is a quality assurance process though which each documents passes, where the end result is a library of information that is correct and complete.

Project planning and management. A more senior level technical writer will also determine what form the documentation will take, and then manage the schedules and deliverables. This helps to offload the detail work and follow-up for the overall project manager.

In summary, a technical writer is a professional who assists the client in creating or maintaining a positive customer experience.

Whatever it takes. Some tech writers are especially good at software coding, or web publishing, or content management databases. The particular skill set you're looking for is out there. You just have to know what to ask for.

The Contracting Mentality

Ten years ago, if you asked me if I was going to get into contracting, I'd give you an emphatic yes! But what happened 7 years ago? I accepted a permanent position at Intel. It was good timing, because I was looking to beef up my retirement and get some high-tech training there. Then the dot-com bust happened. Good thing I was at Intel, otherwise I might on unemployment like so many of my high-tech friends at the time.

But times got better, I got itchy for newer better contracting opportunities.

I've been an agency contractor for many years, and it really fits my personality. Here's how:

1. The job relationship is only as long as the contract. I don't make a lot of friends at work, so when I get tired of the project, it's pretty much over and I get to go look for more friends. :-)
2. I don't like office politics. When you're an employee it's nearly impossible to avoid. Some of it is manitory, like the crap dished out by Human Resources from time to time.
3. There's more money in it. Not a lot more, just enough to make it worthwhile. That includes costs normally incurred by the employer, like insurance, training and paid time off.
4. I don't have a lifestyle that requires a steady, reliable income source. My living expenses are low and I don't have dependents. Anyway I don't believe in a "steady, reliable income source" as any employer can decide that your job no longer exists. If you haven't already planned for your next income, that event will be a life-changing one.
5. The time off in between jobs is more enjoyable. It's not like being an employee with vacation days off, as vacation time accrual is a long-term affair. It's almost like a burden on yourself and your staff; it requires an a good reason (or destination), and planning.
6. After a while, you amass a great body of experience from the variety of places you've worked. Respect is garnered by a wider audience (including peers and former clients).

Contracting requires a really different mindset, compared to career employees, and I think it's a more healthy way of looking at my career. Here's why.

1. I'm always thinking of, and prepared for the end of my current job. Doesn't matter how long my client says I'm on this project. Things could change, and contractors would naturally be the first to go. That's not a bad thing, because when you're on the inside and you see people leaving out the back door, it's miserable, because you know it could be you next.
2. I've learned how to look for work. Being a contractor, it's part of the game. It's like any business - you always look for the next customer. My first resource is my personal network of high-tech friends, associates, contracting agencies, the STC, and so-on. My next resource is what I've learned about where the real jobs are being posted. Amazingly, in the recent past it's been Craigslist.org and the Indeed.com jobs board. There are plenty more, such as Monster.com and Dice.com. These days just do a Google search for "technical writing position" and they all pop-up.
3. I've learned not to be timid. It takes being pro-active on-the-job, and looking-for-job.

I consider contracting as a form of freedom. Yes, it has its responsibilities and burdens, but in the long run, I feel better about what I accomplish and what I am.

Wiki: The "Next Big Thing" for Technical Writers

After a brief period of thinking about it, I think the Next Big Thing for technical writers is collaborative writing, in the form popularized by Wikipedia.

This has been on my plate for a couple years, and I've seen it as the most useful technology for us, as graduating from "Word Janitors" to Content Managers. A tech writer can be thought of as an orchestrator, pulling together widely disparate information sorces and getting them to look like a homogeneous body of knowledge - just like what Wikipedia protends to do - but with very little actual filtering or information management.

As a tech writer, I believe its my job to find the best solution for the information publishing problem that most businesses and organizations face, and to make that information as understandable and accessible as can practically be done - without being too accessible. I've personally been through the shift businesses have made, from mid-scale printed books to simple online conversions to help files, and now to collaborative writing. So now with wikis, a tech writer's role is managing the quality and consistency of the presentation, while the content experts as a whole provide quality and completeness of information.

Wiki and the Writer

But you may think, any programmer or power user can set up a wiki, so why would a tech writer need to be involved? That's representative the typical short-range thinking that would result in everything but substance. It's template thinking taken to the level of information service. What a technical writer would provide is an output-oriented structure. This is the same thing that happens when a tehcnical document is created: define the organization of the wiki in terms of the information being represented.

But you may argue, a wiki is self-organizing! it doesn't need a rigid, formal structure! That may be true, but in the case of Wikipedia, and even the Web, this occurs only after many iterations of self-organization have been tried and discarded. It's time-consuming and wasteful. The techncial writer helps to map out what the wiki will cover, and diverting content to the appropriate channels. (This is the same as defining the scope and the audience.) This activity shows to the content experts what the indended form of the wiki presentation. It also clarifies the status of the project: how much is done, waht is the quality level of what's been done, and what still needs to be done. That's typical project management activity for a tech writer.

Then you have stylistic issues, like the presentation template. That's the part that defines the page layout, top-level links, drill-down mappings (if applicable), fonts, colors, sizes and so-on. It's similar to document templates and cascading stylesheets. That's no-brainer stuff for a tech writer, and is easy to change.

But you don't have to agree with me about wikis being the Next Big Thing. As long as you believe that something coming up Next is going to be Big.

Top Tips: Got too much work?

Most of us take whatever work we are asked to do, and for many reasons:

• My manager wants to load me up so as to maximize my time utilization.
• We're short-staffed, and everyone is working harder.
• Project management issues. Deliverable dates got moved in, multiple projects got consolidated.
• Project scope was re-defined, ill-defined or is suffering from scope-creep.
• Insecurity. If I have a lot on my plate, it justifies my continued paycheck.
• My manager doesn't know how much is too much.
• My manager can't say "No" to his superiors.

How do you know when you have too much work?

• I am prone to more mistakes. This is especially bad when someone else points them out.
• I get snappy or short-tempered.
• I get less efficient. This is due to context-switching, either between concurrent projects or tasks within a single project. Time is needed to reacquaint myself with a task that didn't get completed or the overall status of the project.
• I work late. As I abhor working late, it is very annoying to me.
• I come home with work-related stress, or can't get work off my mind.

What can you do about it?

• Get super-organized. When I prep for a meeting, I can usually commit to memory all the important points of a single project, or one or two points from multiple projects. But it's much more reliable to take notes, create and maintain a project status on each project.
• When things really get busy, I need to also keep a daily journal - full of bullet points. I can do this in a written binder, or utilize the journaling feature in Microsoft Outlook or Lotus Notes.
• Re-prioritize. Ask myself or my manager, "how much documentation is adequate?" Then re-define my strategy or my project's definition.
• Push back. Let my manager know that quality will suffer if I get overloaded. After all, any programmer can whip out a readme file in 5 minutes. Know that I am here to represent the customer, and to put quality into my documentation.
• Let the schedule slip, and see what happens. This is literally a cry for attention when the other methods don't work. Letting the schedule slip is putting my foot down and standing up for what I believe. In my current assignment, I have numerous documents, scheduled sequentially and concurrently, all of which "need to finish by ..." a somewhat arbitrary business process deliverable date. It is only because I can see that the worst could happen only if I don't do my job properly.

How do you go about finding help?

• Try load-balancing. This works great if there are other technical writers on the team. but if that's not the case, I can always ask people on the project team, such as engineering, tech support, marketing, even QA. Their product still needs to go through a tech writer to get cleaned up, but at least it takes a load off for a while.
• Elevate the visibility of the problem. Start with my manager. If that doesn't help, try the project team. Do this early so it doesn't look like I waited till the last minute. Make sure I show that I've tried every other conceivable option before going to them. I also want to provide some possible solutions, so I don't look like I'm merely delivering them a problem.
• Do a better job at doing my job better. Learn from my past mistakes. Know my weaknesses for inefficient use of time, surfing the web or writing my blog.

What's In This Blog Series?

I've been a technical writer for over 20 years. Every once in a while I meet up with other tech writers at an STC conference, and it seems that every time I hear others talk, I not only have a bonified point of view to share, but something that is far and away more poignant and useful than what I'm hearing.

I've maintained a few blogs over the years, but I've never really had a need to vent some wisdom. That is what this blog is about. Pondering some questions that other technical writers may have - perhaps answering questions submitted by email, and also providing some useful information for clients, peers and managers of technical writers.

The next few entries were taken from a brainstorming session at the Willamette Valley Chapter (Portland, OR) of the Society of Technical Writers (STC), who met earlier this month.