Hacker News new | past | comments | ask | show | jobs | submit login
The Heart of W. Edwards Deming (hagakure.substack.com)
113 points by mooreds on Aug 29, 2023 | hide | past | favorite | 27 comments



And even fewer people have heard of Homer Sarasohn[1], who was perhaps even more seminal to the Japanese economic recovery and kickstarted their electronics industry. An entertaining introduction is here[2].

[1] https://honoringhomer.net/

[2] https://honoringhomer.net/wp-content/uploads/2014/08/cringel...


The story of Homer giving Akio Morita one more chance, and that chance becoming Sony Inc. is a wonderful tale…


Indeed. And it generalizes. Good managers generally believe in second chances, because if they saw enough to give a first chance it’s worth the risk. Third chances on the other hand not so much.


I had indeed not known of Sarasohn. Thanks for sharing, will dive into his history!


I followed Dr. Deming since the 1960's when I was a boy. Spent a lifetime since then building on his ideas and how to apply them to scientific laboratory work of various kinds, not just quality control, and it has been quite helpful.

Especially when it comes to the elements of experimentation and discovery.

Not everybody is aware of the way in his later years Dr. Deming was involved with Jim McIngvale "Matress Mac" of Gallery Furniture in Houston, and made a major difference in their operation. As a very promotional local personality it was easy to witness the transformation as it occurred over the years. I would say this influence was what allowed their ultimate growth beyond what would have been possible before.

https://deming.org/customer-satisfaction-and-the-deming-way/

For some quick reading I'll quote a few quotes from the 11-page quote page:

"A bad system will beat a good person every time."

"All that we have has come from people that are responsible only to themselves, only themselves to satisfy."

"Defects are not free. Somebody makes them, and gets paid for making them."

"In my mind, if you run your company on visible figures alone, you will have neither company nor figures, given a little time. The most important figures are unknown and unknowable. That opinion comes from my good friend, Dr. Lloyd Nelson."

"Information, no matter how complete and speedy, is not knowledge."

"It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth."

"Joy in work comes from understanding why your work is important. Not from the work, but from knowledge of who’s going to use it."

"The supposition is prevalent the world over that there would be no problems in production or service if only our production workers would do their jobs in the way that they were taught. Pleasant dreams. The workers are handicapped by the system, and the system belongs to the management."

"To manage one must lead. To lead, one must understand the work that he and his people are responsible for."

https://deming.org/quotes


>"It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth."

Ironically, this may have been a reaction to an early software management book in the 80s by Tom DeMarco of Peopleware fame and similar books that were popular at the time. It's kinda annoying that the people that are maintaining a website in Deming's name don't reference the first edition book dates for the quote attributions. The original book seems to have been published in 1993 (when Deming was 93...), whereas the quote is attributed to a 2018 third edition on the website.

The reason I find it ironic is that Deming seems to have been critiquing the young (relatively) influential upstarts at the time like DeMarco for over-emphasizing the importance of management metrics, And as it turns out, the nuances in his approach turned out to be more compatible with the approach that came to dominate the post-millennial software landscape (led by Google/Facebook at the time)--ie rigid process-averse lower case agile. It turns out the out of touch senile old guy was more prescient than the new suits.

Although DeMarco started deviating from his early utopian management approach when he published Peopleware, it wasn't until the late 2000s when he did a a complete 180 and wrote a mea culpa, disavowing his earlier management books and the "You can't control what you can't measure" quote attributed to him [0].

[0] https://www.cs.uni.edu/~wallingf/teaching/172/resources/dema...


> It turns out the out of touch senile old guy was more prescient than the new suits.

Well, it was Deming. He is still more prescient than the state of the art in management. Managers read his books, make an effort to internalize them, and immediately go and do the complete opposite thing.


I think it's correct about the backlash from Deming against the early DeMarco philosophy. As a young business builder back then when the overuse of metrics began to get popular, I always could see the benefit of basic metrics to get an idea about things that actually could be measured meaningfully, but already was aware that things which made the most difference were not the measurable ones.

Since then I doubled down on the unmeasurable (so I could make the most difference), even though I'm a measurement person in a measurement business. In the commercial analytical chemistry lab, with Deming's influence I was way ahead of the alternative labs who were not yet using control charts, nor were they attempting to produce NBS-traceable (now NIST-traceable) results which I considered essential since my results were utilized for some of the most high-stakes commodities. Most of the people in the established labs at the time had never even heard of an NBS-traceable approach. Continuous improvement is essential and over a period of 40 additional years you can make the kind of progress that can not be accomplished in a mere 30 years or so. Eventually you've got alternative labs so deep into the metrics that you can run circles around them without even using control charts yourself, just the internalized learnings over the years applied to the most meaningful elements which are largely unmeasurable if not completely misleading when you try.

