Do Some Project Managers Suffer from the Dunning-Kruger Effect?
Errol Morris has a lengthy essay in The New York Times on something known as the Dunning-Kruger Effect. Essentially the effect is that even though something is obviously wrong, a person is incapable of recognizing it. Cornell profesor David Dunning stumbled onto the idea when he read about a bank robber who squirted lemon juice on his face, believing that the juice would mask his face from the security cameras.
If Wheeler [the bank robber] was too stupid to be a bank robber, perhaps he was also too stupid to know that he was too stupid to be a bank robber — that is, his stupidity protected him from an awareness of his own stupidity.
He later phrased the assertion more academically:
When people are incompetent in the strategies they adopt to achieve success and satisfaction, they suffer a dual burden: Not only do they reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the ability to realize it. Instead, like Mr. Wheeler, they are left with the erroneous impression they are doing just fine.
To read the full essay, see The Anosognosic's Dilemma: Something's Wrong but You'll Never Know What It Is (Part 1) - Opinionator Blog - NYTimes.com. (Thanks to Bokardo for the tip.)
The Dunning-Kruger Effect might fit nicely into the IT software life cycle. Could we say that project managers who don't involve technical writers into their workflow to provide help for their product may fail to do so in part because of the Dunning-Kruger Effect?
It's obvious that most software applications need help material, and you can frankly tell some project managers that their product needs help, that it's unintuitive, that the help content the project manager may have written is insufficient, but sometimes you may as well be talking to a grasshopper, because the project manager continues forward with the same help-less plan he or she had from the beginning.
It's not that these types of project managers are incapable or incompetent. So maybe it's not a real case of the Dunning-Kruger Effect. In a true Dunning-Kruger Effect, there might be something wrong with project managers' brains that prevents them from ever actually understanding or grasping an actual need for help material. Instead, it's more a matter of project manager's inability to recognize a situation due to certain blinders that hide reality.
Project managers often can't recognize that their decision to exclude help material is wrong because of three underlying reasons:
- Having helped build the application from scratch, project managers are blind to their own product's complexity.
- Because they are rarely immersed in actual user environments, project managers are unaware of the user's knowledge level.
- Because they can read and write, project managers assume they can create help materials as well.
Whereas I used to believe that project managers excluded technical writers out of some skilled knowledge about the uselessness of help and their own distinguishing intelligence about user needs, the Dunning-Kruger Effect helped me see that project managers probably have no recognition of any wrongdoing. Their own ignorance in this area protects them from the guilt of what would otherwise be a crime against the user.
Unlike the Dunning-Kruger Effect, the situation with project managers is correctable. You can -- through careful, tedious, and tactful perseverance -- persuade a project manager to see a new perspective. The approach to bring a project manager into the light of higher understanding involves three strategies:
1. Reveal the Product's Complexity
If you create a software application from scratch, putting together the requirements, outlining the design specifications, reviewing the prototypes, attending countless project meetings discussing the product -- then surely you're at a disadvantage when it comes to seeing the product from a fresh, uninitiated perspective, as a typical user would. The knowledge a project manager has about the product gives him or her an overbalance of assumptions and background information that make it difficult to see the reality of a product's complexity.
As the product nears release, project managers often start user testing, that is, they give beta versions of the product to users to explore and test. It's about this time that project managers begin to realize that their product is more complex than they previously assumed. They start to see the need for help materials for users. For this reason, it's important for project managers to be involved in user testing -- so they can observe first hand the responses of those who lack the same background knowledge that the project manager has.
2. Expose the User's Knowledge Level
The second blindness that afflicts project managers is unawareness of the user's knowledge level. This blindness is usually cured through user testing as well. In general, it's common for project managers to judge an application's complexity by asking where they themselves would need help. Never mind that the project manager is usually a tech savvy IT professional, and our users barely get by in Microsoft Word. The project manager's outlook about the user's ability starts with questions like, What do I find confusing here? What isn't immediately intuitive? Where are my pain points in the application?
These are good questions -- don't get me wrong. The problem with these questions is that users often start from an entirely different skill level. Most likely users don't sit in front of computers all day building and managing software. In fact, users may only use the computer for one to two hours a day! Because of this extreme difference in skill level, the project manager becomes blind to the idea that users may not understand when to single or double click, or how to perform simple computer tasks like changing their computer's resolution or recognizing when a browser window minimizes instead of closes. The user's questions may be much more basic, such as Why would I want to use this application? Or, How does this fit into my own business workflow? Or, Why can't I export everything into Microsoft Word?
3. Show the Project Manager's Writing Weaknesses
The final blindness that makes project managers mistakenly omit technical writers from the software workflow is the perception of their own help authoring ability. Many project managers usually aren't skilled enough writers to judge their own writing level, so they look at what they've typed and see nothing wrong with it. The text and screenshots they've pasted into Microsoft Word and the way they have passively constructed their sentences look entirely fine to them.
Helping project manager's recognize that something is wrong with what the help material they've created requires some tact. If you confront the project manager with accusations about poor grammar, lack of organization, and flatness of design, the immediate reaction will be that your motive stems from resentment. You have no credibility when you seem to be operating out of jealousy and exclusion.
Instead, the technical writer must confront the project manager indirectly, perhaps through an objective third party who has a greater awareness. Or through user testing, or through some other objective analysis.
Whether this whole Dunning-Kruger Effect fits the scenario of project managers, I'm not sure. But it has given me a doorway into a topic I've been reflecting on for some time -- why some project managers don't/can't see the value of involving technical writers to create help material. The project managers who exclude technical writers from their projects may do so only because, like the bank robber, they're too uninformed to realize that they are uniformed about the need for help content.
As we reveal the product's complexity, expose the user's knowledge level, and show the project manager's writing weaknesses, we can help bring project managers to a greater awareness so they can make more better decisions.
Many times the realizations for the project manager come naturally through user testing. I find that I'm often brought onto projects at this time. But by the time the users are testing the beta version of the product (usually one month prior to release), the window of time is usually too brief to produce quality help materials. Consequently, many of the project manager's erroneous assumptions are actually confirmed.
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.