Is Lean Just About Speed and Six Sigma About Quality? No — and Here’s Why

No. The claim that “Lean is for speed and Six Sigma is for quality” misrepresents both methodologies. Lean — based on the Toyota Production System — improves safety, quality, delivery, cost, and morale (SQDCM) together, with built-in quality (jidoka) as one of its two pillars. Six Sigma is one quality improvement methodology among several, and its projects often target time and cost, too. The speed-versus-quality split traces back to a book subtitle, not to Toyota.

I first published a version of this post in 2014. I’ve rewritten it because the myth hasn’t gone anywhere. You’ll still hear it in training classes, certification courses, and conference talks: Lean makes things fast, Six Sigma makes things good. It’s tidy. It’s memorable. And it sells a lot of combined training packages. Oh, and it appears in so so many LinkedIn posts and infographics. Way too many.

It’s also wrong about both methods, in ways that matter for how organizations actually improve.

Where the “Lean Speed, Six Sigma Quality” Idea Comes From

The phrasing isn’t folklore with a murky origin. It has a traceable source: Michael L. George’s 2002 book, Lean Six Sigma: Combining Six Sigma Quality with Lean Production Speed. The subtitle did a lot of work. Two methods, two jobs, sold as a package.

To be fair to George, the book is more careful than the slogan it spawned. That’s often how it goes. A nuanced idea gets compressed into a formula, the formula gets repeated in training decks, and twenty-some years later, people who’ve never read the book state it as settled fact. George’s own text acknowledged that Lean’s focus on speed doesn’t come at the expense of quality — the meme that spread dropped his nuance.

Search Google today for “difference between Lean and Six Sigma” and you’ll find university certificate programs and training vendors presenting the split as definitional: Lean eliminates waste, Six Sigma improves quality. Ugh. Most of the pages making that claim sell training in both. I’ll let you decide whether that’s relevant.

If people are just repeating what they’ve been taught, we can’t blame them. But we can offer a more accurate picture. And ask people to stop spreading a meme that’s inaccurate. As in factually incorrect, not just a difference in opinion.

What Lean Actually Says About Quality

Toyota’s own website describes the Toyota Production System as resting on two pillars: “just in time,” which is about flow, and “jidoka,” which is about building quality in at the source.

One of the two pillars. Quality isn’t a side effect of Lean. It’s half the structure.

The history goes back further than cars. Sakichi Toyoda invented a weaving loom that automatically stopped when a thread broke. That single invention saved time, increased productivity, and reduced the waste of defective fabric — all at once, through the same mechanism. Nobody at Toyoda’s loom works had to choose between speed and quality. The design choice delivered both.

That thinking runs through everything we’d now call Lean:

Defects are one of the classic categories of waste. A methodology built around eliminating waste is, by definition, built around eliminating defects.

Andon systems give any worker the authority to ask for help when something’s wrong — treating a potential line stop as responsible behavior, not a failure.

Error proofing (poka-yoke) designs processes so mistakes are harder to make in the first place, rather than inspecting for them after the fact.

I’ve seen what the absence of this thinking looks like. In more than one hospital laboratory, I’ve watched histology slides for three different patients sitting in stacks within the same small work area — a setup practically designed to produce a mix-up. When I asked one lab manager about the risk, the answer was, “It’s OK. My people are very careful.”

Careful people are a good starting point. They’re not enough. Quality at the source means designing the work so that being careful isn’t the only thing standing between a patient and a mislabeled specimen. That’s Lean. It has nothing to do with speed and everything to do with quality.

But Didn’t Ohno Say It’s All About the Timeline?

Here’s the strongest version of the other side’s argument, because it deserves a real answer.

Taiichi Ohno famously described the Toyota approach this way:

“All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.”

Doesn’t that prove Lean is a speed methodology? The timeline is right there in the quote.

Look at the mechanism, though. Ohno says the timeline shrinks by removing waste — and defects are waste. Rework is waste. Waiting for a correction is waste. You cannot durably shorten a timeline while producing bad work, because bad work creates its own delays: inspection, rework, scrap, complaints, do-overs.

Flow is improved not by working faster, but by reducing waste. I’ve written that sentence in every edition of Lean Hospitals, and it’s the distinction the myth misses. “Speed” in the pushing-people-harder sense isn’t Lean at all. It’s the thing Lean replaces.