A reductionist view might be to consider statistical process control to be helpful but statistical people control to be harmful.

>Managers read his books, make an effort to internalize them, and immediately go and do the complete opposite

In my case I made an effort to internalize then gradually was able to successfully guide the continuous improvement actions over a period of 10 years of less-bold moves as I was racheting up based on accumulating that most-valuable experience. Precisely to avoid immediately going and doing anything really dramatic in what would naturally be so less-informed a time as to end up having something like the opposite of the desired outcome.


That's pretty fascinating stuff, thanks for sharing.

Was there ever a situation were you were tempted to just go by the measurable metrics alone?


>tempted to just go by the measurable metrics alone?

For me that's where I start out, using the metrics that are already available, and often needing to measure a few more things that seem good at the time.

Hard data can tell you a lot, I was a mathematical child and I've been known to do an equation or two, even a statistic now and then. But that's not enough, there are quite a few mathematically gifted business operators who are capitalized with resources way beyond my reach, whom I have always needed to outperform in their capitalist market while being a lowly entrepreneur without any of other peoples' money to rely on. There would be no way to compete with them on their terms.

So the overall objective is to get the early metrics into the rear view mirror where it belongs, since it is intended to fade away to a lesser degree of prominence as real knowledge and strategy is built more deeply to go forward more effectively than measurement would predict no matter how accurate or well-regarded the hard data is.

The temptation is always there to rest on your laurels in a number of ways, but yielding to that is the halting of the continuous improvement process.

Even though absolute perfection may not be fully achievable, that's the direction you want to progress toward as much as you can. But no further progress can be made when you've halted for any reason.

You need to find your North Star for the particular situation and follow it unwaveringly so you can leave past performance in the dust with the data which was once defined by it.


Ah I don't remember the exact words but one of my favourite images he painted was something along the lines of

"Managing an organisation by quarterly reports is like driving a car by looking at the centre line in the rear view mirror."


Nice quote here

“If we focus on never making others feel inferior, there’s no limit to what can be achieved”.

In light of how snarky people can be during interviews and evaluating others, it’s good to remember we are not better than one another in any meaningful way.


One of my favorite quotes comes to mind and is #3 of the Ten Commandments of Egoless Programming: 'No matter how much "karate" you know, someone else will always know more.' :)

https://blog.codinghorror.com/the-ten-commandments-of-egoles...


Paulo here, author of the post.

Thanks everyone for engaging with it and for the lovely insights in the comments here. I hope more people get to know Deming because he showed us — multiple times — that it's people AND profit, not people OR profit. Superior intellect with what I know now was an enormous heart.

Thanks again!


Deming's philosophy was a big part of my professional life in the 1990s. It's good to learn more about the man. Thanks for your article!


One of the books linked within is interesting

https://www.amazon.com/Reckoning-David-Halberstam-ebook/dp/B...

I read it some years ago, and its very very interesting.


I was ready to come down hard on this -- "just what we need, a hagiography of some Taylorist" -- but then I saw that this is not at all what Deming was about. This quote really resonated with me, particularly the part about intrinsic motivation:

> Our prevailing system of management has destroyed our people. People are born with intrinsic motivation, self-respect, dignity, curiosity to learn, joy in learning. The forces of destruction begin with toddlers—a prize for the best Halloween costume, grades in school, gold stars—and on up through the university. On the job, people, teams, and divisions are ranked, reward for the top, punishment for the bottom. Management by objectives, quotas, incentive pay, business plans, put together separately, division by division, cause further loss, unknown and unknowable.

And that first sentence is a hell of a sentence(!) --"has destroyed our people". Fantastic.

When I consider the mess that has been made of the American landscape, of the pollution dumped into waterways by hedge-fund-operated manufacturing plants, I think similarly about "has destroyed our environment".


I highly recommend Beyond The Phoenix Project. It's less of a book and more of a podcast with John Willis and Gene Kim exploring Deming, Goldratt, and related theory.


I wonder how responsible Deming was for the decline in births in Japan. He somehow managed to convert work culture into life purpose for employees and I imagine a lot of that bled into replacing children as one's life purpose as there is only so much a single person can yearn.


To recover from devastation you need to convert life purpose to include work culture more than ever.

Deming just showed them the way to get more done in less calendar time.


Deming was the man. But being a systems thinker, and seeing the corporate idiocy (just watch his talks on management), I suspect he knew that a system cannot be transformed, it can be destroyed and rebuilt. Japan was a great opportunity fro him to rebuild a system the right way.


I think the conflation of software testing and Quality Assurance is a major shame of the tech industry.

