Anti-bias toolbox

Knowing a bias exists almost never protects you; changing the procedure does. Eight lists to print or copy.

≈ 4 min readReading

In brief

Eight moments of work, each with five or six concrete actions.
Each action points to the bias it counters and, where relevant, to the detailed method.
Printable: tick the boxes in kick-off, review or decision meetings.

On this page

Before estimating
Before a go / no-go or a decision to continue
Demo, proof of concept, choosing a vendor
In committee, design review, meetings
To hire or evaluate a person
To design, document, choose a component
To understand the client's need
After an incident or a failure
With AI

The entries explain each bias; this page gathers what you do at the right moment. The idea is to turn avoidance reflexes into procedural habits: we don't count on everyone's vigilance, we change the way we decide. The three most versatile methods have their own entries: the pre-mortem, reference class forecasting and the devil's advocate.

Before estimating#

Write down your own estimate before hearing a figure, a budget envelope or a desired date (anchoring).
Estimate as a range (best case, likely, worst case), never as a single point (planning fallacy).
Find three to five comparable projects and look at their actual variances (reference class).
List what delayed the last projects and build it into the plan (optimism bias).
Don't revise the estimate downward because you know Hofstadter's law: plan for tracking and re-estimation points (Hofstadter's law).

Before a go / no-go or a decision to continue#

Compare only future costs and benefits: what has already been spent will not come back (sunk costs).
Have set stopping criteria and validation milestones from the start (escalation of commitment).
Run a pre-mortem: “the project has failed; why?”.
Have someone decide who did not commit the spending or defend the project.
Ask yourself: “if we were starting from scratch today, would we make this choice?” (status quo bias, loss aversion).
Put a figure on the cost of inaction just as on that of change (omission bias).

Demo, proof of concept, choosing a vendor#

Have the test cases chosen by a third party, without disclosing them in advance (wishful thinking, confirmation bias).
Require an independent second opinion before the file goes up the chain (authority bias).
Distinguish what was seen from what was said; ask what would make the solution fail.
Be wary of novelty for its own sake: what precise problem does it solve (pro-innovation bias)?
Set an expert's opinion against a quantified basis of comparison (expert bias).

In committee, design review, meetings#

Collect written opinions before the discussion (groupthink, bandwagon effect).
The decision-maker or the most senior person speaks last.
Appoint a devil's advocate and give them time to argue.
Name one person responsible for each action: “someone will take care of it” is not enough (bystander effect).
Make individual contributions identifiable (social loafing).
Check the consensus: ask everyone for their position, don't assume agreement (false consensus).

To hire or evaluate a person#

Write the criteria before seeing the candidates or the results (halo effect).
Use a structured interview: same questions, notes by criterion, before the discussion (primacy effect, similarity bias).
Record facts over time so as not to retain only the latest months (recency effect).
Rate each person against the criteria, not against the one before (contrast effect).
Look first for an explanation in the context before a character trait (fundamental attribution error).
Cross-check two indicators that pull against each other (Goodhart's law); watch your expectations (Pygmalion effect).

To design, document, choose a component#

Have the documentation reviewed by someone new to the subject (curse of knowledge).
Compare the options on criteria set in advance, including solutions from outside (“not invented here”).
Have the code or architecture reviewed by someone who did not write it (IKEA effect).
Ask: “what is the simplest solution that works?” (over-engineering).
Ask whether the tool you master is the right one, not just the familiar one (law of the instrument, functional fixedness).

To understand the client's need#

Start from the problem before the solution; ask open questions (need confirmation bias).
Observe the actual work rather than relying on how people describe it.
Challenge the scope already specified: does it hold because of its value or because of past effort (endowment effect)?
Set shared end-to-end objectives, not just per team (local optimization).
Deal with uncertainty explicitly rather than choosing what you know (ambiguity aversion).

After an incident or a failure#

Reconstruct what we knew at the time, not what we know now (hindsight bias).
Look for causes without looking for a culprit; don't credit yourself with successes and blame circumstances (self-serving bias).
Look at the silent failures too, not only the visible successes (survivorship bias).
Relate the incident to its real frequency, not its visibility (availability heuristic).
Test backups and recoveries before you need them (normalcy bias).

With AI#

Each entry contains ready-to-use prompts to detect, remedy or mitigate a bias. Two rules for everyone: explicitly ask for the opposing view (AI tends to approve what you already think), and never entrust it alone with checking its own work. The page on the AI learning curve explains why.