The Curse of Knowledge -- The More You Know, the Worse You Become At Communicating That Knowledge
The Curse of Knowledge is a concept in a book called Made to Stick: Why Some Ideas Survive and Others Die. The curse of knowledge concept has generated quite a bit of buzz. Here's an excerpt, which I got from 37 Signals:
People tend to think that having a great idea is enough, and they think the communication part will come naturally. We are in deep denial about the difficulty of getting a thought out of our own heads and into the heads of others. It's just not true that, “If you think it, it will stick.”
And that brings us to the villain of our book: The Curse of Knowledge. Lots of research in economics and psychology shows that when we know something, it becomes hard for us to imagine not knowing it. As a result, we become lousy communicators. Think of a lawyer who can't give you a straight, comprehensible answer to a legal question. His vast knowledge and experience renders him unable to fathom how little you know. So when he talks to you, he talks in abstractions that you can't follow. And we're all like the lawyer in our own domain of expertise.
Here's the great cruelty of the Curse of Knowledge: The better we get at generating great ideas—new insights and novel solutions—in our field of expertise, the more unnatural it becomes for us to communicate those ideas clearly. That's why knowledge is a curse. But notice we said “unnatural,” not “impossible.” Experts just need to devote a little time to applying the basic principles of stickiness.
JFK dodged the Curse [with “put a man on the moon in a decade”]. If he'd been a modern-day politician or CEO, he'd probably have said, “Our mission is to become the international leader in the space industry, using our capacity for technological innovation to build a bridge towards humanity's future.” That might have set a moon walk back fifteen years.
This book is so relevant to technical writers. In my recent interview with Thom Haller, he mentioned how familiarity is one of the main things that gets in the way of clarity. This is a total paradox, though. The more you know an application, the better poised you are to write a good help file. But the more you know an application, the more familiar you are with it, and so you are less likely to write a good help file.
The trick is, how do you know what you do not know? How do you maintain the fresh perspective of one who is seeing for the first time?
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.