Asking questions right (as in: correctly, appropriately) is more difficult and just as important as asking the right questions.
This is not about asking the right questions – with a little trainning and practice, we tech writers usually know how to do it. I find it much harder to ask the right questions right. I take my cue from Bertrand Russell who (allegedly) said:
The greatest challenge to any thinker is stating the problem in a way that will allow a solution.
(Photograph from Wikipedia.)
I think this is a pertinent issue for technical communicators in several ways:
- It’s our job, essentially. Any customer can state countless questions and problems he or she wants to solve with our product. And any developer or engineer can tell us how the product works. It’s our job to connect the two: To restate the customers’ problems – and to answer them – in a way customers find helpful.
- It helps us get useful answers from developers and engineers. Some of the best developers I’ve worked with always kept me on my toes: They would carefully consider my question and then answer it exactly. On the other hand, they would get easily impatient if I came up with a loose question such as “what is this new feature here?”
- It helps us get constructive feedback from reviewers and SMEs. Asking a reviewer whether “this is good documentation” may not get you very good review comments. For a much better way to state the problem, see Craig Haiss’ post about “Turning document reviews around quickly“. For example, he advises to “clearly indicate any questions that you have for the reviewers”. To allow for an easy and efficient solution, he also recommends “that reviewers can agree to review deadlines beforehand” and to “use a signoff slip”.
- It helps us get support from management. This is probably the most difficult application of the quote. It requires not so much careful phrasing, but also evaluation and judgment of the problem at hand. This doesn’t mean we do the manager’s job. After all, the quote is not about finding a solution, but about allowing a solution. For example, I once had a scheduling conflict and asked my manager whether we could postpone delivery of one of the manuals. Instead, he negotiated to change one deliverable from a manual to a quick start guide, with a manual to be supplied later.
What strategies do you employ to communicate problems to colleagues and managers? Feel free to leave a comment!