People and Robots Together

Comments on: The Coming Auto Industry Battle: Toyota’s People vs. Tesla’s Robots?

Toyota's method is the best and will continue to be.

However, I believe we have reached a turning point where the effectiveness of industrial robots has greatly improved. For several decades it was pretty easy to predict wholesale adoption of the robots will save us mantra would be followed by failure. I still strongly believe Toyota's method (thoughtful use of robotics to enhance people is the best strategy). But the ease of using robots to succeed in the long term is much enhanced these days.

Robot first strategies are going to be succeeding quite a bit going forward. Yes those efforts might not be good enough when competing only with companies using the best strategy well (but that will be rare).

I wrote some about this in a recent blog post: Technological innovation brings great opportunity for improving results and our quality of life. But transforming potential benefits into real results comes with many challenges...

Essentially I see people today too dismissive of the usefulness of industrial robots. And they have past examples to point to in showing how a large commitment to robot first failed. It isn't that today robot first is the best strategy but I do believe the real world conditions have improved to make the blanket assumption that such efforts will fail as unwise.

A big part of this is that while we can simplify the argument to "robot first" or "robots helping people" it really isn't that simple. There are many reasons why today the conditions are different than they have been. Technological and software improvements are a big part of that. But also there is more thoughtful consideration of the advantages Toyota's management philosophy brings. Sadly not enough, but still companies are better today at thinking and acting as if their employees have brains than they were 30 years ago. Granted there is still a long way to go, but still progress has been made it seems to me at the macro level.

Related: GMs huge investment in robotics in the 1980s ($billions) has been an example of how pinning hopes on technology often doesn’t produce the desired results. - Toyota Develops Thought-controlled Wheelchair - Two resources, largely untapped in American organizations, are potential information and employee creativity.

Code Software to be Robust and Easy to Update Quickly

Comment on: Correction vs Prevention in Software Development

I think both prevention and designing the software and management system so that rapid correction is possible are important. While rare events may be difficult to prevent when looking at each instance there are styles of coding that make more "edge case" failures more likely. Coding so that the system is as robust as possible is wise but you should also realize those efforts will likely not be perfect and so designing in visible notifications of failure and coding so rapid correction is possible is necessary.

In addition to the need to update quickly for bugs, software should be easy to update due to changing requirements and to aid in continual improvement efforts.

Related: Improving Software Development with Automated Tests - Software Supporting Processes Not the Other Way Around - Building a System to Reduce Interruptions for Software Developers
- Use Urls: Don’t Use Click x, Then Click y, Then Click z Instructions

The Sociology of Organizational Change

Comments on: Researching Laggards

The Late Majority is the stabilizing force, the repository of institutional knowledge that slowly absorbs and productionizes the ideas proven to best serve the organization. They aren’t as eager for change as the Early Majority, but they’re happy to adopt proven practices.

The Laggards provide challenge the Instigators most directly, questioning or outright denying the value of a new idea, and provide the most vocal and active resistance. However, their direct criticism may inspire the Instigators to find unexpected common ground and more effective solutions than they otherwise might.

Yes, I think laggards really are common. The grey area between laggards and late majority may be pretty large. Many are swayed by the critical mass of opinion. At first they seem like laggards because they side with them, as the momentum grows they side with late majority...

True active laggards fighting well after the critical mass makes it obvious the culture expects the "new" behavior" isn't a huge group I don't believe. But getting the point where the those siding with laggards switch to siding with late majority is a very challenging point to reach for most significant changes.

How you help change the culture of an organization requires understanding the inertia against change in most organizations and the strategies that are useful in creating the critical mass to accept new ideas and cultural attributes as the new normal.

Related: Why Do People Fail to Adopt Better Management Methods? - Podcast: Building Organizational Capability - Culture Change Requires That Leaders Change Their Behavior - Transforming a Management System – A Case Study From the Madison Wisconsin Police Department - Change Management: Create a Culture Seeking Continual Improvement or Use Band-Aids? - Communicating Change - Building Adoption of Management Improvement Ideas in Your Organization - Grow Your Circle of Influence

Iterate to Continually Improve

Thoughts on: The Challenge of PDSA: Feeling Like You’ve Fallen Short

For me, this snowball was the understanding of the continuous improvement cycle, the iterative process towards ideal state or what many call “true north.” I have seen and explained the well-known visual many times; the person climbing up towards target state and, ultimately, ideal state through PDSA, only seeing ahead of them as far as the flashlight reaches.

The relationship of PDSA iterations and ideal state never really dawned on me while I was working through PDSA cycles in problem solving. The visual depicts the learner stair-stepping up through PDSA cycles, each step up the flashlight seeing further, learning more and getting closer to ideal.
...
In absence of a clearly defined Target state, satisfaction with progress, pace, and incremental improvements may more times than not, leave you feeling as if you have fallen short.

Iteration and continual improvement are key. Understanding that "target state" is a temporary target is important. If a "ideal state" is too specific it can hamper innovation. This usually isn't so critical on fairly short term PDSA (except in those cases when we should look at innovation instead of improving the current process).

The PDSA process doesn't hamper innovation. But, when people set in their minds ideal states or targets that they move toward and don't see those as flexible based on new learning they can stunt innovation.

Related post: Resources for Using the PDSA Cycle to Improve Results - Continually Improving Using a Focus on Delighting Customers

Don't Claim Your Customer's Suffering from Your Management System Results are a "Learning Opportunity"

From, Microsoft finally admits that its malware-style Get Windows 10 upgrade campaign went too far":

It’s all well and good for a corporation to promise that its learning from mistakes, but it’s awful hard to believe such promises when the mistakes in question violate basic principles of software design and customer service

They are exactly right. This is one of the huge problems with the "learning from mistakes" excuse. Some mistakes are a sign of an extremely bad management system.

If you force the consequences of mistakes on your customers making up excuses about how this failure is a learning experience for you is only ok if you actually spell out how you are changing to assure you don't fail your customers due to this same management system failure again.

You need to design your systems to minimize consequences to customers when something goes wrong.

Acting as though a problem is due to some specific issue only with the exact circumstances that created the consequences is exactly the message you expect from businesses that have no respect for customers. It is exactly he cover your butt mentality of organizations you definitely do not want to be a customer of.

We need to stop accepting transparent excuses that indicate no acceptance of responsibility for mistreating customers. This wasn't a mistake about updating software. This was a mistake of a management system that allowed colossally customer hostile action to be taken and then continued and accepted meaningless excuses as if they were relevant. Microsoft manages to fail even the extremely low expectations we have for them over and over again.

I was foolish enough to continue to use Skype after Microsoft bought them. I added money to my account so that I would have access to Skype on my trip to China. 3 minutes into my first phone call they disconnected me. They then put up the most customer hostile form I have ever seen. I literally have over 30 questions that were required to be answered (things like what month and year did you sign up). I can't remember them all but at least 15 were insane to expect any customer to know. Needless to say they provided no way to contact them outside the ludicrous form. You can't have such repeated massive failures of basis common courtesy for decades without a horrible management system being in place.

It is so frustrating that such customer hostility is allowed to continue. Microsoft has a massive, decades long problem with treating customers horribly and making excuses for decades. This is just one more example of that pattern. Supposedly they are less horrible today than 20 years ago. Maybe that is true but they give me no reason to want to test out if that is true with their well publicized continuing of their customer hostile patterns.

Sure Apple's very poor software quality over the last 5+ years makes me frustrated with them. But Microsoft is much much worse so I have no desire to make from Macbook to any Microsoft software. Google has issues but if they would target users that don't have (or want to rely on) great internet connections to use their computer I would consider them. Ubuntu is the leading solution Apple has pushed me into strongly considering. The biggest issue I have not is the hardware for Ubuntu just isn't nearly as good as MacBooks. Granted the latest MacBook hardware choices Apple made are somewhat lame, but still it is much better hardware than others offer. Sadly it is stuck with their bad software and combine that with the sky high prices (the old MacBooks were expensive but well worth it) I just don't think I will buy another. While less than great I think one of the Dell laptops is in the lead for my next laptop.

