Debiasing techniques
Bias resists willpower, so the working fixes change the process rather than the person.
Debiasing is any deliberate attempt to reduce systematic error in judgement. Awareness alone does almost nothing. What holds up is procedural: structure the decision, force consideration of the alternative, use outside data, and separate judgement from discussion so errors do not correlate.
How it shows up in software
Debiasing in product work is the premortem before a launch, the estimate made from past similar projects instead of from the plan, the written opinion submitted before the meeting, and the decision log that records the prediction so it can be checked. The tooling is unglamorous and the discipline is what fails, not the method.
Using it well
- Collect independent written judgements before any group discussion, so the first loud opinion does not set the anchor.
- Run a premortem on anything expensive: assume it failed, and have everyone write why, before anyone speaks.
- Forecast from a reference class. Find five comparable past projects and start from what they actually took, then adjust.
- Log the decision, the prediction and the reasoning with a review date, and go back on that date whether or not anyone asks.
Where it turns manipulative
- Debiasing language used to dismiss a colleague's argument, by naming a bias instead of answering the point, is rhetoric dressed as rigour.
- Running the ritual without the consequence, such as a premortem whose risks never reach the plan, produces false confidence that the decision was examined.
- Applying debiasing to the team's judgement while exempting the executive who set the direction makes the process theatre and teaches people not to bother.
Where you have seen it
Amazon six-page narrative memos
Meetings open with silent reading of a written argument, which forces the case to be complete before discussion anchors it.
Google and others' postmortem practice
Blameless written postmortems with action items and owners, which turn an outcome into reference data for the next decision.
GitLab public decision records
Decisions and their reasoning are written down in the handbook, so a later reader can check what was predicted against what happened.
What the research says
- Morewedge et al., 2015 (Policy Insights from the Behavioral and Brain Sciences)Mixed evidence
A single training intervention, delivered as a game with personalised feedback, reduced confirmation bias, anchoring: The first number you see shapes every judgement that follows. and fundamental attribution error, with reductions still present at eight weeks.
Measured on decision vignettes rather than real consequential decisions. Transfer to the workplace is the open question.
- Klein, 2007 (Harvard Business Review) on the premortemMixed evidence
Prospective hindsight, imagining the project has already failed and explaining why, generated more and more specific reasons for failure than standard risk discussion.
Builds on Mitchell, Russo and Pennington (1989). Practitioner-popular and lightly evidenced, but cheap enough that the cost of being wrong is low.
- Flyvbjerg, 2006 and Lovallo and Kahneman, 2003 on reference class forecastingWell evidenced
Forecasts built from the distribution of outcomes in comparable past projects were substantially more accurate than forecasts built from the details of the current plan.
Strongest in large infrastructure where outcome data exists. It requires a real reference class, which many product decisions do not have.
Grades are a judgement about the evidence, not about how useful the idea is. Plenty of contested effects are still worth knowing, as long as you do not cite them as settled.