Lean management is a mindset focused on three principles: delivering quality to the customer at the right time (not just on time), eliminating waste, and enabling continuous team growth. Waste means anything that does not bring value to the customer, including unused features, unclear requirements, and repeated production problems. Understanding the root cause of a problem, rather than rushing to a quick fix, prevents the same issue from recurring.
Key Takeaways
Lean starts with the problem, not the solution
Lean asks you to sit with a problem before you reach for a fix. That runs against instinct. When something breaks, the first reflex is to find a solution and move on.
Nirmala Saneechur learned lean at IKEA, where the company sponsored her Green Belt certification. What stayed with her was how much time the method spends on the problem itself. During training, the group would examine a problem so thoroughly that the solution became obvious. Once you know exactly what went wrong, the fix almost writes itself.
This is where lean meets quality. When you understand the root cause instead of patching the symptom, you solve the problem once. It does not come back. That is quality built into the work rather than bolted on afterward.
The mindset shift is the hard part. Even after a year and a half of practice, Nirmala’s first reaction to a problem is still “what’s the solution?” The discipline is to step back after the quick fix and ask why it happened at all.
What lean management actually means
Lean means reducing waste, and waste is anything that does not bring value to the customer. That definition is the anchor for everything else.
The method rests on three ideas. You deliver quality to the customer at the right time. You keep waste low. And you put people at the center, so teams keep improving.
Lean started at Toyota as a factory concept. It carries over to software because the underlying question is the same everywhere: which parts of what you produce actually help the customer, and which parts are motion without value.
Nirmala treats lean as a mentality rather than a fixed procedure. You can apply it at home or while driving, asking whether you are making a gesture that is not required. The same reflex works on a software process.
Why “at the right time” beats “on time”
Delivering on time is not the same as delivering value. You can hit every deadline and still produce waste.
Nirmala worked on a project where the team built 15 features for a client. When the client started using the application, they never touched those 15 features. The work was delivered on time, exactly when it was requested, and it still counted as waste because nobody used it.
That is overproduction. You built something the customer thought they needed and then never needed. Right-time delivery means shipping what the customer actually uses, when they actually use it, not filling a requirements list because it was written down.
How to spot the waste in your process
Waste hides in the flow of ordinary work, so the first job is learning to see it. Some waste you have to live with, some you can remove.
A double click to open something brings no value, but you may have no choice but to keep it. That is waste you tolerate. The waste worth attacking is the kind that repeats and compounds.
The clearest example is the requirement you cannot understand. You read it, you go back to the person who wrote it, they answer, you read again, you still do not understand. That back and forth is pure waste. Working together on the requirement at the start would have removed the loop entirely.
Eliminating waste is a creative act, not a checklist. If a user clicks through three tabs to reach what they need, a hyperlink on the first page removes the detour. There is no single method. You understand the specific waste, then invent the way to cut it.
A problem in production is waste too
When production stops, the time you spend correcting the issue produces nothing for the customer. That makes the problem itself a form of waste.
The counter to it is getting things right the first time. Each time you understand more about where you went wrong, your odds of getting it right on the next attempt improve. Problem-solving is not a detour from lean, it is one of the ways lean removes waste.
Not every problem earns the same investment. If something happens once, you still find the root cause, but you spend little time on it. If a problem recurs, the analysis pays off.
Take a test environment that goes down regularly. If the fix is always a restart, the restart is a shortcut, not a solution. The recurring pattern is the signal to stop and understand what actually causes the outage.
The quick fix and the real fix are two separate jobs
Keeping production running and solving the problem are different tasks, and lean asks you to do both. First you apply the shortcut so work continues. Then you go back for the real solution so the problem does not return.
The temptation is to treat the shortcut as the end. It feels productive to move on. But the time spent understanding a recurring problem is productive for the future, because it removes the chance of the same failure happening again.
This analysis has one firm rule: it is not about blaming people. The questions are about the process and the requirements. Were the requirements clear? If not, why not? The point is to understand what went wrong so the next round is cleaner, never to find a person to fault.
Root-cause work spreads beyond the part you started on
Fix one problem properly and the effect rarely stops at your corner of the system. Problem-solving in lean tends to ripple through the whole chain.
When you dig into a single issue, you often find it touches more than the piece you were assigned. It can reach into operations, into processes owned by other teams. To optimize the whole chain, you work with everyone involved, because that is where the real gain sits.
At IKEA this started inside IT and grew larger than the IT processes. Getting people who do not know lean to buy into the idea is harder outside the original team, but the surrounding processes began to shift to match the work already underway.
The lesson for anyone starting small: the small piece you handle now has an effect in the long run. Treating it as “just my bit” misses the chain reaction that follows.
Winning management buy-in is the real constraint
Lean costs time up front, and managers under pressure resist spending it. The honest tension is that a manager wants the fast solution now, and lean asks for time to understand.
Nirmala had an advantage: at IKEA, lean came from management. The managers were already trained and wanted it in the company, so they accepted that the work takes time at the start.
Speed comes with practice. Early on, a complex problem could take a day or two just to understand. As the reflexes build into how people think, the same analysis gets much faster.
The argument that convinces management is the durability of the result. Solve the problem properly once, and you never face that exact problem again. That is quality for the future, and it is what makes the time defensible.
Making lean a habit, not a one-off
Lean only holds if it becomes routine, and building that routine is genuinely difficult. Some people buy in fully. Others feel they are wasting their time. Getting momentum and keeping it running is the constant challenge.
To keep the practice alive, Nirmala’s IT team runs a session every Friday. Each week someone shares a problem they solved, walking through their thought process. It could be you next, so everyone stays engaged, and the sharing spreads the method across the team.
Alongside the weekly session, the Green Belt certified members coach anyone who wants to go deeper into lean. Much of embedding lean is education, moving people along until a critical mass practices it by default.
Lean and agile are not in conflict, though some people struggle to see how they fit. You keep your dailies and everything your day already contains. Lean sits on top, giving you a way to see where the problems are.
Visual management is one of the tools here. You draw your processes and map where your tickets sit and who owns each step. It takes time at first. Once you have the gist, it runs smoothly.
Where to start with lean
The entry point is straightforward: read up on it. There is a large amount of material available online, enough to get oriented on your own.
You can also ask ChatGPT, with one caution from Nirmala. Check the answers and make sure they are the right ones before you act on them.
Clean processes matter more as AI tools move into everyday work. If a process is messy and overloaded, layering AI on top does not help. Getting things right the first time is exactly what lean is built for, which puts it squarely in step with the current moment.
Frequently Asked Questions
Why is a lean mindset hard to adopt even after months of practice?
The reflex to reach straight for a solution stays strong. Nirmala Saneechur, who learned lean at IKEA, says that after a year and a half of practice her first reaction to a problem is still to ask what the solution is. The discipline is to apply the quick fix so work continues, then step back and ask why the problem happened at all.
Does lean only work in manufacturing?
No. Lean began at Toyota as a factory concept, but the underlying question travels: which parts of what you produce actually help the customer, and which parts are motion without value. Treated as a mentality rather than a fixed procedure, it applies to a software process just as well as to asking at home whether a gesture is required at all.
Can a project be delivered on time and still count as waste?
Yes. One team built 15 features for a client and delivered them exactly when requested. Once the client started using the application, they never touched any of them. That is overproduction. Right-time delivery means shipping what the customer actually uses, when they use it, not working through a requirements list because someone wrote it down.
What does waste look like in day-to-day software work?
Anything that brings no value to the customer: features nobody uses, requirements nobody understands, production problems that keep returning. A requirement you read, query with its author, and still cannot understand creates a loop of back and forth that working on it together at the start would have removed. Some waste, like an extra double click, you simply tolerate.
Does every problem deserve a full root-cause analysis?
No. If something happens once, you still find the root cause, but you spend little time on it. Recurring problems are where the analysis pays off. A test environment that goes down regularly and gets restarted every time is the clear signal: the restart is a shortcut, not a solution, and the pattern is worth understanding.
Is root-cause analysis about finding who made the mistake?
No, and that is a firm rule. The questions target the process and the requirements: were they clear, and if not, why not. The purpose is to understand what went wrong so the next round is cleaner. Looking for a person to fault produces nothing; understanding removes the chance of the same failure happening again.
How do you convince managers to spend time on lean when deadlines are tight?
Argue the durability of the result. Solve a problem properly once and that exact problem does not come back, which is quality for the future and makes the upfront time defensible. The analysis also speeds up with practice: early on, a complex problem can take a day or two just to understand, and the reflexes shorten that considerably.
Do lean and agile compete with each other?
No, though some people struggle to see how they fit together. You keep your dailies and everything your day already contains, and lean sits on top as a way to see where the problems are. Visual management supports this: you draw your processes and map where tickets sit and who owns each step.