Lean isn’t about working faster. It’s about removing causes of delays, waste, and interruption.

The connection runs the other direction, too. Better flow improves quality. Smaller batches mean a problem gets discovered in minutes instead of weeks, while the trail is still warm. Faster lab results mean better and more timely medical decisions. Fewer handoffs mean fewer chances for miscommunication.

W. Edwards Deming made a version of this argument decades before anyone said “Lean”: improve quality, and costs go down while productivity goes up, because you’re no longer paying for rework and waste. Quality and speed aren’t trade-offs in a well-designed system. They’re outputs of the same design.

What Six Sigma Actually Contributes

My roots and my bias — I always state them — are in Lean. But I’m not anti-Six Sigma, and this post isn’t an argument against it. My experience is with Lean. Plus TQM and statistical methods. I completed Green Belt training at a previous manufacturing employer, but didn’t get certified. I did get certified as a “Lean Black Belt” at Honeywell.

I’m not a Six Sigma expert, but I can state some things that are true. I get frustrated when Six Sigma experts claim expertise in Lean or TPS. It would be unfair of me to say “Six Sigma is all about cost cutting projects,” the way others claim “Lean alone would make bad stuff faster.”

Six Sigma is a data-driven quality improvement methodology created at Motorola in 1986, as an extension of the Total Quality Management movement, and popularized by Jack Welch General Electric in the 1990s. It’s known for the DMAIC project structure (define, measure, analyze, improve, control) and for training and certifying practitioners as “belts” of various levels. The name refers to a statistical goal: a process so capable that it produces only 3.4 defects per million opportunities.

There are problems where that toolkit genuinely shines — complex, multi-factor variation problems where you need designed experiments and serious statistical analysis to figure out what’s actually driving defects. I’ve seen Six Sigma methods do really well on exactly those problems.

But notice what the myth gets wrong even about Six Sigma. First, it doesn’t exclusively own quality. Organizations improved quality for decades before 1986 — through statistical process control, through TQM, through Toyota’s built-in quality practices. Second, Six Sigma projects routinely target cycle time and cost, so “Six Sigma is quality” undersells it the same way “Lean is speed” undersells Lean.

In healthcare, you can see the range of choices organizations make. ThedaCare and Virginia Mason followed Toyota’s example and skipped formal Six Sigma, combining Lean with the basic quality tools of TQM. Johns Hopkins uses both, under a Lean Sigma banner. One common pattern that makes sense to me: teach Lean thinking to everybody as a management system, and give deep statistical training to a small number of experts who take on the genuinely hard variation problems.

That’s a real division of labor. “Lean for speed, Six Sigma for quality” is not.

“Lean Removes Waste, Six Sigma Reduces Variation”? Both Halves Fall Apart

There’s a slightly more sophisticated version of the myth that you’ll hear in Lean Six Sigma courses: Lean handles waste, Six Sigma handles variation.

It sounds rigorous. It’s still wrong in both directions.

Lean attacks variation constantly. Standardized work exists to reduce variation in how tasks are performed. Heijunka — level loading — exists to reduce variation in workload and demand. Ohno described three enemies of good systems: muda (waste), mura (unevenness), and muri (overburden). Unevenness is variation. It’s been a named target of this way of thinking from the beginning.

And Six Sigma projects remove waste all the time. A DMAIC project that cuts rework has reduced waste. Nobody hands back the results because they came from the wrong methodology.

The formula survives because it makes the two approaches look like adjacent product lines with no overlap — which is convenient when the course catalog offers a belt in each. Reality is messier. Both address waste. Both address variation. Both depend on data.

One more thing on the statistics point, because it comes up: you don’t need a Black Belt to think statistically. Process Behavior Charts — the subject of my book Measures of Success — let leaders distinguish signal from noise in their metrics without any belt certification at all. Statistical thinking belongs to everyone, which is something Deming believed long before either “Lean” or “Six Sigma” existed as terms.

A More Accurate Comparison

If you want a side-by-side that doesn’t rely on false choices, here’s my attempt:

	Lean	Six Sigma
