When I told a fellow tech lead I was pursuing a Lean Six Sigma Yellow Belt, the reaction was predictable: “Is that not a manufacturing thing?” It is. And that is precisely why it is useful for engineering leadership. The best frameworks for improving software delivery do not always come from the software industry.
What Lean Six Sigma actually is
Strip away the jargon and Lean Six Sigma is two ideas fused together. Lean is about eliminating waste. Any activity that consumes resources but does not produce value for the customer. Six Sigma is about reducing variation. Making processes predictable and measurable. Together, they give you a framework for asking: “Where are we wasting time, and where are our outcomes inconsistent?”
The waste I found in my own team
Lean identifies categories of waste. When I applied them to our mobile engineering workflow, the results were uncomfortable. Engineers waiting for code reviews, waiting for backend API changes, waiting for QA environment access. Our cycle time data showed that a ticket spent roughly 40% of its lifecycle in a “waiting” state. Not blocked. Waiting.
PRs bounced back from code review multiple times because the ticket description was ambiguous. Engineers built the wrong thing not because they lacked skill, but because the requirements lacked clarity.
You cannot optimise what you have not measured. And most engineering teams have never measured the waste in their own workflow.
What I changed
The changes were not dramatic. That is the point. Lean Six Sigma is about incremental, measurable improvement, not heroic transformations.
I introduced a soft commitment: PRs get a first review within four working hours. Not a hard rule, a team norm. Before a ticket enters the sprint, it must have clear acceptance criteria and, for mobile work, a reference to the relevant codebase area. I moved status updates to structured Slack threads with a consistent format. We cut one recurring meeting entirely and shortened another from thirty minutes to fifteen.
Measuring the outcomes
This is where Lean Six Sigma differs from “gut-feel improvement.” You measure before, you change one thing, and you measure after. I tracked cycle time, rework rate, and sprint predictability. None of these are revolutionary metrics. But tracking them consistently and connecting changes to outcomes is what separates intentional improvement from hoping things get better.
Why this matters for engineering leaders
Engineering leadership is full of invisible process problems. We are trained to optimise code. We spot an O(n squared) algorithm and refactor it. But we rarely apply the same rigour to our team workflows. We tolerate waiting times in our delivery pipeline that we would never tolerate in our application latency.
Agile tells you to iterate. Lean tells you what to fix in each iteration.
If you lead an engineering team and you have not looked at where your time actually goes, start there. You might be surprised by how much of your sprint capacity is spent on things that do not produce value. And once you see it, you cannot unsee it.