It's warped the understanding of the field of QA and pays little respect to Deming's ideas and goals.


It reflects a similar problem in industry. If you look at the trade magazines during the Renaissance in quality management, many paid lip service to the ideas of statistical quality control while trying to sell gadgets and data processing systems to enable 100% inspection. That's because leadership change can't be bought and requires work from leadership.

QA, I've always felt, is the wrong approach, in that I don't think quality is something you can assure, especially if it's not designed into the product. Whether you're talking about software testing, ISO 9000, GMP, or whatever, these approaches are good at providing a lot of activity and reports and not necessarily coordinated with quality product. They may be an essential part of achieving quality, but they don't cause it.

The US government, for a long time, was killing itself with QA that allowed purchasing from anywhere that could supply an "acceptable quality level", meaning on average 3% of any item was defective and an assembly could have a high likelihood of not working.

Similarly to software process, quality management gets fetishized and cargo-culted, so you end up with six sigma, "zero defects", total quality management, etc. I read that Deming once saw a TQM placard and said something like, "I hope I'm not guilty by association."


>software testing, ISO 9000, GMP

Major difference is that ISO and GMP are intended to be mandated in a way that can only result in excess mindless behavior to some extent, but software testing can actually be made to avoid that.

>may be an essential part of achieving quality, but they don't cause it.

In the case of ISO 9000 with 20/20 hindsight it's more like it can be bureaucratically essential to gain acceptance among those orgs who don't know quality enough to recognize it on their own.

This was primarily an anti-competitive standard to keep less-bureaucratic products (from less-developed counties as well as the US) from outside Europe away from the continent, issued during an unfavorable currency situation before the Euro or even the EU existed.

If Deming were here today we'd be talking about the way ISO 9000 brought the continuous improvement process to its knees by requiring additional bureaucracy which diverts more resources than were once being more effectively deployed in true quality improvement efforts. The result has been a freezing in place of the quality that was reached when ISO 9000 accreditation is achieved. It's a huge milestone and the effort just to maintain that level of recognition is entirely focused on no further changes being made if at all possible, due to the extreme added difficulty of pushing a change up or down through the entire organization.

Not every one is frozen back to 1987, but the pervasiveness for so long has had an exorbitantly unmeasurable cost. Especially in terms of reduced innovation.

Plus many US companies that were in production before ISO were making higher quality products then than they do now, it really helps to see this if you were there at the time.


Definitely. I never really understood why ISO 9000 was the focus. It's one thing to say, "We need operational definitions" and "Our procedures should be well specified" but totally another to have all these consultants running about bikeshedding the format of the documents and things like whether you should be able to select and copy from a PDF file. Documentation systems don't give you quality, but something is needed to maintain the documentation of the system, so that you know how you got to where you are.

I have been in many places where I wished that people would apply some of the system of profound knowledge. Just getting the PDSA cycle into effect on a few teams would have been great. More and more, though, it is hard to see how we should be measuring the capability of the system. Deming's examples are generally from things that lend themselves to time series analysis, preferably with small batch samples, like manufacturing processes. It is much harder, in my opinion, to determine what to even study in a software process or a medical care process. If you focus too much on a metric, it will become the goal.

An interesting book to me was Juran on Quality By Design. It complements the systems approach with a design methodology based around trying to understand a lot of the ecosystem of the product. Juran, of course, was another Western Electric guy influenced by Walter Shewart.


Check out the episode of Gene Kim's podcast with Elisabeth Hendrickson, it does such a great job exploring the myths and realities around software testing.

https://itrevolution.com/podcast/the-idealcast-episode-3/


Thanks for this, also there is a reference to her excellent paper from 2000 "Better Testing - Worse Quality?" where she emphasizes the need for engineers to do their own testing for the most part. Still posted in a few places which was worth reading.

Inherent quality depends completely on the factory floor.

But I would say with code development bugs all you can expect the engineers to catch are the ones that can be found during their combined development/testing progress as it goes along. So they should honestly think it's perfect before turning it over to dedicated testers who will put their full effort into trying to find defects that were possible to be overlooked up until that point.

Kind of like having a machinist making motor shafts who can easily see when they are coming out bent and fix it so that doesn't happen, plus manually gage his parts as he goes along to make sure the diameter is holding steady. He's doing all he can to produce what then look like perfect parts. Next the QC guy comes along and using automated measurements, tests the whole shaft along its entire length, and finds a few below-spec items that slipped through the cracks. Feedback to engineering can be used to make sure it doesn't happen again.

The engineer is building value as intended performance is being accomplished, the tester is not building value from scratch or doing invoiceable work but they are essential to make the most of the value that is created.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: