It's time for the final review, when suddenly some smart guy/gal has a brilliant idea: Let's involve a friend of mine who happens to be an expert in [insert specialist field here] and ask for his opinion!
Naturally, everyone thinks this is a brilliant idea. And honestly, what could possibly go wrong...
Once Pandora's box has been opened, you will find yourself having to reevaluate topics that have been shelved weeks ago. Not to mention that you will finally get the chance to tackle essential improvements, such as changing the font face, adjusting the pagination and reducing the use of the letter “m”. (I once had a proposal shot down because the secretary knew someone who was a “Scandinavia expert and (!) professor”...)
Ï don't mean to knock other people's friends. We can safely assume that some of them do have a certain amount of knowledge, and they may even be proven experts in their field. BUT: This does not qualify them to jump into any work in progress on a minute's notice and overrule results that are based on detailed knowledge of a specific situation.
Unfortunately, there is no universal way to counter the ubiquitous external expert. The best way seems to be to build up your own network of advisors who can counter any specialists that might be used in an argument, e.g. “My llama expert trumps your Peruvian goat herder”.
I'm not quite sure why companies write mission statements, but I assume it is in order to commit their employees to some sort of common goal.
Logic dictates that the statement should be concise and easy to understand, so that the average employee can grasp what the company's goal actually is, e.g.
[Company] aims to make the world's best pancakes!
Should you ever be asked what your job is or why someone should choose your company before another, there's your answer.
Unfortunately, because of their strategic nature, mission statements are often considered top priority and as such, they are developed and written by upper management.
This leads to statements such as
[Company] continuously keeps the company product portfolio modernized and updated in order to be our customers' first choice, and R&D is the main contributor to our overall vision of becoming the Leading technology supplier in [market segment], with special focus on [buzzword 1] and [buzzword 2]“.
That's quite a mouthful.
You can almost smell the cold sweat as the committee tries to cover all the bases just in case some C-level manager should decide to have a look and check if the lower echelons have internalized what the company really stands for.
Some product names are quite clever, e.g. “iPhone”. Others less so, e.g. “Aygo” (I see what you did there, Toyota!).
Not taking personal preferences into account, it's probably a very good idea to leave product naming to professionals, such as augurs, shamans, voodoo priests, or monkeys with typewriters.
Under no circumstances must the naming process be left to the R&D department! Before you know it, you will have to deal with “Backup Interpreter Control Module Connector 0.0.3.12 (alpha)” and “Loose anchor bolt retriever and transmitter – for US market only™”.
If the milk is already spilt and you are being presented with a bunch of insane product names, don't waste your time crying over it. Simply start using acronyms: The “Loose anchor bolt retriever and transmitter” thus becomes a “LAB RAT”, which is easier to handle anyway.
That'll teach them!
STE is short for “Simplified Technical English”. Or alternatively “Sucks The joy out of Everything”.
I have been a strong advocate of using STE for technical documentation. The idea behind it makes sense, and since we usually need to translate our manuals into 30+ languages, providing an easy to understand source text seemed like a good idea.
What we did not take into consideration was that writing technical documentation is not terribly exciting at the best of times. Having to double-check every single word and making sure that it is in fact allowed by the latest issue of the STE specifications did not improve overall job-satisfaction.
So after a year or two of producing ISO 9001 certified manuals we are now back to writing pidgin with the odd limerick being thrown in.
Most companies run a well staffed documentation department. Or, alternatively, employ the services of the owner's daughter because “she always wanted to do something with writing” and “has written a term paper using her MacBook”.
At the very least, they hire an intern during the summer holiday in order to bring the documentation up to date. Starting with the electric can opener that the owner's great-great-uncle had developed in 1927...
As you can see, documentation is by no means an afterthought driven by legislation and dubious directives. It is instead an integral part of product development, customer care, and marketing. As a result, technical writers usually find themselves near the top of the company hierarchy, right between building maintenance and the lady who sells cookies in the cafeteria.
Many people believe that technical documentation exists first and foremost in order to help customers with their products. Obviously, this is an utter misconception.
Documentation is, in fact, an ancillary discipline that covers the engineer's back in order to allow him to concentrate on developing fancy products without having to worry about applicability and usefulness in real-world scenarios.
This means that the technical writer's job is always a creative one. We fabricate usefulness where there is none, we invent non-existing procedures, and we describe solutions to problems no one has ever thought of. It is we who turn gimmicky gadgets into must-have items.
Yes, technical writers are the real bards of our age. Forget poetry slams! Readme files are the new sagas; troubleshooting guides the epics.
In two thousand years, historians will likely discuss if “User manual” was an actual person or simply a collective term for multiple semi-mytholocial writers.