Skip to content

Instantly share code, notes, and snippets.

@mjang mjang/imposterTW.txt
Last active Mar 20, 2018

What would you like to do?
Imposter Syndrome for Documentarians
Discussion from WtD Slack
Bear with me, documentarians. I’ve a big thought to share, and I want to use separate paragraphs/entries so that people can respond to points separately. (Vs. me just dumping five paragraphs into one Slack message.)
I’ve been troubled by several aspects of a seemingly prevalent _imposter syndrome_ among a lot of documentarians. Well, more among the technical writers among us documentarians. And although I considered posting to the #career-advice channel, (or the meetpus channel becasue this is the subject of an upcoming presentation), I chose the #watercooler for a bigger audience.
While I’m certainly not advocating that anyone exaggerate their knowledge or deliberately mislead others into thinking we’ve more abilities than we do, it seems that the catchy phrase _imposter syndrome_ contributes to too many people short-changing themselves in discussions with others. And, very importantly, it contributes to the lack of respect for tech writers that we all rightly complain about.
When an engineer doesn’t know the details of a given technology/language/framework/whatever, they’re just not going to say, “oh, yeah, one more example of how I really don’t know what I’m doing; I’m just winging it all the time.” But far too often tech writers will do just that.
Such language definitely makes others pause at the thought of including a writer in their team/work if they don’t have to. After all, why invite someone who themself says, “oh, I can’t really do any of this.” And that hurts not only the individual, but the profession.
I’m interested in sparking a discussion because this seems to be a popular topic for documentarians, and I’m frankly at a loss as to why. We’re a mighty smart group, and an important part of our jobs and personalities is the ability to learn new things. That’s what we’re hired for. So why present that as a problem, and say that we’re imposters?
(done now :slightly_smiling_face: )
hey you touched a raw nerve with me here most definitely
I don't think I tend to do this. But I do think that it happens because technical writers don't code. Or at least don't write production code.
But engineers don’t write, and they don’t act like they’re incompetent because of it.
I definitely feel this way, especially with regard to the sheer amount of technologies that exist that I just don't even know how to start using. Plus the fact that my "technical writing" experience is in a completely different field, and well.
And for all the calls to understand that software requires equal input from many sorts of contributors, at the end of the day, code trumps everything
but they *think* they can write
at least, the engineers that I work with do
they can do All The Things
writers exist only to take the burden of documentation off the shoulders of Real Coders
now here's where I should take a small break
yes, - my point: engineers think they can, and they’ll learn to do so if they care. But the writers sometimes throw up their hands and say, “oh, I can’t do that” for the stuff that’s not their job to do.
and explain that I do not refer here to any individuals, and certainly not to all programmers
So it’s external pressures that cause many writers to feel this way?
but it's one dominant cultural model
well, not only do the writers throw up their hands
they are also, at least in some environments, encouraged to think of their contributions as lesser
Everybody Can Write, y'know?
Yes, that’s definitely true (that some environments devalue writers’ contributions). And I’ve been wondering if somehow (oh, I sure to hate to blame the victim) writers inadvertently contribute to that feeling.
It’s more of an inferiority complex than imposter syndrome, I think.
Which comes from being in terrible environments where writing is not valued.
And sadly those environments were quite a bit the norm for a long time.
I’ve seen some of the “I can’t do that” attitude on a spectrum: I feel that way myself for some things (like web services) but have also been frustrated by a coworker making the same declaration about accessing documents in GitHub
> but they *think* they can write
Any skill which is endemic in a culture is automatically undervalued.
Almost everyone in the Anglophone world thinks they drive cars much better than they do because driving a car is a near-universally-acquired skill in the Anglophone world. So it is, in effect, an _invisible_ skill. Everyone can do it, so it can’t be all that hard.
The other two endemic ‘skills’ that immediately come to my mind: writing and sex.
And, in my experience (and in the reported experience of pretty much everyone I know), people are nowhere near as good at either of these things as they think they are.
And they think they are better because ‘everyone’ can do it, so real mastery doesn’t look remarkable because, superficially, it looks the same as what everyone else is doing.
Love the “endemic skills”!
Maybe some of it is the question of where to draw the line in terms of specialization? It seems like some job postings ask for a writer who is also a graphic designer, and some job postings ask for a writer who can also write Python scripts, and once you’ve read enough of those, you start wondering at what point you can claim to have a full skill set for your position
Yes, - I can understand how a writer could come to suffer an inferiority complex in bad environments. But that seems a bit distinct from how I understand the _imposter syndrome_ issue: thinking and acting as if one is so incapable at one’s own job (not others’ jobs) to the point that one is only impersonating a skilled professional. But perhaps I’ve not understood the term rightly. I’ll go look it up instead of making assumptions.
Separate to the problem of ‘endemic skills’, I was recently introduced to a new fallacy:
*The fallacy of transferable expertise*
It came over my transom via a tweet containing a screenshot from a book (seriously meta, I know). To wit:
The text transcribes thus:
> American-style libertarians abound on the Internet. Computer
> programmers are highly susceptible to the just world fallacy
> (that their economic good fortune is the product of virtue
> rather than circumstance) and the fallacy of transferable
> expertise (that being competent in one field means they’re
> competent in others). Silicon Valley has always been a cross of
> the hippie counterculture and Ayn Rand-based libertarianism
> (this cross being termed the “Californian ideology”).
And it comes from David Gerard’s recent book _Attack of the 50-Foot Blockchain_, a careful critique of cryptocurrency that is worth reading for reasons completely unrelated to the nifty quote above.
Gerard’s day job is as a system administrator and he argues that system administrators and developers are, in particular, susceptible to this fallacy. (edited)
A term I’ve been looking for for years: “the fallacy of transferable expertise.”
From excellent critique of cryptocurrency et al, Attack of the 50-Foot Blockchain.
Hmm.. good point, - and it makes me think, “why aren’t engineers prone to those same thoughts?” They certainly can’t be experts in frontend, backend, security, all languages, all web technologies, all build systems, etc., etc. And yet, they don’t seem to feel as if they’re impersonating a real engineer.
Imposter syndrome does not mean openly admitting you feel like an imposter to people who might already think you are an imposter. :smile:
What you’re describing sounds more like reverse-bragging, “oh I’m so bad at that…”
But that’s nitpicking terminology. I do absolutely think that happens and tech writers often have a big problem with it.
And I again I think it’s a sort of awful survival tactic: those engineers already think I’m an idiot and maybe I am an idiot so I’ll just admit up front I don’t know what I’m doing rather than challenging anyone and being PROVED an idiot….
I think tech writers have to be more honest about knowledge gaps, simply because it's more on display. If a dev doesn't know something, they can often fake it, or leave it until someone else picks it up. Writers have to get something on the page and then *ask people who actually know this stuff* if it's right. We're much more exposed.
Also, it's a well-worn tactic of tech writers to write something--*anything*--in order to get good feedback from devs (they will always correct you if you're wrong, but won't provide information to fill a blank page)
I think it might be the demarcation of the jobs? E.g. as a front end engineer, you're not necessarily expected to know C or Java. "Tech writer" is much more nebulous.
Also I think at least in the past in addition to tech writing being a low status profession in tech it was also considered low status in *writing.* So the inferiority complex got doubled.
“low status in *writing*“? among who? maybe “real writers” of serious literature?
Right. Despite the fact that tech writing always paid so much better than other writing professions, it was a hack job you did while you were working on your “real writing.” (edited)
> why aren’t engineers prone to those same thoughts?
I think engineers and sys admins are particularly susceptible to falling for the fallacy of transferable expertise for two reasons
1. The demographic and historical reason: most engineers and sys admins are straight, white, and male. They are used to being treated as if they are the centre of the universe and are used to being taken seriously no matter what they say.
2. The occuptational reason: engineers and sys admins work environments are structured and controlled and subject to relatively formal rules. Things either work or they don’t. And, once a broken thing is fixed, it tends to keep working forever. This can’t help but engender a conviction that you can understand anything relatively easily and make it work just as well.
likely so. And this is so highlighting my narrow viewpoint/perspective. So I’m pleased that you’re all sharing your perspectives.
> Despite the fact that tech writing always paid so much better in
> writing professions, it was a hack job you did while you were
> working on your “real writing.”
Not just tech writing.
The class-ridden, but mostly unspoken, social hierarchy of ‘real writers’ has only one High Status group: writers of mainstream literary fiction, and even then, said fiction best be about the internal moral lives of upper-middle-class, Anglophone, white people.
*Everything else* — screenplays, teleplays, journalism, advertising copy and instructional materials — is lowbrow at best, and hack writing at worst. (Can you tell that I *loathe* the Leavis’s and the Leavisite tradition and that *&^&%$ing awful book _The Great Tradition_?)
replied to a thread:
So now I’m starting to get it. And actually, I feel it the other way: as a technical grad without a lot of English/liberal arts studies, I feel so woefully uneducated. And whenever I have a few months between jobs (well, the very few times I’ve been able to swing it), I rush to the library to read some more classics that I feel are essential for me to even pretend to be semi-literate.
Also, finally. I think there’s a gender aspect to this as well, with tech writing traditionally being a very female-dominated profession. Women tend to use a lot of self-deprecating language, even when we’re supremely good at what we do, as a sort of shield against criticism: they can’t call me dumb if I call myself dumb first and joke about it. (edited)
Is Your Sense Of Humour Psychologically And Socially Damaging?
When a little joke goes too far
Yes, - I agree that this is definitely a big factor. I worked with a woman who was very technical, and an excellent product manager who had a mechanical engineering degree. And yet she’d constantly say about technical issues, “oh, that makes my head explode!” I just wanted to shake her and demand she stop saying that. But it must have served her in some fashion. (edited)
(I note that most of my replies to this topic are qualified with “I think…” which is another female-speech habit I have had a lot of trouble breaking. :grimacing: )
Oh dear, “several people are typing”
Just chiming in here, because this is a very interesting conversation. Though not female, I’ve definitely always been an introverted person and often have a self-deprecating sense of humor, will couch statements as questions or conditional (I think… if…?), and have trouble making hard stands with people I don’t know, or co-workers who are more senior.
Lately at work I’ve been put into situations where I need to be assertive and have a stance, and _be the writer_ - they hired me to do this job, so I should be the expert with regards to it, when talking to an engineer or the like. It’s helped a lot to be forced into these types of situations - helped drag me out of my shell a bit I think?
— although ‘I think’ is absolutely a strongly gendered qualifier, I also over-used it (and other hedging language) when I was younger. I’m not sure how generalisable my cure is, but I was cured of it when I was put in command of a company of infantry.
Nothing like a bunch of young soldiers expecting you to know exactly what you are doing in every circumstance, because you are *the CO*, to cure you of hedging language.
OTOH, I've seen recent arguments to the effect that the "I think" qualifier is a good thing
nope, cannot cite source
but the argument is to the effect that it leaves more room open for differing opinions, more open conversation
“I think” is definitely good, in a contextual way… but the problem is those of us that overuse it, yes? “I think that you shouldn’t say this, because xyz” - do I think that, or is it fact and I’m trying to soften my statement?
i've got two thoughts:
1. technical writers benefit from acting from a position of less knowledge. i was reading an article by a digital ethnographer (Crystal Abidin; she's awesome, do check her work out) that i can't find at the moment that described working with the "influencer crowd" (think beauty instagrams), and that being in that (specially calibrated) position allows for a relationship where the subject matter expert would be much more willing to _coach_ the information seeker. this seems pretty similar to the relationship between the technical writer and engineer, where we're always having to seek the engineer's expertise and domain knowledge
Ooooo thats good.
2. I was also reading Richard Hamilton's _Managing Writers_, who had a chapter on the formal power and informal power of writers in a product team -- that we as writers usually have little of the former (formal power as structurally granted, i.e. can literally order people around), and need to garner more of the latter (informal power as getting people to trust you, be willing to volunteer information to you)
dredging up my time in command again. Certainty in language is great for commanding others. But commanding others is not always great. In fact, most of the time it’s not great at all, it’s the opposite of what you are trying to do.
Qualifiers, among other things, can cast you and your speech as equal to, not in charge of, the people you are addressing. And that’s probably the way you want to come across, most of the time.
re: qualifiers, I tend to tack "yeah?" and "does that make sense?" on to the end of statements, which I'm increasingly noticing (and becoming annoyed by)
There’s probably not a rubber stamp solution to all of this. You have lots of things in play here - relationship dynamic (is someone senior), personal dynamic (is someone a more assertive personality), and actual content of the communication (fact vs opinion). If I’m a dominant personality, softening up my language might help people to hear me. If I’m very introverted, it might behoove me to be a little bit more clear and firm. If I know what I’m talking about, I should act so; if it’s a subject I’m flimsy on, especially if I’m talking to a subject matter expert, being more questioning and hedging around might be the way to make things smooth and learn.
The problem is that I imagine we aren’t all perfect at automatically doing all of this in our heads, and so we end up with over-assertive people who walk all over everyone else without realizing it, plus quiet people who don’t speak up when really they should…
(When I can,) I'll jump into chats with answers to technical Qs from Devs, QA, support engineers, and devOps sales types.
I (and most of my fellow writers) have become known as "go to" people in certain complex topics.
My boss has encouraged us to become "reverse engineers", and frequently, we find issues that devs haven't considered -- we can take a more holistic PoV to address various problems. (edited)
Nevertheless, I'd struggle to get to "Hello world" in Java or JavaScript.
Even with that limitation, I feel like an equal to (most) everyone in "Engineering" and "Support" who work on our product.
When I first started jumping into conversations, I made technical mistakes. I still make such mistakes -- but so does everyone else on the team.
(Yes, it's taken some hubris, but to me, that's how I overcome imposter syndrome.)
replied to a thread:
This is why I'm glad that we'll have a speaker at WtD NA on "Writing the Next Great Tech Book". I think we have documentarians here who are more qualified than devs to "write the book" on certain topics. (and a few of us have done so :slightly_smiling_face: )
For me, the sweetest way to answer a question -- is with a link to a doc section that solves the problem presented by a dev/support engineer/QA/etc. :slightly_smiling_face:
I'm way too late to the conversation, - But something I've personally noticed is that there are a large number of defensive pessimists among writers - and defensive pessimism can play right into the imposter syndrome if displayed around people who aren't familiar with the personality type.
I've also seen evidence of point #2 - There have been times that developers approached me, to approach their manager- because when THEY suggest something is "broken as designed", they're basically given the Product Manager version of "thoughts and prayers". When I (or the other writer) bring it up, everyone raises an eyebrow and starts investigating.
This conversation above is really good. One thing I'd like to add is that writers need to emphasize the importance of the knowledge and perspective that we do have. While we'll never have the same understanding of code and technical detail of a developer or engineer, the technical writer generally has a higher-level view of a project and knowledge of the user
we're more likely to see every module of a product than a developer that might specialize in one. this can mean that suggestions on the product that directly impact the user experience or business objectives are better received from a technical writer than from a developer.
however this all means that as a technical writer, you have to really study up on the use cases, business objectives, etc. of each project to make up for the gap of understanding on technical detail
I disagree with "While we'll never have the same understanding of ... technical detail of a developer or engineer".... (edited)
Perhaps we won't have the same understanding as an SME, I feel like I have to understand technical detail as well as devs / QA other than the SME. When I don't have that level of understanding, I feel like the quality of my writing is crap. (edited)
that's fair. "technical detail" is maybe not the right word. the understanding is always going to be on a different level. a technical writer might have a really strong understanding of the data or components that make up a product, without touching or being familiar with the underlying code
I know one of the big demands on us is an understanding of how to customize a product. For me, that requires understanding of
* Use cases
* How to customize code to meet those use cases (edited)
Frequently, I check use cases that a developer hasn't considered -- at that point, I can ask devs if they've considered the impact on other related code, etc.
Late to the conversation started but I was finally able to demonstrate the true value of docs yesterday when I helped a senior UI developer and a tester who were struggling to configure a new integration. I happened to be looking over their shoulders at the time and pointed out the reason the configuration wasn’t working was because they hadn’t removed the `;`s in the .ini file (which are used to comment lines out) - something they would have known had they read the third line of my document!
I'm also late to this conversation, but can add that this imposter syndrome issue has long bedeviled tech whirlers in non-code fields as well.
I was senior TW at a engineering & manufacturing concern, and all of the TW, myself included, struggled with this issue. I was lucky enough that my having a background in interface design meant that I was able to help the main interface design engineer w/ QA as part of my documentation process. This reinforces the already-made point that the severity of imposter syndrome , internal though it is, can be deeply impacted by firm culture, as that engineer valuing my input helped the whole TW team.
Coming back this morning to say this conversation gave me a lot to think about last night. A++ discussion, thank you all.
I think it’s interesting coming from the perspective of a developer-turned-documentarian. In some ways I’ve fought battles (and won!) to elevate documentation to first-class citizenship in my development ecosystem, but I also simultaneously feel a deep sense of imposter syndrome among _documentarians_. I don’t have a background in literature or anything that might obviously lead to a career in documentation. I have a background in development.
And so I might just be the rare developer who had that lightbulb moment so many in this community seem to strive for when working with engineers. My ability to speak engineer seems to have translated into being able to write effective documentation. (edited)
I would not consider myself to be the most qualified to do a lot of the documentation work I do, but I’m definitely the _most willing to give it a shot_. Perhaps the true measure of “qualified” in some circumstances is willingness to step outside your comfort zone and go for it. :slightly_smiling_face: (edited)

This comment has been minimized.

Copy link

hillaryfraley commented Mar 8, 2018

Hi Mike! I'm summarizing this conversation for the newsletter and found a few later-breaking additions to the conversation--thought you might be interested in adding them into this gist. Thank you for putting this together!

Interesting to see /Attack of the 50' Blockchain/ cited here. Not only because I've read it, but because Dave Gerard is an old friend of mine, going back 15+ years, and I contributed a few small points while he was writing it. It's very good and I strongly recommend it. It's very short -- because it is wildly controversial, given the raging popularity of cryptocurrencies at the moment, fully half of the page count is references. He provides at least 1 reference for every single point or claim he makes. So actually it's quite a short clear book and everyone who has any interest watsoever in Bitcoin and related stuff needs to read it.

I work for a small software development shop and I'm the first and only technical writer they've hired in their 20+ years of existence. They asked me what title I'd like. Based on the level of responsibility I have, I thought Senior Technical Writer was an accurate description of what I do on daily basis, even though I'm relatively new to the tech writing world. I only have 4 years of experience in TW, but I have experience other fields. When I switched to technical writing I entered a Master's in tech comm program and started at a mid-sized software company that used the titles: associate, specialist, senior, and principal. I compared my new role with the job descriptions from my former employer and my responsibilities lined up with what they would ask a senior writer to do, so I went with that. In my new role, I've selected the authoring tool (Flare!), version control, built the help center and coordinated the implementation of context-sensitive help, serve as the only documentation specialist, wrote a style guide and trained our software re-sellers on its use, and wrote a documentation strategy white paper that maps out the documentation initiative (that was important to get the ownership's buy-in for my proposal). So, even though I'm tackling all of that, I still feel a bit like an imposter since I was able to choose my title and don't have the depth of years in experience.

I still feel a bit like an imposter since I was able to choose my title and don't have the depth of years in > experience.
This is what I mean. I understand that completely - and we have a Principal QAE at my company with only 2 years of experience... but it was what they needed to do to make the numbers work, I suppose. I was offered Senior after one year, but I put the offer on hold while I try to pursue a more project-oriented track over the next 6 months... but if I still want it in September, you can bet your butt I'm taking it. I'll feel like an impostor, too - but it looks good on the resume and comes with a bump large enough that I can maybe start looking for a little house somewhere. I'll LARP as Richard the Lionheart for that, much less a Senior Tech Writer. (edited)

And here's me in the corner applying to senior TW roles because why not.
You never know- my first QA job was supposed to be a Team Lead position, but they liked my pluck and the cut of my jib, and all that.

I don't know, you're right, but I feel way out of my depth on this one.
I wonder what happens if you say to the recruiter "I never expected to get this far."?

They'll start focussing on other candidates

Fair enough.

FWIW I had no problem hiring a senior customer support engineer into a senior technical writer position. She had 20 years of tech experience in various roles, and solid writing experience. On those terms alone, nothing would raise any flags.

One of the things I've learned over the years to conquer imposter syndrome is to

  1. Accept that you won't know everything. People knowing different things from you doesn't mean they know more, they just know different. As long as you're willing to continue learning, you can grow into a position.
  2. Don't downplay the things you do know and the experience you do have. This was one of the hardest things for me to do, as a woman (and woman in tech), but I've also come to accept that if someone thinks I'm arrogant because I take ownership of my accomplishments and try not to downplay them, then I probably don't want to work for them anyway.

One of the sayings I've started actively trying to live by is "own yo' sh*t" (as the entrepreneur community would put it). What this means is to take ownership of what you do, be it good or bad.

Apologize and take ownership of when you've actually done wrong, hurt someone, etc., and only when you've done those things. Don't apologize for things like speaking up about something, raising red flags, protecting others, etc. (Needlessly apologizing cheapens your apologies and conveys that Doing The Right Thing is somehow wrong. It's not. You have a right to speak up and be heard. You have a right to raise concerns and offer suggestions. You have a right to take up space.)

Also, own up to mistakes. For example: Yep, I made that mistake. I also learned this, this, and this from the experience. I apologize for the damage it caused, but I've learned how to avoid it in the future and have put safeguards in place to avoid someone else making the same mistake.

Likewise, make your accomplishments and contributions known. You put in the work, you did the learning, you had the experience. You deserve to own and be recognized for that. Many people don't like to do this for fear of being branded a braggart. It's a legitimate concern and requires some practice to balance, but it is possible to make your contributions known and visible without being a braggart, such as not pawning off (all of the) credit for something you did to other people. You're part of the team, too. Making your contributions invisible renders you invisible and devalues your worth to the organization.

I know in my line of work, at least, my successes are invisible, but my failures are evident. That stacks the deck against my worth, so I need to take an active role in shifting that balance, or my career (and my well-being) suffers.


This comment has been minimized.

Copy link

geckel commented Mar 14, 2018

The fact of the matter is that everyone CAN write and not everyone CAN code. That's not to say that everyone CAN write well. In fact, just the opposite is often the case. Developers are often the worst people to explain what they've created because they're too close to the product.

But we find ourselves in SOFTWARE companies whose #1 way of making money is selling software products, not books. So, the #1 priority is creating great software products. But a software product can't be great if customers don't know how to use it. That's where writers come in. Our ignorance as a first-time user of a software product is one of our greatest contributions to the product. When we make sense of the product, we give others, starting at ground zero, our understanding. We figure things out so the reader doesn't have to (as much). We don't need to know all of the details under the hood like the developers do; we just need to know what the reader needs to succeed.

There's nothing wrong with asking a developer if your interpretation of the software functionality is correct. Asking for feedback is not a confession of stupidity. Feedback is part of a team agenda to create a great product that customers can easily use.

If you're in this field it's because a) you have a fascination with writing, b) you like technology and c) you like learning new things on a regular basis. There's no need for you to worry about your validity in an organization. If they pay you, you're valued. Period.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.