The retrospective becomes a blame session. How should I run it?
Unsafe and unproductive learning reviewFocus discussion on observable events, decision context, system conditions, and improvements within the team's influence. Use a neutral facilitator when needed and keep individual performance or misconduct processes separate. Psychological safety does not mean ignoring serious concerns; it means handling them through the proper process.
What to do now
- Establish a constructive evidence-based review scope
- Collect events and perspectives without personal attacks
- Select practical improvements and owners
- Route separate conduct concerns appropriately
When to escalate
The discussion becomes harmful or raises a concern requiring a formal process.
The sponsor and accepting business or service owner
Example
The team examines why review capacity was missing instead of blaming the person who waited for approval.
Mistake to avoid
Using the retrospective to publicly rank who caused the most problems.
Prevent a repeat
Verify that transferred obligations and important lesson actions are completed after the project closes.
Suggested ApprovedFlow setup
- Projects
- Documents
- Tasks
- Approvals
Keep the closure decision and final evidence with the project and transfer accepted residual actions to named ongoing owners. See the platform
Related cases
- The receiving team says knowledge transfer happened too quickly. What now?Unverified handover learning
- Our closure report hides major problems because the project eventually delivered. What should it say?Misleading retrospective reporting
- A risk we recorded has now happened. What changes?Risk becoming an issue
- The database migration has no rollback plan. Can we proceed?Unsafe migration readiness