This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I was talking to a teammate about how you deal with the "not recognizing one's own incompetence" problem. If someone thinks everything is fine, how do you get them to agree to try a better way. I've tried modeling the better way, but have difficulty getting the person to try it in certain circumstances. For example, "my" way of finding/opening a certain document is three steps. A (different) teammate takes 7 steps to do the same thing. Both work. But over the course of a day, we look up these documents many, many times. Which means my teammate is easily wasting 15 minutes a day on this. It doesn't sound like much, but it adds up. I've tried to get him to try it in front of me. But then he goes back to the old way.
Well, maybe the 15 minutes a day adds up but not to much. I've spent longer than that dealing with pointless memos from hyperactive micromanagers on some projects. If this guy is delivering his fair share of work and is happy to open files his way then who cares? Maybe it's not a question of recognising one's own incompetence, but recognising when not to sweat the small stuff? As for me, most days bring me plenty of reminders of my own incompetence in one way or another!
This is an interesting (though not uncommon) issue which needs to be handled tactfully.
Now, I'm not a management person () but what I do is:
When we find that somebody else's methods need to be modified, as those methods are not optimum (in terms of resource, simplicity etc.), it is not very helpful to tell them that their methods do no work. In almost all of the cases, it doesn't work (except the other person has good level of trust in you - which quite frankly is not very common at workplaces ).
What I do is: try and ask them how 'my' methods can be improved and how they are doing that particular task. They will (or will not) tell you what is 'missing' in your methods, but in almost all the cases, they are going to realize that 'my' method is better that 'their' method, and they proactively take necessary measurements (they might even end up asking you about how to improve the workflow).
Of course, these things ought to be done on case to case basis, but personally I think this kind of 'indirect' approach works better than direct one (i.e. telling them that their methods are not efficient and all).
So, it sounds like the issue isn't the 15 minutes to open documents, but that this guy basically isn't up to the job right now, for whatever reason? That sounds like a more general and hardly unusual management problem. Obviously your situation is specific, but - for example - this guy could be under-performing because of "incompetence", lack of appropriate training/support, poor integration into the team, personal issues outside work (family illness, relationship breakdown, substance-abuse, depression etc), unhappiness with the job/employer/working conditions, and so on. All the usual stuff in other words. So I wonder if getting too focused the "Dunning-Kruger effect" might just be a distraction here?
author & internet detective
Jeanne Boyarsky wrote:"not recognizing one's own incompetence" problem.
I would expect that most folks can not recognize their own incompetence. I think its part of human nature, just as most people think they they are better than average drivers. All of our children are smarter than average.
Since I'm retired, I wasn't part of the effort, but I know a lot of folks who work at the two major software consulting houses that worked on healthcare.gov. While the press has been claiming that all of them are grossly incompetent, most of the blame does not belong on the consultants' heads. The people managing the overall project had never seen a project of this scope or complexity. They didn't start to have the contractors try to do integration tests until less than a month before it was to go live.
Even greenhorns here on the Ranch know that a big system needs serious testing. The old pros know that you need as much testing time as you allow for development. So allowing a month or so is highly optimistic, to be diplomatic.
1.you 3 times and other guy 7 times. is not 7 times are better?;breaking in to pieces-->morden approach ;-)
2.you both IQs are little bit below than average. because either that guy should know how to pickup or you should know how to teach.
3.he may be a numerologist(check with him...); most of the product *version 7 will be popular*. check history
4.from same link =>
Studies on the Dunning–Kruger effect tend to focus on American test subjects. A study on some East Asian subjects suggested that something like the opposite of the Dunning–Kruger effect may operate on self-assessment and motivation to improve. East Asians tend to underestimate their abilities, and see underachievement as a chance to improve themselves and get along with others.
Duh...guess I'm not competent to respond here, eh? But that's never stopped me before (Dunning-Kruger strikes again?).
Got to say that I struggle to see the relevance of the "DK effect" to my working life. In any case, on a purely human level, we'd probably never get out of bed in the morning if we had a truly objective understanding of our limited abilities to cope with all the potential pitfalls in the world outside. Humans are feeble apes with tiny teeth, no claws, no fur to protect them, and they can scarcely outrun a chicken, yet they have taken over the world: maybe DK is just an evolutionary defence mechanism to let us get on with daily life and try new things: "Making fire? I dunno, but how hard can it be, right?"
Even within the familiar and relatively benign IT world, things are complicated. On the one hand, most of us are college grads, above-average intelligence, perhaps accustomed to being very good at some things, and no doubt vulnerable to being a little too pleased with ourselves on occasion. Obviously we are susceptible to over-estimating our abilities or our understanding of complex problems some of the time e.g. the classic developer's tendency to under-estimate how much work is really involved in solving some problems.
On the other hand, I don't know about you, but much of my working life consists of failure, and being reminded of my own limitations. Think about TDD - test, fail, code, test, fail, code, test, pass, re-factor, test, fail, code, test, fail... Hard to remain convinced of your own infallibility when you only see working code for a few moments each working day before it's taken away for delivery or you break it again! And one of the best pieces of advice I've seen for working in this industry is to make sure you always work with people who are smarter than you are, which is obviously going to bring you down to earth with a bump if you start getting inflated ideas of your own skill.
True, we're all human and thus incapable of judging our own competencies objectively. But that applies to everybody else as well: Am I under-performing because of my "incompetence" or that of my managers? Here in the UK - and I suspect in the USA - we tend to blame the individual "incompetent" worker rather than their manager or the wider working environment, but when I worked in Germany, an under-performing worker was usually seen as evidence that their manager was also failing to help them deliver their work properly. Same problem, different perspective. And then you have wider cultural variations in assessing your own or other people's competence, like those raised in the posts above. What do we do if our incompetence includes the inability to judge competence in other people as well?
My own experience is that most people I work with are good at some things, not so good at others, but I've rarely worked with anybody I'd describe as truly "incompetent" (well, one or two maybe...). Hopefully most of my colleagues feel the same way about me. So it's not really a question of "incompetence", but varying levels, measures and interpretations of what constitutes competence in a particular context. And in a complex and dynamic environment like the average IT project, how easy is it really to pick apart an individual person's specific competencies and assess them objectively, beyond the relatively trivial example of some guy who's a bit slow opening files? One reason recruitment is such a nightmare is that people still seem to have very little understanding of how to measure or predict competence in a given role.
If an individual is under-performing in a particular role, there are so many possible reasons for - and potential responses to - this situation that a narrow focus on a concept like the "DK effect" seems kind of inadequate and probably irrelevant. To my mind this is just too complex an issue to try to address in these terms. But what do I know, right?
I kinda agree that it may be irrelevant. The Dunning-Kruger effect basically states that the candidate is unable to recognize incompetence -- in fact, the effect states that the candidate is very confident of his/her competence (and the correctness).
So, if it is the Dunning-Kruger effect, then trying to fix it is futile. If you have to try to fix it, meaning convince the candidate that he/she is wrong, you have to assume that it is not the effect.
In other words, I find the Dunning-Kruger effect as just a way to give up on someone (or on the point itself). I am pretty sure that I have been in debates that may have been the Dunning-Kruger effect, and hence, futile... but it could also be that I was tired of the debate, and declared it as futile.
I wonder if whole organizations go through DK effect. Obviously if an organization is successful, it might think that the methods used to run the org are the best, even though they might be suboptimal.
author & internet detective
Jayesh A Lalwani wrote:I wonder if whole organizations go through DK effect. Obviously if an organization is successful, it might think that the methods used to run the org are the best, even though they might be suboptimal.
I like that thought. Especially since almost nothing is optimal. That's why the top levels of CMMi and the like are about continuous improvement.