Eric Budd asked on The W. Edwards Deming Institute group (LinkedIn broke the link with a register wall so I removed the link):
If observed performance/behavior in a system is a result of the interactions between components–and variation exists in those components–the best root cause explanation we might hope for is a description of the interactions and variation at a moment in time. How can we make such an explanation useful?
A single root cause is rare. Normally you can look at the question a bit differently see the scope a bit differently and get a different “root cause.” In my opinion “root cause” is more a decision about what is an effective way to improve the system right now rather than finding a scientifically valid “root cause.”
Sometimes it might be obvious combination which is an issue so must be prevented. In such a case I don’t think interaction root cause is hard – just list out the conditions and then design something to prevent that in the future.
Often I think you may find that the results are not very robust and this time we caught the failure because of u = 11, x = 3, y = 4 and z =1. But those knowledge working on the process can tell the results are not reliable unless x = 5 or 6. And if z is under 3 things are likely to go wrong. and if u is above 8 and x is below 5 and y is below 5 things are in trouble…
To me this often amounts to designing systems to be robust and able to perform with the variation that is likely to happen. And for those areas where the system can’t be made robust for some variation then designing things so that variation doesn’t happen to the system (mistake proofing processes, for example).
imagine various people working within it, somehow swapping out gears and cogs without the clock stopping or slowing down even a little.
This is a fairly good quote on a good management system. Some people might not like the mechanistic model – comparing an organization to a clock, and I agree that isn’t the right model, but even so it is a good quote.
The quote, from a story about the San Antonio Spurs captures what should happen with a good management system. Things just keep running well as inevitable changes take place (and keep getting better in the case of a management system).
A good management system doesn’t rely on heroic efforts to save the day. The organization is designed to success. It is robust. It will succeed with all the variation thrown at it by the outside world. A good management system takes advantage of the contributions people offer, but it is not perform poorly when others are relied on.
A well run organization has graceful degradation (when one component fails or one person is missing the performance doesn’t suffer, bad results are avoided).
An organization succeeds because of the efforts of many great people. But the management system has to be created for an organization to prosper as what we all know will happen, happens: people will leave and need to be replaced. And the people that stay will need to adjust to new conditions inside the organization and in response to external forces. A good management system is constantly improving performance, innovating, increasing the robustness of systems and increasing the capability of people.
I’m a writer. It’s the one thing that I intend to do for the rest of my life. That means, when I focus on writing, I cannot focus on knitting. Somebody else will have to do the knitting, so I can focus on the writing. And maybe later, I can trade my wonderful book for someone’s beautiful sweater. This concept applies to all other professionals too. Everyone is entangled in a web of economic dependencies, and therefore, the purpose you choose for yourself should somehow generate value for the others around you. Or else nobody will give you a knitted sweater.
This all makes perfect sense to complexity scientists, who have known for a while that complex adaptive systems find a global optimum through local optimizations and interdependencies. (At Home in the Universe by Stuart Kauffman) The parts in a complex system all try to optimize performance for themselves, but their efforts depend on the dependencies imposed on them by the parts around them. With a mix of competition and collaboration, the parts interact with each other without any focus on a global purpose. Nevertheless, the end result is often an optimized system. Biologists call it an ecosystem. Economists call it an economy. I call it common sense.
Putting the “Why” in Your Mission Statement
Most management scholars and experts have ignored the insights from the complexity sciences (or are unaware of them) and some have suggested goals for teams, and purposes for businesses, that are too narrow. There are many corporate mission statements in the world expressing ideas such as, “Make money for shareholders”, “Put customers first”, and “Achieve superior financial results” (The Leader’s Guide to Radical Management by Stephen Denning). In each of these cases, the purpose of the organization is (too) narrowly defined as providing value to one type of client or stakeholder.
Amazon continues to be innovative not just in technology but with management thinking. Jeff Bezos has rejected the dictates espoused most vociferously by Wall Street mouthpieces and MBAs that encourage short term thinking and financial gimmicks which harm the long term success of companies.
Most CEOs and executives are too fearful or foolish to ignore what they are told they must do because Wall Street demands it. CEO’s and boards often ratchet up the poor management thinking by tying big bonuses to financial measures which are much more easily achieved by gaming the system than by improving the company (so companies get the games there boards encouraged through their financial extrinsic motivation focus).
Amazon does many good things focused on making Amazon a stronger company year after year. These innovative management practices seem to largely be due to the thinking of the strong willed founder and CEO: Jeff Bezos. Jeff was smart enough to see the great things being done at Zappos by Tony Hsieh and bought Zappos.
Jeff Bezos has added his letter to shareholders to Warren Buffett’s (for Berkshire Hathaway) as letters worth reading each year. In the latest Amazon letter he includes many worthwhile ideas including:
Career Choice is a program where we pre-pay 95% of tuition for our employees to take courses for in- demand fields, such as airplane mechanic or nursing, regardless of whether the skills are relevant to a career at Amazon. The goal is to enable choice. We know that for some of our fulfillment center employees, Amazon will be a career. For others, Amazon might be a stepping stone on the way to a job somewhere else – a job that may require new skills. If the right training can make the difference, we want to help.
The second program is called Pay to Quit. It was invented by the clever people at Zappos, and the Amazon fulfillment centers have been iterating on it. Pay to Quit is pretty simple. Once a year, we offer to pay our associates to quit. The first year the offer is made, it’s for $2,000. Then it goes up one thousand dollars a year until it reaches $5,000. The headline on the offer is “Please Don’t Take This Offer.” We hope they don’t take the offer; we want them to stay. Why do we make this offer? The goal is to encourage folks to take a moment and think about what they really want. In the long-run, an employee staying somewhere they don’t want to be isn’t healthy for the employee or the company.
A third inward innovation is our Virtual Contact Center. It’s an idea we started a few years back and have continued to grow with terrific results. Under this program, employees provide customer service support for Amazon and Kindle customers while working from home. This flexibility is ideal for many employees who, perhaps because they have young children or for another reason, either cannot or prefer not to work outside the home.
The first point reinforces Dr. Deming’s words encouraging companies to do exactly that – pay for education even if it wasn’t related to the work the employee was doing or would do for the company. Still quite rare decades after Deming’s advice.
I am sometimes asked about how use Deming’s ideas on management in a software development context. My belief is Deming’s ideas work extremely well in a software development context. The main issue is often unlearning some assumptions that people might have about what the Deming management system is.
It really is surprising to me how many “knowledge workers” respect Deming ideas but then say his attempts to treat factory workers as thoughtful people who should be respected and involved in improving their processes doesn’t make sense for them because they are “knowledge workers.”
There are many good things being done to improving the software development process. I think many of them are very Deming-like in their approaches (but to me miss out on aspects of the Deming management system that would be helpful). I think Dr. Deming’s approach to software development would focuses on the system of profound knowledge (the 4 inter-related areas below):
Understanding variation – software development has quite a bit of variation, some probably innate [unique work] and some due to not having good procedures, batching work, not fixing problems right when they are seen, quick fixes that leave the system venerable in the long term (when you make one simple change to the code it has an unanticipated consequence due to poor practices that could have been eliminated), etc.. Many good coding practices are effective strategies to deal with this issue. And building an understanding of variation for managers (and business process owners/product owners) is very helpful to the software development process. The ideas in agile and kanban of focusing on smaller delivery units of work (one piece flow, just in time, cycle time…), customer value, maintainable code, sustainable work conditions, etc. are directly found in a Deming management system.
Appreciation for the system of software development. Don’t just complain about bugs. Examine the process of development and then put in place mistake proofing efforts (don’t duplicate code, use integrated regression tests, don’t put artificial constraints on that result in system distortions – unrealistic targets…). Use things like kanban, limited work in progress, delivering value to customers quickly, think of success in terms of getting working software to customers (not meeting internal delivery goals), etc. that take into account our experience with systemic software development problems over the decades.
Theory of knowledge – how do we know what we know? Are estimates reliable? Lets look at what users do, not just what they say (A/B testing…). Software developers often appreciate the value of usability testing, even though they rarely work for organizations willing to invest in usability testing. In my experience when software developers object to usability testing it is normally really an objection to overwork, and the usability testing is just going to give them more work or criticize things they were not allowed to spend the time they needed to do great work. That won’t always be the reason but it is the main one in my experience (I suppose their is also fear and just the psychology of not wanting to hear anything negative about what has been created – even if the usability testing shows tons of great results people will often focus on the negative).
psychology and respect for people – This pretty much seems like it is the same for software development as everywhere else.
“I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special.”
Getting hung up on the figure 94% is a mistake. His point was that you improve performance going forward by improving the system not blaming people. His two books provide background and the thought process involved behind why we are failing to manage better. Changing the people, while leaving the system in place, most often doesn’t help.
Variation does confuse people sometimes. The same mistake as say yelling at someone any time results are really bad. Most likely results will get better. Not because yelling helps but essentially regression to the mean. So you can move people out after really bad results and things get better. Of course, most of the time they would have gotten better if you left the people there (and did nothing or yelled).
Even when the person did totally mess up, why did the system allow that? Why did the system put that person in a place where they were not qualified? Answering and fixing these types of questions would help improve the system and the results going forward.
Yes, occasionally the answer might be that Joel was hired sensibly, managed and coached sensibly but he just became a complete jerk and won’t respond to coaching and this is only his fault. But normally that won’t be the case, even when the person seems nearly totally to blame (and that isn’t even a very common situation) normally there are obvious weaknesses in the system that put them in the place to fail and will likely put anyone else in the same place in the future.
The job of managers is to create a robust system that delivers value to customers. A system that fails constantly (fails during the continual variation the system faces) is a failed system. Bad weather is part of the variation airlines face. Any management system has to cope with the variation that it faces. The management system must be designed and managed so that the organization successfully delivers value to customers under the conditions the organization will face.
The air travel system in the USA is a disgrace for so many reasons it is hard to catalogue them all. One, of many, is how fragile the system is; causing massive (nation-wide) customer harm multiple times a year due to weather. Weather is sometimes bad. If your organization fails when there is bad weather, fix that problem (make your system robust in the face of bad weather), because you are not going to be able to fix the weather to let your un-robust system be effective as it is.
Instead airlines only response seems to be to get their friends in government to approve anti-competitive mergers to eliminate competition and allow failed organizations to become even larger and harm even more people. Airlines should design robust systems that work in the environment they will face (which they don’t do now).
Their planes don’t fall out the sky when they face bad weather. The engineers behind designing planes have made them very robust. Pilots have been trained to handle variation they will face. And yes, the system has been designed with adjustments to avoid flying into conditions that are risky.
The safety of the air transportation system is very good. The management of airlines in most every other aspect is pitiful, and has been for decades.
The managers running the airlines have done amazingly bad job of creating robust organizations capable of delivering given the variation they know they will face (weather, mechanical problems, IT problems, etc.) for decades. Poor management is the cause of these failures that result in harm to customers. Weather is not the cause. Poor management, over decades, resulting in incredible fragile systems that constantly punish customers is the responsibility of the airlines. And they have done an incredibly bad job at creating a robust system to deliver value to customers.
Saying “Managers care about efficiency and leaders care about effectiveness” is like saying “Doctors care about theory and nurses care about patients.”
Managers that don’t care about effectiveness are lousy managers.
Leaders that don’t care about the gemba are lousy leaders.
Doctors that don’t care about patients are lousy doctors.
Nurses that don’t care about theory are lousy nurses.
Your role in the organization (and for the particular situation in question) and training and the situation will impact how you contribute. But the attitude that leaders are visionaries that think big thoughts, make decisions then tell everyone what to do (act as the brain for the organization) is outdated. Every list of what traits are for leaders that then contrasts them with managers that I have seen shows leadership traits managers need.
Seeking to separate leadership and management is a bad idea. If you want to have a few leadership traits that you want to focus on at various points (creating engagement, communicating a vision, building consensus, setting organizational direction) that is fine. But those things are traits managers need; they are not traits reserved for some separate leadership cadre.
And disconnected leaders that don’t understand the organization, the organizations customers etc. are not going to lead well (normally the contrast lists have the managers doing all the hands on stuff, at the gemba, with customers etc.). Nurses may not have as complete an understanding of the theories behind medical treatment decisions but they need to know a great deal of theory to do their jobs well. Everyone contributes and has different roles to play but I don’t see value in the contrast of leaders and managers mentality.
From what I have seen mainly the manager v. leader comparisons seem to be about belittling managers and elevating leaders; but leaders are this vague concept that isn’t well defined. Who are these leaders? Are they only senior executives? They can’t be managers because you are contrasting them with managers – by the contrasting model used they can’t be leaders and managers.
There are several keys to pulling sustained long term excellence. Unfortunately, experience shows that it is much easier to explain what is needed than to build a management system that delivers these practices over the long term. The forces pulling an organization off target often lead organization astray.
Each of these concepts have great deal more behind them than one post can explain. I provide some direct links below, and from those there are many more links to more valuable information on the topics. I also believe my book provides valuable additional material on the subject – Management Matters: Building Enterprise Capability. Sustained long term excellence is the focus of the book. A system that consistently provides excellent performance is a result of building enterprise capability over the long term.
Process thinking flows from viewing the organization as a system. Only by building a network of reliable processes is sustained excellence possible. To build those processes an understanding of process thinking is required (understanding variation, monitoring using in-process measures, visual management, continual improvement etc.).
People must be willing to challenge their mental models in order to find non-obvious areas of high leverage – which allow significant improvement.
System thinking is a term that is often confusing to people. From my perspective it is important to understand the importance of leverage. Understanding systems lets you find solutions that may not be direct, but provide powerful leverage. Another important point is looking at the organization as a system.
As Peter Senge mentions in the video the concept of long term thinking plays a role. Often we are now neglecting or vastly under-appreciating long term impacts (focusing on only the results in the short term) and thus often their are opportunities to improve just by factoring in not just the short term impacts but also placing importance on longer term impacts.
Peter Senge: “Its not about the smartest guys in the room its about what we can do collectively. So the intelligence that matters is the concept of collective intelligence.”