Am familiar and in my experience TQM is just as cargo-cult as Six Sigma, Waterfall, Agile, etc etc. You get these highly-stylized idealist models, often which have books and courses, then the consultants... Ugh. IDK - all of this crap is noise to me. I found Deming's work super thick, and honestly I'm probably too much of a simpleton to really "get it"... =|
In contrast, my personal commandments are near-100% inspired from the two lists:
* Tom Sach's "10 Bullets" (how to work)
* Joel Spolsky's "The Joel Test" (how to run an effective software company)
It doesn't surprise me to hear there's a ton of BS around Deming's work (it's had even longer to build itself up) but I still think there are valuable things there that software companies, especially larger ones, are missing... And we seem to have the existence proof of there being something to it (i.e. Japan's rise, and later on US companies adopting things... though as Jobs once noted (https://www.youtube.com/watch?v=kib6uXQsxBA) customers won't think highly of your quality if you keep shipping garbage despite winning a Deming Award or having all sorts of advertising that claims high quality).
Even starting from the surface root level with Deming's "System of Profound Knowledge" -- his 4 key components -- I see a total lack of "Knowledge about variation" all over the place. Without some intuition of variation you can't even appreciate what you mentioned about how programmers sometimes just seem to have "off weeks", and from what I've read Deming wanted the understanding to be more deep than a basic "yeah things vary" instinct, and to know it applies not only to individuals or individual units of work (e.g. red beans experiment) but to larger scopes as well. Ultimately the knowledge needs mathematical grounding (specifically in probability and statistics), which is something else sorely lacking in management trees (and even more and more on the programming side). If there are things like TQM certifications out there that don't imply a holder has a certain level of mathematical sophistication with statistics, that's all the more damning to the certificates and bodies of work around them, but not I don't think to the importance of such knowledge...
> Ultimately the knowledge needs mathematical grounding (specifically in probability and statistics), which is something else sorely lacking in management trees (and even more and more on the programming side)
This is one of the biggest struggles of my career... dealing with quantifying something that's incredibly difficult to quantify.
---
Glad you're checking out Tom Sachs' list! It's an odd one for sure - weird artsy video and all. It's about an art studio in NY and how it manages it's people/process. It's sorta hokey I'll admit, but I find the simplicity of it helps me get back on the rails myself during those times of variation =)
The next set of questions: "If you are a higher-level manager, are your first-line managers capable of reading programs ... ? ... Our surveys indicate that nine-tenths do not ... Do you think it is possible for a first-line manager to know how good his programmers are or how well they are doing without occasionally reading their programs?"
I'm glad to read your report to know that at least somewhere out there exist software managers that seem to 'get' that code is (or should be) the central artifact in all the crap we programmers produce. Not that the other stuff isn't valuable, but things can still work without it, whereas without the code nothing works. My remaining fantasy is to encounter a software manager who is familiar with Deming's work and has thought about how to apply it to software management.