(To be clear, this is not a diss of the article. It is hard to create fake data that look realistic at first glance but are not under statistical process control. That's just how good control charts are at separating signal from noise.)

I think you're confusing Deming with statistical process control.

It is true that SPC works best for the non-chaotic parts of product development and manufacturing alike. There are parts of product development that are non-chaotic, and SPC works just fine there, too.

In addition to SPC, Deming had strong opinions on how organisations ought to work and these are relevant also for product development. These are things like

- Understand the underlying customer need.

- The leaders shape the output of the organisation by shaping its processes.

- It is cheaper and faster to build quality and security into the product from the start instead of trying to put it in at the end.

- Close collaboration with suppliers can benefit both parties.

- Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.

- Collaborate across parts of the organisation instead of throwing things over walls.

- Don't just tell people to do better. Show them how they can do better. Give them the knowledge, tools, and authority they need to do better.

These are just as relevant for product development as for manufacturing. If anything, even more so, thanks to the chaotic nature of product development.

I think Donald G. Reinertsen did a good job in his books applying Deming to the design process.

The core issue with the article is that author mixes up bad management and "fog of management" with the fact that financial results have a disproportionate amount of influence in how things are organised. Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year. Which clashes with Deming's points 11b and 12b [1].

_________

1. https://deming.org/explore/fourteen-points/

> trying to control those engineering processes with SPC doesn't really improve the quality of the engineering, it just adds stress, makes things take longer, and probably lowers the quality of the thing that is being engineered

Totally depends on the scale. For pizza-sized times with a neighbourhood pizza shop sized impact, sure. Large scale projects without controls & feedback loops in place will fall apart; see: Scaling teams: https://archive.is/FQKJH

If you'd follow some medium to large scale projects (like Go / Chromium), the value of processes & quality control, even if it may seem at the expense of velocity, becomes clear.

  The great insight of Deming's methods is that you can (mostly) identify the difference between common and special causes mathematically, and that you should not attempt to fix common causes directly - it's a waste of time, because all real-life processes have random variation.

  Instead, what you want to do is identify your mean and standard deviation, plot the distribution, and try to clean it up. Rather than poking around at the weird edges of the distribution, can we adjust the mean left or right to get more output closer to what we want? Can we reduce the overall standard deviation - not any one outlier - by changing something fundamental about the process?

  As part of that, you might find out that your process is actually not in control at all, and most of your problems are "special" causes. This means you're overdriving your process. For example, software developers working super long hours to meet a deadline might produce bursts of high producitivity followed by indeterminate periods of collapse (or they quit and the whole thing shuts down, or whatever). Running them at a reasonable rate might give worse short-term results, but more predictable results over time, and predictable results are where quality comes from.

Distributed systems is also a way to be throughly humbled by complexity: https://fly.io/blog/corrosion/

Deming was a statistician first, yes, but he also had strong opinions in terms of management science/philosophy. These opinions came from a perspective of systems theory and understanding variation.

Management Science? Only management science I read so far (with actual measured outputs and ideas) was Peopleware. Everything else was more like philosophy. Has anyone ever measured, long term results from multiple management methods? What I saw when I looked into it was simple - the Toyota Way was the model for a lot of successful companies, including Pixar.

The thing is, the Toyota methods relies on people on every level to work to improve processes. If you're an employee and know you'll be there 10 years down the line or even until you retire, you have an incentive to improve said processes.

Now check most Western companies: since the 70 / 80, everything is about reducing headcount. Lay-offs, outsourcing, offshoring, now the concept of spending your whole working life at the same company feels like a fever dream. So why would an employee try to improve things for the company when they know there is no future for them there? Better improve their own career and future prospect. So yeah, things like Kaizen are doomed to fail until things change.

This is rather like my observation about British car companies in the late 20th century:

- large factory of British workers + British management: strife, strikes, disaster, bankruptcy (British Leyland)

- small factory of British workers + British management: success, on a small scale (lots of the F1 industry, McLaren etc; also true of non-car manufacturing)

- large factory of British workers with overseas management: success (Nissan Sunderland, BMW era Mini, etc)

Fortunately, once we impose a wealth tax on corporations we can solve this. Billionaire corporations should not exist.

Not sure about your opening thesis. The vast majority of employees work for privately held businesses and from personal experience of working in such companies, “management” by OKRs and the like is common in companies who are not listed on stock markets also.

Not necessarily limited "intellect", but rather limited background knowledge.

Deming requires quite a bit of knowledge and understanding in failure/success modes. The core tenet of Deming is that every output is a result of some process and, therefore, output is controlled by controlling* the process itself. Look at your process and tackle failure modes in this priority list.

Drucker, on the other hand, puts the process under the fog of war and basically says deploy pressure on process outputs and let the process adjust itself. It requires much less understanding behind the processes to make sense.

* - Process control in Deming is mostly about variability.

that kind of ties in with the article's thesis; deming's approach is more scientific in the classic sense of taking observations and using those to build up your mental models, whereas drucker proposes a one size fits all recipe for managing roadmaps.

Talking about “virtues” of OKRs is a long stretch.

You could read The Long Twentieth Century by Giovanni Arrighi.

Fiat money is not the problem, the financialization of economy is actually a common by-product of aging great monetary powers. The US chose to become a monetary power in 1945, rejecting Keynes' Bancor proposal.

Then in 1971, it found it couldn't keep it working, due to the very reasons Keynes explained to them at Bretton Woods. Arrighi argues this has happened 4 times already.

So Fiat money and the financialization of life is just an outcome of something else - that being a monetary superpower is just not sustainable.

The tulip craze and many other market excess crashes occurred under non-fiat currency schemes. The money system being fiat or metals backed or crypto is incidental to "let the corporations go out of business, let efficient small companies take their place". If you want smaller corporations and more competitive marketplaces, it's anti-megascale taxes and anti-monopoly regulation that can achieve that.

> abolish the fiat soft money system,

And replace it with what?