You can't allow your business to treat customers horribly if you don't have a monopoly (or monopolistic position). Sadly for those stuck with Microsoft, they have close to that monopolistic position and rely on that. They have an extremely long way to go just to stop treating customers horribly. And treating an inexcusable failure as something they are learning from is yet another indication they are not learning at all.

Related: Practicing Mistake-Promoting Instead of Mistake-Proofing at Apple - Making Life Difficult for Customers - Incredibly Bad Customer Service from Discover Card

Don't Use Targets as a Management Tool

comments on: Deconstructing Deming XI B – Eliminate numerical goals for management


I agree with the comments that targets are unwise. There is one sense in which I think the idea of (but not actual) targets can be useful and that is in setting the scope.

If we want to find an improvement that is immense (versus small continual improvement) that can set the expectation of how we approach improvement, including an understanding that we are going to have to really make big changes in how things are done.

I have written more about this, here:

Deming on Targets

Basically I don't see that scoping "target" as really a target but it is similar so if you want to see it that way, then in that sense I can see a "target" as useful.

Related: Innovation at Toyota - Targets Distorting the System - Righter Incentivization

Root Cause - Addressing Systemic Causes Not Symptoms

Comment on Just Ask Why Five Times? Effective Problem Solving for #Lean or #LeanStartup Doesn’t Start or End There

> Would you agree that complex systems rarely have a single root cause?

Yes. And also "root cause" is a neat concept but in reality it is not usually "true" but an a sensible acceptance of a cause that is systemic enough and addressable enough to consider "root." It isn't that there is this "true root cause" that created the current problem. There is a way to look at the issue and find a deeper cause that will allow you to address it and improve the future performance of the system.

Depending on how you look at the problem there can be many different "root causes" that are sensible from their different perspectives. The important thing is by aiming to fix root/systemic problems you will not just treat the current symptom you are dealing with today but eliminate future problems from occurring. If you are doing that, you are doing well.

If you start noticing that you are addressing problems that could have been addressed in previous attempts to address root causes, you can exploring whether going further in each attempt makes sense. It isn't as simple as this but if you notice you addressed a systemic problem at the "branch" level effectively for example. So if you had 3 fixes that did stop future problems on each of the branches but on the fourth fix you looked and said hey all 4 of these connect to this larger branch (or tree trunk - which is connected to a real "root") I would say asking if you should have addressed the "next why" may well make sense.

Related: Root Cause, Interactions, Robustness and Design of Experiments - Address the Root Cause Instead of Finding the Person to Blame - Poor Results Should be Addressed by Improving the System Not Blaming Individuals - Firing Workers Isn’t Fixing Problems - Examine the System, Don't Look to Blame a Person - Why Do You Ask Why?

Spend More Time Doing What You Do Well

Comment on: Is it Better to Work on Strengths or Weaknesses?

As you say to the extent your weaknesses are things you have to do spending time improving them usually makes sense. I think often the most productive thing is to spend time working on the system to maximize the use of people's strengths and minimize the use of their weaknesses. This often has a big impact without much effort.

