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.

Dunner writes,

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.

Bank robbers who squirt lemon juice on their faces thinking that it will hide them from security cameras are too stupid to recognize that they shouldn't be a bank robber.

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 – (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:

  1. Having helped build the application from scratch, project managers are blind to their own product’s complexity.
  2. Because they are rarely immersed in actual user environments, project managers are unaware of the user’s knowledge level.
  3. 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.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

  • comma hater

    If the question is the perennial why doesn’t the documentation get respect and needed internal support, the answer is that you’re looking in the wrong place.

    My take is simple: documentation is a supporting product on its own. It should be managed closer to customer support services rather than as a piece of the software. It does straddle the line that divides the product from the support, so it will always occupy some murky area.

    It took me working at a large enough organization that has a dedicated support, engineering, & dedicated PLM group to realize this. The problem is that we usually feel most comfortable in the engineering group, but it’s where we get the least support; documentation is a formality to engineering.

    So either get an advocate in PLM/marketing who considers the documentation as a product with equal importance as the software (never gonna happen), or embed yourself with customer service where your work will relieve the or 1800support line from the same question 1000 times. Do that and you will instantly prove your work’s value.

  • Helen Abbott

    Tom, this post is spot-on. It reminded me of another of your posts (my favorite) — on the “unknown unknown”.

  • TOny Chung

    Technical Writers can also suffer this effect, Tom. It’s not limited to PMs. I’ve met and worked with TWs too overconfident in their abilities that they also never consulted the user to learn what they really need.

  • Mike Starr

    I have a tendency to take a much less direct approach to showing the project manager’s writing weakness… I reorganize and rewrite their stuff and show them the difference but don’t attempt to rub their nose in it. When they review what I’ve done, the sun begins to break over the horizon and they begin to perceive the true value that a professional technical writer can bring to the project.

  • Glenn Lea

    Thanks Tom for pointing out this concept. Lots of applications of this inate ability in human behaviouir – the unknown unknowns. Incidently, I also learned through reading your blog and linked articles that yes, there is indeed an English word for the German word “schadenfreude” – “Epicaricacy (n. – taking pleasure in others’ misfortune).

    • Tom Johnson

      Glenn, I enjoyed reading your post on the unknown unknowns. You should write more frequently — I enjoy reading your thoughts. Thanks for the tip on word schadenfreude. My colleague actually used that in a post the other week and I was too lazy to look it up.

  • Glenn Lea

    Hi Tom, thanks, especially the encouragement to write more. I have lots of ideas bouncing around in my head, especially about usability and human factors. Need to put fingers to Qwerty more often. That will free up some more neurons for other cognition. PS, sorry to hear about the cat. Life’s experience can always give us lessons for our professional lives.