Most companies build their continuous improvement programs the wrong way. They train a single green belt or black belt and expect that one person to fix everything. However, studying Six Sigma principles in Amazon's operations reveals a completely different model. At Amazon, process engineers do not own the solutions. Instead, they build the capability for frontline teams to find the answers themselves.

In this episode of the Why They Fail Podcast, Kevin Clay sits down with Mariam Abdalmasih, Senior Process Improvement Engineer for London Fulfillment Operations at Amazon. Mariam brings nearly a decade of cross-functional experience across automotive, food manufacturing, and retail logistics. As a result, she offers a rare inside look at how a structured metric environment functions at genuinely massive scale.

Amazon treats process excellence as a foundational part of daily operations. It is not a standalone department. It is not a temporary initiative. Therefore, continuous improvement is built directly into the operational infrastructure from day one.

During the conversation, Mariam explains how corporate metrics cascade down to visual display screens on the fulfillment floor. Every individual operator can see exactly how their work connects to larger corporate performance indicators. Furthermore, Amazon relies on an independent system of Gemba walks to verify those numbers on the ground. This prevents data from being analyzed in silos. Instead, operations and process safety teams work together in real time to validate what the dashboards are actually showing.

A major theme of this episode is how Amazon develops its organizational culture around enabling rather than dictating. Mariam outlines how prioritizing leadership capability in hiring allows continuous improvement professionals to serve as true guides. Consequently, ownership of improvement stays exactly where it belongs: with the subject matter experts on the floor.

Additionally, the episode unpacks Amazon's "one-way door vs. two-way door" decision-making framework. This operational model actively encourages calculated risk-taking. It empowers frontline teams to make faster, independent improvements while keeping the customer experience completely protected.

Understanding Six Sigma principles in Amazon's operations means understanding that sustainability comes from infrastructure first, not individual practitioners.

Applying these principles is what separates a lasting continuous improvement culture from one that fades within 18 months.

First, process improvement practitioners must act as frontline enablers, guiding teams rather than dictating solutions. Second, metrics must cascade from corporate targets down to visual management systems on the floor so every operator understands their impact. Third, data trends and control chart signals must always be verified firsthand through structured Gemba walks. Fourth, evaluating actions as reversible two-way doors empowers teams to move fa...

• (00:00:00) - Why Continuous Improvement Efforts Fail
• (00:01:09) - Why They Fail: Continuous Improvement at Amazon
• (00:02:46) - Alex Jones on Continuous Improvement at Amazon
• (00:10:25) - Six Sigma vs Lean: What's the Difference?
• (00:13:15) - Six Sigma in Amazon
• (00:18:34) - Six Sigma and the Chaos of Operations
• (00:19:56) - Does the Continuous Improvement Strategy Help?
• (00:27:04) - Continuous Improvement: The Process-based culture

Most business leaders believe they are running a lean operation. However, if your Kanban cards are still moving to the beat of unstable MRP lead times, you are not pulling. You are running a heavily masked push system. Implementing true pull system vs push operations is what separates an 11% EBITDA crawl from a 30% to 200% financial explosion in year one.

In this episode of the Why They Fail Podcast, host Kevin Clay sits down with Toyota Motor Manufacturing veteran Phil Ledbetter. Together, they expose exactly why standard lean initiatives stall out and what a genuine, system-wide pull framework actually looks like.

Continuous improvement efforts frequently turn into corporate toys. Leadership rolls them out, loses interest, and abandons them within months. This happens because most organizations treat Kanban cards as isolated, standalone fixes. As a result, departments remain siloed and every process step continues running to its own localized drum.

When you push batches through isolated cells, you create massive workflow imbalances. Furthermore, push methods rely on the false assumption that internal lead times are perfectly accurate and stable. Because push systems cannot anticipate daily machine downtime or quality failures, work-in-process inventory piles up between stations. Consequently, excess safety stock blinds your management team and actively hides the true constraints of your system.

Transitioning away from push schedules requires a complete inversion of traditional operational thinking. An authentic pull framework acts as the autonomic nervous system of your entire facility. In this environment, material replenishment is dictated by real-time customer usage rather than rigid weekly schedules.