Origin	Toyota Production System, developed over decades (the term “Lean” was coined in 1988)	Motorola, 1986; popularized by GE in the 1990s
What it is	A management system and culture	A project-based problem-solving methodology
Who practices it	Everybody, every day	Trained specialists (“belts”) leading defined projects
Approach to quality	Built in at the source: jidoka, error proofing, andon, standardized work	Improved through statistical analysis of defects and variation
Approach to speed	A result of removing waste and delays, never a goal pursued at quality’s expense	Projects frequently target cycle time alongside defects
Where it shines	Engaging everyone, improving flow, daily kaizen, running the organization	Complex, data-heavy variation problems

And the overlap matters more than the differences suggest. Both aim at quality. Both reduce waste. Both reduce variation. Both are grounded in data and the scientific method. Any comparison that presents them as non-overlapping is describing the marketing, not the methods.

What This Looks Like in Practice

Early in my career, at a General Motors engine plant, I asked our plant manager whether quality or productivity came first. He was Larry Spiegel, one of the first GM leaders trained by Toyota at the NUMMI joint venture, and his answer has stayed useful for thirty years:

“Both. They go hand in hand.”

That wasn’t a slogan. NUMMI took a workforce that GM had written off, applied Toyota’s management system — standardized work, built-in quality, the authority to stop the line — and within a couple of years was near the top of the industry in quality and productivity. Same people. Same building. The system changed, and both results improved together.

I’ve watched the same pattern in hospitals. When a laboratory improves flow — smaller batches, clearer standardized work, fewer interruptions — turnaround times get shorter and more consistent, and errors drop. Reducing defects in a discharge process means fewer delays and better patient flow. Reducing delays in an emergency department means faster treatment and better outcomes. Pick either thread, quality or flow, pull on it honestly, and you end up improving the other.

The same holds in knowledge work, where the biggest waste is often the invisible rework loop: the report that bounces back three times, the requirements that were never clear, the handoff that silently dropped something. Fix the quality of the handoff and the work gets faster. Nobody had to type harder.

Is There Evidence That Lean Improves Quality?

I’d rather address this directly than pretend the question doesn’t exist. The academic literature on Lean in healthcare is mixed. A 2016 systematic review questioned whether the evidence base was strong enough to call Lean a proven quality improvement method for healthcare.

Part of what’s going on, I think, is a labeling problem. Many of the “Lean” implementations that get studied are tool-only projects — a 5S event here, a value stream map there — without the management system, the daily kaizen, or the leadership behavior change. When Lean as Mistakenly Explained (I call it L.A.M.E.) gets studied, I’m not surprised the results disappoint. That’s not a defense against all criticism, and healthy skepticism about any methodology is warranted. But there’s a real difference between “Lean doesn’t work” and “shallow Lean doesn’t work,” and the research often can’t distinguish the two.

Can Lean and Six Sigma Work Together?

Yes. I once worked at a manufacturing company where they coexisted, and there were problems well suited to each.

But coexisting isn’t merging. Someone once put it this way — I forget where I first heard it, so I can’t give credit where it’s due: you can put a cat and a poodle in a room together, and they might get along fine, but they don’t become a new animal called a “catoodle.”

The failure mode I’ve seen isn’t using both methods. It’s the packaging that shrinks Lean down to a few tools — 5S, a waste walk — bolted onto a Six Sigma project structure, while skipping the management system, the daily improvement culture, and respect for people. I’ve written before about why that packaging usually delivers more Six Sigma than Lean, and why “5S Six Sigma” would honestly be a more accurate name for a lot of what gets sold.

If you use both, get real depth in each. In my experience, organizations do better building the Lean culture as the foundation and reaching for Six Sigma’s statistical methods when a problem genuinely calls for them — rather than adopting a hybrid that waters down both.

The Question I’d Ask Instead

When somebody tells you Lean is about speed, it’s worth asking a quieter question: faster how? By pressuring people to hurry through a broken process? Or by removing the delays, rework, and defects that made the work slow in the first place?

The first approach isn’t Lean. It’s the thing that gives Lean a bad name. The second approach improves quality and speed together, because in a well-designed system they were never opponents.

If you were taught the speed-and-quality split in a class or a book, that’s not on you. It’s a system problem — the way these ideas get packaged and sold. But now you’ve seen a different picture.

What were you taught about Lean and Six Sigma? And has your own experience matched the formula, or contradicted it? The original 2014 post gathered a decade of reader discussion on exactly this question — it’s worth scrolling through, and I still read what comes in.

Frequently Asked Questions