How much time do you waste being ignorant and afraid to ask?
As a technical writer, I realized I was getting stuck in a mental trap. Let me tell you about it. Maybe you can relate to this story.
My job is to write about new and obscure topics. Often, I’m a visiting team member (i.e., contractor) or a new team member among semi-experts and experts (i.e., people who have been working on the subject for months or years).
And here is my dilemma:
Almost by definition, I’m ignorant of the subject material. My job is to learn those nuggets of information and communicate them to others who are similarly ignorant and learning.
At the same time, I want to be and accepted and respected part of the team. This means fitting in and sharing in part of the tribal knowledge. Not acting like a complete outsider.
To solve this dilemma, I do these things before asking the developers for more information:
- Study the request in detail. Usually a written bug ticket or email, it might contain layers of information, discussions, links. Often, this information is highly contextual — meaning it can be hard to follow if you weren’t there. Just take it in. You’ll come back to it later.
- Look at the software. Learn the generalities — make a first pass at producing the expected result.
- Read the supporting documentation. Often, this is the content you are tasked to update or expand. Read the content around it.
- Read outside sources. You may need to read up on terminology. If the customer mentions a competitor’s product or feature — read up on that.
- Study the software some more. Try to produce the expected result or confirm that your conceptual understanding is correct. Sometimes the feature isn’t available yet, other times it doesn’t work as expected. Make notes.
If some of the above steps aren’t possible—I try to find a solution but also try to keep moving forward without getting too stuck. I’m doing my homework, trying to gather a reasonable amount of information to understand what’s going on. When I’m done , I know a lot more about the subject than when I started out.
NOW, I’m ready to talk to the team. I describe what I’ve done and understood. I ask for clarifications. I ask for a clearer picture of the information they expect to see me produce and where to presented it.
Sometimes, when I discover things that don’t make sense, it’s possible I’ve uncovered broken software, a missing requirement, or an unsupported use case. When this happens, I approach these issues humbly and respectfully, as questions. I don’t assume that I know what’s going on. Often, I’m writing about software that’s still a work in progress for a team that’s up against a deadline.
If possible, I show team mates visually and interactively what I’m talking about. This can be the most delicate part of the process, but is also where I bring the most value to the team. I’m often the first outside user — able to give a valuable first round of feedback on the new feature or product. I’m helping make the software better both by satisfying customers’ information needs and possibly by making the software work smoothly and clearly.
The important thing is to make a responsible effort, share honestly and respectfully what you’ve discovered, and ask thoughtful questions.