I think the lesson was designed so that this was just obvious enough for people to realize it themselves as the demonstration progressed.

Also, when done well, the teacher acts the part of the manager who keeps pushing people even as this realization spreads throughout the group.

The meta-lesson is something that Deming emphasized over and over: Don't rate your workers based on the outcome of a random number generator.

Exactly, but that's out-of-story knowledge. Presumably in-story, the "red beads" means something else which we don't have intuition about - downtime incidents, number of broken widgets produced, part yield...

If those (in-story) managers had a basic statistics knowledge, they would have said: "Wait! The variance is too high, you cannot make any decisions based on 2-4 points". Then they'd do some statistical tests (or at least plot points with error bars and eyeball it), and realize that the numbers given are random noise and are not actually related to individual performance.

But those managers apparently flunked their stat, or they forgot it all, so innocent people got fired, and project got cancelled.

A sad story about why math is important even if you are not in STEM directly.

The workers control the paddle and the scooping of the beads.

A smart worker will eyeball their draw for red and redraw a few times until they get a good draw.

There may be other ways to flick off red beads by tilting and tapping.

None of this is excluded behaviour at least in this article.

Figuring out that the numbers are pure luck is the only important thing here.

Yeah, but anybody with statistical knowledge might have been able to guess that this is a random process and that not evetything is down to individual performance.

The point of the thought experiment is to make us think of what the system contributes to team/individual performance. In reality every procedd might have a random component, but it might also have a feedback component — e.g. you give a project with many red beats to a team that did well before only to have them (to us: predictably) underperform, then you give it to another team etc.

The lesson here is to understand this underperformance doesn't necessarily mean they got worse, it just means they got the harder project to pull off and other teams might have underperformed even more.

If you as a manager focus on the totally fictional underperformance of one team vs the other you optimize things that had no bearing on the outcome. In fact you will make things worse as you make yourself believe the (in reality worse) team that only handled red-bead-free projects before will perform better.