And when you do that it is often the magnitude of strengths that makes a big difference. So you can avoid dealing with much of the weaknesses in the team and focus most effort on the strengths. And when you do that my getting even better at x allows the improvement not to just be x * 1.1 but (x * 1.1) + (y * 1.3) + (z * 1.4) - (if say I am now 30% "better" than y at the task and 40% better than z. Obviously it doesn't work so cleanly in the real world but that concept that you can get way more improvement normally by adjusting the way work is done than just by having everyone get less bad at the stuff they really should avoid doing most of the time.

You do also have to pay attention to the long term, so if someone wants to move into supervision but has some weaknesses they need to address and strengths to improve working on that makes sense.

Related: Take Advantage of the Strengths Each Person Brings to Work - Helping Employees Improve
- Many Good Employees Want to Continue to Do Their Current Job Well - Lessons for Managers from Wisconsin and Duke Basketball

Learning From Process Improvement Efforts

Comment on: How to Improve (at just about anything)

1. The classic way:

Do – make an improvement
Do – change a process
Do – implement some training
Do – install a system

When you have been through the 4 do’s keep right on doing.
2. The recommended way:

Plan – develop an idea or innovation, work out how you will implement it.
Do – carry out the plan on a small-scale, test it to see if it works.
Check – study what happened, did the plan work? If not why not? What can you change?
Act – adopt the change and roll it out, abandon it or learn from it and adapt it.

Another huge benefit to the PDSA cycle in my experience is to learn. I can't remember how many times I would see in the do-do-do-do organization that

do#1 was x
do#2 was y
do#3 was x again
do#4 was z
do#5 was y again

Um, ok, yeah why are we trying things we already know don't work (they are presented as fixes not, as well this old way wasn't great but jeez it was much less bad than the mess we have now so lets go back). Why are we thinking x is going to work when we just dumped x because it wasn't working? PDSA makes you think about the process, study the historical data and document your predictions. The learning will

Related: How to Improve - Document Your Decisions to Learn More Effectively - Learn by Seeking Knowledge, Not Just from Mistakes - Write it Down

Deming Wanted Managers to Understand the Systems They Managed and to Visit Where the Work was Done

Comments on Deming wasn’t a fan of Management by Walking Around

Deming’s view is entrenched in Lean management practice in the form of “Genchi Genbutsu”, literally “go and see” at the “real place”. Where practitioners of Management by Walking Around merely visit the workers for a chat, practitioners of Genchi Genbutsu stay with the workers to understanding what is going on.

True, and the details you provide are important. It wasn't managers going to the gemba Deming was against. What mattered is the system. Some people did Management by Walking Around (MBWA), even decades ago, in a useful way - with understanding. But most did not.

Gemba walks are much more likely to be useful (because the expectations are for a more engaged leader) but there are plenty of times those are not done well, and are no better than bad MBWA. Jim Womack has a book out on Gemba Walks which provides good details to managers on what they should do (and what Deming wanted them to do).

Related: Out of Touch Executives Damage Companies, Go to the Gemba - Leadership and Management - Jeff Bezos Spends a Week Working in Amazon’s Kentucky Distribution Center (2009) - Customer Gemba

Building a System to Reduce Interruptions for Software Developers

I feel strongly about the damage done by interruption to maker's focus. My appreciation for this damage to system performance was greatly enhanced as I became a software developer.

In my work prior to software development I could see that interruptions were not ideal but they were not so damaging to my work and they do also have value. But work that requires extra focus, and software development sure did for me, the damage increasing greatly.

Over 20 years ago at the Madison Area Quality Improvement Network they had a simple visual management sign at everyones office and cube. You could dial between various settings - GREEN available (free to interrupt)... RED busy, don't interrupt... There were 3 to 5 settings. It worked very well for them.

Of course such a system is highly dependent on the overall management system. Just putting that up in most offices would likely fail. MAQIN was an organization that embodied modern management practices (Deming, lean, respect for people, organization as system, etc.). It worked very well for them.

When building a software development team I tried to protect developers from interruption while having very open communication between developers and program managers (product owners). As is often the case, the real roles didn't line up exactly. In our organization, the people that needed us to develop software (to varying levels) didn't want to take on the responsibilities that agile would suggest (setting priorities etc.). Nor did the that organization want to deal with the conflicting priorities of the various people in their organization had for software development. As part of making things work, I took on a bit of the priority setting roles.

One of the things I did was explain to those that had us do software development was why it was critical to allow software developers to have uninterrupted time to focus. I shared various articles and reports over time and would talk about this as I interacted with them. I encouraged people to talk to me first (at that time I had transitioned from developer/software-development-program-manager to nearly entirely a program manager role).

We also had weekly meetings (when it made sense) with the "product owners", me and the developers working on the software. We scheduled additional meetings when necessary.

