Lean Six Sigma and Psychological Safety: The Human Side of CI
Organisations that invest heavily in Lean Six Sigma training often discover, a few years in, that the tools are not producing the results they expected. Green Belts and Black Belts have been certified, DMAIC projects completed, yet defect rates have not moved materially and the improvement pipeline has run dry. The diagnosis, when it comes, is rarely about the tools. It is almost always about the culture — specifically, whether the culture makes it safe to surface problems, report failures, and challenge how things have always been done.
What psychological safety is — and is not
Harvard Business School professor Amy Edmondson developed the concept after her research on medical teams produced a counterintuitive finding: the best-performing teams reported more errors, not fewer. The reason was not that high performers made more mistakes — it was that they felt safe enough to acknowledge and discuss them. Edmondson defined psychological safety as the shared belief that the team is safe for interpersonal risk-taking: one can speak up, propose unorthodox ideas, or admit uncertainty without fear of humiliation or punishment. It is important to be clear about what it is not: not comfort, not niceness, not the absence of conflict. Psychological safety is the precondition for productive disagreement, not a substitute for it.
Why psychological safety is essential for CI
Continuous improvement depends, at every stage, on people being willing to surface uncomfortable information. In the Analyse phase, root cause analysis only works if real causes — which often include management decisions and organisational constraints — can be named without career consequence. In a psychologically unsafe culture, problems are reported only after they become crises, defects are reworked quietly rather than escalated, and the Five Whys stops at two or three because the fourth why points at someone with power.
Building psychological safety as a CI leader
Model the behaviour yourself. When you say "I was wrong about that" in front of the team, you set a norm that being wrong is survivable. Admitting uncertainty demonstrates that intellectual honesty is valued here.
Respond constructively to bad news. The single most powerful determinant of whether people bring you problems is what happened the last time someone brought you one. The response must be curiosity, not anger: "Tell me more about how this happened" rather than blame.
Separate the problem from the person. LSS is explicit about this: most defects are caused by process failure, not individual failure. The Ishikawa diagram and the Five Whys are both designed to surface systemic causes. When root cause analysis drifts toward individual blame, redirect it: what condition allowed this error to occur, and what would have to change?
Use humble inquiry. Edgar Schein described humble inquiry as drawing someone out by asking questions to which you do not already know the answer. The workers closest to the process usually know the real causes; your job is to create the conditions in which they will share that knowledge.
The Scrum Master faces the same challenge
A Scrum Master trying to run a productive Sprint Retrospective faces exactly the same problem: team members will not surface real impediments or process failures if they believe the information will be used against them. The Retrospective becomes a positive-feedback session rather than an honest assessment of what needs to change. Both roles — the Scrum Master and the CI practitioner — depend on creating a climate where the truth can be spoken without the speaker paying a personal cost for speaking it. The tools are different; the human challenge is the same.
If your improvement initiatives are producing projects on paper but not the results you expected in practice, XNM's strategic advisory services can help you assess whether a culture gap — not a methodology gap — is limiting your continuous improvement programme.