How to Do a Technical Review

Here's a training course I did for a client a few years back, which I have since adapted for general use.

If you're a writer who works with Subject Matter Experts who review your documents, I think they'll appreciate this. Best of all, the course is free to use, as many times as you want.

http://www.lensoo.com/#!/market/view/cid/189/How-to-Do-a-Technical-Review

Can Anyone Be a Technical Writer?

Not too many years ago, I would have said, “Sure, if they’re bright, hard working, and are fluent in written English. For anyone like that, technical writing is a great career!” Today, I would say, “It depends a great deal on what you mean by a ‘technical writer.’”

So what changed? The market’s definition of a “commodity” technical writer. When I use the word “commodity” in this sense, I’m referring to the garden-variety technical writer. In technical writing, just like in every other profession, there is a picture of what a typical person should be able to do, and for how much compensation. Of course, there’s another implication to being perceived as a commodity. If you have no added value beyond the typical member of your profession, there is only one way you can compete, and that’s on price. You become no different from a pork belly or a bar of gold.

Being a commodity technical writer today is vastly different from what it used to be in the dot-com boom years. Back then (as I implied at the beginning), if you were bright, hard working, and were fluent in written English, the only other thing you needed to become a commodity writer was proficiency with a couple of packaged desktop publishing software tools. You could then find a well-paying job without too much difficulty. Now that such writers can work virtually, most of these commodity jobs have moved outside the United States, where labor is cheaper: this was just a normal market response to commodity trading.

But even in today’s market, technical writers exist and even thrive. Just not the ones who allow themselves to be commoditized.

The first thing a successful tech writer needs today is true technical proficiency. Look at the description of the commodity writer in earlier paragraphs, and you’ll see that it makes no mention of technical training. A great many people trying to work as technical writers are liberal arts majors with no technical background at all. Such writers can still perform well if they are adept at learning technical things quickly, but even in these cases it’s more difficult to sell themselves.

Another important thing that tech writers have to do to avoid the commodity trap is to stay away from the consumer market: no manufacturer will invest in good writers to create manuals for DVD players, TVs, microwaves, or anything similar. In that market, customers simply aren’t willing to pay more for better document quality.

Finally, remember that technical proficiency, along with skill at writing clearly AND good organizational ability, is a rare combination. Very few technical writers have all three, and that small group will never become a commodity.

The Perils of Hourly Work

My consulting business charges clients by the deliverable instead of by the hour, and this is hardly a novel concept. Even so, and even in business-savvy Silicon Valley, I frequently encounter prospective clients and colleagues who find the deliverables concept alien, or even scary. “Isn’t that dangerous?” is a common reply. Sure, if you underestimate the scope and cost of the project. Because most technical writers don’t have these kinds of project management skills, their best option (other than a direct hire) is to work on an hourly basis for a technical service agency.

Unfortunately, hourly writers are not the best solution for most clients in most situations. The one exception is the client who is about to undertake a project that’s very similar to a previous one: for example, the fifth generation of a product that has been on the market for years, or even decades. In this case, the client company knows exactly how the product should be documented and exactly what its own customers want to see in the documentation. It’s just a matter of bringing in people to do the grunt work, without much need for organization or creativity. However, when a project is not so clearly defined, the company quickly gets into trouble if they have to rely only on hourly writers.

There is an old joke in the technical writing profession that there are two kinds of technical writers: those who are not technical, and those who are not writers. (There are even some who are neither, and I’ve encountered all three types in my career.) Consider the case of a large telecommunications company – whose name I will not divulge – that contracted with an agency for six hourly writers to create a suite of manuals. They paid the agency $37 per hour per writer (which would be the equivalent of about $65 today), so the agency almost certainly did not pay the writers more than $30 per hour, and probably paid closer to $25. At the end of the project, this company ended up paying $250,000. The problem was that about $100,000 worth of these hours resulted either in nothing at all, or in manuals that were so poor in quality that they had to be scrapped.

How did this happen? Sadly, these disasters aren’t so rare. Part of the blame goes to the technical service agencies. They don’t make their money by fielding the best candidates for a client: there’s too much competition for them to take the time to find the best. So they simply field a large number of candidates quickly and let the client sort them out. Most agencies also rewrite their resumes to some extent, in order to emphasize what the client is looking for. In the case of this telecom company, one of the six writers on the project turned out not to be a writer at all. His only experience was a writing project in college, which the agency had made appear to be a full-scale job. Three more of the writers were English or other liberal arts graduates, who had no technical knowledge whatsoever. One of them had taken a technical writing course, but all three had major problems understanding the products.

Incidentally, I’m not implying that all technical service agencies are unethical. Proportionally, there is probably no more dishonest behavior in that business than there is in any other.

Unfortunately, charging by the hour, along with the perception of technical writers as commodities, has become so commonplace that many companies have forgotten that paying by the deliverable is usually a better option, when it’s available.

The major advantage of this approach is that it eliminates a great deal of the uncertainty, and therefore the risk, in the project. As a client, you will know exactly what you will receive, exactly when you receive it, and exactly how much it will cost. The hourly contract guarantees none of this. In addition, an hour by itself has no value that directly translates into the project. Nobody sets the price of, much less buys, a car based on how many hours it took to assemble. On the other hand, valuing the deliverables is an easy way to keep your company’s financial analysis robust.

The bottom line is that working with a deliverable-based contract is the safest way to get the best quality for your budget. There will always be those who try to get away with paying workers as little as possible and settle for substandard results from them, but – as Circuit City has shown us – the market doesn’t reward that behavior.