In Part I of this series, we traced Motorola’s landmark quality transformation of the 1980’s – a 100:1 improvement that earned the company the inaugural Malcolm Baldrige National Quality Award in 1988, and made the case that the Shainin System was at the heart of it.
Six Sigma became the platform.
Red X was the performance multiplier.
In Part II, we explore the principles that make the Shainin System so effective and how organizations of today can implement it to enhance their current problem solving efforts, including their existing Six Sigma programs.
What Made Red X Different?
The Five Fundamental Principles
To understand why the Shainin approach delivered such dramatically different results, it helps to understand the five fundamental principles that underpin it. While Gregg Young provided a descriptive first look at the five principles in his 2009 white papers, “Six Sigma’s Best Kept Secret Parts I and II” this article will dive deeper with Shainin’s own insight into each of these principles.
Principle 1: Pareto's Law Is Universal
Pareto’s Law, often called the 80/20 Rule, suggests that a small number of causes are responsible for a large percentage of the results. In technical problem solving, this means most failures are not generated equally across dozens or hundreds of variables. A small number of dominant causes are typically responsible for the majority of the observed variation.
The Red X methodology was intentionally structured to leverage this Pareto imbalance.
Rather than treating every possible factor as equally important, Red X assumes that dominant causes exist and uses structured contrast and convergent investigation techniques designed to expose them quickly. In some cases, the dominant cause is not a single variable but an interaction between two or more factors that must occur together to generate the failure. The investigation progressively eliminates weak contributors so engineering effort becomes concentrated on the few variables, or variable interactions, exerting the greatest influence on the response.
This fundamentally changes the economics of the investigation.
Traditional investigations often spread resources broadly across long lists of possible causes. Teams may test numerous variables, implement several corrective actions, and achieve only partial improvement, commonly reducing failures by 20 to 50%. This becomes even more difficult when the dominant cause is an interaction effect, since those relationships are often masked within large groups of secondary contributors. In many cases, investigations stop after one contributing factor is identified even though stronger drivers of variation remain active within the system.
Red X approaches the problem differently. Early-stage investigation activities are intentionally designed to eliminate secondary contributors before significant engineering, metrology, and validation resources are consumed.
By isolating and controlling the dominant causes rather than simply identifying contributing factors, Red X investigations commonly achieve defect reductions exceeding 90%.
Principle 2: A Process That Usually Works Is Fundamentally Sound.
Gregg Young correctly and succinctly identifies that “when an operation works correctly most of the time but occasionally generates defects, the process itself is usually not broken.” The operation already demonstrates that it is capable of producing good output under the correct conditions. Something changes when the failures occur.
This creates an important shift in how the investigation should be approached. Rather than redesigning the entire operation, the objective becomes identifying the differences between successful and failed conditions.
The Red X approach is built to leverage this contrast.
By comparing good output against defective output, the investigation works to isolate what changed when the failure occurred.
This distinction is especially important in high-volume manufacturing environments where the process may already be producing acceptable output most of the time. Redesigning it risks introducing new variation to fix something that was not fundamentally broken. Rather than disrupting a fundamentally capable operation through broad redesign efforts, the investigation focuses on identifying and controlling the specific variables responsible for defect generation.
The result is defect reduction through tighter control of the critical factors rather than broad process disruption to fix a system that was already fundamentally capable of success.
Principle 3: Compare Performance Extremes to Identify Consistent Differences
This is, as Bhote put it, the principle to remember above all others. The Red X approach focuses exclusively on performance extremes: the Best of the Best (BOBs) and the Worst of the Worst (WOWs). Whatever critical factors are causing defects will show their most pronounced differences when comparing these extremes.
This is what makes the approach so effective. Extreme differences amplify signal.
Any factor that is consistently different between the best and worst outputs is critical — pursue it. Any factor that is not consistently different is non-critical — ignore it.
This principle sits at the operational heart of the Red X methodology. Rather than relying primarily on engineering intuition, historical assumptions, or broad brainstorming exercises, the investigation uses physical contrast to let the evidence identify what matters.
The parts themselves reveal the answer.
"The best way to discover why things go right is to observe what is different when things go wrong."
Principle 4: Effects Have Causes — There Is No True White Noise
Most engineers are familiar with the distinction between common cause variation and special cause variation. Gregg Young often described similar concepts as White Noise and Black Noise. Black Noise represents variation with an identifiable assignable cause. White Noise represents variation assumed to be random, unavoidable, or simply part of the system.
The Red X philosophy challenges how quickly organizations accept variation as unavoidable.
In many manufacturing environments, long-standing defects eventually become normalized. Teams adapt to them, build containment around them, and begin treating the remaining variation as background noise rather than something still driven by identifiable causes. But longevity does not make a problem random, and familiarity does not make it unsolvable.
This does not mean every source of variation justifies investigation. Engineering effort must still be weighed against operational impact and return on investment. The objective is not to eliminate every possible source of variation. The objective is to identify and control the dominant causes creating the greatest performance loss, risk, or cost to the operation.
As those major contributors are resolved, the economics of the investigation change. Variation previously considered insignificant or unavoidable may now represent the next largest opportunity for improvement. Many chronic issues labeled as “common cause variation” are ultimately traced back to specific variables, conditions, or interactions that were simply never isolated.
All effects have causes. Many chronic problems persist not because they are random, but because they have been accepted as unavoidable.
Principle 5: “90% of Specifications Are Wrong” … or at Least Inadequate
One of the most common refrains during chronic investigations is: “But the parts are in spec.”
Specifications are important, but they are not the final authority on whether a process will successfully produce acceptable output. Specifications are created using the knowledge available at the time the product or process was designed. In complex production environments, real-world interactions and process sensitivities are not always fully understood until failures begin occurring in production.
This creates a critical distinction in the Red X approach: if defects are occurring consistently, then at least one condition currently considered “acceptable” is contributing to unacceptable output.
The drawing may be correct. The process sheet may be correct. Individual measurements may all remain within tolerance. Yet defects can still occur because the actual operating window required for stable performance is narrower than originally understood, or because interactions between factors were never fully recognized.
The Red X approach recognizes a critical distinction: “in specification” and “capable of consistently producing good output” are not always the same thing.
Rather than assuming specifications are automatically correct, the investigation focuses on identifying which conditions consistently separate good output from bad output. Once the dominant causes are isolated, Realistic Target Values and Tolerances can be established based on observed process behavior rather than assumed acceptable ranges alone.
When this principle is applied consistently, Zero Defects shifts from aspiration to achievable reality. A supplier who reaches Zero Defects while competitors still generate defective output has created a structural competitive advantage that compounds over time.
Red X and Six Sigma: A Powerful Partnership
Red X and Six Sigma address different parts of the problem-solving challenge, which is precisely why they have historically worked well together.
When Motorola crafted Six Sigma, Red X primarily existed as a set of highly effective convergent investigative tools. Since then, the methodology has evolved into a complete problem-solving framework with its own structured investigative process: FACTUAL.
The methodologies are complementary, but they are not interchangeable.
Six Sigma excels in environments where systems, inputs, and variation sources are already reasonably well understood. DMAIC provides strong structure for managing variation reduction, process control, optimization, and organizational deployment at scale.
Red X excels when the dominant causes are still unknown.
This distinction becomes increasingly important as manufacturing systems grow more complex. New materials, tighter tolerances, layered supplier networks, automation, software integration, environmental sensitivity, and interacting variables dramatically increase the number of possible failure pathways inside the system.
Many investigations struggle not from lack of data, but from lack of convergence. Teams collect more measurements, generate more hypotheses, and expand analysis activity without confidently isolating the factors materially driving the response.
The Red X methodology addresses this directly through convergent investigation techniques designed to separate dominant causes from secondary contributors and progressively narrow the search toward the variables exerting the greatest influence on the output.
This is where the partnership becomes powerful.
Red X rapidly isolates the dominant causes hidden within complex systems. Six Sigma provides the organizational structure to control and sustain those improvements across the operation. What Motorola’s history clarifies is that they work better together than either does alone.
Six Sigma became the platform.
Red X was the performance multiplier.
For quality leaders who have already built a Six Sigma infrastructure — who have Black Belts, project charters, control plans, and a culture of data-driven improvement — the path forward is not to abandon what they have built. It is to strengthen their ability to rapidly converge on the true drivers of variation before broader optimization and control efforts begin.
It is to add back the tools that Motorola treated as proprietary.
What This Means for Your Six Sigma Program Today
For organizations already invested in Six Sigma, the implication is not that the methodology failed. The implication is that many organizations implemented only part of what originally made Motorola’s problem-solving capability so effective.
The public rollout of Six Sigma emphasized DMAIC, statistical tools, process control, and organizational deployment. What remained largely proprietary were the convergent investigative methods Motorola used internally to rapidly isolate dominant causes inside complex production systems.
Those methods eventually evolved into the modern Red X framework and its structured FACTUAL investigation process.
This distinction matters because many organizations today already possess strong quality infrastructure: Black Belts, SPC systems, metrology capability, data collection, control plans, and extensive reporting structures. Yet chronic problems still persist because teams struggle to confidently narrow toward the variables materially driving the response.
The challenge is often not generating more analysis, but converging on the factors that actually matter.
This is where Red X methods become particularly valuable. Tools such as Multi-Vari, Component Search, Paired Comparisons, Variable Search, and B vs. C were specifically developed to isolate dominant causes rapidly while minimizing unnecessary disruption to production operations.
The historical results documented by Gregg Young suggest the performance difference was substantial. Standard Six Sigma deployments often reported defect reductions in the 20–50% range over extended investigation periods, while Motorola’s Shainin-based investigations repeatedly achieved defect reductions exceeding 90% on some of the company’s most complex manufacturing problems.
The financial impact reflected the same pattern. Reported ROI figures for Shainin deployments ranged from 20:1 to 29:1 compared to roughly 2:1 to 4:1 for more traditional Six Sigma implementations, with some organizations reportedly achieving operational impact exceeding 4% of revenue.
Importantly, these methods were designed for real production environments. They do not require shutting down operations, building massive experimental matrices, or relying exclusively on advanced statistical software. They were built to converge quickly using physical contrast, structured investigation, and production-safe analysis methods.
They can be applied by direct line workers, as demonstrated by an appliance manufacturer who solved a 7-year-old warped grill problem in a single week.
For organizations seeking the level of problem-solving performance historically associated with Motorola, the opportunity may not be rebuilding the quality system already in place. It may be strengthening the organization’s ability to rapidly isolate and control dominant causes using the convergent investigative methods that were never broadly deployed outside Motorola’s internal programs.
Ready to Close the Performance Gap?
Contact us to schedule a call. We’ll help you review the current problem solving performance gap and develop a plan to fix it.
Download our checklist to help you identify the hidden gaps in your current approach.
