The big squiggly mess in the article is filled with people. I think Deming’s deepest concept was giving workers on the production line simple tools to improve processes on their own. His books are filled with exhortations to trust the workers. This is what American managers could never bring themselves to do.
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.
He would say to trust the workers, but also all the other things you need to do in addition to trusting the workers. Look at his 14 points. You need to do all the things to get all the benefits.
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.
> He also espoused pride in craftsmanship, quality, and analysis, things most American workers don't value as much as the Japanese
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.
> His books are filled with exhortations to trust the workers. This is what American managers could never bring themselves to do.
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.
In case anyone is interested, I enjoyed the book "Turn the Ship Around!" by L. David Marquet, about management lessons applied by the author who was a US Navy submarine captain. It does very much emphasize giving trust, responsibility and accountability to workers (or enlisted personnel, in this case).
Pray we never need statistical process controls for the mass manufacturing of military objectives.
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]
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.
Which is also a relatively recent thing, all things considered. If I remember correctly it was primarily WWII Germany that pioneered this approach, which was then quickly adopted by everyone else
>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
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.
Deming’s idea is that each line worker is responsible 1) for understanding and minimizing variation in their specific area of work, and 2) for speaking up when they have ideas on how to do that better.
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.
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.
Deming taught statistical methods that regular workers could learn and use, mostly based on simple tables and pencil-and-paper graphing. It predates the computer age. And you can go far with those methods, or just a spreadsheet.
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.
Deming’s revenge was the cratering of American manufacturing in the early 80’s.
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.
> 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.
The main point that I did not see mentioned in this piece is that Deming should only be applied to MANUFACTURING environments, because things like engineering are too chaotic to identify processes or trends in the engineering itself, and 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.
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.
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%"
> 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.
> 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.
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.)
The chief problem I have with Reinertsen (and it's not his fault, at all) is how difficult it is to get people to buy in to the idea that cost of delay exists, let alone buy in to measuring it.
Deming's observations and suggestions can be widely implemented.
- 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.
But, it tends to be difficult to find any metric that's meaningful.
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 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].
The problem is that "every team and employee doing their part to contribute to financial targets", as-stated, is liable to produce suboptimization.
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.
> Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year
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.
Having worked on software that runs manufacturing plants your comment echos the idea that too many engineers have that they are "better" than manufacturing and lessons don't apply to them.
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.
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.
There'll inevitably be cargo culting driven by MBA curriculums and "they're making a lot of money, let's do what they did" without examining the specifics of the situation to distinguish luck from judgement.
We need to appoint people who really CARE. When CEOs hop from company to company, the culture of CARING takes a backseat. Everything becomes transient with no one with deep technical or cultural knowledge at the driving seat. This is the reason people who have been at the company for long time should get a chance to transform it from within like Satya Nadella.
This is a very trivial treatment of Deming and I’m surprised how it makes its way to the top of HN.
The arc from Walter Shewhart to W.E. Deming is a bedrock foundation in an Industrial Engineering curriculum. These men paved the manufacturing process quality principles of modern industrialization. Drucker was about management science, truly an apples to oranges comparison.
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.
Peopleware is extremely old, and if you were to crack open a modern MBA text you'd find statistics and statistical process control type of thinking integrated everywhere, in all the MBA subjects. Management being soft and opinionated ended a long time ago, but then again, "the future is unevenly distributed" so who knows what conceptual envelope you find yourself.
It is also worth noting that US management is notoriously bad at the actual management. Toyota v. US car manufacturers did not look like a fair fight when Deming was in the ascendant, and it is hard to tell given the scales involved but it looks a lot like the US has been outmanoeuvred in all aspects of industry by the Asians.
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.
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.
> Lay-offs, outsourcing, offshoring, now the concept of spending your whole working life at the same company feels like a fever dream
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.
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)
Where does someone like Rover fit in to your matrix?
If I can respectfully recommend. If you can go have a read of "We sell our time no more" by Paul Stewart.
Tory governance and fiscal policies had all the responsibility for Leyland, Hillman and more importantly Rover.
That's too arbitrary, and you say that as if a billion dollars is a lot of money.
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"
I don't think the problems of US corporations are due to being over-capitalized, they're all to do with interactions with the political and media sphere plus unnecessary conflict with the staff.
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.
> Where Deming reads like a science paper, Drucker reads like an installation guide.
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 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.
For the millionth time, would it kill ya to spell out the abbreviation the first time you use it? My googling suggests we're talking about https://en.wikipedia.org/wiki/Objectives_and_key_results , but my googling isn't always right.
Readit News
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.
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.
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.
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.
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.
https://apenwarr.ca/log/20161226Distributed systems is also a way to be throughly humbled by complexity: https://fly.io/blog/corrosion/
(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.)
- 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.
_________
1. https://deming.org/explore/fourteen-points/
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.
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.
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.
None of this works for the system of life and consciousness.
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.
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"
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.
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.”
https://deming.org/explore/red-bead-experiment/
Drucker -> Tactics