Executive summary: TLS combines Theory of Constraints, Lean, and Six Sigma into one sequence rather than three competing programs. Theory of Constraints decides where to work, Six Sigma removes the variation and defects stealing capacity at that point, and Lean removes the waste and setup time surrounding it. The order is the method. Applied in this sequence, integrated programs routinely outperform any single methodology run alone, because the other two stop being aimed at processes that were never limiting output.
- What is TLS?
- Why does the order matter more than the tools?
- What does each methodology actually do well?
- Which method should you reach for?
- How do you stop the three camps fighting?
- What does one integrated cycle look like?
- What are the most common TLS mistakes?
- TLS: operator FAQ
- About the Stagnation Assassin
What is TLS?
TLS is the integration of Theory of Constraints, Lean, and Six Sigma into a single improvement sequence. Theory of Constraints identifies where to focus, Six Sigma eliminates variation and defects consuming capacity there, and Lean removes waste and setup time around it. The sequence is what distinguishes it from running all three simultaneously.
The three methodologies are usually presented as alternatives, and organizations tend to pick one and build an identity around it. That framing is the problem. They are not competing philosophies answering the same question. They answer three different questions, and each is weakest exactly where another is strongest.
Theory of Constraints is excellent at telling you where system output is limited and hopeless at telling you how to fix a process once you get there. Six Sigma is superb at eliminating variation and defects and offers no guidance on which defects matter to the business. Lean is unmatched at removing waste and flow interruption and will happily remove waste from processes whose waste was costing nothing.
Put differently: Theory of Constraints supplies targeting, Six Sigma and Lean supply firepower. A methodology with targeting and no firepower identifies the constraint and cannot fix it. A methodology with firepower and no targeting improves whatever is nearest and wonders why the numbers do not move.
I have led transformations at Berkshire Hathaway, Illinois Tool Works, and Whirlpool, and I have watched organizations run all three of these simultaneously as rival programs with separate budgets, separate steering committees, and separate consultants. That arrangement produces enormous activity and very little movement in system output, which is a particular kind of organizational tragedy because everyone involved is competent and working hard.
Why does the order matter more than the tools?
Because improvement applied away from the constraint does not change system output, no matter how well executed. Sequencing constraint identification first means every subsequent Lean or Six Sigma hour lands where it converts into throughput. Reverse the order and you get technically excellent projects producing no measurable business result.
The evidence for this is uncomfortable and easy to observe. I watched one team identify twenty-three legitimate improvement opportunities during a mapping exercise, form kaizen teams for all of them, implement nineteen over the course of a year, and raise system throughput by three percent. Only one of the twenty-three sat at the constraint. The other twenty-two consumed real resources, delivered real local improvements, and contributed nothing to what the business produced.
Nobody on those teams did poor work. The tools were applied correctly. Every project would have passed a technical audit. The failure was upstream of execution entirely: the portfolio was selected democratically rather than by constraint impact, which felt fair and was completely wrong.
One team identified 23 improvement opportunities, implemented 19 over a year, and moved system throughput 3 percent. Exactly one of the 23 sat at the constraint. The other 22 were competently executed, locally successful, and irrelevant to what the business produced. The tools were not the problem. The targeting was.
This is why TLS is a sequence rather than a toolkit. The sequence is doing the work. Once constraint identification comes first, the same Lean and Six Sigma capability that produced three percent starts producing double-digit throughput gains, because it is aimed at the one place where improvement compounds into system output.
What does each methodology actually do well?
Theory of Constraints optimizes system throughput by managing the limiting resource. Six Sigma reduces variation and defects using statistical analysis through the DMAIC cycle. Lean eliminates waste and improves flow using tools such as SMED, 5S, and total productive maintenance. Each is strongest precisely where the others offer least.
Theory of Constraints: targeting
Answers where. It identifies the single resource limiting output, then prescribes exploiting it, subordinating everything else to it, and elevating it only when exploitation is exhausted. Its weakness is that it tells you your welding operation is the constraint and offers no method for making welding better once you arrive.
Six Sigma: variation and defects
Answers how to make a process consistent. DMAIC provides a rigorous cycle for finding root causes of defects and variation. Its weakness is project selection. Teams pick projects by defect rate, which means a high defect rate on a non-constraint outranks a moderate defect rate on the constraint, even though only the latter costs the business capacity it cannot recover.
Lean: waste and flow
Answers how to remove everything that is not adding value. SMED for changeovers, 5S for workplace organization, total productive maintenance for reliability, pull systems for flow. Its weakness is scope discipline. Lean philosophy says remove waste everywhere, which is admirable and, applied without targeting, spreads finite improvement capacity across processes where waste removal changes nothing.
Read those three weaknesses together and the integration case writes itself. Theory of Constraints has no repair method. Six Sigma has no targeting. Lean has no prioritization. Each gap is precisely filled by one of the others.
Which method should you reach for?
Route by symptom once the constraint is known. If the constraint loses capacity to defects and rework, use Six Sigma. If it loses capacity to changeovers, searching, or downtime, use Lean. If it is fully exploited and still limiting, elevate with capacity. Away from the constraint, the answer is usually to do nothing yet.
Here is the routing rule I use, applied only after constraint identification.
- Constraint capacity lost to defects or rework means variation is the enemy. Run a DMAIC project on that specific defect mode. Every defective unit at the constraint consumed constraint time you cannot get back, which is why moderate defect rates there outrank severe rates elsewhere.
- Constraint capacity lost to changeovers means setup is the enemy. Run SMED on that changeover specifically. This is frequently the largest single block of recoverable capacity in the plant.
- Constraint capacity lost to searching, walking, and disorganization means the workplace is the enemy. Run 5S at that workstation, and only that workstation, before extending it anywhere else.
- Constraint capacity lost to breakdowns means reliability is the enemy. Run total productive maintenance and condition monitoring on that asset, budgeted by constraint status rather than by machine value.
- Constraint starved by upstream behavior means flow is the enemy. Install pull signals and subordinate upstream release to constraint consumption.
- Constraint fully exploited and still limiting means capacity is genuinely the enemy. Now, and only now, elevate through investment.
Notice that every branch begins with constraint capacity. That is not stylistic. It is the mechanism that keeps the routing honest, because it forces every proposed project to state which specific constraint loss it addresses. A project that cannot answer that question goes back in the queue, however good it looks on its own terms.
How do you stop the three camps fighting?
Give them one shared diagnosis instead of three competing mandates. The conflict is structural, not personal: separate budgets and separate success metrics guarantee competition for resources. A single constraint diagnosis that all three camps helped produce removes the thing they were fighting about.
The pattern is remarkably consistent across companies. The Lean camp favors mapping, 5S, and kaizen events. The Six Sigma camp favors DMAIC and defect reduction. The constraints camp favors throughput optimization. Each has genuine expertise, a track record it can point to, and a budget it needs to defend. So they compete for improvement resources, argue about which methodology is superior, and improve inside their own silos.
Three structural fixes work.
One diagnosis, produced jointly. Run the constraint identification as a cross-functional exercise with all three camps present, measuring together on the floor. When the Six Sigma lead personally counted the inventory in front of the constraint, the argument about where to focus is finished. Shared observation beats shared reports every time.
One success metric. System throughput, not local metrics. If the Lean camp is measured on waste eliminated and the Six Sigma camp on defect reduction, both will optimize their own number and neither will own the outcome. Measure all three on the same throughput figure and the competition dissolves, because they now win or lose together.
One sequenced queue. A single prioritized list of improvement work, ordered by constraint impact, that all three camps draw from. This is where the political fight actually resolves, because the queue makes explicit that a Six Sigma project at the constraint outranks a Lean project elsewhere, and that this is about location rather than about which methodology is better.
Expect resistance to the third one. Telling a capable team their well-designed project sits behind someone else’s because of where it is located feels arbitrary until people internalize the throughput logic. That is a change management problem, not a technical one, and it is the part that determines whether integration survives its first year.
What does one integrated cycle look like?
A full cycle runs roughly a quarter: diagnose the constraint, analyze what is stealing its capacity, run targeted Six Sigma work on defects and rework, then targeted Lean work on setup and flow, then confirm the constraint has moved and restart. Integrated cycles commonly deliver throughput gains in the mid-twenties percent range within a single quarter.
Weeks 1 to 2: diagnose
A cross-functional team maps the flow and identifies the constraint through inventory accumulation, cycle time against takt, and measured availability. Expect the measured availability at the constraint to be substantially worse than management believes. That gap is usually where the opportunity lives.
Weeks 3 to 4: analyze the losses
Break the constraint’s lost capacity into causes. How much to quality rework, how much to changeovers, how much to breakdowns, how much to starvation from upstream. This breakdown is what routes the next two phases, and it is the step most programs skip in their eagerness to start improving.
Weeks 5 to 8: Six Sigma on the constraint
Run DMAIC on the dominant defect mode consuming constraint capacity. Trace it to root cause rather than treating symptoms. Fixture alignment, tooling wear, material variation, and operator technique variation are common culprits, and the fixes are frequently inexpensive relative to the capacity they return.
Weeks 9 to 12: Lean on the constraint
Now attack setup and flow at the same operation. SMED on the constraint changeover, 5S at that workstation, and pull signals from the constraint to stop upstream overproduction. Doing this after the quality work matters, because rework was inflating the apparent workload.
Week 13 onward: confirm migration and restart
Measure the new throughput and find where the constraint went. It will have moved, often to packaging or shipping. That is success, not failure, and it starts the next cycle.
An integrated cycle at one manufacturer took final assembly availability from 72 to 91 percent and system throughput from 420 to 535 units per week, a 27 percent gain in 14 weeks. Lean alone typically delivers less over six months, and Six Sigma alone improves quality metrics without necessarily moving throughput at all.
What are the most common TLS mistakes?
Four dominate: running the three methodologies in parallel instead of in sequence, keeping separate budgets and metrics that guarantee camp conflict, selecting Six Sigma projects by defect rate rather than by constraint impact, and improving upstream processes that then flood the constraint with inventory.
Mistake 1: parallel instead of sequential
The defining error. All three programs run simultaneously across the plant, each doing competent work, with no shared targeting. Activity is high, morale is often good, and system throughput barely moves. Sequence them. The order is not a preference, it is the mechanism.
Mistake 2: improving the process that feeds the constraint
A specific and expensive version of the parallel trap. A Lean team achieves a genuine efficiency gain on the operation upstream of the constraint, which increases the rate of material flowing toward a process that cannot absorb it. Work in process balloons, working capital gets consumed, and the constraint team watches its buffers overflow while the Lean team celebrates. Halt non-constraint improvement until the constraint is exploited.
Mistake 3: selecting projects by defect rate
Six Sigma teams choose projects where the statistics are most dramatic. A high defect rate on a process with spare capacity has low business impact, because that process can absorb the rework. A moderate defect rate at the constraint has severe impact, because every defective unit consumed capacity that caps the entire plant. Select by constraint impact, not by defect magnitude.
Mistake 4: keeping the budgets separate
As long as each camp defends its own budget and reports its own metric, integration is rhetorical. Structural incentives beat stated intentions in every organization I have worked in. Consolidate the budget, consolidate the metric, and consolidate the queue, or accept that you have three programs with a shared slogan.
My own mistake here was assuming that demonstrating the logic would be enough to dissolve the camp conflict. It was not. People had built careers, credibility, and identity around a specific methodology, and asking them to subordinate it to someone else’s targeting felt like a demotion. What eventually worked was making the constraint diagnosis a joint exercise so that every camp had authorship of the answer. People will subordinate to a conclusion they helped reach far more readily than to one handed to them.
TLS: operator FAQ
What does TLS stand for?
Theory of Constraints, Lean, and Six Sigma, integrated into one improvement sequence. Theory of Constraints identifies where system output is limited, Six Sigma removes the variation and defects consuming capacity there, and Lean removes the waste, setup time, and downtime around it. The sequence is what makes it work.
Why does TLS outperform Lean or Six Sigma alone?
Because it solves the targeting problem. Lean and Six Sigma are both excellent at fixing processes and offer little guidance on which process to fix, so their capacity gets spread across operations where improvement does not change system output. Constraint identification concentrates that same capability where it converts into throughput.
In what order should the three methodologies be applied?
Constraints first to identify where, then Six Sigma to eliminate defects and rework stealing capacity at that point, then Lean to remove setup time, disorganization, and downtime there. Quality work comes before flow work because rework inflates the apparent workload, which distorts any setup or balancing analysis performed first.
What is the most common TLS implementation failure?
Running the three programs in parallel rather than in sequence, each with its own budget and success metric. This produces high activity, competent local improvements, and little movement in system throughput. A related failure is improving the operation upstream of the constraint, which floods it with inventory and consumes working capital.
About the Stagnation Assassin
Todd Hagopian is a Fortune 500 transformation executive who has generated $3B+ in shareholder value across Berkshire Hathaway, Illinois Tool Works, Whirlpool, and JBT Marel, where he serves as VP of Global Product Strategy. Known as The Stagnation Assassin, he is the author of two published books: The Unfair Advantage: Weaponizing the Hypomanic Toolbox and Stagnation Assassin: The Anti-Consultant Manifesto. His blog is published in 15+ languages and read by operators worldwide. Bring him to your stage via the speaking page or connect with him on LinkedIn.
Next step: audit where your improvement effort lands
Count your active improvement projects, then count how many sit at the process that actually limits your output. If the second number is not most of them, your improvement capacity is being spent on work that cannot move the business. Book a 20 minute audit and I will help you re-sequence it. Start the audit here.