Comment on Are You Really Listening to Your Customer or Just Going Through the Motions?
I find myself very frustrated at how incredible poor and superficial "listening to our customers" is at nearly all companies I have to deal with. It is atrocious, often beyond the superficialness of any concern is creating hoops to waste customers time who even deign to raise an issue of persistent failures by the company (I have had this with Amazon for the last 2 months - it is amazing how they expect you to repeatedly jump through hopes while they ignore you over and over). I would have dumped them for this horrible service but I can't get them to refund my sizable balance because it isn't their "policy" to bother to refund money in your balance.
A method to get useful feedback I learned maybe 20 years ago at a quality conference, it is really simple, why nearly no companies do it is a sign how little they actually care about customer service and improvement. Just ask "customers, what one thing could we do to improve?"
Then you also need systems in place to use what you learn to improve, of course.
Related: Delighting Customers - Simple Customer Care: Communicate - Poor Customer Service: Discover Card - What Job Does Your Product Do?
Saturday, August 29, 2015
Friday, July 31, 2015
The Use and Misuse of Technical Jargon
Comments on: You want muda? Let’s talk about muda!
Essentially the terms are precise technical jargon. As with nearly all technical jargon it is very useful for experts and confusing (and, to many, off-putting) to people that are not experts.
You are exactly right, overwhelming people with jargon when trying to introduce new ideas is not usually helpful. Using a couple pieces of jargon can be helpful as it reinforces the idea that this is new stuff and can make people tie the new ideas to new terms.
When some people are learning it is easier to think of muda than "waste." They have an understanding of "waste" and it may well not include what is meant to be included in a lean context. They can rearrange in their head that in the context of lean "waste" is different - we do this all the time.
For some people using muda to think differently is helpful, for others it is not and often creates resistance.
English has many words we understand differently depending on the context (for example, "lean"). It works remarkably well but especially when people are learning it is easy to miss special "lean" meaning when using common words. Technical jargon is helpful with experts being able to quickly communicate unambiguous (well less ambiguous) specific meaning which is why jargon usually exists - to allow for communication to be more effective.
Certainly at times jargon is also used by experts to baffle or impress non-experts rather than to help communication. Reducing this use of jargon would be a good thing.
Related: Learning, Systems and Improvement - Open Source Management Terms - Getting Known Good Ideas Adopted
Essentially the terms are precise technical jargon. As with nearly all technical jargon it is very useful for experts and confusing (and, to many, off-putting) to people that are not experts.
You are exactly right, overwhelming people with jargon when trying to introduce new ideas is not usually helpful. Using a couple pieces of jargon can be helpful as it reinforces the idea that this is new stuff and can make people tie the new ideas to new terms.
When some people are learning it is easier to think of muda than "waste." They have an understanding of "waste" and it may well not include what is meant to be included in a lean context. They can rearrange in their head that in the context of lean "waste" is different - we do this all the time.
For some people using muda to think differently is helpful, for others it is not and often creates resistance.
English has many words we understand differently depending on the context (for example, "lean"). It works remarkably well but especially when people are learning it is easy to miss special "lean" meaning when using common words. Technical jargon is helpful with experts being able to quickly communicate unambiguous (well less ambiguous) specific meaning which is why jargon usually exists - to allow for communication to be more effective.
Certainly at times jargon is also used by experts to baffle or impress non-experts rather than to help communication. Reducing this use of jargon would be a good thing.
Related: Learning, Systems and Improvement - Open Source Management Terms - Getting Known Good Ideas Adopted
Sunday, July 05, 2015
Customer Service is Often More Like a Mugging Than Service
It is so frustrating to deal with most companies with monopolistic positions in the USA (which is a lot of them).
I find dealing with those companies a matter of being confronted by someone trying to pick your pocket while they both ignore and insult you and give you orders about what hoops you have to jump through if you want to stop one of the things they are doing to harm you.
Some are not that bad, I get water and garbage from the local county, they are actually the best service I get from a monopolistic provider. The electricity provider is just designed mainly to make their lives easy but they don't make it horrible to deal with them.
Getting broadband (Verizon and Comcast where I am) is horrible - dealing with them is exactly what I wrote above. Health insurance (and I don't even make any claims) is bad, and if I actually got any service I imagine it would be horrible dealing with the service providers seeking to rip you off and the paperwork being a nightmare.
I avoid dealing with the monopolistic providers as much as possible but you often are stuck. For example, I can (and have) only use sensible providers to get my mortgage, but then they are sold to service companies that are horrible and I have no say in the matter.
Much more than the costs taken by companies when they can buy politicians in order to allow the abuse of the market by dominant providers I abhor the pain of dealing with these companies as a customer and the constant vigilance required to protect yourself from them ripping you off. It is like being forced to commute in a packed subway with bought off police that allow pickpocket teams to work without interference.
Related: Worst Business Practices, Fees to Pay Your Bills - Customers Get Dissed and Tell - Incredibly Bad Customer Service from Discover Card - Don’t Let the Credit Card Companies Play You for a Fool
I find dealing with those companies a matter of being confronted by someone trying to pick your pocket while they both ignore and insult you and give you orders about what hoops you have to jump through if you want to stop one of the things they are doing to harm you.
Some are not that bad, I get water and garbage from the local county, they are actually the best service I get from a monopolistic provider. The electricity provider is just designed mainly to make their lives easy but they don't make it horrible to deal with them.
Getting broadband (Verizon and Comcast where I am) is horrible - dealing with them is exactly what I wrote above. Health insurance (and I don't even make any claims) is bad, and if I actually got any service I imagine it would be horrible dealing with the service providers seeking to rip you off and the paperwork being a nightmare.
I avoid dealing with the monopolistic providers as much as possible but you often are stuck. For example, I can (and have) only use sensible providers to get my mortgage, but then they are sold to service companies that are horrible and I have no say in the matter.
Much more than the costs taken by companies when they can buy politicians in order to allow the abuse of the market by dominant providers I abhor the pain of dealing with these companies as a customer and the constant vigilance required to protect yourself from them ripping you off. It is like being forced to commute in a packed subway with bought off police that allow pickpocket teams to work without interference.
Related: Worst Business Practices, Fees to Pay Your Bills - Customers Get Dissed and Tell - Incredibly Bad Customer Service from Discover Card - Don’t Let the Credit Card Companies Play You for a Fool
Tuesday, June 02, 2015
Learning From Process Improvement Efforts
Comment on: How to Improve (at just about anything)
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
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
Tuesday, May 26, 2015
Businesses Need to Capture Potential Information and Use the Creativity of Employees
Comments on: Asking the Employees
The problem I see is that management systems can't be seen as independent from the specific tactic in some area (for example getting employees to share ideas). So the effectiveness of soliciting ideas from employees varies mostly by the overall management system unrelated to the specific tactics of the attempt to get ideas from employees. The specific tactics matter but less than the management system (which is often a mess and something no one wants to address).
My father wrote an article a long time ago on how to use ~"two resources, largely untapped in American organizations: potential information and employee creativity."
I think it provides worthwhile ideas.
Related: Trust Your Staff to Make Decisions - Leading Improvement and Enjoying the Rewards - Do What You Say You Will
The problem I see is that management systems can't be seen as independent from the specific tactic in some area (for example getting employees to share ideas). So the effectiveness of soliciting ideas from employees varies mostly by the overall management system unrelated to the specific tactics of the attempt to get ideas from employees. The specific tactics matter but less than the management system (which is often a mess and something no one wants to address).
My father wrote an article a long time ago on how to use ~"two resources, largely untapped in American organizations: potential information and employee creativity."
I think it provides worthwhile ideas.
Related: Trust Your Staff to Make Decisions - Leading Improvement and Enjoying the Rewards - Do What You Say You Will
Tuesday, May 19, 2015
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
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
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
Wednesday, May 13, 2015
What is a Lean Program, Deming Program?
Thoughts in response to: Dr. Deming’s Last Interview & Jack Welch’s Thoughts on Him by Mark Graban.
Deming sure provided some great quotes in that interview; those you listed above and more (in fact I posted about one this week in To Achieve Success Focus on Improving the System Not On Individual Performance). From Mark's post:
This is so true. Basically organizations can be making good progress but essentially none that *have* a Deming or lean program. Toyota is sensible to consider the closest - I mean lean after all originally was just documenting Toyota and calling it lean instead of Toyota management or whatever. But Toyota does plenty of things that are not what even Toyota says how things should be done.
And beyond that lean has evolved away, IMO, from just being able to say anything Toyota does is by definition lean. Lean and Deming are more about a philosophy of managing - continual improvement, respect for people, etc. than prescriptions. So you can't really have a checklist and say that if your org can check off all these things they are lean or Deming.
The fact that the management systems can't be reduced to a checklist is a necessary given the long lasting power they offer. When you reduce the ideas for management that far (so you have a checklist of exactly what to do) you get a stupid system that can't be used for managing large systems of people. Organizations doing the best job of being worth of claims of being true to the management systems are likely to have the widest understanding of all the ways in which they are failing to live up to that vision.
I continue to think Toyota is doing a very good job. But they also have plenty of room to improve. And they continue to be tempted by becoming more like other companies instead of recommitting to the principles of lean and Deming.
Related: Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said - Long Term Thinking with Respect for People - Deming and Software Development
Deming sure provided some great quotes in that interview; those you listed above and more (in fact I posted about one this week in To Achieve Success Focus on Improving the System Not On Individual Performance). From Mark's post:
I’m not sure what 'a Deming program' is anymore than I know what 'a Lean program' is sometimes.
This is so true. Basically organizations can be making good progress but essentially none that *have* a Deming or lean program. Toyota is sensible to consider the closest - I mean lean after all originally was just documenting Toyota and calling it lean instead of Toyota management or whatever. But Toyota does plenty of things that are not what even Toyota says how things should be done.
And beyond that lean has evolved away, IMO, from just being able to say anything Toyota does is by definition lean. Lean and Deming are more about a philosophy of managing - continual improvement, respect for people, etc. than prescriptions. So you can't really have a checklist and say that if your org can check off all these things they are lean or Deming.
The fact that the management systems can't be reduced to a checklist is a necessary given the long lasting power they offer. When you reduce the ideas for management that far (so you have a checklist of exactly what to do) you get a stupid system that can't be used for managing large systems of people. Organizations doing the best job of being worth of claims of being true to the management systems are likely to have the widest understanding of all the ways in which they are failing to live up to that vision.
I continue to think Toyota is doing a very good job. But they also have plenty of room to improve. And they continue to be tempted by becoming more like other companies instead of recommitting to the principles of lean and Deming.
Related: Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said - Long Term Thinking with Respect for People - Deming and Software Development
Thursday, May 07, 2015
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
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
Subscribe to:
Comments (Atom)