Additionally, a successful pull framework relies on mathematically calculated buffers. These limits are not random piles of extra inventory. Instead, they are specifically engineered to absorb everyday operational variation without disrupting downstream flow. When you commit to implementing true pull system vs push architectures, inventory levels remain constant while finished goods steadily build. Therefore, your teams are forced to address root causes immediately rather than hiding behind safety stock. This disciplined approach drives a measurable surge in total profitability.

Applying these principles consistently is what separates a genuine lean transformation from another abandoned corporate initiative.

First, standard lean initiatives stall because companies treat Kanban as a standalone visual tool rather than an integrated operational system. Second, localized push schedules and faulty lead times create WIP inventory that hides critical process constraints. Third, authentic pull systems consistently generate 30% to 200% EBITDA growth within the first year of proper execution. Fourth, operational buffers must be scientifically calculated based on process distance and flow structure to protect customer pace. Fifth, tr...

• (00:00:00) - Why They Fail: Continuous Improvement (
• (00:01:11) - Why They Fail: Continuous Improvement (
• (00:05:37) - What is the Kanban?
• (00:07:17) - Process Flow and Pull
• (00:08:47) - Kanban First
• (00:14:22) - Machine operators: Push and Pull
• (00:17:22) - What is a Buffer at Toyota?
• (00:20:00) - How Lean Economics Work in Manufacturing
• (00:23:36) - Kanban and the Lean Initiative
• (00:26:58) - Keynote: Just In Time Continuous Improvement

Most continuous improvement programs fail within 18 months. The reason is almost always the same: leadership started by avoiding bad Six Sigma projects the wrong way. Instead of using data, they used gut feeling.

In this episode of the Why They Fail Podcast, host Kevin Clay sits down with 40-year CI veteran Wade Harper. Together, they expose the systemic failures behind poor project selection. More importantly, they show what a disciplined, data-driven deployment actually looks like.

Wade's career is built on real-world results. He engineered nuclear weapons components under Six Sigma pioneer Michael Harry at AlliedSignal. He then rose to Master Black Belt roles at Ford and Honeywell. Additionally, he led the largest Lean Six Sigma deployment in U.S. Army history. All resources, tools, and links discussed in this episode are available at Wade's website: https://ameripie.com/

Avoiding bad Six Sigma projects starts with understanding why good leaders make poor choices. Most executive teams do not lack ambition. However, they consistently avoid the hard work of establishing clear performance standards.

As a result, corporate deployments measure success using vanity metrics. Total people trained. Total certifications issued. These numbers look impressive. Unfortunately, they say nothing about bottom-line value created.

A newly appointed CI practitioner then gets sent off to tackle arbitrary projects. There is no data infrastructure. There is no clear problem statement. Therefore, the project is set up to fail before it begins.

Every project charter must be grounded in hard numbers. That is the foundation of avoiding bad Six Sigma projects. Emotion and workplace pain are not valid starting points for a deployment strategy.

One of the most costly mistakes in any CI deployment is optimizing a non-bottleneck step. For example, fixing step three in a seven-step process may look compelling in a presentation. However, if step three is not the true constraint, output at the door does not change. The financial return is zero.

Furthermore, when baseline data is absent, executives default to a destructive pattern. They begin managing people instead of managing process capabilities. Consequently, employees get blamed for failures that are actually structural and systemic.

Shingo-style process mapping is one of the most effective tools for solving this problem. It separates flow from work in a way that traditional value stream mapping does not. As a result, transactional and service teams gain the granular visibility needed to isolate defects before they move downstream.

Applying these principles consistently is what separates high-performing CI programs from failed ones.

First, every project charter must be grounded in baseline operational data, not emotion or workplace pain. Second, program success must be me...

• (00:00:00) - Why They Fail
• (00:00:59) - Why They Fail: Why Leadership Chooses Bad Projects
• (00:02:57) - Wade McAfee on Continuous Improvement
• (00:09:28) - Black Belt vs. Six Sigma
• (00:16:57) - Black Belt vs. Yellow Belt
• (00:22:29) - Six Sigma and the Lean Process
• (00:27:14) - Why They Fail