How to Tolerate Ambiguity in Technical Writing and Keep Anxiety Under Control

© Ugur Akinci
Technical communicators need to have a healthy capacity to tolerate ambiguity; not permanently throughout a project, but during certain phases of it.
William Goldman, the award-winning screenplay writer and filmmaker, is famous for describing Hollywood as a place where “nobody knows anything.” And he meant it.
The situation is not that bad in technical communications. There are a lot of smart people who work in the industry and they do know a lot about the products they are creating. That’s why your car runs, refrigerator keeps your food fresh, and the elevators stop where they’re supposed to.
Yet, from an insider’s point of view, there are still some moments during a product development cycle when things are not crystal clear, by necessity.
When for example the project team is discussing the “marketing requirements,” when the management, marketing, and the engineers are trying to agree on the features that the new product should have, things are not clear due to the very nature of the process.
Similar back-and-forth discussions and a lack of absolute consensus carries over into other phases of product development.
And you, as a technical writer, will usually find yourself in the midst of that shifting landscape since you need to document the specs, release notes, as well as the user’s guide, system admin guide, and so forth.
Your job sometimes gets as impossible as fixing a jet engine in flight. That creates some stress and anxiety of course.
As a writer people ask for clarity from you. Yet you cannot always be as clear as you’d like to be since (for example) the physical dimensions or the operational tolerances of the product are still being discussed by various tasks groups in your company.
Just when those sets of questions are answered, perhaps you’ll have a whole new set of inputs from the legal department that will force you to change the language in certain sections of your documentation.
All that requires an ambiguity-tolerant personality.
My advice to you is this: when things are not razor-sharp clear, don’t panic. It’s a normal healthy part of the whole technology development cycle.
Just rest assured that you’re not alone. You are a part of a smart group of people who usually have a good reason why they’re still keeping their options open regarding some important choices and that’s why there is still ambiguity in the system.
If you do your part and first take care of those sections of your documentation that are clear and mark the others as “pending”, you’ll see that all that ambiguity eventually takes care of itself. Like the fog lifting off a valley with the first rays of the rising sun, all that ambiguity evaporates once the project reaches a certain point. Until then, trust the process and take care of the things that are already known about the product.
Technical documentation is like a marathon in which the next leg of the course is sometimes decided by the runners themselves each time they reach a major watering station.
If you keep your anxiety under control and take care of your daily business, not only you’ll survive and prosper in this wonderful industry, but you’ll also help create a better world by contributing to the development of better products and services.