Using data to understand your processes and improve them is very useful.
But using data often results in unintended consequences. If you don’t have a good understanding on the pressures collecting data will bring to bear on the system you can create pressure for results that damage the delivery of value to customers.
In this example there are requirements to take action if certain conditions are present. In this case, if the airplane is pushed back from the gate for more than 3 hours without taking off passengers must be given the opportunity to get off.
Indeed, to avoid the fines, airlines are now far more likely to cancel flights that are sitting at the gate or on the tarmac than they once were, explains Vikrant Vaze, an assistant professor of engineering at Dartmouth and a co-author of the study. That means you’re now more likely to board your plane, sit there, and then still have the flight canceled.
It doesn’t seem the conditions imposed are unreasonable to me. But the expectation was for airlines to make sensible adjustments and not force customers to wait so long in the airplane sitting on the ground. The system could be improved by having more gates in operation, not pushing loading planes if you knew plane wasn’t going to leave for more than 30 minutes, etc.. But when customer value is taken very lightly (as USA airlines do) it isn’t surprising the USA airlines would take a very customer unfriendly method to avoid the issue that was the source of the new rules.
Distorting the system or distorting the data are often the result, instead of the process improvement that is desired and expected.
For professors that have “made it” you will do a great service to others (and help promote the ideas in your field that you have devoted your life to) by refusing to submit to closed science journals (or closed professional society journals etc.). For those trying to secure full professorships I wish they would too, but I realize the hard choices they face.
The maximum closed-ness we should tolerate, in my opinion, is closed access for 1 year after which it becomes open. Require this in writing in the agreement, don’t just accept that the current practice is to promote the sharing of ideas; if it isn’t in writing some person may have the publisher adopt closed science later and block access to the content you wanted to share.
My father had the most job satisfaction of anyone I have known. He had no separation between work and life. We toured factories on vacation. I visited Davidson College in North Carolina because he was consulting with a client in Charlotte before we went up to Duke and North Carolina for visits and asked the CEO what school I should visit. His grad students would call the house frequently.
Many of his best friends were colleagues. That is how I grew to know people like George Box, Brian Joiner, Soren Bisgaard and Peter Scholtes as I grew up. Various permutations of our family lived overseas based on his jobs in London (before kids), Singapore, Nigeria and China. Those experiences dramatically impacted all our lives and they were not about separating work from life.
The desire for a life embedded in other cultures and for travel drove decisions about work. He lived in Japan (because of his Dad’s job) for 2 years as a kid and that sparked his desire to do more of that as an adult.
My little brother, Justin, pushing me on a scooter at our house in Singapore.
The sensible aim is to optimize your life. Work is a big part of life. As with any system the results depend on the overall system not the performance of individual parts taken separately. Dad also died young. He was happy to have lived such a good life, even if he wished he could have lived longer he wasn’t bitter about missing anything.
He honestly looked back on his life and felt he had a life that few could have topped, even though it was cut short. He was certainly optimistic and positive. But my sense was this was his honest assessment, it wasn’t just some fake front he put on for others. He had been living his life as well as he could his whole life. And continuing to live it as long as he could was all he wanted to do.
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.