I got this tweet today, as a part of a larger conversation that technological breakthroughs could help predict disruptive economic times. During the past 10 days or so, the US and global financial markets have taken a deep plung, as a result of, well, according to the CIOs (chief investment officers) and politicians, we don’t know. The new industry pins the almost unanimous economic decisions of sell sell sell, to the latest new is geo-political interactions and/or financial specific news.
We see headlines like “Downgrade Ignites a Global Selloff” at the Wall Street Journal, referring to the Standard & Poor’s downgraded credit rating of US treasuries, which by the way soared during the selloff of equities, because of their relative strength.
More importantly than what to buy, none of the headlines, nor the vague analysis captures the actual root-cause of this regular, or rather, irregular economic downturn occurring over the past decade. The general ideal that one should be able to buy low and sell high that once held true in the 20th century no longer exists. The root of the problem is in our use of technologies to error-proofredundant problems in the modern work world. Further, we know that mostly all errors exist by the hands of humans. Thus, error-proofing can be synonymous with human-proofing. We usually think of technologies that replace human activity as a device or software…”the robots”, and those do exist, but they are less of a threat than the methodological technologies.
We rarely think of a routine as a technology, but they are. Benchmarking is a technology. With all of the methodological expertise being poured into corporations over the past 30 years, we’ve finally got somewhere, efficient. How many times have you heard that word at the office? Since the late 1960s and the creation of Poka Yoke by Dr. Shigeo Shingo, and on to Lean-Manufacturing, and Six-Sigma, and most recently the 3rd version of IT Infrastructure Library (ITILv3), we are actively depleting the work force to ensure our qualitative (effectiveness) and quantitative (efficiency) superiority to the competition.
Its a difficult dialogue to have, because a valid argument is: what’s wrong with business being efficient? My answer would be: Nothing at all. The problem comes into play when human-kind has rendered its ability to distribute value, obsolete. In the past we’ve distributed value through a currency of some sort, and that currency (in primitive times and modern day) is backed by more than gold or bonds, it is also backed by faith in a philosophical system that a woman/man get paid for an “honest days work”, quite the primitive slogan. In a knowledge economy where people aren’t performing back-breaking work at the volumes that they used to, and 10 knowledge workers of the 1980’s can be performed by 1 Project Manager using 30 years of benchmarked data with soft/hardware help, it’s difficult to spread the wealth that we once did.
When the markets sell off equities into cash, they are saying that the economy is inflated and weak. There are no buyers for the products being produced, because there are no jobs. There are no jobs, because of all of the error-proofing that proceeded them; and finally, it is exceedingly difficult to quantify what people’s knowledge, experience, existence is worth in the old paradigm. While it feels better to point the finger at the CEOs and Politicians today, of which I’d likely get a finger or two, the problem is that we are trying to distribute the wealth that still exists using an antiquated model.
If one looks at the M1&M2 numbers at the US Federal Reserve, they’ll notice that all of the money we need to fix/build anything still exists. This is the same across the globe. When the news says that money supply is lower, what they actually mean is that money distribution is lower, because the money supply, as the link shows is rarely diminished. As an economy retracts, funds return to its originator. The wealthiest of our species cannot justify how to spread a trillion dollars around, at the moment, because there fewer and fewer tasks to assign a wage and a human resource. I’ve got a few solutions to recommend in my next book project, Integrationalism: Essays on ownership and distributing value in the 21st century.
Transhumanists are into improvements, and many talk about specific problems, for instance Nick Bostrom. However, Bostrom’s problem statements have been criticized for not necessarily being problems, and I think largely this is why one must consider the problem definition (see step #2 below).
Sometimes people talk about their “solutions” for problems, for instance this one in H+ Magazine. But in many cases they are actually talking about their ideas of how to solve a problem, or making science-fictional predictions. So if you surf the web, you will find a lot of good ideas about possibly important problems—but a lot of what you find will be undefined (or not very well defined) problem ideas and solutions.
These proposed solutions often do not attempt to find root causes or assume the wrong root cause. And finding a realistic complete plan for solving a problem is rare.
8D (Eight Disciplines) is a process used in various industries for problem solving and process improvement. The 8D steps described below could be very useful for transhumanists, not just for talking about problems but for actually implementing solutions in real life.
Transhuman concerns are complex not just technologically, but also socioculturally. Some problems are more than just “a” problem—they are a dynamic system of problems and the process for problem solving itself is not enough. There has to be management, goals, etc., most of which is outside the scope of this article. But first one should know how deal with a single problem before scaling up, and 8D is a process that can be used on a huge variety of complex problems.
Here are the eight steps of 8D:
Assemble the team
Define the problem
Contain the problem
Root cause analysis
Choose the permanent solution
Implement the solution and verify it
Prevent recurrence
Congratulate the team
More detailed descriptions:
1. Assemble the Team
Are we prepared for this?
With an initial, rough concept of the problem, a team should be assembled to continue the 8D steps. The team will make an initial problem statement without presupposing a solution. They should attempt to define the “gap” (or error)—the big difference between the current problematic situation and the potential fixed situation. The team members should all be interested in closing this gap.
The team must have a leader; this leader makes agendas, synchronizes actions and communications, resolves conflicts, etc. In a company, the team should also have a “sponsor”, who is like a coach from upper management. The rest of the team is assembled as appropriate; this will vary depending on the problem, but some general rules for a candidate can be:
Has a unique point of view.
Logistically able to coordinate with the rest of the team.
Is not committed to preconceived notions of “the answer.”
Can actually accomplish change that they might be responsible for.
The size of an 8D team (at least in companies) is typically 5 to 7 people.
The team should be justified. This matters most within an organization that is paying for the team, however even a group of transhumanists out in the wilds of cyberspace will have to defend themselves when people ask, “Why should we care?”
2. Define the Problem
What is the problem here?
Let’s say somebody throws my robot out of an airplane, and it immediately falls to the ground and breaks into several pieces. This customer then informs me that this robot has a major problem when flying after being dropped from a plane and that I should improve the flying software to fix it.
Here is the mistake: The problem has not been properly defined. The robot is a ground robot and was not intended to fly or be dropped out of a plane. The real problem is that a customer has been misinformed as to the purpose and use of the product.
When thinking about how to improve humanity, or even how to merely improve a gadget, you should consider: Have you made an assumption about the issue that might be obscuring the true problem? Did the problem emerge from a process that was working fine before? What processes will be impacted? If this is an improvement, can it be measured, and what is the expected goal?
The team should attempt to grok the issues and their magnitude. Ideally, they will be informed with data, not just opinions.
Just as with medical diagnosis, the symptoms alone are probably not enough input. There are various ways to collect more data, and which methods you use depends on the nature of the problem. For example, one method is the 5 W’s and 2 H’s:
Who is affected?
What is happening?
When does it occur?
Where does it happen?
Why is it happening (initial understanding)?
How is it happening?
How many are affected?
For humanity-affecting problems, I think it’s very important to define what the context of the problem is.
3. Contain the Problem
Containment
Some problems are urgent, and a stopgap must be put in place while the problem is being analyzed. This is particularly relevant for problems such as product defects which affect customers.
Some brainstorming questions are:
Can anything be done to mitigate the negative impact (if any) that is happening?
Who would have to be involved with that mitigation?
How will the team know that the containment action worked?
Before deploying an interim expedient, the team should have asked and answered these questions (they essentially define the containment action):
Who will do it?
What is the task?
When will it be accomplished?
A canonical example: You have a leaky roof (the problem). The containment action is to put a pail underneath the hole to capture the leaking water. This is a temporary fix until the roof is properly repaired, and mitigates damage to the floor.
Don’t let the bucket of water example fool you—containment can be massive, e.g. corporate bailouts. Of course, the team must choose carefully: Is the cost of containment worth it?
4. Root Cause Analysis
There can be many layers of causation
Whenever you think you have an answer to a problem, as yourself: Have you gone deep enough? Or is there another layer below? If you implementt a fix, will the problem grow back?
Generally in the real world events are causal. The point of root cause analysis is to trace the causes all the way back for your problem. If you don’t find the origin of the causes, then the problem will probably rear its ugly head again.
Root cause analysis is one of the most overlooked, yet important, steps of problem solving. Even engineers often lose their way when solving a problem and jump right into a fix which later on turned out to be a red herring.
Typically, driving to root cause follows one of these two routes:
Start with data; develop theories from that data.
Start with a theory; search for data to support or refute it.
Either way, team members must always remember keep in mind that correlation is not necessarily causation.
One tool to use is the 5 Why’s, in which you move down the “ladder of abstraction” by continually asking: “why?” Start with a cause and ask why this cause is responsible for the gap (or error). Then ask again until you’ve bottomed out with something that may be a true root cause.
There are many other general purpose methods and tools to assist in this stage; I will list some of them here, but please look them up for detailed explanations:
Brainstorming: Generate as many ideas as possible, and elaborate on the best ideas.
Process flow analysis: Flowchart a process; attempt to narrow down what element in the flow chart is causing the problem.
Fishikawa: Use a Fishikawa (aka Cause and Effect) diagram to try narrowing down the cause(s).
Pareto analysis: Generate a Pareto chart, which may indicate which cause (of many) should be fixed first.
Data analysis: Use trend charts, scatter plots, etc. to assist in finding correlations and trends.
And that is just the beginning—a problem may need a specific new experiment or data collection method devised.
Ideally you would have a single root cause, but that is not always the case.
The team should also come up with various correction actions that solve the root cause, to be selected and refined in the next step.
5. Choose the Permanent Solution
The solution must be one or more corrective actions that solve the cause(s) of the problem. Corrective action selection is additionally guided by criteria such as time constraints, money constraints, efficiency, etc.
This is a great time to simulate/test the solution, if possible. There might be unaccounted for side effects either in the system you fixed or in related systems. This is especially true for some of the major issues that transhumanists wish to tackle.
You must verify that the corrective action(s) will in fact fix the root cause and not cause bad side effects.
6. Implement the Solution and Verify It
This is the stage when the team actually sets into motion the correction action(s). But doing it isn’t enough—the team also has to check to see if the solution is really working.
For some issues the verification is clean-cut. Some corrective actions have to be evaluated with effectiveness, for instance some benchmark. Depending on the time scale of the corrective action, the team might need to add various monitors and/or controls to continually make sure the root cause is squashed.
7. Prevent Recurrence
It’s possible that a process will revert back to its old ways after the problem has been solved, resulting in the same type of problem happening again. So the team should provide the organization or environment with improvements to processes, procedures, practices, etc. so that this type of problem does not resurface.
8. Congratulate the Team
Party time! The team should share and publicize the knowledge gained from the process as it will help future efforts and teams.
Kevin Kelly concluded a chapter in his new book What Technology Wants with the declaration that if you hate technology, you basically hate yourself.
The rationale is twofold:
1. As many have observed before, technology–and Kelly’s superset “technium”–is in many ways the natural successor to biological evolution. In other words, human change is primarily through various symbiotic and feedback-looped systems that comprise human culture.
2. It all started with biology, but humans throughout their entire history have defined and been defined by their tools and information technologies. I wrote an essay a few months ago called “What Bruce Campbell Taught Me About Robotics” concerning human co-evolution with tools and the mind’s plastic self-models. And of course there’s the whole co-evolution with or transition to language-based societies.
So if the premise that human culture is a result of taking the path of technologies is true, then to reject technology as a whole would be reject human culture as it has always been. If the premise that our biological framework is a result of a back-and-forth relationship with tools and/or information, then you have another reason to say that hating technology is hating yourself (assuming you are human).
In his book, Kelly argues against the noble savage concept. Even though there are many useless implementations of technology, the tech that is good is extremely good and all humans adopt them when they can. Some examples Kelly provides are telephones, antibiotics and other medicines, and…chainsaws. Low-tech villagers continue to swarm to slums of higher-tech cities, not because they are forced, but because they want their children to have better opportunities.
So is it a straw man that actually hates technology? Certainly people hate certain implementations of technology. Certainly it is ok, and perhaps needed more than ever, to reject useless technology artifacts. I think one place where you can definitely find some technology haters are the ones afraid of obviously transformative technologies, in other words the ones that purposely and radically alter humans. And they are only “transformative” in an anachronistic sense–e.g., if you compare two different time periods in history, you can see drastic differences.
Also, although perhaps not outright hate in most cases, there are many who have been infected by the meme that artificial creatures such as robots and/or super-smart computers (and/or super-smart networks of computers) present a competition to humans as they exist now. This meme is perhaps more dangerous than any computer could be because it tries to divorce humans from the technium.
