...assuming people want to know that the change is in the expected range. That's often not the case. People's careers are built on phantom improvements and being able to say that regular process issues were one-time occurrences.
You don't need expertise in statistics to draw control charts. You might need that expertise to teach people to draw control charts, but not to draw them.
Line workers are the reflexes of the organisation. They can react to trouble before the central nervous system (management) is even aware that something has happened.
One of my favourite techniques from that book is to remove the centralised backlog. People's ideas for improvement shouldn't be everyone's administrative burden. There are too many ideas for that.
Instead, keep a central record of the things that need to be done right now, and if something is important to do later, then someone will probably keep track of it personally and bring it up later when it is more relevant.
Reinertsen has borrowed more from queueing theory than from Deming. This is not unexpected -- Deming worked mainly with thin-tailed statistics, whereas Reinertsen applied his knowledge to the power laws that show up more in design and development work.
(The two approaches meet in the middle. Deming inspired lean manufacturing which also applies queueing theory. The latter has convenient results both for thin and thick tailed processes.)
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.
| - Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.
I think this is the biggest hurdle for US style management produced from the MBA cookie factories. Their only skill sets are MBA speak, assigning blame, taking credit and granting themselves the largest bonuses possible while telling all the actual workers generating value that "due to current financial conditions, your raise is limited to 2%"
It doesn't help at all the US union rules make switching from line work to supervisor work a bad thing. If someone with a union job switches to management they have to start from zero - the company cannot count all those years of experience and so you start at the bottom of the ladder again despite your experience, and your former friends now do mean things to you because you "went to the dark side". It isn't just unions that do the above, but it is the worst there.
> There are parts of product development that are non-chaotic, and SPC works just fine there, too.
Not to detract from your main point, but being non-chaotic is still not enough for SPC to work. Almost all of development tasks have thick-tailed time distributions, even if one is perfectly capable of analyzing them, they are not controllable.
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.
> for thermostat B there are many more outliers. We’d say that [...] thermostat B is not [under statistical process control]. (In practice, you’d draw a control chart to identify whether the system is under statistical control).
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.
Eh depends what you mean I suppose, but a small dense cluster with enormous outliers is not a great sign usually.
Almost nothing has (effectively) unbounded variance, so most things are under statistical control in a sense. With some notable exceptions (earthquakes, any other event with exponentially decreasing frequency and exponentially increasing damage).
For the sake of argument I assumed the author meant that the variance of the thermostat was too high to be practical.
My expectation is that Lorin would read the parent comment and say some variant of "oh, whoops, I didn't check." As the parent noted, it's not really that important to the overall point.
None of those data points are outliers, since they are within the band of what's expected from the process.
Yes, the variability of the thermostat is awful, and the SPC practitioner would care about that. But the key thing is that dealing with bad variation that's in control requires different techniques than dealing with actual out-of-control processes.
How much of this reply is environmentalism baked into it with post-training?
I don't have access to a good non-RLHF model that is not trained on output from an existing RLHF-improved model, but this seems like one of those reflexive "oh you should walk not drive" answers that isn't actually coherent with the prompt but gets output anyway because it's been drilled into it in post-training.
reply