This experiment is something he did in classes etc so people could _experience_ the obvious idiocy in trying to manage individuals for system behaviour. His point is that ALL actual work is also dominated by system behaviour, just more subtly, and managers must focus on the systems and not worker performance.
> His point is that ALL actual work is also *dominated* by system behaviour
If that's his point, it seems obviously wrong. Some work, like in the experiment is dominated by system behavior. For others, system would play a much smaller role. For example, 2 people cranking code in a startup. No matter what system you apply, if they are not good programmers, nothing of value will come out.
Something will most certainly come out. You're just not defining the system. If I define the system as "one programmer is responsible for looking at the desired product and writing specifications" and the other programmer is to translate specification into programming code, and never shall one do the other's job, I assure you, the best programmers in the world will produce shit over time.
Randomly swap in two new actors with different life experiences into the same spots to do the same work, and you'll still get shit. If in the unlikely event, you get amazing work, it's not that the people doing it were special; it's just anothe outlier in the data stream. Add in the emotional toll of working as hard as possible to succeed but never being able to meet prescribed quality levels?
A system is perfectly tuned to produce the results it does. Want different results? Change the system. That is Deming's point. We have a tendency to blame variance in a system on the human actors immediately proximal, instead of paying attention to the actual significant constraints. This is an important lesson to management types, as they are to process/system what a programmer is to a computer.
The planners cast the dice for downstream long before downstream can do anything about it, and in many corporate setups, top down works just fine, but bottom up never gets any attention.
That's also missing the point somewhat. Put the best two programmers in the world in a shitty system that rewards them for the wrong things and they will produce garbage. Put mediocre programmers in a fantastic system that brings out the best in their collaboration and you might actually get to market sooner and better than the other group.
To extend your example: make those two programmers maintain 100% unit test coverage, document all decisions in Jira/Confluence, raise change requests and issue change freezes for stability, and you'll have enterprise velocity and stability. Allow them to hack away with little process and you'll have startup velocity and stability. Systems exist at all levels of organisation, just at smaller organisations that system is usually more implicit.
