I did draw the control chart, and thermostat B is definitely under statistical process control: https://xkqr.org/info/xmr.html?baseline=33,97,41,65,72,71,64...
If someone wants to learn more, this is how I put the introduction: https://entropicthoughts.com/statistical-process-control-a-p...
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.
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.
Especially older buildings where things like uneven sun loading have a bigger impact, and where things like outdoor reset are less common.
Obviously, if a quality issue is detected in manufacturing, there may be some steps that engineering could take to improve the manufacturing process and make things stable enough to obtain meaningful statistics. This is part of the Deming feedback process, and part of the System Engineering Life Cycle.
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 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%"
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.
- Size of pull requests (due to feedback loops)
- Effort required for bug fixes (the variation is large, but not a power law)
- Developer-hours in a sprint (this might seem obvious but it is still useful!)
- Weekly code complexity increase (counted as lines of code added)
- Fraction of effort spent on paying off technical debt
- Time taken by CI
- Weekly count of deployments
- Number of commits in a deployment
There are many more, but this should be enough to illustrate that software product development is not only subexponential.
- Process improvement can be applied all over the place. In how you merge PRs, how you run tests, how you manage sprints, how you deploy safely, etc
- SPC is just used to identify defects. It does not inherently create stress; how you use it matters
- You can identify quality issues in any engineering discipline. High-level method: identify a quality measure ("time to merge PRs", "website is up", "tests are not flaky"), observe it, record the observation, plot it on a chart. Chart trends down? Quality issue. Process improvement cycle to attempt a fix. Chart trends up? Quality issue abated. Must add intelligent study/reasoning though, not just chase metrics.
- Training workers improves output by ensuring there is uniform and correct knowledge of tasks required. Software engineering is particularly guilty of hiring workers without ever giving them specific training, and it results in frequent mistakes from simply not understanding the technology they're using (most devs today will probably never read an entire technical manual).
- Look at the rest of his advice. Drive out fear (improving trust in changes allows shipping more changes faster), improve leadership (help staff improve, don't just make sure they're writing code), break down barriers (improving cross-team collaboration makes changes easier and better), eliminate numerical quotas (focus on quality over quantity makes a better product), remove barriers to pride of workmanship (a dev that makes good code is a happy dev), institute education and self-improvement (brings in new techniques that improve output), take action for transformation (make everyone responsible for improving the org), improve constantly (look for ways to improve, don't coast), etc. All these apply to SWE.
For example, increased test flakiness can be a positive sign. I know that seems unlikely, but if you see some spike in flakey tests, it's often a side effect of people adding end to end tests, because some issue made it to production.
At my current job they monitor how long PRs are open, and it appears to mostly be a measure of repository age. Old repositories have more PRs sitting around.
What you really want to measure is "how good is the product?", or "are we delivering quickly relative to the difficulty of what's asked?" and those turns out to be extremely expensive to measure, so people use metrics that don't work well instead.
(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.)
_________
A person on the assembly line can "contribute to financial targets" taking a shortcut, reducing their local spend, but which emerges as a much more expensive problem down the road.
So it's true that every employee should do their part to contribute to financial targets, but defining "their part" is the hard part, something only management can do, and that MBO obscures and tries to make as simple as waterfalling the goal from above.
The inevitable result of this is however the devaluation of the future. Eg if the statement was true, it'd be the R&D workers responsibility to hand in their resignation ( or their managers layoffs) if their product won't get paying customers within the same fiscal year... And the same applies to any other long term expenditure/investment that company might be considering. E g building a new fab/production line etc pp
So no, that statement of yours is not actually true. It should not be entirely ignored, but it should not become a leading cause unless you want to run the company in the ground.
It might not apply to R&D-heavy companies, but we do see engineering companies pivoting into more finance-oriented management. Boeing is one such case and look at the damage.
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/
Go back to your desk and work on a PR that is going to go through a 20 step process that is constantly changing before a hopefully semi-regular release goes out to customers and tell me how you ignoring all of knowledge on how to do this well is good for your career.
For a long time I assumed folks like you were simply uneducated, but know I see it for what it is, elitism.
None of this works for the system of life and consciousness.
But nobody wants to hear stuff like “well first we’re going to need a baseline, and if you want it to be any good we’ll probably need two years or so before we can start trying to measure the effects of changes”. They just want something convincing enough that everyone can nod along to a story in a PowerPoint in four months. Two years out? Lol you’ll be measuring something totally different by then anyway. Your boss may be in a different role. You’ve asked something the company is literally incapable of.
Meanwhile, last I checked, measuring management effectiveness isn’t something we can do in practice for most roles, except bad ways that only pretend to tell us something useful (see above). Good scientists, excellent and large dataset, just the right sector, just one layer of management under scrutiny, maybe you get lucky and can draw some conclusions, but that’s about it, and it’s rare to see it happen in an actual company. Any companies that do achieve it aren’t sharing their datasets.
This kind of thing has been consistent everywhere my wife or I have worked. Similar things reported by many friends. Companies want to pretend to be “scientific” and “data-driven” but instead of applying it to only a couple things where they might do it well (enough data, cheap to gather metrics, clear relevant business outcome) they try it everywhere, but don’t want to spend what it would take to be serious about it, with the result that most of their figures are garbage.
This trend has become just another “soft”, as you put it, tool.
The whole point of SPC is to separate signal from noise. Pointing out that some change that everyone is obsessing over is well within the expected range is useful, it can head-off knee jerk reactions to phantom issues.
Hence, every action of a company needs to be measured against the upcoming quarterly results.
OKRs et al are great at that.
Who cares about quality/sustainabily. We just want the stock go wheeeeee and get our bonuses.
US companies are generally a better bet though, because despite the handicap of being run by Americans, they are hosted in a country that generally believes in freedom and rule of law which means they have an unfair advantage even if they do a sub-par job of making the most of what they have.
Exceptions abound in the details.
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.
You are missing something here imo, very few companies actually increase pay (or to be more clear, show a clear way to get there) enough to make it attractive enough to stay there for long periods of time.
From my experience here in Germany the people staying at companies for a long time are those who don't focus on their career.
- 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)
Tory governance and fiscal policies had all the responsibility for Leyland, Hillman and more importantly Rover.
For Rover in particular, https://en.wikipedia.org/wiki/Phoenix_Venture_Holdings stands out. Similar to Maplin and Toys R Us, an example of the owner-management taking a large amount of cash out of a business that was declining.
That factory was fascinating to work in, looking back on it I saw a lot of Deming-compatible stuff going on that I wasn't equipped to recognise at the time. There was strong German representation in factory management, lots of interaction with people coming and going from Munich all the time. But the production line staff had a large agency contingent so it didn't have the "job for life" ethos that the Toyota Way would say is essential.
Heck, even things like shipping, the oldest insured industry, become impossible. Corporations used to have minimum capital requirements that were roughly in the region of a year's average income. https://www.doingbusiness.org/content/dam/doingBusiness/medi...
("corporation has too much money" and "individual has too much money" are different problems; Elon Musk is a problem in the way that Apple isn't)
It's not.
There was a time when millionaires were considered 'rich'. Now that's just a retiree, in most housing markets, who's paid off a house. Or even a townhome... and in some places, a condo!
It doesn't matter "whether it should" cost that much, that's irrelevant for my example. The point is, being a millionaire isn't a big deal. It's common. It doesn't mean wealthy.
Likewise when a company is large, and has infrastructure all over the world, and is worth much of a T, a B is nothing. Cash reserves in the billions is really not all that much, just fiscal prudence.
An alternate is that "banks should get free money, by forcing all companies to borrow money for capital projects". Because if you tax companies for "wealth", then they'll just spend all that capital on loan payments.
I feel people have such weird ideas about taxation. People see "oh no, someone has free money!" then get excited and want to tax. What? The goal of taxation isn't "take money from anyone we can", nor is it 'wealth redistribution', it's instead 'how to pay for joint projects' that all of society benefits from.
Losing track of that last bit, is when people stop asking "should we tax" and instead say "they have money, so tax"
But I think the author of the comment you were replying to had a different goal in mind. I think their goal was "prevent corporations from getting too big".
We can and should debate whether that is a goal we should be trying to achieve, but if it is then progressive taxation for companies might be a way to achieve it.
One might note the unrestrained concern about fluid capital acquisition, in the post I replied to. It's not having billions in infrastructure that was cited, nor having a large number of employees, both metrics of size, but instead having fluid, unused capital.
If we wish to constrain upon size, there needs to be nuance, conjoined with the specific industry, and even sub-industry. Some capital equipment costs can be enormous. Should we work to prevent financing such via stored profit? Should we work to force companies to finance, then pay off, just to feed the banks, rather than store and then spend?
Should we tax so that "big ideas" may never occur?
I think far more would be gained by ensuring taxation just stays fair between smaller and larger company structures. There's a lot of book-keeping that can be done as a large company, to hide profits, that cannot be done when you're a small mom and pop.
Where Deming reads like a science paper, Drucker reads like an installation guide.
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.
Worth adding that Deming (after Shewhart) recognised two kinds of variation: special cause (specific the work item in question) and common cause (an artifact of the process). That knowledge work involves a lot more of the former than does manufacturing does not excuse inattention to the latter.
Reminds me of a seminal treatise for Waterfall by Royce[0], where he basically says it’s fraught with issues, but can be coerced into something semi-usable. Not exactly a ringing endorsement. I think that paper is used as the template for all Waterfall work.
Think Stats: Probability and Statistics for Programmers (https://allendowney.github.io/ThinkStats/)
Computer Age Statistical Inference (https://hastie.su.domains/CASI/)
Statistical Rethinking (https://xcelab.net/rm/)
An Introduction to Statistical Learning (https://www.statlearning.com/)
Obviously maths is going to be involved to do the subject justice. These recommendations are more about applied statistics, but that's the foundation. From there it is a small transition to statistical process control.
If you are looking for "do this" then Deming is not your person. If you seek understanding that drives transformation (knowing what to do in your context based on a broadly applicable value system), then Deming's system can deliver.
Lessons from the Red Bead Experiment include the fallacy of rating people and ranking them in order of performance for next year (based on previous performance), as well as attributing the performance of the system to the performance of the “willing workers” in this simulation of an organization governed by what Dr. Deming referred to as the “prevailing system of management.”
That’s a lot harder, and more expensive in the short term. It’s also something that benefits from having long term employees that both understand the organization and don’t view the organization as hostile to their employee interests whenever some other metric of short term profitability is a mutually exclusive choice.
Without this, you’re limited to people who may have more natural or intuitive leadership capabilities instead of those who can learn, given the opportunity and example.
In short, corporate practices have systematically eliminated the circumstances under which there would grow a sufficient number of people with leadership skills.
Eventually manager as a profession will be replaced by tools, just like computer as a profession, editor as a profession.
The evolution of computer science will be manager science. There is more than loss function and KPI.
The Toyota Way attempts bottom up process improvement. Teams generally organize themselves. Team leads take responsibility for quality and report it up the chain. Instead of deflecting blame, they often work themselves to exhaustion. Which is not an ideal result either.
> One of the virtues of OKRs is that they are straightforward for managers to apply.
Choose wisely.
They both fit straight lines to noisy data.
Deming regression is an errors-in-variables model that tries to fit the line of best fit when you have errors in both x and y and they are both known and in general _different_; the Theil-Sen estimator is based on medians and is particularly robust if you have an error process that fails more "one way" than the other. Simple linear regression is everywhere in our lives and yet remarkably not robust to errors that are not IID normal, particularly with a small number of data points: a process that can only fail in one direction if it breaks is likely to completely and utterly bugger up the line that you fit. Both approaches have their place and I wish were more widely used, particularly by people who like fitting linear models to complex phenomena because they are easily understood.
[0] https://en.wikipedia.org/wiki/Deming_regression [1] https://en.wikipedia.org/wiki/Theil%E2%80%93Sen_estimator
This is why companies can’t do Agile, especially Scrum: Scrum requires the most of the people in power, who typically can’t be bothered and who get to dictate process.
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.
Still, at the root, I blame the system itself, not specific participants.
By using fiat, dollar as a reserve currency and the petrodollar, the US gets to export inflation and devalue everyone's currency against their own (I think). The best explanation I've seen of this are by Varoufakis, but there are others.
People are far more willing to spend large amounts of other people's money on frivolous things than they would if it was their own money. Also, the ability for a government to create large amounts of money on demand allows them to spend on destructive activities which can create opportunities for certain connected people in the private sector. Price discovery in the markets cannot work if one party has a theoretically unlimited amount of currency. It just devalues the currency.
If the government knew that the budget was limited and they only had x amount of money to spend that year as an absolute maximum, they wouldn't be sending it to foreign countries as foreign aid.
Even in manufacturing, the application of statistical process control was never entrusted to the workers, but became a department of its own, with bureaucracy, OKRs, and elaborate software.
This is why Deming never landed here. He espouses a complex view, and most people just aren't that smart or skilled. He also espoused pride in craftsmanship, quality, and analysis, things most American workers don't value as much as the Japanese, which is another reason Toyota took them up so quickly while it took us 50 years.
Is that American workers or American managers? Because in my experience, it's usually managers pushing against those values. It seems like American business culture sees quality and craftsmanship as money left on the table that should be sent to the shareholders, so there's always pressure on workers to cut corners. Also American managers are too quantitative, and quality and craftsmanship are hard to quantify (unlike dollars).
Workers like "craftsmanship, quality, and analysis," not the least because they make their job more satisfying (no one enjoys pushing out low quality junk), but most aren't stubborn enough to keep pushing for them against management resistance.
Then Toyota came in, taught them TPS, and the transformation was night and day. Read the interviews and stories. Workers reported they gained more pride in their work, it made them want to do better, and they did do better. So we can have pride in our work, but it's not ingrained culturally like it is in Japan.
To loosely paraphase George Carlin: "Where do you think Managers come from? They don't fall out of the sky. They don't pass through a membrane from another reality. They come from the same place Workers do: American parents and American families, American homes, American schools, American churches, American businesses and American universities. This is the best we can do folks. It's what our system produces: Garbage in, garbage out."
This is one of the big differences in the military, with far more trust given to the "workers" in the US and generally western countries compared to others.
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.
Deming's exhortations exist because they are aspirational, essentially propaganda for his vision of organizational cybernetics. "Deming was part of the Teleological Society with Wiener, Turning, von Neumann, and others during and after the Second World War — one of the groups that was the precursor to the Macy Conferences and worldwide cybernetics movement that also led to the development of the Cybernetics Society." [0]
"[Deming's] view of cooperation stood in stark contrast to business as usual, which emphasized competition, even within one’s own company. Throughout his life, he demonstrated how even competitors working together benefited their respective companies and, more importantly, their customers." [1]
0. https://cybsoc.org/?page_id=1489
1. Willis, John. Deming's Journey to Profound Knowledge: How Deming Helped Win a War, Altered the Face of Industry, and Holds the Key to Our Future (p. 164). (Function). Kindle Edition.
That is wrong thinking. While you can go overboard with bureaucracy, the line worker doesn't have the the background (or time) to evaluate statistics. You need an expert in statistics at times to see if what looks like a pattern really is. Mean while the line worker needs to spend their time on what they are good at.
Trust the line worker is important, it just isn't a shortcut to people who really know specialized domains.
It is management’s job to protect their ability to do that, and integrate the information from workers to make decisions about what to change next.
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.
Fancy statistics get you in trouble anyway. If the effects are too weak to see in a graph, chances are there are more important things to work on.
Kinda what Gladwell talks about in Blink
In one of Goldratt’s last books he confesses he refused to translate his books to Japanese until late in life because he feared if he did that the 80’s would have been twice as bad as they already were. People here were just not open to new ideas.
I has been a long time since I have looked at it, but I think not even Toyota did that, though.