Technical writers, documentation managers and product managers often reach out to us when trying to gain the support they need from their engineering colleagues, managers and executives. They often find that gaining such support isn’t always easy or, in extreme circumstances, even possible.
They discover that some of the smartest people on the planet have a deadly blind spot: They routinely (and dramatically) underestimate the breadth and depth of their own expertise.
As a result, Silicon Valley is needlessly littered with carcasses of now-defunct start-up companies once doing brilliant work that was mostly misunderstood. Such failures may be dismissed as being “ahead of their time” or “victims of the status quo.” But sometimes rationalizations from founders and technical leaders include comments such as “the customers weren’t technical enough” or “they just didn’t get it” or “we just couldn’t get them to understand the benefits.”
Too many times, companies fail because they don’t explain their technology well enough for customers, partners, and even new employees to “get it.” They fail because of poor technical communication.
The culprit at the root of this blind spot is so common that we gave it a name: the context gap. This is the difference in understanding between those who invent a new technology and those who need to use it to produce additional value.
The good news is that the context gap can be bridged, but only if you recognize that it exists and take corrective action.
Consider the following illustration:
The context gap is created when innovators follow an “ascent to invention.” Note that this is never an easily understood or well-traveled journey. Instead of Interstate 80 (the freeway that runs up and over the Rockies), it’s more akin to the first hike that Daniel Boone made up and over the Appalachians. That’s the way invention works. It’s never a clear path and involves trial and error but — through sheer intelligence, creativity, perseverance, and grit — innovators endure and ultimately invent amazing new things.
However, unlike Daniel Boone’s followers, technology users don’t get to follow the ascent to invention. Instead, they’re asked to jump to the top on day one. To the inventors, it looks easy — but they are already there. Looking back, the learning seems obvious, and it is — but only to them. The inventors, having experienced the ascent to invention, have implicit yet higher-level understanding of what they’ve created, how it should be used, and the benefits that it can deliver.
To put it simply, those who attempt to jump to the top do not always share this level of understanding. But that doesn’t mean that they cannot.
What’s needed is an elevator to quickly transport those at the very beginning of the learning curve up the shortest path to the top. But someone needs to build that elevator.
Depending on the industry, the components used to build the elevator vary. For software APIs, for example, users need reference materials that document each API call. But, unless it’s an extremely simplistic API, they might also need a tutorial (to get started), a conceptual illustration (that shows the big concepts and how they relate to each other), a design guide (to help them think about its effective use), code examples that show how others use it, recipes and advice for specific use cases, and cookbooks that collect recipes for a specific industry or category. They might even need guru-led training, instructor-led training, and eventually self-directed study materials.
Taken together, such an arsenal can be powerful. It can transform a developer who thinks your API is too complicated into a developer who appreciates your API, becomes an advanced user, and possibly even a volunteer evangelist for your API.
Further, the most effective documentation is rarely written for a single type of individual. Instead, it addresses the needs of a whole spectrum of users who range from entry level to technically sophisticated. The best documentation makes all of its users as productive as possible.
We’ve seen it happen. Bridging the context gap makes a huge difference.
Here at Expert Support, we are defining and documenting techniques and best practices employed by technical communication professionals to conquer the context gap. Watch this space for practical know-how gleaned from the collective Expert Support experience over the past couple of decades.
So, what’s your situation? Do you have an elevator, a staircase, a broken ladder, or a hole? Do you have the resources, expertise, and grit required to help your community to understand your technology and its potential? If you’re struggling with these issues, please let me know. I’d love to learn more about your specific situation and explore how we might be able to help.
And, I invite you to sign up for our email list so we can let you know about important posts and updates.