I want to be honest about something before I start. I almost skipped the first course entirely.
November 2020. I was in the middle of a busy stretch at work, things were moving fast, and a short online course on operational excellence felt like the kind of thing you do when you have time - which I didn't. I started it anyway, mostly out of curiosity. Got partway through, thought "this is useful, I'll come back to it," and then didn't. Not properly. Not until something at work made the idea click in a way the course hadn't quite managed to do on its own.
That gap - between learning something and actually using it - is maybe the most honest thing I can say about this whole journey.
Operational excellence isn't just for big organisations
There's a version of this topic that feels corporate and distant. Factories, defect rates, Six Sigma black belts in large multinationals running improvement projects. If you're not in that world, it's easy to assume the framework doesn't quite apply to you.
It does. I'd argue it applies more to smaller teams and individuals than most people realise - because at smaller scale, one broken process hurts proportionally more. There's less buffer. Less redundancy. A process that works inconsistently doesn't get absorbed by the system. It shows up immediately in the results.
Standardise across thousands of processes
Reduce variation at scale. The cost of one broken process multiplied by hundreds of executions every week.
Simplify processes for effectiveness
Stop rebuilding the same process from scratch. Make good results repeatable rather than accidental.
Whether you lead a team of hundreds or work independently - you still need to work on the reasons, not just the outcomes. The scale changes. The logic doesn't.
That last line is the one I keep coming back to. Working on outcomes feels productive. It's visible, it's urgent, it gives you something to report. But outcomes are downstream. By the time you're managing them, the decision that caused them was already made.
Why I went back - 14 months later
By early 2022, about a year into a CLM role, I had a frustration I couldn't quite name. The strategies were working. The thinking was sound. But the execution was inconsistent in ways that were hard to pin down. Good results one month, unexplained drop the next. The same process run by two different people producing noticeably different outcomes.
I knew this was a process design problem. I'd absorbed enough from the 2020 course to recognise the shape of it. What I didn't have was a structured way to actually diagnose and fix it. So I went back to LinkedIn Learning and this time I didn't stop partway through.
Lean Six Sigma Foundations in February. Then Green Belt and Black Belt - both finishing on the same day in March, which sounds more impressive than it was. The Black Belt path had been running alongside for weeks. They just happened to complete together.
Over 35 hours of material in under a month, alongside a full-time job. I'm not recommending that pace. It worked because the material was solving a problem I was actively dealing with. When that's true, it's hard to stop. When it isn't, courses feel like homework.
What Six Sigma actually taught me
The honest version: the first few modules felt like confirmation of things I already knew. Of course you should define the problem before solving it. Of course you should measure before you improve. I nearly got impatient with it.
Then I started applying it to actual work situations and realised I hadn't been doing those obvious things at all. Not properly. I'd been defining problems loosely, measuring the outputs I had available rather than the ones I actually needed, and jumping to solutions that addressed symptoms rather than causes. The framework wasn't telling me things I didn't know. It was showing me that I wasn't actually doing what I thought I was.
Six Sigma didn't change what I knew. It changed what I actually did - and those turned out to be more different than I expected.
DMAIC - the part that stuck
Define, Measure, Analyse, Improve, Control. The whole methodology is built around not skipping steps. Specifically not skipping to I before you've properly done D, M, and A.
That sounds obvious. In practice, almost everyone skips to I. Something isn't working, you have a theory about why, you implement the fix. Sometimes it works. Often it doesn't, or it works temporarily and then drifts back. DMAIC is structured specifically to prevent that - to slow you down at exactly the point where you most want to speed up.
Define
What is the actual problem?
Measure
What does current state actually look like?
Analyse
Root cause, not symptom.
Improve
Design the fix, test it small first.
Control
Make the improvement hold.
The Control step is the one I underestimated most. It's unglamorous. The problem is solved, the improvement is showing, and documenting it and building controls feels like admin. But skip it and the process drifts back within months. I've seen this - improvements that held for a quarter and then quietly disappeared because nothing was monitoring whether the right inputs were still in range.
Y = f(X) - the equation behind everything
This is the idea that ties all four courses together. Your output (Y) is a function of your inputs (X). You cannot directly control Y. You can only control the X's that produce it.
It sounds simple. It changes how you look at almost every problem once it's properly in your head. At Beximco Communications, I got the chance to share this concept with the team in a workshop setting. Standing up and explaining it to others was probably the moment it fully clicked for me - teaching something always does that.
The result you track. You can measure it but you can't touch it directly.
The variables that produce Y. These are what you actually control.
Subscriber retention rate
Plan upgrade conversion
Revenue per subscriber
Campaign response rate
When in the lifecycle we reached out
How the offer was framed
Which segments received which message
Channel and frequency of contact
The trap most teams fall into is managing Y and hoping X will sort itself out. They track the output obsessively, report on it weekly, have meetings about why it moved. But Y is always lagging. By the time it tells you something went wrong, the decision that caused it was already made weeks ago. The fix is to get upstream - identify the X's that actually drive the output and control those instead.
The Lean side - waste you stop noticing
Where Six Sigma focuses on reducing variation, Lean focuses on eliminating waste. Steps that consume time and effort without delivering any value to the customer. In practice, the hardest waste to eliminate is the kind you've stopped seeing - the things that have always been done a certain way, so nobody questions whether they need to be done at all.
Overprocessing
Effort applied without targeting. Campaigns sent to customers who weren't at risk anyway.
Waiting
Triggers that fire after the optimal window has passed. Almost right is still wrong.
Rework
Rebuilding the same process from scratch each cycle because nothing was documented last time.
Overproduction
Reports generated because they're scheduled, not because anyone needs them or acts on them.
I recognised all four of these immediately. Which was slightly uncomfortable - it meant they'd been present in my work for a while and I'd been working around them rather than fixing them. Naming something as waste rather than just "the way things are" is the first step to eliminating it.
Choosing the right tool
One thing the Operational Excellence course did well was explaining that these methodologies aren't interchangeable. Using the wrong one - even well - wastes time.
Lean Six Sigma
Fix a process that exists but isn't performing. Best when you know something is broken but not exactly why.
Continuous Improvement
Small, fast, incremental changes made regularly. Better for embedding a culture of improvement than solving one big problem.
Design for Six Sigma
Build something new with quality designed in from the start, not fixed afterwards.
Value Stream Mapping
Map every step, identify which add value and which don't. Shows where waste lives before you decide what to cut.
Things I'd tell someone starting this
Have a real problem in mind before you start
I learned almost nothing useful from the 2020 course because I was treating it as general knowledge. The 2022 courses landed completely differently because I had a specific operational problem I was actively trying to solve. The same material, different context, completely different retention.
Control is the step that matters most
Everyone gets excited about Improve. Nobody wants to spend time on Control. But an improvement without a control system isn't an improvement - it's a temporary fix that will drift back the moment attention moves elsewhere. Build the controls before you call the project done.
It applies to you, even if you're not running a factory
This framework is for anyone with a repeatable process that isn't producing consistent results. That's most people. The vocabulary is heavy with manufacturing examples but the underlying logic translates everywhere.
Work on the X's, not the Y
This is the one to take away if you take nothing else. Stop managing outputs and start controlling inputs. Find the reasons behind the outcomes. That's where the leverage is - and it's the thing most teams never quite get around to doing.
I'm glad I went back to these courses when I did - with a real problem to solve rather than a vague intention to learn. The gap between the 2020 course and the 2022 ones taught me something the courses themselves didn't: knowledge you can't apply right now doesn't stay with you. File it away and come back when you have a reason to use it. That's when it actually works.
