i

Description

La navette spatiale Challenger transportée sur son chenillard vers la rampe de lancement, au milieu des marais de Floride.

Source

NASA · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

The manager's Dunning-Kruger

The farther we move from hands-on practice, the more we think we understand what we now only see from afar, and the less anyone dares to say so.

In brief

• What: a leader who used to be a strong technician now judges technical choices with a confidence their current practice no longer justifies.
• Why: technical skill expires, confidence does not; hierarchy cuts off the feedback that would make this visible.
• Detect: firm decisions made without experts, “by-eye” estimates, vocabulary from ten years ago, team objections that fade away.
• Avoid: separate “deciding” from “judging the technical side,” ask for reasoning rather than opinions, define your own competence boundaries, and invite contradiction.

On this page

1. Definition
2. The mechanism
3. Where you encounter it
   1. In project management
   2. In management
4. Well-known cases
   1. The day before the Challenger launch: “take off your engineer hat” January 27-28, 1986
   2. Why lower-competence people do not see it, and what helps 1999-2008
5. Detection Signals
6. Avoidance Reflexes
7. With AI: detect, fix, soften
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to integrate into your practices
   5. How to integrate them
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Illustration inspired by the person

Fictitious illustration

The manager's Dunning-Kruger is not a distinct bias in the strict sense: it is the intersection of an established phenomenon, overestimating your competence where you have little (see the Dunning-Kruger page), with a very common organizational situation: a leader judging a domain they no longer practice.

The typical case is an excellent developer who became a team lead, then a director. They have technical legitimacy, good instincts, real experience. But that experience is dated: the platform, tools, practices, and constraints have changed. They keep making calls with the confidence of the era when they were the specialist.

This should be distinguished from two nearby situations: the generalist manager who knows what they do not know (a healthy situation), and the manager who never practiced the domain (then the bias is classic Dunning-Kruger). Here, the issue is obsolescence.

The mechanism#

Kruger and Dunning (1999) proposed that, in a given domain, the skills needed to perform well are the same ones needed to evaluate performance: those who lack them judge poorly, including their own judgment. For managers, three additional factors apply.

• Competence expires; confidence does not. Technical knowledge has a shelf life: versions, tools, deployment practices, and security practices evolve. The memory of “how it works” remains, along with its certainty; what disappears is updating. You do not perceive what you have stopped learning.
• Feedback disappears when practice disappears. A developer sees their code fail tests; a manager sees summaries. A manager's technical judgment errors show up months later, under different names (delay, debt, incident), with no visible link to the original decision. Kahneman and Klein (2009) remind us that expert intuition is reliable only in a regular environment with rapid feedback; the manager role lacks that.
• Hierarchy silences correction. Contradicting your boss is costly, so people provide answers that confirm them. They infer they were right. Authority and the halo effect (“they used to be excellent, so they still are”) close the loop.

Where you encounter it#

In project management#

