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
Tuesday, May 26, 2015
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:
Posts (Atom)