I also encouraged people to use email when possible to just check on things, ask simple questions, ask to meet. Again I explained how just going up to talk to the developer could impose significantly higher costs to them being able to focus of their work than there were for interrupting my work or others that had work that could more easily be interrupted with lower consequences.

When there were very important deadlines I would increase these instructions not to interrupt the software developers. And I would talk to the developers about how things were going and if the developers wanted help pushing back a bit I would then do so - mainly by trying to work on the system (provide a set time to allow needed discussions, coach the "product owners" on the difficulty caused by interruptions etc.).

As you might expect this worked better with some people than others. It made a significant difference though. And in our organization it was actually a bit less effective because the software developers were all so nice. They could say how interruptions damaged what they could do systemically but were always super friendly whenever they were interrupted. I was by far the most willing to actually disappoint people face to face in the name of improving overall performance.

It is very hard to overestimate the systemic nature of all of this. By delivering great results we were able to reinforce that if we followed the modified Deming/agile methods we were using were important. Those needing work from us ranged from very skeptical to accepting of those ideas but our performance (both in meeting their desires for software and for interpersonal interactions) made them willing to go along with the methods we said were important.

Related: Deming and Software Development - Mistake Proofing Deployment of Software Code - Creating a Culture that Values Continual Improvement

The Value of Putting Pen to Paper

Comments on Learning by Writing… by Hand

The psychology behind the learning advantage of handwriting is starting to be understood... [Carol Holstead] "It turned out my theory was right and now is supported by research. A study published last year in Psychological Science showed that students who write out notes longhand remember conceptual information better than those who take notes on a computer."

I am also a fan of technology. And also a fan of learning and paying attention to research. Pen on paper has advantages for learning that technology has yet to equal. At the same time technology has many advantages also.

We seem to understand the advantages of using technology fairly well but under-appreciate the advantages of pen on paper. To make sure we don't lose out due to this bias we should think before we accept that pen on paper isn't worthwhile.

From a post I wrote in 2005, Measurement and Data Collection

I believe, it is better to focus on less data, really focus on it. My father, Bill Hunter, and Brain Joiner, believed in the value of actually plotting the data yourself by hand. In this day and age that is almost never done (especially in an office environment). I think doing so does add value. For one thing, it makes you select the vital few important measures to your job.

Lots of data will be kept in computers and that makes sense. But putting pen to paper has value that we too quickly dismiss.

Related: Experience Teaches Nothing Without Theory - The Illusion of Knowledge - Write it Down to Improve Learning (Ackoff)

Learning Can't Take Place Without Theory

Response to: The Secrets of Lean

I think you make good points, but I think you make a mistake stating:

"This system of learning has come from experience, not theory."

For some reason, culturally, we created this idea that theory was about disengaged people (away from the gemba) thinking in a way disconnected from practice. But this is not what theory is.

Learning can't take place without theory. Experience doesn't lead to learning. Experience with a theory and an informed observer that questions what they see can lead to learning.

It seems to me accept theory that is separated from the gemba as what theory is and then say theory is not useful, experience is. But we are making a mistake when we think this way. The problem we see in theory being used disconnected from feedback from the gemba is a bad use of theory. But the problem is not that theory needs to be eliminated, but that theory disconnected from the gemba is not useful in learning about systems and improving our organizations.

Related: Experimentation is an iterative process - Effort Without the Right Knowledge and Strategy is Often Wasted

Patient Centered Doesn't Mean Patient Directed

One thing I find annoying is when people talk about patient "choice" as if that is the fundamental principle in health care. We often try to simplify things so much that they are untrue. Health care is complex and trying to point to pithy sayings does more harm than good I think.

Patient focus matters but there are conflicts between what is the best care and what patients want. And there are conflicts between what those paying for care want and drug companies want and hospitals want and doctors want. These require difficult choices and in order to optimize results we need very well designed systems that take these issues into account.

