I have read (and realized) that amongst the problems that technical writers face, majority relate to the dead end of pending technical reviews from the SMEs (Subject Matter Experts). In this post, I talk about the workarounds that technical writers deploy to gather information when they hit this dead end. I haven’t list everything – obviously – but I have provided my learning/conclusion. After all, that is what matters to you.
One of the most promising things in life is the pursuit of knowledge. The knowledge of expression, the knowledge of truth, and the knowledge of choice, are all important (but not the only) aspects of this pursuit. And the more of such knowledge you possess, the more of it you seek. Don’t think that I have wrongly (or deliberately) lead your thoughts towards Nirvana, because I am talking about only technical writing. And, if you are reading this article for insights about writing technically, then you are right.
Knowledge is both, the journey and the destination
For technical writers, the knowledge of product is the journey and the destination. We aim to become the SME of our field. We pursue this journey with utter faith in our products, and we praise the products by writing user/developer/administrator guide and release notes. And we feel that the more we know the better it is. And, we are true – to an extent.
The path to the knowledge of a product leads through knowledge itself. The more information we have about our products, the more comfortable we are at handling our documentation. But, does having more information have any positive impact on our documentation? Yes and No! Remember the day you began working on your current project (Or, the day your boss surprised you by assigning you on a totally new project). Even with the limited knowledge you had, or gathered, about its functionality, you could record enough about it – a New Features document, a piece in a functional document, a write-up for its dashboard, and a release note, if needed. Wasn’t that enough? And, even though you now know a lot about your product, does that change anything in your documentation, besides the new features that are introduced within this time? Maybe not!
The pursuit of knowledge is an endless journey, and you don’t need to document every milestone you reached; you only need to document what is required.
What is important is what’s important.
Technical Writing 101, by Sarah S O’Keefe and Alan S Pringle, is amongst the must have books in your collection on technical writing, and I got my hands to it recently. I found the work good but very basic (Only to have asked myself later, if there would be anything in technical writing except documenting the basics!). The authors, Sarah and Alan, have listed some of the very basic, yet comic, ways of approaching SMEs of our products. And, I liked what I read, because I could relate to it.
Now, I have figured (and agree) that approaches that are routed through personal interests trigger more than formal approaches. But, in the dynamic environment where writers like us are loaded with work and deadlines, doesn’t it become an overkill for us to read and find about the interests of our SMEs only to approach them for the “just another” product feature? It makes sense to have a friend-face and approach only if we continue to focus on our need. After all, we are in discussion with the SME only to provide correct information to our readers.
Do not provide what you know, provide what they (readers) need to know.
Question every think!
Through the experience that I have gleaned over the years, I have understood that it is no good to talk to SMEs with anything that interests/disinterests them, including work! Neither does it make them more willing to answer you, nor does it contribute to the already less time-frames you have for documentation. Even when doing so, your purpose – to prepare and present accurate, needed information in the least amount of time – still remains unsolved.
As a conclusion, which I could draw, I realize that it is easier to question one’s self, or the SMEs, with every possible idea or interpretation derived out of the drafts (only if a draft is available!). I have observed that it suits me to question every idea and interpretation. Of course, you may come up with stupid questions/comments, but then asking them for “expected” replies is really up to you!
I have listed a few examples, from my previous organization, which I presented to my SME, while preparing documentation for the ad hoc reporting scenarios of the product:
– Does the information about the vendors get auto-populated into the Vendor ID field?
– What features have been introduced in the current release, besides the ones we’ve discussed? Can you provide a list of the features, along with their possible impact on data representation?
– Does the dashboard allow auto-upgrade feature in the current build? If so, are there any settings that a user is required to do in the dashboard before the new build is installed?
– As I understand the Version Protection feature allows users to update the underlying database, while keeping the overall look and feel of the dashboard unchanged. Is my understanding incorrect? If yes, how?
My purpose is to stir SMEs beliefs and test their understanding about their product (and not challenge their knowledge). The difference lies in making them answer first in a Yes or a No (a closed-ended question), and then graduate to an advanced level of questions (open-ended “If yes, how?” sort of questions), because unless you make them think about their product, they will not come up with replies that are full of crisp information. I do not intend to tell you to keep on asking questions; I only intend to notify that if it worked for me, it might work for you as well. Next time you approach an SME for a project, do not talk about the favorite football team, movie, or most downloaded iPad app, but bring up crisp questions that have a purpose and relate your queries with examples from real life. Present your rationale in a planned, purposeful manner, and let them know that your purpose has a purpose.
– Ask intelligent questions.
– Be specific.
– Go with a purpose.
– Think from the users’ perspective.
In the end
I realize that features and situations differ for products and services. The time-tested techniques of personal touch and questioning will not be the only techniques in the list. Questioning and other similar techniques may not always serve the purpose, but will help us gain knowledge. The knowledge, which is gained based on observations; knowledge, which is absolute, will lead us to getting read (bliss for us), and will bring us on the same pursuit – of knowledge. So that we continue to grow, learn, evolve, and communicate.
Have a clear perspective and approach your SMEs in a smart and meaningful manner.