• Architecture trade-off: the technical director imposes a solution they mastered ten years ago (“we've always done it this way”), without reading recent team feedback on its current limits.
• “By-eye” estimate: “it's just one field to add, two days.” The estimator has forgotten tests, data migrations, security review, deployment—everything that, in their former practice, was done by others or did not exist.
• Technical debt review: the issue is labeled “developer comfort” because the manager no longer perceives the cost of what they do not experience daily anymore.
• Tool or vendor choice: judged from a demo, by someone who no longer has the eye to distinguish what is solid from what is presentable.
• Drive-by code or design review: a categorical one-line comment that redirects a multi-week workstream.

In management#

• Evaluating an expert's performance: speed and reliability are judged based on what one understands of their work—meaning visible deliverables, not the actual difficulty of what they handle.
• Technical hiring: obsolete interview questions, or selecting reassuring candidates because they speak familiar language.
• Promoting the expert to manager: they keep the habit of making technical calls alone, as a reflex from former responsibilities.
• Scoping a goal: a deadline or scope set “because it's feasible” by someone who no longer has current orders of magnitude.

Well-known cases#

Detection Signals#

• Technical choices are settled in committee, without hearing from the people who actually do the work, or after they have spoken.
• “That can't be very complicated” or “back in my day, we did that in one day.”
• Responses to experts' objections are appeals to authority (“I know this stuff”), not reasons.
• Experts stop making proposals, and technical discussions happen before and after the meeting, not during it.
• The manager's vocabulary and examples come from an outdated technology or era.
• The manager's estimates are systematically shorter than the team's, and the gap is never tested.
• There has not been a recognized error on a technical topic for a long time: that is not a sign of accuracy, but of missing feedback.

Avoidance Reflexes#

1. Separate deciding from judging. The manager decides priorities, costs, and acceptable risks; experts judge feasibility and technical soundness. Saying out loud who decides what prevents one role's authority from spilling over into another role's domain.
2. Ask for reasons, not opinions. “What makes you think this won't hold up? What data? What would we need to see for you to change your mind?” You can assess an argument without having to assess the technical topic itself.
3. Map your own scope. For each domain, note honestly: “practiced this year,” “followed closely,” “known in the past,” “never practiced.” The label “known in the past” means you cannot decide alone.
4. Assign a challenger. Give someone the role of devil's advocate on technical decisions, with an explicit guarantee that they will face no consequences (see The Bandwagon Effect (Trend Effect), which works in the opposite direction).
5. Speak last. When the topic is technical, the manager gives their opinion after the experts, not before: speaking first anchors responses.
6. Maintain real hands-on practice. A half-day per week reading code, doing support, or acceptance testing; participating in an incident; carrying a small technical topic through to completion. The goal is not to become an expert again, but to keep criteria current and maintain direct feedback.
7. Measure your own judgments. Record the forecast (“I think this will be delivered in three weeks”) and compare with the outcome in a decision log. Calibration errors finally become visible.
8. Run a pre-mortem. Before a high-impact technical decision, ask the team to imagine it failed and explain why: this legitimizes criticism without making it personal.

With AI: detect, fix, soften#

Prompts to integrate into your practices#

1. What has changed since my practice. Use before making a decision in a domain you no longer practice.

I practiced [technology / domain] until [year], and I need to make a decision on [topic] today.
1. List what has changed since that date that could make my instincts obsolete (tools, practices, risks, constraints).
2. Tell me what I probably still believe that is likely false or incomplete.
3. Give me the ten most useful questions to ask my team, phrased so I can understand without putting them on the spot.
State what you are sure about and what needs verification; do not invent any references.

2. Devil's advocate on a technical decision. Use before deciding, with your decision and your reasons.

I am about to decide: [decision]. My reasons: [reasons].
Play a current technical expert who disagrees with me.
Give the three most serious objections, the signals that would prove I am wrong, and what my team might hesitate to tell me.
Do not try to reassure me, and point out if my reasons rely on outdated experience.

How to integrate them#

• Before the meeting: prompt 1 prepares questions; you ask them, you do not let it decide for you.
• Before deciding: prompt 2, then a real discussion with the people involved; AI prepares the dialogue.
• In review: record your forecasts in the decision log and review them quarterly.

Precautions#

• AI can confirm what you already believe if your question assumes it: describe facts, not your conclusion.
• Its technical explanations are plausible but sometimes wrong; verify with people who actually practice before acting.
• Do not paste code, customer data, or confidential information into an unauthorized tool.
• It must never be used to bypass experts, or to justify after the fact a decision already made.

Limits#

• The Dunning-Kruger effect itself is debated: part of the observed curve may be explained by statistical artifacts (Gignac and Zajenkowski, 2020), and the original study focuses on lab tasks.
• Applying it to managers is a reasonable hypothesis, not a result established by measurements on managers. The table above describes a risk, not a law.
• A manager can retain excellent technical judgment for a long time (continuous training, residual practice, deep experience). Seniority is not a flaw; lack of updates and feedback is.
• The opposite also exists: the manager who doubts themselves too much, abdicates, and leaves experts without arbitration. The goal is calibrated judgment, not distrust.

Sources and verification#

• Kruger & Dunning (1999), “Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments,” Journal of Personality and Social Psychology
• Ehrlinger, Johnson, Banner, Dunning & Kruger (2008), “Why the unskilled are unaware: Further explorations of (absent) self-insight among the incompetent,” Organizational Behavior and Human Decision Processes
• Gignac & Zajenkowski (2020), “The Dunning-Kruger effect is (mostly) a statistical artefact: Valid approaches to testing the hypothesis with individual differences data,” Intelligence
• Kahneman & Klein (2009), “Conditions for intuitive expertise: A failure to disagree,” American Psychologist
• Rogers Commission (1986), Report of the Presidential Commission on the Space Shuttle Challenger Accident, NASA — chapter V, “The Contributing Cause of the Accident.”
• Vaughan (1996), The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, University of Chicago Press.
• Peter & Hull (1969), The Peter Principle, William Morrow — for the related concept of promotion beyond one's competence.

See also#