What Could we do Better?
Instituting a Management Improvement Culture in Your Organization
Find the Root Cause Instead of the Person to Blame
Good Process Improvement Practices
Management is Prediction
The Purpose of an Organization
Performance Without Appraisal
Manufacturing and the Economy
Practical Ways to Respect People
10 stocks for 10 years
Deming and Toyota
Curious Cat Management Improvement Articles
Institute for Healthcare Improvement
Management Improvement Jobs
Deming on Management
Management and Leadership Quotes
I am now using this blog to re-post some comments I make other blogs. For my full management blog see the
Curious Cat Management Blog
Create a Continually Improving Management System - not the Perfect Management Solution
My response to a LinkedIn question*
> Hi everyone, i have a question in relation to Lean, what steps will i
> take if i wanted to apply Lean to an engineering firm?
In most instances I think a PDSA approach to the approach to use it best. Test out various options in parts of the company. See what works. Build and improve the process and spread it more widely.
There are some advantages to a wholesale, uniform CEO led unified effort. But the drawbacks of a centrally driven process to start a transformation without a powerful CEO (or close, COO...) directly involved is likely to have problems.
Instead try approaches on smaller scale, build on what works, adjust based on experience
... Depending on how big you are many times different focus will be needed. What the call center uses and what the research department uses may be fairly different. There should be unified principles that hold true everywhere but honestly those are almost always useless words at first (in the cases where they actually start as real guiding principles that is great - it just seems rare in my experience).
A decade later maybe a company will really be guided by respect for people
, data based decision making, going to the gemba, customer focus
, continual improvement... And those really will be the core behind some fairly different processes in divergent parts of the company. But at first it is usually just word that don't connect to actions.
Some of the most important things about the initial plans (off the top of my head - I may be forgetting some things...) in my opinions are
- continual improvement - a rigid approach is likely to fail (unless you get really lucky). Build the plan with the idea that we are putting forth our first approximation and we will be continually evolving this approach. Therefore the plan most importantly needs to be adaptable based on what we learn (more important that being "right" at the start).
- a focus on experimentation and all that means (providing people training if needed, providing expertise if needed, understanding variation, using data properly...)
- go to the organization gemba and user gemba
- focus on accessing what is working and what isn't and adapt
- respect for people
My suggestions in a post for the Deming Institute blog
My suggestion in such a case is to start slowly, learn as you go and build on successes. Learn directly from Deming (the books and videos) and from other great books by those that worked with him. My favorites include: The Leader’s Handbook by Peter Scholtes, Fourth Generation Management by Brian Joiner, The Improvement Guide by Gerald Langley, Kevin Nolan, Clifford Norman, Lloyd Provost and Thomas Nolan.
Start using the tools (PDSA, control charts, flowcharts, cause and effect diagrams, visual job instructions, …), focus on respect for people and move toward evidence based decision making. Focus on doing a few things well. Don’t try to do everything at first. Concentrate on getting a few tools and new concepts well understood and effectively used in the organization. Then build from there. As part of this build an appreciation for systems thinking (seeing how interconnected things are is important to moving forward).
* I would link to the LinkedIn discussion but they chose not to provide sensible options (closed group anyway so you couldn't see the conversation). Even so a web site designed with usability in mind could make this work usefully (and use links that would work if the group discussion became public later). It is pitiful how poor huge internet companies are about programing usable websites.
Labels: business, evidence based management, experiment, leadership, management, systems thinking
System Imposing Burden on Customers Driven by Pointy Haired Boss
When Begging for Customer Service Scores Hurts Customer Service
I always think… you want patients to say you give “excellent” service and care… then focus on providing excellent service and care! Don’t guilt trip me or don’t manipulate me… that makes me feel a bit worse about the service, when that’s not the intent. Employees shouldn’t be put in the position of begging for scores… help them provide the best service possible, instead.
The practice of telling your customer they must save you from horrible management is terrible. Managers designing a system that puts a burden on customers to rescue people from harsh treatment is about as lame as management can be. Definite Dilbert's pointy haired boss level idiocy
Any company with this setup likely has little clue about how to use data. When you mistake the data for the proxy indication it is suppose to be a measure of
you can't manage at all. Giving huge incentives to people to make the number good (like having employees impose a burden on customers to have a number better which directly burdens the customer) is idiotic.
Relate: Managing to Test Result Instead of Customer Value
- Distort the data instead of improving the system
- Jiro Dreams of Sushi
Labels: business, customer focus, customer service, evidence based management, gemba, leadership, management, managing people, process thinking, psychology, systems thinking
The Tendency for Lean Experts to Distrust Technology
My thoughts on Why can't we use technology to accelerate Lean adoption across my company?
I think biggest objection is how often and badly technology efforts fail. This makes a knee jerk reaction against jumping to technology fairly wise.
I think the second reason is technology expertise is often not found in the same people that have lean expertise (it can be it just isn't super common). Combined that with number 1 and the fact that making technology projects successful requires great system (rare) or can be made more likely with a deep understanding of technology and management systems (but I just said they often don't have the tech expertise) so again a reason to shy away from tech.
If a good lean consultant saw the organization had great system for making technology projects, countermeasures etc. successful they would support such efforts even if they were weak on tech. I'll also say most lean consultants aren't great. They don't understand lots of stuff about respect for people, management systems, customer focus, gemba etc.. Due to fear I think many that don't have strong lean understanding will shy away from technology.
I think technology solutions can be great. There is nothing wrong with them, when conditions are right. Conditions are almost never even decent - forget right. Technology projects and efforts are much more likely to be messed up due to bad systems and lack of expertise.
Technology solutions can have huge impacts - there are many good things possible with technology. The problem is so often technology wielded inside organizations (human systems) fail for many reasons very closely tied to bad management practices. The better the management practices the less likely technology will backfire in my opinion. The stronger the management system the more likely technology projects will be managed sensible, tested at the gemba, adjusted by people with a strong understanding of the gemba, project managed by people with an understanding of lean thinking practices (deliver working code fast etc.)...
The fear of technology projects is those reasons and more. Things like the same problem with brain-dead implementations shoving down a horribly inflexible ERP program or shoving down a 10% across the board budget cut and many other such efforts. Technology efforts really are no different than others but there are some difficulty in the problems of technology often being more difficult for people to see.
Technology also is often seen as this wonderful simple quick fix by executives - letting them avoid the gemba and just put hope in a essentially magic bullet solution.
The whole effort to make problems visible is much less likely to be done well around technology (which has to do with some issues with the domain but also with the lack of technology expertise [especially software development] of management and decision makers). Lots of the efforts in lean software development and agile have very good practices for technology efforts.
Related: Deming and Software Development
- Involve IT Staff in Business Process Improvement
- Mistake Proofing Deployment of Software Code
Labels: agile software development, gemba, information technology
Respect for People Isn't Just Being "Nice"
Ex-Toyota Manager Consulting with Porsche in 1994
Interesting article from 1994. Shock therapy for Porsche
: The prestigious German car firm was speeding to destruction, so its chief swallowed his pride and hired Japan's top consultants to improve outdated methods of production. John Eisenhammer charts the brutal remedies they prescribed at the company's plant near Stuttgart:
The results are already impressive. The production time of the new Porsche 911 Carrera has been reduced by a third, to 86 hours. That is still some way behind the best comparable Japanese time of 50 to 60 hours, but Porsche claims to be well on target. Whereas 70 per cent of Porsches three years ago required expensive rectification at the end of the production line, the proportion is now half that. Inventory levels have been reduced by 44 per cent: 7,000 square metres of shopfloor space have been freed and rented out. A worker suggestion scheme, which in the past generated fewer than 20 ideas a month, has now exploded to around 2,500
While respect for people is an important part of the Toyota Production System, the practice of former Toyota managers were often the "tough love" variety
. Today, many people are often too timid, in my opinion, to call out things that need to be improved for fear of making someone uncomfortable. Where that balance properly lies though is based on the culture of the organization (and what needs to be done - occasionally there is a need to "shake people up" in order to make change take place more effectively).
In his own gruff way Mr Iwata agrees. 'We are not here to praise,' he growls. 'But there is hope for Porsche.'
Related: Early "Lean" Thinking
- Pay Practices Say More About Respect for People Than Words Say
- Respect for People and Understanding Psychology
- Respect for Everyone
Funny item from the story:
When not discussing production-line changes or conducting workshops, the Shin-Gijutsu people are ambushing staff. 'When I see one of Porsche's fine engineers, I do not say 'good morning',' grins Mr Nakao. 'I say, 'show me your hands. They must be dirty - engineers must always have oily hands'.' Used also to checking the soles of shoes worn by managers in the finance department, to see if they spend enough time walking around the factory, Mr Nakao was devastated to discover the trick did not work with Germans, who are used to resoling old shoes. 'We do not do this in Japan,' he says. 'How can I see if a man is doing his job properly if he keeps changing his soles?'
It is also illustrates that your practices need to adjust to the system. Time at the gemba
is important and transfers. Your specific means of checking that might have to be adjusted.
Labels: gemba, lean thinking, management consulting, manufacturing, respect for people, Toyota
The damage caused by "Management" by targets is much larger in dysfunctional organizations
The damage caused by "Management" by targets
is much larger in dysfunctional organizations - they are also more likely to be given more importance by dysfunctional organizations, that is a bad combination. In a great organization with an strong understanding of systems, respect for people, no pay based on "performance," an understanding of data and variation... then damage managing by targets does is much smaller. But the number of those organizations is not huge.
Reaction to: Target Setting, Cause and Effect
Related: Setting Goals Can Easily Backfire
- I achieved my goal by not my aim
- Be Careful What You Measure
- Targets Distorting the System
Labels: business, data, Deming, evidence based management, goals, management, motivation, process improvement, process thinking
What Works for One Business May Not Work For Others
Lean Thinking at Amazon
My comments on Michel Baudin's post discussing lean, service and Amazon
Unlike other Shmula readers, I can't jump from this to the conclusion that Amazon are based on Six Sigma or Lean. Instead, what I hear Bezos saying is "We studied what's out there, and went our own way." And that way is a game changer in retail worldwide, worthy of study in its own right...
It is interesting to see what Amazon continues to do. I think you are right that they have learned good things and are applying them their way. Often Bezos does what I see as much more fundamental lean thinking
than those that spout the term a great deal.
For example: Bezos going to the gemba
, Bezos root cause analysis
... Bezos understand the weakness of traditional accounting more than most any executive (he was a Wall Street analyst), this is way more important than I ever see mentioned in what makes him, and Amazon, different.
Bezos practices long term thinking
better than nearly every "lean" company (though Toyota, and some others do this very well). From this mindset many things spring - focus on long term customer value, invest in value stream (Amazon's purchase of Kiva robots for example). Willingness to go against the current fashion, being directed by Wall Street analysts what is in the businesses, etc..
There are also job announcements, over the years, looking for lean experience and expertise I have seen from Amazon (which is a clue they are interested in lean).
Labels: business, customer focus, innovation, lean thinking
Hopefully Other Countries Will Save Us From USA's Attempt to Sell Us Out to Aid Big Political Donors
The Trans-Pacific Partnership has been atrocious. Essentially the USA has been strong arming other countries into secretly selling out their citizens to provide benefits to large USA political donors. The Obama administration has once again done the opposite of being the open and honest organization candidate Obama promised.
The hopes of stopping the corruption of the USA political system, in this case, wrests with other countries protecting their citizens (and the citizen's of the USA from the corrupt practices. Vice President Bidden seems particularly focused on paying off his donors and friends with this horrible treaty. The USA administration realizes the selling out the innovators and rights of citizens for large political donors is so toxic it would likely not survive if there was the transparent government candidate Obama promised.
The TPP should be stopped. I would not trust politicians that don't speak out against it publicly now. Politicians have become adept at hiding what they promote behind secrecy and misdirection. Many are hoping they can hide behind the secrecy around the trampling of innovators and citizens in the TPP to pay off their donors while claiming the appose the horrible policies of the TPP. If they are not speaking out now, all they are doing is taking advantage of the secrecy the Obama administration has made its policy for trying to hide government action that harms the country from public view.
The Trans-Pacific Partnership being pushed by Washington is nothing more than a corporatist power grab
by William Pesek.
American lawmakers and civil liberties groups have complained for some time about the opacity surrounding the treaty's terms. Mild grousing turned into outrage last month after WikiLeaks did what Barack Obama's White House refuses to: share portions of the document with the public. The draft of the intellectual property rights chapter by Julian Assange's outfit validated the worst fears - that TPP is a corporatist power grab.
Rather than heed the outcry, the US doubled down on secrecy, refusing to disclose more details.
Hasn't the US wondered why so many of east Asia's most promising democracies have avoided the treaty? The popular excuse for why Indonesia, the Philippines, South Korea, Taiwan and Thailand aren't among the 12 TPP economies is that they aren't ready or are trapped by their own timidity. A better explanation is that their leaders realise that truly transparent and accountable governments, to borrow Kerry's own words, shouldn't be leading their people into the unknown.
The root cause of this situation is the corrupt USA political system
. At a bit less abstract level the TPP seeks to worsen the deadly diseases of the broken patent and copyright system
(and also worsen the broken health care system). The TPP is an attempt by those that understand systems thinking to mold the system in secrecy to benefit those giving USA politicians lots of cash. We can only hope that other countries are not willing to do the bidding of the USA in this case (though the USA is willing to provide incentives and threats to allow it to deliver for those giving USA politicians cash
Related: Intellectual Property Rights and Innovation
- The People We Elect Recently Are Dramatically Falling Us
- Cash for Votes subreddit (political corruption)
- Why Copyright Extention is a Very Bad Idea
Labels: business, copyright, government, information technology, innovation, society, techonology, trust
Risks Should be Taken Wisely
I agree. I think it is wise to understand you are willing to take certain risks in order to improve and innovate. Sometimes things might not work out. That doesn't mean you don't do what you can to mitigate the impact of things that don't work out.
It does seem to me the "accept risk" (fail fast, accept failure...) folks would be better served to focus a bit more on mitigating the results of failure. Sure accept risks when you determine it is worth taking the risk due to the benefits.
I wrote about this earlier this year: Taking risk, but do so wisely
Accepting risk doesn't mean failure is good. And it doesn't mean the results of experiments are all blameless. You can do a poor job of taking risks. If that is done, we should learn from it and improve how we take risks going forward. I would also put my focus process over people (what, good and bad, can we learn about how we did this experiment or took this risk to do better experiments and risk taking going forward).
In response to: To Blame or Not to Blame
Related: Find the Root Cause Instead of the Person to Blame
- Blame the Road, Not the Person
- Respect for People Doesn’t Mean Avoiding Any Hint of Criticism
Labels: business, design of experiments, evidence based management, experiment, innovation, process improvement, systems thinking
Lean v Innovation is a False Dichotomy
The whole idea that process improvement efforts are harmful to innovation frustrates me. It is due to misunderstanding what is labeled as process improvement. Lean isn't about just making whatever process exists less wasteful. Lean focuses on value added to customers but people forget that.
A separate idea people have is that in order to improve processes you need to improve all of them the same way. Wrong! The way you improve the internal operations of a fast food restaurant are not going to be the same things you do to improve a think tank or research lab. But both have processes. The results of both can be improved by improving how the systems work.
Yes a think tank or research lab would not be served well by the same types of processes as a fast food restaurant. And a fast food restaurant wouldn't be served by the type of process improvement that would benefits a research lab.
I have written about this several times, including:
Response to: Lean v. Innovation…Wrong Question!
Related: Clayton Christensen on Innovation and Macro Economics
- Accept Taking Risks, Don’t Blithely Accept Failure Though
Labels: innovation, management consulting, process improvement, process thinking, systems thinking
Pilot on a Small Scale First - Good Advice We Often Ignore
Response to: Pink NFL Penalty Flags Surprisingly Cause Confusion
This is an example of why piloting new ideas is wise. The truth is we often don't pilot stuff. Many times it works out fine (and no-one mentions we didn't pilot it on a small scale). When you don't pilot and it then fails on a big scale this is the question, I think.
Were we bozos for not seeing the risk - looking back is it a pretty strong case we should have piloted.
If we often don't pilot and it works 99 times out of 100 it may be we are pretty good at knowing what needs to be piloted and excepting some failures is ok in order to get things done. Part of the decision that is critical is making sure you don't fail to pilot when it is really costly to be wrong (which is part of the decision on whether to pilot).
We can just always point to failure to pilot as the dumb thing to do when it fails. But I see that as a bit overly simplistic. Many organization don't pilot well. Getting them to do so all the time would likely stop you from doing better stuff. Getting them to do so when
- there are likely to be be things we should learn
- there are significant questions about how it would work
- the costs of widespread failure are large
- we can't consider the potential risks and make a judgement that there is likely not to be a problem
Piloting on a small scale is best. It is what I recommend and encourage. I just think seeing the failure to pilot as a cause of the widespread problem is too simplistic. Why did we fail to pilot needs to be the next question - don't stop at the failure to pilot as the root cause. From there you will nearly always discover, unless maybe you are Toyota or the Kaizen Institute or something :-) that your organization consistently fails to pilot before adopting on a wide scale. Then you need to dive into that issue...
With this particular example it seems to me one that could have been thought about rationally and a decent case that we don't need to pilot could have been made. And that illustrates that there is always a risk to implementing without piloting (there is a risk of doing it anyway including a very big one of failing to catch the problems because your pilot failed to capture some important features (for example - you didn't think of the need to pilot with pink towels... - this would be an easy mistake to make).
And it shows why thinking about pilots is important - which is another thing we often fail to do, considering how to make the pilot cover the risky scenarios that may take place. Sometimes organizations will use certain locations to pilot stuff which can be useful - you can train these locations to provide good feedback, etc.. But as soon as you make the pilot locations different than were it will be done there are risks of not catching things.
It is the interaction of variables that often creates problems which it was this time. Pink flags meet the initial criteria of being noticeable. The interaction of putting many other pink items into play (certain jerseys, towels, etc.) is what seems to be the issue.
Related: What is the Explanation Going to be if This Attempt Fails?
- Accept Taking Risks, Don’t Blithely Accept Failure Though
- Management is Prediction
- Combinatorial Testing for Software
- European Blackout: Human Error-Not
Labels: business, coaching, Deming, evidence based management, experiment, leadership, lean thinking, management, process improvement, process thinking, quality tools, systems thinking
Early "Lean" Thinking
"There are some who criticize the 'early days' of the Lean movement as being too focused on tools. But, I’ve re-read a lot of the early material and this is not the case
." - Mark Graban
Exactly right. It seems to me it was when the first "lean manufacturing" fad wave hit and you had lots of people (that didn't study and learn what it was really about) quickly churn out their oversimplified "lean manufacturing" cookbook tool approach. That is when the tool approach took off and because it is easy to train people on tools that has always been a popular way to sell services to companies.
It is really just putting new tools into the existing management system instead of adopting new management thinking which is what the people that actually studied "lean" were doing and talking about. The tools can be helpful but it is a very limited approach to "lean" (if you can even call it that - really it should be called using a couple of lean manufacturing management tools). The initial people who studied Toyota, and other companies in Japan (mainly), understood it was a different
way to manage - not just using a couple of tools.
But it was hard to figure out how to actually do it (getting management to improve is hard - it is easy to sell management some training that will "make workers better"). It was easy to offer training in setting up QC circles and how to use various tools, so much of that happened. The biggest change in the selling lean training is you no longer see people selling QC circle training, they now sell other tools.
Here are some early reports (so early it preceded the lean terms widespread use). It also means the focus hasn't already been set by the Machine that Changed the World
but it is the same stuff that those that studied in 1980, 1990, 2000 or 2013 saw - it is more about respect for people and using everyone's brain than any specific tool. And these articles have a bit more focus on using statistics and data than much of lean literature today (partially because George Box
and Dad were statisticians and partially, in my opinion, because current lean literature is light on using data).
Peter Scholtes report on first trip to Japan
Managing Our Way to Economic Success: Two Untapped Resources - potential information and employee creativity
by William G. Hunter, 1986
How to Apply Japanese Company-Wide Quality Control in Other Countries
by Kaoru Ishikawa. (November 1986).
Eliminating Complexity from Work: Improving Productivity
by Enhancing Quality by F. Timothy Fuller, 1986
On Quality Practice in Japan
by George Box, Raghu Kackar, Vijay Nair, Madhav Phadke, Anne Shoemaker, and C.F. Jeff Wu. (December 1987).
The early lean stuff was much like what is discussed there (though these were before the "lean" term had taken hold). These were all first published as reports at the University of Wisconsin - Madison Center for Quality and Productivity Improvement
founded by my father
and George Box.
While the format of the documents may be a bit annoying thankfully they are actually available, unlike so many articles supposedly meant to stimulate better management practices (look at major "associations" that don't even make articles available online without a blocking paywall preventing the articles from doing much good).
Related: Management Improvement History (2004 post)
- Early History Of Management Improvement Online (2007)
- Transforming With Lean (2007) "Successful management improvement is not about mindlessly applying quality/lean tools."
- "The tools are very helpful but the change in mindset is critical. Without the change in the way business is viewed the tools may be able to help but often can prove of limited value."
Lean Thinking and Management (2006)
- From lean tools to lean management
by Jim Womack, 2006 - I would link to the original article but it is gone :-(
Labels: Deming, employees, experiment, lean thinking, managing people, manufacturing, process improvement, process thinking, quality tools, respect for people, statistics, systems thinking, Toyota
Mistake Proofing and Mistake Making Less Easy
Kanban And Lean - A Challenging Association
I've come to refer to American Lean literature as "Boston Lean" to clearly differentiate it from Toyota materials generally translated from original Japanese. What makes me uneasy about Boston Lean is its focus on "the pursuit of perfection" through "waste elimination" where waste is "muda" (or non-value-adding activities). The typical Lean consulting firm, and again, I find myself mentioning, McKinsey, offer Lean through a defined approach that involves value stream mapping, identifying non-value-adding activities in the workflow, designing out those activities and then managing a change initiative to install the new, leaner process with the waste designed out. Like yesterday's post, my objection is to the process-engineering-centric approach and the notion that the process engineer knows best. This designed and managed change approach is truly the antithesis of of the Toyota kaizen approach where the workforce is empowered to make their own changes and processes evolve.
I think your kanban ideas are excellent. I think you are defining "Boston lean" to really be badly done lean. There is a lot of badly done lean - just as it seems to me every management system is poorly executed very often
(specific practices or management tools can be adopted quite successful fairly frequently but overall system just are not, from what I have seen). I am not sure if management ideas are necessarily poorly executed so often but they certainly are quite frequently.
There are tons of great lean blogs by people based in the USA (Jon Miller
, Mark Graban
, Kevin Meyer
, Jamie Flinchbaugh
, Tracey Richardson
, Mike Stoecklein
, Bill Waddell
, Bob Emiliani
...). If people read what those people are doing and saying I don't think any of the negatives of "Boston lean" are present.
I am guessing "Boston lean" is a swipe at the Lean Enterprise Institute
(since they are based in Boston). I don't really think that is accurate. It seems to me LEI support lean done right - a system that help employees improve, not some top down dictate approach. I agree with you that much of what is called lean is bad management. I think LEI and those I listed about (and many more) practice lean as it should be, and I don't think that practice of lean has the drawbacks you mention.
Related: Lean Manufacturing and the Toyota Production System
- Why Use Lean if So Many Fail To Do So Effectively
- Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said
====== David's comment on his blog ===========
Please take the time to observe what Lean consulting firms actually do. Do they sell managed transition initiatives that involve value stream mapping, designing out the waste and then deploying the expert designed "lean" (waste reduced) process definition? If you can refute that this is actually not what they are doing and how they make their money, then we can talk. Please show me the case studies where a true kaizen culture has been coached into organizations by these firms? Please show me the evidence where the workforce are empowered to perform their own kaizen events and that the consulting experts involved didn't actively design the new processes and manage the transitions.
====== my response to David's comment =======
You can look at what the people I suggested are doing, or you can chose not to. I am just suggesting that you would benefit from looking at them. I don't feel it is my job to provide the evidence packaged up for you. I also understand you have no reason to listen to anyone unless you feel like doing so.
I think your claims are what I said, looking at bad implementations calling themselves "lean" (and as I said, there are many) and defining that as Boston Lean. That is your right but it isn't so useful it doesn't seem to me. The main problem I see is that you seem to have missed all the good stuff being done with lean in the USA - that is your right, but I think you are missing a good opportunity to learn from others good work.
A great deal of great work is being done with the real lean principles -- respect for people and continuous improvement
-- in the USA, and it has been done for decades.
You can ignore the good work being done by some because there is lots of bad stuff labeled lean. I just think the great stuff being done is useful and those interested in managing their organizations better would benefit from paying attention to the people doing good work (the ones I mention above and plenty of others).
Labels: agile software development, lean thinking, management consulting, process thinking, respect for people, systems thinking
Twice the Cost, Significantly Worse Results - The Sad State of Health Care in the USA
Why Is the United States So Sick?
Americans die younger and experience more injury and illness than people in other rich nations, despite spending almost twice as much per person on health care. That was the startling conclusion of a major report released earlier this year by the U.S. National Research Council and the Institute of Medicine.
Not so startling if you have paid attention the last few decades. The deadly disease of excessive health care costs (with, as Deming noted, the bad results that come from poor systems that are bloated with cost, waste and poor quality) has been a huge problem for decades.
The newest part of the breakdown is how even the massive spending in the USA has not been successful in even keeping the USA at a mediocre level compared to other rich countries. It was maybe arguable the results in the USA were no worse than average 20 years ago. It is getting impossible to make that claim today. Twice the cost, significantly worse results. Eventually you would think people would get tired of excuses.
The poorer outcomes in the United States are reflected in measures as varied as infant mortality, the rate of teen pregnancy, traffic fatalities, and heart disease. Even those with health insurance, high incomes, college educations, and healthy lifestyles appear to be sicker than their counterparts in other wealthy countries.
Related: USA Spends $7,960 Compared to Around $3,800 for Other Rich Countries on Health Care with No Better Health Results
- Can We Expect the Health Care System in the USA to Become Less Damaging to the Economy?
- Measuring the Health of Nations (USA ranked 19 of 19 rich countries)
- CEOs Want Health-Care Reform (2009)
- posts on the health care system on my management blog
Labels: government, health care, society, software testing
Giving and Accepting Advice and Feedback
Reaction to: The Trap of False Hypocrisy
When you are getting feedback or advice the most important factor is if you can use it effectively.
When you giving feedback or advice the most important factor is doing so in a way that is most likely to result in it being used effectively.
When you get feedback or advice that isn't particularly well delivered (lets say much delivered in way that is much worse than the example - even cruelly given). Your reaction (if what you care about is getting better) should be based on what would help you be better, not the form the advice takes. If what you care about is doing what is suggested in a good manner (which may even be lousy advice) then your reaction should be baed on how they give feedback, or advice to you.
People are affected by how advice is given and in fact how much they like the person giving advice and whether they think the advice is good or not. Those are factors to consider in giving advice. In my opinion those are factors to overcome in accepting advice. If I miss good advice because the person delivers it inelegantly or I don't like them or whatever it is I who lose.
If the core issue the person raises with feedback is something you should address, do so. Don't have that determined by how successfully they gave feedback. In the post one of the issues I think Benjamin was trying to address was providing better feedback and in encouraging logical thinking. Both of which are worthy and make sense doing. I would say that is a 2nd issue. Issue 1 is if the feedback has merit. Issue 2 is if the feedback provided could be improved and if the logic behind the explanation of the feedback is good.
As I said in a previous post, I believe you should evaluate advice on merit, not whether the advisor follows the advice
Related: The difference between respect and disrespect is not avoiding avoiding criticism
- Respect for People, Understanding Psychology
- I would much rather hear that someone felt a proposal won’t work
than have them be quiet because they don’t want to be seen as negative
=== more thoughts, based on James' comments
on my comments above ===
James, I agree with your thoughts. One of the things I continually struggle with is completely presenting my thought in writing - normally I think of 4 caveats I should make then what I say is so long I get tons of complaints it is too long. In general I have tried to reduce that. But I often leave things with too much imprecision (that is too much that is/can be wrong). Trying to be clear, complete and conscience is something I still need lots of work on. Your points about really most isn't right... are exactly my thoughts.
I think not wanting to take the "time to process hostile feedback" is something everyone does though often with less self awareness. And it extends beyond "hostile" to any type that is hard to process (different people have different points they struggle with most). If it is too much bother to figure out why this is useful (logically, emotionally...) we don't want to deal with it.
We will seek out people that we work well with. We will pay more attention to feedback from those who have given us feedback in the past that we used to make a change and saw a good result (either because they are perceptive in seeing the problem, skilled at presenting the case to us, skilled at showing us a way forward, skilled at providing feedback we can actually use (you can give me all the feedback in the world about how to be a better pro basketball player I am not going to be able to use it effectively).
And much more we will block, ignore and deflect feedback we don't want - whether it is hostile, confusing, impossible for us to figure out how to act on, unconvincing... That is why, if you care about having your feedback listened to you often need to design it for the person you are talking to - do they want it all dressed up with compliments about their overall wonderfulness, do they want you to provide some possible options for doing things differently, do they want you to explain the impact of the issue...
I think most people are frustrated with feedback that "takes too much energy and time to process." I think this is why there is so much talk about giving effective feedback. I see too little talk on how to take even effectively given feedback and use it to improve, which is a big part of taking too much energy to implement.
My opinion is that many people have trouble processing the feedback they get, but even more so they have trouble figuring out what to do with it even if they could understand what the issue was (I have a feeling that isn't nearly as big a problem for you but I am just making guess). Even if they can really see what could be improved, turning that into actual improved performance is often not easy.
There are lots of details to consider in order to provide effective feedback. If your goal is to get the feedback used (such as when you are coaching an employee) I think it is often wise to spend the most time on helping people with process of improvement. If people get feedback they can easily use to improve and they can see the results they often want more. The same ideas as your "feedback into information I can use."
And when I say "they can see the results" that again is an indication that it might be an effort to improve feedback in an organization will be enhanced by increasing people's ability to see results (which to me is about understanding data, understanding processes, customer focus, systems thinking...).
Well I went on far to long and it is still not very clear I don't think but, that is the best effort I could make today...
Labels: coaching, management, managing people, systems thinking