Lean Six Sigma is having a moment in large organizations right now. After years of Agile dominance, some leadership teams are rediscovering process improvement methodologies from manufacturing and wondering if they might solve the problems that Agile did not.
They might — in the right context. Lean Six Sigma is a serious methodology with real applications and a track record of genuine results. The problem is not the methodology. The problem is what happens when it gets applied to work it was not designed for.
This post is about that mismatch — what Lean Six Sigma is, what it does well, and why applying it to software engineering teams usually produces the wrong outcome even when everyone involved has good intentions.
What Lean Six Sigma Was Built For
Lean Six Sigma comes from factory line work.
The core idea is straightforward: find a repeatable process, map it carefully, identify the waste and variation within it, eliminate what does not add value, and standardize what remains. Do this consistently and you get a process that is faster, cheaper, and more predictable than the one you started with.
This works extraordinarily well when the work is genuinely repeatable. A manufacturing line that produces the same part hundreds of times a day is the ideal Lean Six Sigma candidate. The process exists. It can be observed. It can be measured. The waste is visible — unnecessary steps, defects, idle time, excess inventory. Remove the waste and the line gets better.
Lean Six Sigma is not a bad methodology. It is a methodology that was built for a specific kind of work and works best when that kind of work is what you are actually doing.
The Factory Line Problem
Here is what happens when you try to apply Lean Six Sigma to software engineering.
The methodology assumes there is a repeatable process to optimize. But software engineering teams are not running the same process over and over. They are standing up new factory lines — building new systems, solving new problems, navigating new constraints — every time they take on significant work.
You cannot optimize a process that does not exist yet. You cannot find waste in a factory line that is still being designed.
The work that does repeat in software engineering — routine maintenance, standard deployments, predictable support requests — can benefit from Lean Six Sigma thinking. If your team has a consistent intake process for business-as-usual requests, if the first request in is the first request out, if the work is genuinely predictable and repeatable, then looking for waste in that process makes sense.
But that is not the majority of what engineering teams do. The majority of what engineering teams do is build new things in response to new problems. Each project has different requirements. Each solution requires different thinking. The factory line is not optimized — it is invented.
Applying Lean Six Sigma to that work does not find waste. It finds novelty and calls it inefficiency.
What Leadership Is Actually Looking For
When leadership proposes Lean Six Sigma for engineering teams, they are usually not thinking carefully about the methodology’s origins or its design constraints. They are thinking about control.
Leadership wants to be able to say “jump” and have everyone jump. They want to know when the jumping will be completed. They want the jumping to look the same every time so they can predict it, report on it, and hold people accountable for it.
Lean Six Sigma, in theory, offers that. It promises repeatable processes, measurable outcomes, and continuous improvement toward a defined standard. For a leader who is frustrated by the unpredictability of software delivery, that promise is appealing.
The problem is that the work requires more than jumping. Sometimes it requires running. Sometimes turning around. Sometimes stopping entirely to reassess. The right movement depends on the problem — and the problem changes every time.
A framework that treats every situation as the same jump produces the wrong movement at the wrong time. The process gets followed. The jumping happens on schedule. And the team arrives at the wrong place because jumping was not actually what the situation required.
Leadership gets the control they asked for. They do not get the delivery they wanted.
What Gets Lost
When Lean Six Sigma thinking takes over in an engineering organization, something specific gets lost: the judgment of the engineers.
A Lean Six Sigma process, properly implemented, does not need engineers who think. It needs engineers who follow the process. Variation is the enemy — and judgment is a source of variation. The engineer who looks at a requirement and asks “is this actually the right approach?” is introducing variation into a process that is supposed to be standardized.
This is exactly the opposite of what builds ownership and engagement. The engineers who care about their work — who ask why before asking how, who surface problems nobody assigned them to find, who have opinions about the best way to solve a problem — are the ones who make product teams work.
They are also the ones who introduce the most variation from a Lean Six Sigma perspective.
The methodology that was supposed to improve the process ends up optimizing the people out of it.
What to Do If Your Organization Is Mandating It
If your organization is requiring Lean Six Sigma certification or implementing Lean Six Sigma processes for engineering teams, here is the honest advice: take the class. It is not worth fighting.
Not because Lean Six Sigma is right for your team. Because the fight costs more than the certification. Leadership has made a decision. The energy you spend arguing against the methodology is energy you are not spending protecting your team’s ability to deliver.
Take the class. Learn the language. Understand the framework well enough to speak to leadership in terms they recognize.
And then — this is the part worth doing with some genuine care — look for the actual waste in your actual processes. Not the waste that Lean Six Sigma predicts based on manufacturing assumptions. The waste that actually exists in how your team works: the meetings that produce nothing, the approval gates that add weeks without adding value, the handoffs that create delays, the rework that happens because requirements were not clear enough before work began.
Some of that waste is real and worth eliminating. The Lean Six Sigma vocabulary gives you a way to talk about it that leadership will hear. Use the language even if you are skeptical of the framework.
The most useful thing about learning Lean Six Sigma in an organization that has mandated it is that you can now find the waste in the Lean Six Sigma process itself — and name it in terms leadership understands.
The Longer View
Methodologies come and go in large organizations. Lean Six Sigma was the dominant framework before Agile. Agile displaced it. Now, in some organizations, the pendulum is swinging back.
The engineering teams that survive these swings are not the ones that fight each new methodology. They are the ones that keep delivering — that maintain the outcomes orientation, the short feedback loops, the culture of ownership — regardless of what the methodology is called this week.
The sprint review where a metric moved is still the sprint review where a metric moved, whether the meeting is called a sprint review or a process improvement checkpoint or something else entirely. The engineer who shows up prepared and asks why before asking how is still that engineer, regardless of whether the organization is running Agile or Lean Six Sigma or some hybrid that has not been named yet.
The methodology is the container. The delivery is what matters.
Keep delivering. Learn enough of the new language to have the conversations you need to have. And protect your team’s ability to do the work that actually moves the numbers — whatever framework is currently wrapped around it.
Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →
Use code SEPTEMBER20 for 20% off the book or a paid subscription through September 30.
I publish every Tuesday at danielholt.substack.com
Top comments (0)