Technical

What does "technical" mean?

When is a technical communicator not a technical communicator? What do we really communicate about? What does technical really mean? Computers and other forms of machinery are clearly technical; what about finance and the law? What about office procedures? What, even, about sports and games?

I am always reluctant to use the origin of a word as a direct indication of its present-day meaning. However, etymology can provide a key to unlock that meaning by allowing us to explore its evolution. So with technical.

The Greek root of technical meant “pertaining to the arts”. To the ancient Greeks, though, the arts included what we would now call science. Indeed, in many of the older universities in Europe, science students still graduate with an Arts degree. The “black arts” — sorcery and so on — included alchemy and astrology, the direct precursors of today’s chemistry and astronomy.

It’s instructive to note how that Greek root evolved in two slightly different directions. We forget, for the most part, that technology and technique are close to being the same word. Technology is usually seen as meaning “applied science”; technique is akin to expertise, but is generally reserved for things we do with the body (a hairdresser’s hands or a footballer’s feet) rather than the brain.

For our purposes, then, I would like to think of technical as embracing anything that requires skill, expertise, or knowledge. We would not hesitate to speak of “legal technicalities”, nor would we be reluctant to speak of a skilled programmer’s technique. Law and finance, on those grounds, are certainly just as technical as computers.

I don’t think it’s forcing the issue to extend this understanding to office procedures, or even to sports and games. Documenting the process by which a clerical worker gets an account approved and paid is not very different from documenting the process by which another clerical worker gets a computer to send an email. And, while we might hesitate to draw the comparison too closely, that’s not very different from documenting the process by which a game player sets up the Monopoly board. (Does anybody still play Monopoly?)

Now most of us would probably feel that the instructions for a board game were somewhat beneath our usual level of technical sophistication. Yet in many ways they epitomise what technical communication is all about. Most obviously, they are entirely task-oriented; they deal with specific aspects of the game such as (and I’m staying with Monopoly) allocating each player’s starting funds, choosing tokens, determining the order of play, buying and selling, paying rent, and so on. Less obviously, but still relevantly, they cover the important distinction between tutorial and reference material: not only “how to play”, but also “what to do if …”.

It’s fair to say that board games are less complex than most of the business-related activities we are mostly involved with. It’s also fair to say that, in some sense, they are less important. But we shouldn’t write them off as being trivial. If the written instructions for Monopoly make it easy to understand and play the game, they meet all the criteria for successful technical documentation. We would do well to learn from them.