What makes an expert Technical Communicator?

There’s a massive and very fundamental error which many companies make when recruiting a new Technical Communicator (or for that matter, a Business Analyst). In fact, this error is so common as to be practically ubiquitous.

What does this error typically look like?

“Acme is looking for someone with extensive experience in blah blah technologies, using the ABC content management system in the XYZ industry.”

Sounds familiar, yes? Sensible? Well, Acme may well be looking for someone with extensive experience in blah blah, ABC and XYZ, but such a search will inevitably constrain the field of available applicants so narrowly that it will have a severely adverse effect on the recruitment process, and thus personnel quality. In fact, sticking blindly to such criteria is likely to result in recruiting a merely adequate person at best, rather than one who excels. It’s not that Acme should necessarily employ someone with only mechanical engineering experience for their latest software product, more that insisting on experience with a particular programming language or platform will adversely affect the available pool of candidates.

Suppose you’re trying to communicate the ins and outs of a complicated suite of software, or an oil refinery. You’re probably looking for someone with a degree in Computer or Process Engineering, perhaps combined with some kind of postgraduate Diploma in Technical Communications, then years of experience in your industry. Those factors are certainly relevant, but they don’t necessarily add up to finding a brilliant technical communicator, any more than you would find a best-selling novelist from English graduates banging away at novels for years. Best-selling authors arise from diverse and mysterious backgrounds.

It’s ironic, in the same way as a professional plumber having dodgy plumbing in their own home, that the body of professional Technical Communications performs poorly in communicating our role. Perhaps this is because for technology end users (such as many senior managers), technical manuals are merely a necessary evil, often used only as a last resort when “this damned thing isn’t doing what I want it to!” or “We only have the documentation to sell until the [vapourware] is released.” Thankfully perhaps, the great majority of Technical Communications consumers are themselves Engineers and Technologists, who greatly value clear technical communications.

So what is it that a Technical Communicator does? And what makes an expert?

In general terms, a Technical Communicator (TC) is something of a Detective investigating a mystery. The mystery is the technology. Subject Matter Experts (SMEs) are witnesses (or sometimes suspects…) The TC must explore the mystery of the technology by a combination of direct investigation, research and interrogation of available witnesses. Sometimes the TC starts with a blank sheet; sometimes engineers provide such comprehensive documentation drafts that he is relegated to the position of proofreader, editor and publisher. The service a TC provides is usually dictated by their client or manager, in terms of the type of publication required, its audience, purpose, tone and style. A technical communication may be – necessarily or not – terse or verbose; stand-alone or integrated with the technology; textual or multimedia. Whatever the situation, the TC is ultimately required to present a clear case to the court, tailoring the material to an audience which could lie anywhere between a jury of laymen and a tribunal of expert judges.

An expert TC is not necessarily an SME. Indeed, seemingly paradoxically, it is actually often better if the TC is NOT an SME. This seems counter-intuitive. Why would a non-expert perform better than an expert? This is a deceptive question, worded in the same faulty terms as the job advertisement quoted above. There is all the difference in the world between an expert Technical Communicator and a Subject Matter Expert. Although the technology itself is an impersonal and impartial thing, the way in which it is understood and exploited will inevitably differ according to the perspective of each person interacting with it.

There may actually be a conflict of interest between the SME and the end user. SMEs will, by definition, be expert in technical intricacies and may even wish to keep their knowledge restricted, in order to maintain or increase their own value. End users may broadly be divided into two camps: consumers and other experts; for both, their objective is to understand and use the technology as smoothly as possible. Whatever the situation, when it comes to deliverables, the TC must, as the investigation phase ends, take on the role, not of a Detective or Expert Witness, but a Barrister. While all three roles deal with objective facts, the Barrister must present them subjectively, in the interests of his client (the technical communications consumer). The TC-Barrister must take on the mind-set of his client, presenting information not entirely objectively, but intelligently presented for the intended audience – usually spun with a pinch or more of marketing. For even articulate SMEs, to do all this and put themselves in naïve users’ shoes is a tall order. What is obvious to the SME may well be a mystery to the technology user.

The TC becomes expert when stepping beyond mere excellence in writing, multimedia production and particular technologies. The expert TC is accustomed to dealing with many different people and technologies, often in various fields or industries. This experience of technical and business diversity can again be analogised as that of a senior Detective who has investigated many types of crime, or a top Barrister used to prosecuting or defending a wide variety of cases. The expert TC goes way beyond competence with using and describing particular technologies. The expert TC:

  • clearly understands and develops his role within the team.
  • asks searching questions and performs exhaustive peripheral research around a topic.
  • shows initiative and develops new ideas.
  • questions narrow deliverable specifications and asks “how could we communicate this more clearly and effectively?”
  • nimbly adapts to new technologies, people and industries.
  • goes out of his way to find end-users, and see what they think about the technology and its documentation.
  • takes an active role in product development as the end-user’s ally, suggesting useful usability improvements and avenues for development.
  • knows that when it comes to technical communication, less is most definitely more. Like the art of a great musician or artist, his deliverables look effortless and easy (even when the source material is incomprehensible gobbledegook).
  • is perfectly poised to take on related roles such as Business Analysis, Usability or Product Manager.

Of course no man is an island, especially within the realm of technology development. An expert TC can only shine when given demanding challenges by a confident, expert manager with an accomplished team.

The fallacy of seeking a communicator with specific technical experience is intimately connected with misunderstanding the role, or interpreting it too narrowly. Real success in finding, engaging, developing and retaining expert TCs only comes with fully understanding their role.