Sadly I think the USA generally has very bad systems in place. The rest of the world isn't that great either, but by and large is better than the USA and much cheaper. Most health care providers care about patient care and often make heroic efforts to provide it. But the systems are just lousy.

Those systems that seem the most lousy to me around extracting cash from payers - it is absolutely horrible in so many ways in the USA. Sadly this creates hugh waste in the USA that is ripe for improvement (and has been for at least 30 years). Patient care also has plenty of room for improvement, but thankfully it isn't as messed up as the whole payment system is.

One of the things people ignore is that we are not talking about GM in the 1980s being pitiful compared to Toyota. When we look at how poorly the USA health care system does it is in comparison to other rich countries it isn't a comparison to "Toyota." It is more like being pitiful compared to 1980s Fiat or something. When you are twice as expensive with no better results than Toyota that is somewhat lame. When you twice as expensive as not very well run systems with no better results that is super lame. And then add on the top of it that you bankrupt hundreds of thousands of people a year, force people to avoid health care so they don't go bankrupt...

We need to have systems that are patient focused but that doesn’t mean patients dictate treatment. And we need to see a much wider system than we normally do. We need to be focused on healthy living not just disease treatment. And given the mess that is the USA health care system we need to focus on reducing the burden of coping with the horrible USA health system bureaucracy - that system does great damage to those having to deal with it (and it is nearly all waste that shouldn't be creating such hardship).

Response to: A Story About a Hospital Putting Safety First Over Patient Satisfaction

Related: USA Health Expenditures Reached $2.8 trillion in 2012: $8,915 per person and 17.2% of GDP - Our Failed Health-care System - Overview of 5 Nations Health Care Systems

Sustaining Management Improvement Through Personnel Changes

My reply to a comment on Reddit about my interview: Leadership While Viewing the Organization as a System.

So if a new manager is able to mess it up, the system was necessarily weak? Not sure I agree.

Looking at the context the interviewer asked about a new CIO coming in a gutting the management system. I said if they have a strong management system that can't happen. Executives can't just have whims (usually driven by a desire to "make their mark") that throw out the principles used to manage the company if there is actually a strong management system.

Most organizations just float with whatever fads are going on, so in most they can flip flop as new executives come into place.

On the question of new managers making mistakes. Yes, I agree they can. Once again good management systems make a significant effort to bring new managers up to speed. Those management systems reduce the likelihood of failures created by new managers making mistakes. Again, most organizations do a poor job of brining new managers up to speed: Toyota does a good job, the USA military does also, Costco does a good job, I think P&G does (but my information could be outdated). Many others do this well, but the majority of companies do this extremely poorly. That is a serious failure of a management system and I would put more of the blame for those failures on the poor management system, that the managers making mistakes when they were put in a position they shouldn't have been (being made responsible without proper preparation).

Related: Poor Results Should be Addressed by Improving the System Not Blaming Individuals - Management Training Program (2005 Curious Cat post) - Curious Cat Management Improvement Dictionary

Data on Medical Errors

How Many Die From Medical Mistakes in U.S. Hospitals?

In 1999, the Institute of Medicine published the famous “To Err Is Human” report, which dropped a bombshell on the medical community by reporting that up to 98,000 people a year die because of mistakes in hospitals. The number was initially disputed, but is now widely accepted by doctors and hospital officials — and quoted ubiquitously in the media.

In 2010, the Office of Inspector General for Health and Human Services said that bad hospital care contributed to the deaths of 180,000 patients in Medicare alone in a given year.

Now comes a study in the current issue of the Journal of Patient Safety that says the numbers may be much higher — between 210,000 and 440,000 patients each year who go to the hospital for care suffer some type of preventable harm that contributes to their death, the study says.

That would make medical errors the third-leading cause of death in America, behind heart disease, which is the first, and cancer, which is second.

I wish these reports would provide some detail on what these really mean. Is it 250,000 people that were completely healthy coming in for a physical and they die when they would have been healthy if the medical system didn't exist? I doubt it. Is it 2,000 completely healthy people and 248,000 people that were under intensive medical care for years keeping them alive and now we slipped up and they died? Probably not, again, but my guess is it is closer to the second.

Preventing errors is obviously important. And in health care it is very important, of course. But just because you use data doesn't mean it isn't misleading. Medical errors leading to death is just too big an operational definition to be very meaningful in my opinion. For these numbers to provide much insight I really think they need to be segmented more:

• perfectly health person that was going to be perfectly healthy for decades but were killed by medical error.
• person that needed life saving care of they were going to die that month and we routinely should be able to provide the very easy care to make them perfectly healthy again but they were killed.
• etc…
• person that was extremely sick with many problems for years and was saved with medical care over and over again. Complex care was needed and much of it was done well but in the very challenging situation there was a mistake and that mistake is the proximate cause of death.

We should be working on making everything better and eliminating medical errors that cause damage and death. But there are huge differences between a medical error conditions that caused death and to me those differences are so huge lumping them together is hardly useful.

My understanding is we do use risk based assessment to compare things like survival rates or operations at different hospitals. A figure of survival rates comparing two hospitals when one was the hospital where all the most difficult case for the Western USA were sent to a local hospital that dealt with the easy operations for that health issue would not be very useful. So they try to adjust for the severity of the problem (as I understand it). It would seem to me a similar thing would be much more useful for medical error death rates. Was the person in such a risky state that the tiniest misstep (error or whatever else) would kill them or was it someone who is perfectly health and dies immediately due to an error.

Related: Errors in Thinking - Epidemic of Diagnoses - Health Care Crisis - Great Visual Instruction Example (taking pills)

Response to comment on my comment

Right, l think the thing I am getting at is there is a big difference between making a mistake while you are in a complex situation where any of 30 bad decisions in a pressure situation could result in death (and where doing nothing results in death) versus a situation where there is no risk of death until you do an absolutely idiotic thing that turns my visit to get a physical into death.

Everything should be constantly improved and made safer with mistake-proofing thinking... And healthcare needs this more than most everything due to the dangers and consequences involved.

When there are headlines like 100,000 deaths due to medical error every year that reads to me like John was walking along the street and boom a medical-error/piano dropped on his head and killed him. But I don't believe that is true. I bet it is true that are lots of deaths due to just unforgivable errors - someone is given a drug which was indicated in numerous sensible ways would kill them due an allergy but they were given it anyway and died.

But I don't trust how much of the deaths attributed to error are really 20% error, 19% cancer, 18% diabetes, 17% cardio-vascular disease, 16% long term high level use of powerful drugs ravaging the body, 10% car accident (which also someone else might say is 5% error, 30% cancer, 25%...). The error is still bad, and the system needs to be improved to reduce the frequency and consequences of errors. But I just don't know how to take the error to death data without much more explanation.

In reading more details on the studies they comprehend this issue with the data but I haven't found where they provide more meaningful data. What I read just talks about the contributing nature of "blame" on medical error etc..

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

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

Email Isn't the Problem

"Email is a tyrant. Combined with Personal Kanban, it can be a great way to receive work." [the broken link was removed] - Jim Benson

I find there are plenty of times when email is a great tool (for example: providing background material in advance of discussions). Yes, often email is misused and there are plenty of bad processes around email. But it isn't very sensible to say we shouldn't use a hammer (email) because when we use it to cut paper it isn't very useful. We shouldn't misuse a tool; that doesn't mean we shouldn't use the tool properly.

Yes, fix the problems with how emails is used and how you integrate email into your daily work etc. But I think way too often people think email (the "tool") is the problem when I rarely see it that way.

Killing Email Interruptions: Personal Kanban using LeanKit, Gmail, and Zapier [the broken link was removed] provides details on a way to manage the process of dealing with email.

Related: Process Thinking, Process Email Addresses - Effective Communication is Explicit

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:

• New – Different – Better
• Process Improvement and Innovation

Response to: Lean v. Innovation…Wrong Question!

Related: Clayton Christensen on Innovation and Macro Economics - Accept Taking Risks, Don’t Blithely Accept Failure Though