informativeMedia - what does it take to be a technical author?

A broad field such as technical communication can accommodate practitioners with a diverse range of skills and personal characteristics. So there is clearly no such thing as the ideal technical author. However, my experience in software development has taught me that certain attributes can help a technical author survive and thrive. If you are considering a career as a technical author, see how you match up to the following criteria.

Possess the vision of an eagle

If you are reasonably intelligent and professional in your work, you will probably find a multitude of ways to benefit your employers and colleagues. Unfortunately, when a manager makes a passing judgment of the quality of your work, it will probably be based on his or her ability to find one or more microscopic errors in your material. If a graphic is misaligned by one pixel or a single comma has gone astray, someone important will notice. You can always argue that faults at this level have little influence on the usefulness of the information you publish. However, the damage will already be done. A good reputation will often boil down to—though I hate to say it—your ability to spot and correct the most trivial errors before anyone else notices them.

Know about football

To operate effectively on a project, a technical author needs to cultivate good working relationships with all kinds of people. There are several ways that you can go about this. In my experience, the best ploy is to talk football (real football, not the over-padded American variety). If ever you need information, even from the most reticent programmer, you just need to drop a casual comment about a team or a player. He will feel obliged to abandon his keyboard to respond. Then you just have to steer your conversation towards the subject that really interests you. At first glance, my suggestion might seem like further evidence that software development remains largely a male domain. However I can recall working on a project with two female programmers who were both rabid Liverpool supporters. If ever I needed to bother them for information, I simply had to precede my questions with a few positive comments about Michael Owen's last game (I wrote this article in the days before he moved to Real Madrid). After that, I could have all the help I wanted.

On an international project, football plays an even more important role. Sometimes it can seem to be the only shared interest that spans the various cultural divides. However, even football has its limits. In my experience, it is does not interest Filipino or Australian programmers. And Americans are, of course, a whole new ball game.

Be humble

Many technical organisations have one or more stars—people with such scarce, specialised knowledge that they are treated as sacred or endangered species. These people benefit from a status that has nothing to do with their official places in the organisational hierarchy. For example, if the star programmer wants to work at the dead of night, so missing all project meetings, managers will typically show no signs of disapproval.

Technical authors are never the stars in any organisation. They always have to struggle for the slightest recognition, and their work is generally misunderstood and undervalued. So if you want admiration and loud praise, consider an alternative career.

Don't be a perfectionist

We all want to do good work and to be proud of what we produce. However, IT development rarely provides an environment where we can achieve the standards we would like to set ourselves. Instead, I suggest that a technical author needs to be pragmatic enough to aim to for a standard that is just "good enough". Negotiate clear and realistic targets for yourself at the start of a project and then try to meet them. Don't set out to exceed them because you won't. Every project will throw up some unpleasant and unforeseen surprises that will push your initial targets further into the distance.

If you want your career in technical communication to be a long one, you must accept a simple truth; nothing infuriates managers more than scheduled work that never seems to end. Your boss will be furious if you deliver superb, award-winning work one week after the project deadline but will be delighted and grateful if you hand over adequate work on the allotted day.

Enjoy annoying people

When you approach colleagues, one question will come to mind, "So what does she want now?" From the perspective of a technical colleague or a subject-matter expert (SME), the technical author serves as an unwanted distraction from the real work. She wants answers to questions. She wants to organise a meeting. She wants a document reviewed for accuracy. The frustration for the technician or SME is that the relationship only seems to operate in one direction. And often this is close to the truth.

If, as a technical author, you want to avoid becoming some kind of project leper, you will have to play on friendships. Sometimes you will have to be sufficiently cynical to cultivate "friendships" solely to get the necessary level of collaboration. Although your natural tendency will be to show your colleagues the respect they deserve, you will occasionally have to be bloody-minded and selfish. If a certain programmer has started working during the night ever since you needed to discuss his work with him, you had better be lying in wait at the office when he arrives at 02:00. However, to soften the confrontation, have some pizza ready.

Have an insensitive stomach

The main purpose of a development project is not actually to develop software. Instead, it is to provide feasting opportunities. On the various projects I've worked on, I've participated in: