🎯 Quick Answer

What: Lean Six Sigma mentoring is the practice of putting an experienced practitioner alongside a newly trained one for their first real project, so that judgment calls get made with support rather than alone.

Why it matters: Training reliably transfers knowledge. It does not transfer judgment, and judgment is what the first project actually demands. This is why organizations routinely train large numbers of people and finish very few projects.

How to apply: Name a mentor for every practitioner before their first project starts. Protect a short recurring slot, twenty minutes a week is enough. The mentor's job is not to teach the toolkit but to answer four or five judgment questions a month.

The payoff: Projects finish. The practitioner develops a reference for what "good enough" looks like, which is the thing they will use on every project afterwards, without help.

The training was good. That is what makes this worth writing down.

Twelve people sat through five days of it. Real instructor, real exercises, real data. At the end they could all build a process map, run a capability study, and explain why a mean without a spread tells you almost nothing. I have seen their tests. They were not guessing.

Eleven months later, one project had finished.

The wrong conclusion

The easy read is that the training failed. It is also the wrong one, and it is worth being precise about why, because the wrong diagnosis leads to a very expensive response: buying better training.

Ask any of those twelve what a control chart is and you will still get a clean answer. Ask them to explain the difference between common cause and special cause variation and they will explain it. The knowledge was there and it stayed there. If the failure had been a knowledge failure, it would have shown up as people doing the wrong thing. Instead it showed up as people doing nothing, for a long time, and then quietly returning to how they worked before.

That is not what forgetting looks like. That is what being stuck looks like.

Where it actually breaks

The gap opens somewhere a course cannot reach. It is the first Tuesday morning back at the desk, holding a real problem that resembles none of the exercises, with a manager who wants an update by Thursday.

At that moment the question is never "what is this tool." Nobody is stuck on the definition. The question is "is this the moment for it," and it has a dozen variants, all of them uncomfortable:

Is the data good enough to stop collecting, or am I stopping because I am tired of collecting it? Is this the real cause or the convenient one? Is my analysis finished, or merely tidy? This cause sits in another department and I am two levels junior to it, so what exactly am I supposed to do on Monday? Is the thing in front of me a project at all, or just a bad week that will pass?

Those are judgment calls. Each has no correct answer, only a defensible one. And a person facing their first will almost always resolve it the same way, which is to wait, gather a little more data they do not need, and hope the ambiguity resolves itself.

Three weeks pass. Then another three.

What a mentor is actually for

This is the part that gets consistently misunderstood, including by people who agree with the principle. A mentor is assumed to be a teacher: a more knowledgeable person who explains the harder parts of the method.

In the cases I have watched work, that is not what happens at all.

The most effective mentoring relationship I have seen involved a retired process engineer who had never used the toolkit the practitioner had been trained on, and said so in the first week. The engineer taught them nothing. What the engineer did was sit with them for twenty minutes every Wednesday morning and answer four or five questions a month, always of the same shape. Is this enough. Should I stop here. Is this the real cause. Do I take this to the sponsor now or wait.

That is not supplying knowledge. It is supplying calibration, and something rarer: a person it is safe to be uncertain in front of.

That second part is doing more work than it appears to. The reason a trained practitioner sits on a question for three weeks is almost never that they cannot find the answer. It is that the only people senior enough to answer are the same people they are about to present to, and asking looks like admitting they should already know. So the question stays unasked and the project stays open.

A mentor is somebody outside that dynamic. That is most of the value, and it costs almost nothing to provide.

Why organizations fund the wrong half

Nobody decides against mentoring. It simply never becomes a line.

Training produces a certificate. A certificate is countable, it arrives on a predictable date, and it can be reported upward as a number that went up. Lean Six Sigma mentoring produces nothing countable for months, and what it eventually produces is a finished project that will be attributed to the practitioner rather than to the ninety minutes a month that made it possible.

So the budget goes where the evidence is legible. The organization trains forty people, reports forty trained people, and eleven months later cannot explain why the improvement program feels like it stalled.

It stalled in the specific, narrow, unglamorous place where a person needed to ask somebody whether their analysis was finished, and there was nobody in that role. Not because the organization refused. Because it never occurred to anyone that it was a role.

What to do instead

The intervention is smaller than the problem suggests.

Name a mentor before the first project starts, not after it stalls. Choose somebody who has finished projects, not necessarily somebody who scored highest in the training; experience of having been wrong is more useful here than mastery. Protect a short recurring slot and let it be genuinely short, because twenty minutes forces the practitioner to bring the question that actually matters. Make clear to both parties that the mentor's job is judgment, not instruction, or the sessions will drift into re-teaching the toolkit and waste everyone's time.

And measure the program on finished projects rather than trained people. The moment that changes, the case for Lean Six Sigma mentoring makes itself, because the two numbers stop agreeing with each other and somebody has to explain the gap.

I write one of these every week, drawn from what actually happens on projects rather than what the methodology says should. You can join the newsletter here.

Frequently asked questions

What is the difference between coaching and mentoring in Lean Six Sigma?

Coaching in this context usually means structured support on the method itself: how to run the tool, how to read the output. Mentoring is broader and more judgment-led. A mentor helps decide whether the analysis is finished, whether a cause is worth pursuing, and how to handle the organizational parts of the work that the method does not cover.

How much lean six sigma mentoring does a practitioner actually need?

Less than most people assume. Across the cases worth learning from, the pattern is roughly twenty minutes a week during a first project, handling four or five real questions a month. The value is in the availability rather than the volume. The point is that a question never waits three weeks for want of somebody to ask.

Who makes a good mentor?

Somebody who has finished improvement projects and remembers getting things wrong. Deep expertise in the specific tool is helpful but not essential; the questions a practitioner is stuck on are usually about sufficiency and sequencing rather than technique. Seniority matters less than being outside the reporting line the practitioner is nervous about.

Does this apply if my team already has strong technical people?

Often more so. Technically strong practitioners tend to be the ones least willing to ask whether their work is finished, because the question feels like it reflects on their competence. They will over-analyze rather than ask. A mentor gives that instinct somewhere safe to go.