Dealing with impostor syndrome

Ryan Macklin wrote an excellent description of feeling like an impostor, which is something that I’ve suffered from throughout my career. Or more precisely, something that I’ve inflicted on myself.

I’ve talked to a few other people about this article, and they agreed that they feel the same way; maybe not every day, but it hits them sometimes. That’s purely anecdotal, and with a very small group, but I suspect that more people feel that way but just don’t talk about it. After all, what’s the benefit of exposing your own weaknesses?

I started to write a long-winded reaction to his post, but damned if it wasn’t embarrassingly self-referential, and probably self-serving.

So instead, a summary

When I go to work every day, I want to be part of a team. I want to share a common goal, and work to help achieve that goal in any way that I can. I’m not good at dealing with office politics, or using that to my advantage. I’ve worked in competitive environments, and they’re exhausting. I don’t want to sit in a corner and do nothing but write all day, but I also don’t want to spend all of my time forming committees to celebrate my can-do synergistic leadership skills.

Which isn’t meant to be a boast. Obviously, there’s a wide middle ground there, between quiet isolation and massive egotism.

For me, I think the Impostor Syndrome is primarily caused by being deeply invested in the projects I work on. I’m hugely fortunate because I have the luxury of seeking out interesting work. But then I have the perverse tendency to take on too many tasks. Which is intended to prove how valuable I am, but then makes me worry that I’ve taken on more than I can handle…so it just spirals from there.

Or maybe it’s a symptom of working in Documentation Triage mode for the past decade (“The mountain of work isn’t getting smaller…what am I doing wrong?” I ask, holding a very small shovel and ignoring the line of trucks dumping more work on the other side of an overused analogy).

How to fix this problem

The best, but most difficult way to stop feeling like an impostor is to build your skills. But to build your skills, you need to take on projects that push you to develop existing skills and learn new ones. But you will only get those projects if someone trusts you to handle them. So you prove that you’re capable in your assigned role, and then push to get more projects.

But it’s easy to get pigeonholed into those types of projects, and never find a way out. And it makes sense for managers to assign their team to the projects that they’re most suited for: If person A is a master of writing install guides, why assign him to write an API reference?

Possibly because he’s bloody well sick of writing install guides and wants a chance to write ANYTHING else. (…he writes, twitching a bit as the flashback passes.)

If you have writers B, C, D, and E, it becomes more difficult to shuffle people around for every project, and your bosses are going to wonder why you’re messing around like that.

But that’s what a manager needs to do: Building up the skills of a doc team does require time (and money), but it makes the team so much stronger. Having one tools expert is fine, until that expert goes on vacation or quits. Then the team is in trouble until someone else fills that role, either by training an existing member or hiring a new one. And hiring a new person always includes that ramp up time.

Can we get back to me, and not this manager person?

Maybe that doesn’t help all that much: “Convince your manager to let you work on new projects” isn’t the only solution, of course. So, what has helped me?

Er…I think it really does go back to learning. When I was most overwhelmed, I dove into a pile of books about information architecture, web-specific writing guidelines, content strategy, and other, related topics. At first, this is even more daunting: I learned enough to realize that I’m not a fully-formed Content Strategist, or a master of information architecture. And not being great at everything is a little worrying to me.

But I found that at least understanding what content strategy is, and how it applies to me, does help me feel more competent. I realized that I have a good reason to work with our marketing team, to better understand what they do and why, and what I can take from that and use in the product documentation.

Similarly, although I learned enough about information architecture to figure out what I’ve been doing so far (right and wrong), determine what has worked, and construct a documentation set that serves my users. It might not be perfect, but I at least know how I can improve it.

Not knowing that is what really makes me feel like a fraud.

I think I’m getting close to an answer

I think that’s it: How do you stop feeling like an impostor? By having a plan! Analyze what you have done, where you are, and what you’re doing, then synthesize that into a plan.

For example, I once realized that my documentation needed improvement. Unfortunately, it was a vague understanding, based on a handful of internal and external user comments and my own intuition. So I worried about it for a while. Taking a tip from content strategy, I blocked off a few days to perform a doc audit. I reviewed and rated 1500 topics, listing every one of them in a spreadsheet. I used status tags (Redundant, Outdated, Trivial, or OK) to identify work that needed to be done. And then I got to work, starting with the redundant topics (because they were the easiest to fix). Just getting rid of those gave me a sense of accomplishment, and that’s what I needed. By removing redundant topics and combining similar content into a single topic, I was making a measurable improvement to the documentation set (measurable because I could cross it off that list in the spreadsheet).

Even better: If two or three similar topics were getting a handful of page views, combining those into one would likely mean that you have a single page that will get all of the views. Make that page better (better content, more links to related content), and all of those page views will be more productive for your users.

As technical writers, we see all of those flaws and dangling threads in our documentation. Although the existence of those flaws can make us feel like we aren’t accomplishing everything we were hired for, what’s really true is that we were hired to identify those problems and find solutions to them. Which might mean rolling up our sleeves and fixing them ourselves, or admitting that it’s time to bring in other experts. (I leapt at the chance to work with a contractor to create videos, for example.)

Useful is not the same as realistic, or easy

Even through “build your skills” is entirely valid advice, it’s not always the most feasible. Being in doc triage mode leaves you will little time to practice skills that might be useful at some point in the future.

I’ll be honest: It took me a long time to read all of those books. But while doing that, I was able to start applying everything that I was learning. And although that can lead to a few mistakes, imperfectly structured documentation won’t kill anyone.

Unless you’re writing Brain Surgery for Dummies. But we can take advice from the Hippocratic Oath: Focus on “do no harm.” Learn new skills, implement those skills, and do your best to do no harm to the documentation (and your readers) while doing so.

So: Learn! Plan! Work with other teams to increase your sense of value (and your visibility in your company). And realize that the rest of us feel the same way, at least some of the time.