Conquering imposter syndrome¶
You are a technical writer. At some point in your career, you may face the notion that you are “just” a technical writer. That notion might originate from the perception of your more technical coworkers, or your own self-doubt.
Some common themes emerge in many teams: anyone can write, but writers don’t code, so they can’t understand technical content. There might even be a notion that the docs should be written by engineers, but they either don’t want to, or don’t have the time. The actual product or code is going to trump its accompanying documentation when push comes to shove. It might seem logical to accept that writing is going to take a backseat and garner less esteem.
All of this can engender an inferiority complex. Combine that with a non-technical background, and you have the recipe for imposter syndrome. You may feel like you are just winging it, and fooling people into thinking you are competent.
If you are worried that you as a writer are just impersonating a skilled technician, you may need to revise your perception of what the required skills for your work truly are.
“Anyone can write”¶
They sure can. Writing well is a different matter. So is writing well in a technical context. You were not hired because you can capitalise words and punctuate sentences correctly. You’re not copying and pasting what the engineers say and making it look nice. Your skill goes far beyond that.
You have cultivated a cognitive skill set that lets you distil meaning out of a mass of information, and convey it in a way that your entire audience can put it to use. You transform your engineers’ input into chunks that can be readily processed cognitively, and structure those chunks into meaningful sequences. You embed the lot into a context that helps your users apply what they learn and solve their business challenges. You convey not just the WHAT and the HOW, but the WHY. You are at the crossroads of engineering, product management and user enablement.
Your skills require a deep understanding of cognition, communication, how people learn, and what real-life scenarios your users grapple with. These are not skills that people with technical backgrounds possess automatically.
Perspective¶
Who are your readers?
- Beginners who are just getting started
- Intermediate or advanced users trying out something new
- Any type of user who tried to do something and got stuck
You not being a technical expert is actually an asset. As a technical writer, one of your great skills is the ability to adopt different people’s perspectives and understand exactly what bits of information they need, and how to present them. You may be writing for a very varied audience, not just in terms of learning level, but goals and personal background. As a good writer, you excel at understanding what your readers bring to the table, and what you need to give them so that they can learn efficiently. You make a qualified judgment call on what and how much to include.
Being overly proficient could lead you to overlook something; a step that may be glaringly obvious to a power user could seriously stump a beginner. You don’t skip those obvious parts, and you provide complete information without being blinded by routine.
Complex information and user context¶
The engineers have a deep understanding of their domain. They are used to outsiders not understanding it. The first answer you get to your technical question might be way too superficial because they haven’t yet gauged how far your understanding reaches.
Know that it does not reflect on your ability to grasp complex technical information. It’s a normal process. The conversation might take a few steps to reach the answers you need. This is another one of the areas where you excel. You ask the right questions and hunt down the answers to make sure that your documentation is of value to all your users.
You do not need to be able to write code or even understand the code itself. Your job is to understand how the resulting software works and how it can help your users solve their business challenges.
Dealing with knowledge gaps¶
For all that, you do of course need to learn about the technologies that you document, and you do need to be prepared to enter domains that are outside of your comfort zone. You can avoid some common traps.
- Don’t take the developer’s word for it when you don’t understand something. Keep asking questions, keep reading. Acquire the knowledge you need.
- Don’t dwell on the parts of your docs that you are most comfortable with. Focus on the sections of your documentation that users need the most, even if those are sections where you are less knowledgeable.
- If you are an introvert, overcome your natural aversion to hounding people for answers.
- Your role isn’t to know everything, but to synthesise the knowledge of everyone working on your product in form that is of most benefit to your users.
- The knowledge gap might go both ways. Communicate actively with all your internal stakeholders. Keep them in the loop about the work you are doing.
- Be honest about what you do and do not know. Be upfront when you don’t understand something or got something wrong.
- Relentlessly ask questions and maintain a healthy thirst for more knowledge.
Documentation as a part of the product¶
Some of the issues need to be addressed on an organisational level. We won’t be able to change the fact that it’s the product that rakes in the money, not the docs. However, the user experience is strongly tied to whether or not your users can reach their goals with the product or not. Documentation has a valuable role to play from that angle. The Definition of Done can include meaningful documentation, enshrining your contribution to a positive user experience from the get go.
