The big squiggly mess in the article is filled with <i>people</i>. 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.<p>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 <i>all the other things</i> you need to do <i>in addition</i> to trusting the workers. Look at his 14 points. You need to do all the things to get all the benefits.<p>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<p>Is that American <i>workers</i> or American <i>managers</i>? Because in my experience, it's usually <i>managers</i> pushing <i>against</i> 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).<p>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.
American managers don’t espouse pride in craftsmanship, quality, etc. The actual worker cares.
> His books are filled with exhortations to trust the workers. This is what American managers could never bring themselves to do.<p>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).
One of my favourite techniques from that book is to remove the centralised backlog. People's ideas for improvement shouldn't be <i>everyone's</i> administrative burden. There are too many ideas for that.<p>Instead, keep a central record of the things that need to be done <i>right now</i>, 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.
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
It was practiced by the Prussians during the Franco Prussian war. In WWI, it led to the small team grenade tactics, the Germans deployed to try to overcome trench warfare. It culminated with the blitzkrieg tactics of WWII.
I've heard this dichotomy in terms of military command presented in many different ages and different ways. It is primarily the difference between communicating the goals of an operation versus communicating how to achieve those goals. Most recently I've listened to accounts that it explains Russia operational failures in the invasion of Ukraine. I've also read analysis suggesting that it was a relevant difference in the battle of waterloo.
Sort of. The word to search the web for is Auftragstaktik. Here's the Wikipedia page on it: <a href="https://en.wikipedia.org/wiki/Mission-type_tactics" rel="nofollow">https://en.wikipedia.org/wiki/Mission-type_tactics</a>
Pray we never need statistical process controls for the mass manufacturing of military objectives.<p>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]<p>"[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]<p>0. <a href="https://cybsoc.org/?page_id=1489" rel="nofollow">https://cybsoc.org/?page_id=1489</a><p>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.
>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<p>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.<p>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.<p>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 <i>teach</i> people to draw control charts, but not to draw them.<p>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.
The line worker has a canny instinct for the right answer long before the statistics are significant though.<p>Kinda what Gladwell talks about in Blink
Sometimes, but a few times those instincts are very very wrong. Blink is interesting, be sure to read the criticism though <a href="https://en.wikipedia.org/wiki/Blink:_The_Power_of_Thinking_Without_Thinking#Reception" rel="nofollow">https://en.wikipedia.org/wiki/Blink:_The_Power_of_Thinking_W...</a> - it isn't clear that the book is correct.
In my experience, the line worker's instincts are to be trusted but verified. If we blindly follow every crisis from the line we'd quickly find ourselves in a pit. These crises need to be backed up with context and a sense of criticality as there are finite resources to work through problems, and solving one person's immediate problem on the line may have a crushing impact elsewhere.
> the application of statistical process control was never entrusted to the workers<p>I has been a long time since I have looked at it, but I think not even Toyota did that, though.
> 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).<p>I did draw the control chart, and thermostat B is definitely under statistical process control: <a href="https://xkqr.org/info/xmr.html?baseline=33,97,41,65,72,71,64,93,62,71,64,70,100,71,64,71,46,64,38,70,63,64,71,61,70,101,64,48&values=38" rel="nofollow">https://xkqr.org/info/xmr.html?baseline=33,97,41,65,72,71,64...</a>
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.<p>If someone wants to learn more, this is how I put the introduction: <a href="https://entropicthoughts.com/statistical-process-control-a-practitioners-guide" rel="nofollow">https://entropicthoughts.com/statistical-process-control-a-p...</a>
Eh depends what you mean I suppose, but a small dense cluster with enormous outliers is not a <i>great</i> sign usually.<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).<p>For the sake of argument I assumed the author meant that the variance of the thermostat was too high to be practical.
Statistical control is a very specific term: <a href="https://entropicthoughts.com/statistical-process-control-a-practitioners-guide" rel="nofollow">https://entropicthoughts.com/statistical-process-control-a-p...</a>, and one which you'd expect anyone with a significant interest in Deming to understand.<p>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.<p>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.
Short cycling is bad, most residential systems will look like the second chart.<p>Especially older buildings where things like uneven sun loading have a bigger impact, and where things like outdoor reset are less common.
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.<p>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.<p>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.<p>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<p>- Understand the underlying customer need.<p>- The leaders shape the output of the organisation by shaping its processes.<p>- 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.<p>- Close collaboration with suppliers can benefit both parties.<p>- Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.<p>- Collaborate across parts of the organisation instead of throwing things over walls.<p>- 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.<p>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.<p>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.
Just wanted to point out that you may be arguing for the article.. IE US style management is heavily inspired by Drucker and resistant to Deming.
Upper management could and should easily detect that.
> There are parts of product development that are non-chaotic, and SPC works just fine there, too.<p>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.
I disagree. Where I have worked, these important quantities have appeared thin-tailed:<p>- Size of pull requests (due to feedback loops)<p>- Effort required for bug fixes (the variation is large, but not a power law)<p>- Developer-hours in a sprint (this might seem obvious but it is still useful!)<p>- Weekly code complexity increase (counted as lines of code added)<p>- Fraction of effort spent on paying off technical debt<p>- Time taken by CI<p>- Weekly count of deployments<p>- Number of commits in a deployment<p>There are many more, but this should be enough to illustrate that software product development is not only subexponential.
I think Donald G. Reinertsen did a good job in his books applying Deming to the design process.
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.<p>(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.<p>- 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<p>- SPC is just used to identify defects. It does not inherently create stress; how you use it matters<p>- 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.<p>- 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).<p>- 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.
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].<p>_________<p>1. <a href="https://deming.org/explore/fourteen-points/" rel="nofollow">https://deming.org/explore/fourteen-points/</a>
The problem is that "every team and employee doing their part to contribute to financial targets", as-stated, is liable to produce suboptimization.<p>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.<p>So it's true that every employee should do their part to contribute to financial targets, but defining "<i>their part</i>" 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<p>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<p>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.
The statement holds true for a broad set of companies and management styles. I speak from personal experience: the wrong incentives are always there, and they run counter to many things listed by Deming. The obsession with "financial impact" is there with varying degrees, even in functions where it is hard to quantify said impact.<p>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.
> <i>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</i><p>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: <i>Scaling teams</i>: <a href="https://archive.is/FQKJH" rel="nofollow">https://archive.is/FQKJH</a><p>If you'd follow some medium to large scale projects (like Go / Chromium), the value of processes & quality control, even if it <i>may</i> seem at the expense of velocity, becomes clear.<p><pre><code> 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.
</code></pre>
<a href="https://apenwarr.ca/log/20161226" rel="nofollow">https://apenwarr.ca/log/20161226</a><p>Distributed systems is also a way to be throughly humbled by complexity: <a href="https://fly.io/blog/corrosion/" rel="nofollow">https://fly.io/blog/corrosion/</a>
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.<p>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.<p>For a long time I assumed folks like you were simply uneducated, but know I see it for what it is, elitism.
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.
What I’ve seen in the wild is that this is entirely a veneer. It’s important to have numbers. It doesn’t matter if they mean anything. In fact, management is full of numbers that a slightly-clever high school sophomore who’d paid attention in science classes could tell you are totally useless, because they were gathered all wrong. They mean nothing whatsoever. They’re just noise.<p>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.<p>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.<p>This kind of thing has been consistent everywhere my wife or I have worked. Similar things reported by many friends. Companies want to <i>pretend</i> 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.<p>This trend has become just another “soft”, as you put it, tool.
> In fact, management is full of numbers that a slightly-clever high school sophomore who’d paid attention in science classes could tell you are totally useless, because they were gathered all wrong. They mean nothing whatsoever. They’re just noise.<p>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.
Fundamentally stock markets won the world of business, so everything has a horizon of a financial quarter.<p>Hence, every action of a company needs to be measured against the upcoming quarterly results.<p>OKRs et al are great at that.<p>Who cares about quality/sustainabily. We just want the stock go wheeeeee and get our bonuses.
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.
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.
OKRs took off after a VC named John Doerr introduced them to Google, and the industry followed their lead. <a href="https://www.whatmatters.com/" rel="nofollow">https://www.whatmatters.com/</a>
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.<p>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.<p>Exceptions abound in the details.
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.<p>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<p>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.<p>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:<p>- large factory of British workers + British management: strife, strikes, disaster, bankruptcy (British Leyland)<p>- 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)<p>- large factory of British workers with overseas management: success (Nissan Sunderland, BMW era Mini, etc)
... do you think Japan doesn't believe in freedom and rule of law?
Fortunately, once we impose a wealth tax on corporations we can solve this. Billionaire corporations should not exist.
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.
That's too arbitrary, and you say that as if a billion dollars is a lot of money.<p>It's not.<p>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!<p>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.<p>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.<p>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.<p>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.<p>Losing track of that last bit, is when people stop asking "should we tax" and instead say "they have money, so tax"
Tax is not only that, it's a way of incentivizing growth in the "correct" areas (areas that build long-term value), and correcting inevitable distortions in the market. One of the problems with money is that it's both extremely important for some people (on the edge of poverty) and a complete plaything for others (investor class).
You write:
> 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.<p>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".<p>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.
We might presume that was the goal, yet it wasn't explicitly stated. And many have a goal of generic wealth redistribution, and will inject such into any conversation about large companies.<p>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.<p>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?<p>Should we tax so that "big ideas" may never occur?<p>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.
* Eliminate management by numbers, numerical goals. Substitute leadership.*<p>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.<p>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.<p>In short, corporate practices have systematically eliminated the circumstances under which there would grow a sufficient number of people with leadership skills.
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 <a href="https://en.wikipedia.org/wiki/Objectives_and_key_results" rel="nofollow">https://en.wikipedia.org/wiki/Objectives_and_key_results</a> , but my googling isn't always right.
I envy people that haven't had to deal with the OKR crap in "modern" IT orgs. :D
Yes, that's correct.
Maybe it’s my limited intellect but I found Drucker to be a lot easier to understand.<p>Where Deming reads like a science paper, Drucker reads like an installation guide.
Not necessarily limited "intellect", but rather limited background knowledge.<p>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.<p>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.<p>* - 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.
> Where Deming reads like a science paper, Drucker reads like an installation guide.<p>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.<p><i>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.”</i><p><a href="https://deming.org/explore/red-bead-experiment/" rel="nofollow">https://deming.org/explore/red-bead-experiment/</a>
Deming -> Strategy<p>Drucker -> Tactics
OKRs attempts to impose top down centralized command and control. What ends up happening is an executive who is accountable notices an OKR trends the wrong way and when he asks why, the best bullshitters deflect blame. And nothing is resolved.<p>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.
This topic is very relevant in the age of agentic AI when every decision is a statistical next token prediction “trained” on some loss function. AGENT.md, SOUL.md etc are just smoke and mirrors of The Wizard of the Oz.<p>Eventually manager as a profession will be replaced by tools, just like computer as a profession, editor as a profession.<p>The evolution of computer science will be manager science. There is more than loss function and KPI.
The analogy I used with the team was that, set the goal, present the map, and figure how to make a better map. Drucker was about the goal with a given map. It is not uncommon for people receiving the OKR not resonating with it. Sometimes they actually have insight into making a better map, but if OKR is OKR, one just have to follow, people swallow their thoughts
This made me spit out my coffee…<p><i>> One of the virtues of OKRs is that they are straightforward for managers to apply.</i>
Well it didn't say <i>successfully.</i><p>But truly there's nothing easier than putting a couple bullets in a document and saying, "Now go forth, underlings, and make these bullets ring true! If you don't, you're fired and without health insurance."
Talking about “virtues” of OKRs is a long stretch.
Optimize for mediocrity, you get mediocrity. Optimize for quality, you get quality.<p><i>Choose wisely.</i>
I think this article is a great opportunity to mention two under-used statistical techniques: Deming regression [0] and the Theil-Sen estimator [1].<p>They both fit straight lines to noisy data.<p>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 <i>everywhere</i> 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.<p>[0] <a href="https://en.wikipedia.org/wiki/Deming_regression" rel="nofollow">https://en.wikipedia.org/wiki/Deming_regression</a>
[1] <a href="https://en.wikipedia.org/wiki/Theil%E2%80%93Sen_estimator" rel="nofollow">https://en.wikipedia.org/wiki/Theil%E2%80%93Sen_estimator</a>
“ Drucker makes a manager’s life easier, Deming makes it harder”<p>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.
[dead]
[dead]
Or you can just abolish the fiat soft money system, let the corporations go out of business, let efficient small companies take their place and then you'd have founders who actually care about long term results in charge and they could manage the company however they want. If they do a bad job, they'd go out of business. If they do a good job, they'd stay afloat or maybe even grow a little. And over time, all the companies with incompetent leaders would be wiped out, everyone would get a fair shot at being a leader and everyone would end up in their rightful place and capitalism would function as it was designed.
You could read The Long Twentieth Century by Giovanni Arrighi.<p>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.<p>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.<p>So Fiat money and the financialization of life is just an outcome of something else - that being a monetary superpower is just not sustainable.
I don't live in the US but I'm definitely feeling the negative effects of the fiat system really harshly. From my perspective, I believe that the effects would be similar regardless of which country had the superpower status. Interlinked fiat currencies are just a perfect mechanism to allow militarily or economically dominant countries to manipulate the global economy in their favor. As a superpower, you can leverage corruption in foreign countries to load them up with debt denominated in your currency to allow you to export your inflation to them... You can also leverage foreign corruption to sign large, unjust trade deals or oversized military contracts which will prop up your currency.<p>Still, at the root, I blame the system itself, not specific participants.
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,<p>And replace it with what?