Watch the webinar here:
View the slides here:
Lao Tzu's line is famous enough to be a cliché: the journey of a thousand miles begins with one step. The line that gets less attention is the implication. You're going to take that first step badly. You have to take it anyway.
This webinar is unlike most of what gets published about continuous improvement. It's not a methodology overview or a tools curriculum or a case study of organizational success. It's two practitioners reflecting honestly on what they got wrong in their first years -- Mark Graban as a young industrial engineer at a GM engine plant in 1995, then as someone making the transition to healthcare in 2005, and Greg Jacobson, MD as an emergency physician launching a Kaizen program at Vanderbilt in 2004. Each of them has roughly two decades of continuous improvement work behind them now. Each of them remembers very specifically what they would do differently if they could go back.
The session is also a working argument about how to think about continuous improvement at all. The frame that runs through it: this isn't a thing you implement. It's a practice. The word implementation suggests a project with a start, a middle, and an end. The word practice suggests something you keep doing, get better at over time, and never finish. Physicians practice medicine. Lawyers practice law. Architects practice architecture. The expression isn't accidental. Greg traces it back to the Oxford English Dictionary: the earliest English usage from 1421 meant pursuing or being engaged in a professional skill or art, and by 1542 it had taken on its modern meaning -- performing an activity repeatedly in order to acquire, improve, or maintain proficiency.
The implication for continuous improvement is direct. Organizations that frame the work as "we're implementing Lean" set themselves up for failure, because implementation has an endpoint and Lean doesn't. Organizations that frame the work as "we're practicing Lean" set themselves up for the long arc -- learning, missteps, recovery, improvement, more missteps, more recovery, all of it ongoing. The first frame produces "we tried that already" within a couple of years. The second frame produces practitioners who are still getting better at the work two decades in.
Mark Graban is a Senior Advisor to KaiNexus and the author of Lean Hospitals and co-author of Healthcare Kaizen. Greg Jacobson, MD is co-founder and CEO of KaiNexus. Both have spent more than two decades practicing continuous improvement in healthcare and other settings. Both are happy to talk about what they got wrong.
Before getting to the specific mistakes, both Mark and Greg make a point worth pulling out. People starting their first year of continuous improvement will make mistakes. That's not a failure of intelligence or effort. It's a feature of any practice. The healthier response from those further along the journey isn't to step back and criticize but to coach and help.
The implicit warning is to the experienced practitioner. The reflex when watching someone make a mistake you remember making yourself is to dismiss them. That reflex makes the field worse. It treats expertise as a club rather than a discipline that exists to develop other practitioners. Mark's own reflection: when criticizing a practice that he thinks is misguided, he tries to attack the practice rather than the person. The acronym he's developed -- LAME, "Lean as Misguidedly Executed" -- frames the criticism around the practice rather than the people. Whether that lands gently enough is its own question, but the underlying discipline is to keep the criticism aimed at what people are doing, not at who they are.
This matters because continuous improvement depends on people being willing to try things, fail at them, and try again. An environment where the established practitioners are quick to dismiss newcomers produces a field where newcomers stop trying. The cost is invisible and substantial.
Mark offers a framing of how a continuous improvement practitioner's role typically evolves over time.
First, you learn how to do. You learn how to use a particular tool or method, and you can produce real results -- helping people improve organization, safety, errors, throughput. This phase is necessary. It's also incomplete.
Then, you learn how to teach. The transition is from doing the improvement work yourself to teaching other people how to do it. The center of gravity shifts from your hands to other people's hands, mediated by your coaching. The Green Belt is at the doing stage. The Black Belt is at the teaching stage.
Then, you learn how to teach how to teach. The Master Black Belt isn't teaching the work directly; they're teaching other people how to teach the work. This is the multiplier stage, where one practitioner develops dozens of practitioners who each develop dozens more.
The framing is useful as a self-assessment for anyone in the field. The reflex is to keep doing the work yourself because you know how. The discipline is to keep moving up the stack -- from doing to teaching to teaching-how-to-teach -- so that the practice scales beyond what you can do alone. Practitioners who never make these transitions become bottlenecks. Practitioners who make them become builders of capability.
Greg's first year in continuous improvement began in 2004 when his department chair at Vanderbilt handed him Masaaki Imai's book on Kaizen and asked him to teach the residents how to apply it and to launch a Kaizen program in the emergency department.
His mistake was structural. He went straight from the CEO-level conversation to the frontline staff and skipped everyone in between. The middle managers and senior leaders -- the people whose buy-in and engagement would have determined whether the program survived its first year -- weren't included in the early conversations at all. The frontline staff got excited about identifying opportunities for improvement, but their managers didn't know what was happening, didn't understand the expectations, and didn't have context for how this fit into the department's strategy.
In retrospect, Greg names the missing work specifically. Five to ten short conversations with five to ten key middle leaders. Not hours of training -- just enough to say "this is what's about to happen, this is why, this is what we'd like from you, what concerns do you have, what questions can I answer." A few hours of total time investment. Without it, the middle layer of leadership had no idea what was expected of them, and the program was operating on the energy of frontline staff and the cover of senior leadership without the management infrastructure that actually sustains the work.
The framing he applies in hindsight is change management. The decision to launch a Kaizen program is a change. Changes require management. The work of change management is making sure that everyone affected understands what's happening, why, and what role they play. Skipping the middle layer -- which is what most central CI teams do when they get excited -- is the single most common pattern that produces stalled programs.
Greg's offsetting success in that first year, which he attributes more to luck than to deliberate strategy, was that he followed Masaaki Imai's guidance about what kind of improvements to ask for. Specifically: low-cost, low-risk changes. Small problems. Annoyances and irritations. Things that frustrate staff in their daily work.
This matters because of what it does to the feedback loop. When you ask staff to identify expensive, high-risk, complex improvements, the ideas they generate are either rare (because most people don't have million-dollar ideas at the ready) or unimplementable (because the organization can't act on them quickly). The feedback loop is broken. People stop submitting ideas because nothing happens to them.
When you ask staff to identify low-cost, low-risk frustrations, the ideas come in volume, the organization can act on them quickly, and the staff member sees their idea implemented within days or weeks. That feedback loop is the engine. It produces the habit of looking for improvement opportunities, because every time you identify one, something visible happens.
Greg's reading of the underlying mechanism comes from habit science. The immediate visible reward -- "I identified a problem and now it's fixed and I don't have to deal with it anymore" -- is what builds the habit of continuous improvement participation. Without that immediate reward, the behavior doesn't compound. With it, the behavior becomes self-reinforcing.
The interesting footnote is what happens at volume. Roughly one in fifty to one in a hundred small improvement ideas turns out to have major impact -- $50,000, $100,000, sometimes more. The point isn't that you ask for small ideas because small ideas are valuable on their own. You ask for small ideas because the small-ideas process is what produces the big ones, almost incidentally. The team that generates a thousand small ideas finds the ten or twenty large ones embedded in them. The team that only asks for big ideas never finds either.
Mark's first year began in 1995 as a young industrial engineer at the GM Livonia engine plant in suburban Detroit. The environment was a traditional manufacturing culture. The lessons he draws from that year are honest about what he got wrong, and they're useful precisely because the failure modes were structural rather than personal.
The first pattern: he operated in engineer mode. "It's my job to do stuff" -- to do the analysis, do the research, pick the equipment, make the decisions. Even when the work was nominally for the benefit of frontline employees, the work itself was solo. The team members who would have had useful input weren't asked for it. The reflex was to make decisions for them rather than with them. The cultural environment of the plant didn't particularly encourage doing it any other way, but in retrospect, that's a description, not an excuse.
The second pattern: ideas went into a suggestion box and disappeared. The plant had a formal company-and-union endorsed suggestion program. Mark participated in it as an engineer, submitted ideas he was proud of, and watched them go nowhere. The lesson he draws from his own frustration is the one that has shaped his work since: if you're going to ask for ideas, you have to do something with them. The cost of asking and then ignoring is higher than the cost of not asking at all, because it teaches people that their input doesn't matter.
The third pattern: too much time in computer simulation software. Mark had learned manufacturing simulation as an industrial engineering tool in college, and GM had the software, and he spent hours running scenarios to find the "right answer" to questions about inventory levels and uptime improvements. Some of that work was valuable. Most of it was a substitute for going to the gemba and watching the actual process. The reflex of the trained engineer is to model the system. The discipline of Lean is to observe the system. The two are different activities and the first one without the second one produces optimization of a model that doesn't quite match the world.
The fourth pattern: he wrote off the frontline supervisors. The plant's day-to-day operations were run by people the company called "team coordinators" -- a well-intended title for what were, culturally, traditional manufacturing foremen. Mark worked well with frontline staff and reasonably well with senior management. He wrote off the supervisors as people who would never change. The honest reflection now: that was wrong. They weren't bad people. They were products of thirty years in a culture that had taught them how to behave. The plant manager Mark had a good relationship with -- one who had experience with the GM-Toyota joint venture -- later told him that he'd been patient with those supervisors because he understood what Mark hadn't understood at the time: they hadn't had the benefit of being mentored in a different way. They were doing what they'd been trained to do. Coaching might have changed them. Dismissing them definitely didn't.
The fifth pattern: he got emotional about an unsafe situation. Mark spent significant time on the shop floor and saw situations that had been reported and weren't being fixed. After watching a near-miss that he thought could have produced a serious injury, he left a strongly-worded voicemail to a maintenance manager and copied a number of other people. He was right that the situation was dangerous and right that it should have been fixed. He was also wrong about the strategy. The voicemail damaged the working relationship with the maintenance manager and made the next conversation harder rather than easier. There's a difference between being right and being effective. Both matter. The reflection is not that he should have stayed quiet -- it's that there are ways to make waves that build coalitions and ways to make waves that burn them. He chose the wrong one.
Several practices from that first year held up over time.
He took the advice of one supervisor -- a graduate of W. Edwards Deming's training who had come around to a different management philosophy -- to spend time building relationships, not just doing tasks. That advice opened doors with the UAW shop committee that wouldn't have opened otherwise. The advice to "sit down and have a cup of coffee with them" turned out to be one of the most consequential investments of Mark's first year.
He engaged the people in the jobs bank -- a unique UAW-GM arrangement that paid laid-off workers to sit in the cafeteria rather than being unemployed. Most engineers wouldn't go near the jobs bank workers. The contract actually allowed engineers to bring jobs bank workers into improvement projects, and Mark did. Some of those workers turned out to be genuinely excited to participate in the work rather than rotting in the cafeteria. They became some of his best partners that year.
He learned a foundational lesson from the plant manager about the relationship between quality and cost. When Mark asked which of the plant's problems they should work on first -- the cost problem or the quality problem -- the plant manager was patient enough to coach rather than judgmental enough to dismiss. The answer he gave: both, and by improving quality you reduce costs. The two aren't separate problems with separate solutions. They're connected, and the work of improving quality is the work that drives the cost improvements that finance wants. That framing has stayed with Mark across thirty years of continuous improvement work.
He learned by watching the plant manager spend time at the gemba. The plant manager was responsible for 800 employees. He spent significant time on the floor -- talking, listening, building relationships, setting a model. He once told Mark, talking about the cultural change he was trying to lead, that he probably knew most of the answers, but the employees didn't know he knew. The work was building the trust that would let them learn what he had to teach. Mark watched a leader who spent more time listening than talking, and the model has stayed with him.
Mark's transition to healthcare in 2005 was his second first year. The lessons from that one are subtler.
The first lesson was about humility. The temptation when making the transition from manufacturing to healthcare is to walk in saying "I'm here to fix you." The healthier posture is "let's figure this out together." Healthcare organizations are sophisticated at resisting outsiders who arrive with answers. They're more receptive to partners who arrive with curiosity. Mark partnered with clinicians who had good continuous improvement instincts. The combination of an outsider with methodology experience and an insider with domain experience and credibility worked. The outsider alone, no matter how skilled, struggled.
The second lesson was about using manufacturing examples sparingly. Mark's first instinct was to draw on his factory experience to explain methodology to healthcare audiences. The factory stories were interesting to Mark. They were largely irrelevant to the people he was teaching. They didn't translate the way he assumed they would. Within a year he was developing healthcare examples and using them instead. The methodology travels. The stories don't, or at least they don't travel easily.
The third lesson was about the balance between getting stuff done and bringing others along. The pressure on an outside consultant or internal change agent is to produce results. The discipline of continuous improvement work is to teach people to produce results themselves, which is slower in the short run and faster over the long arc. The tension is real and never goes away. The mistake Mark names is leaning too far toward getting stuff done at the expense of teaching, because the work that gets done by the consultant disappears when the consultant leaves. The work that gets taught stays.
Michael Lombard, then corporate director of operational excellence at Cornerstone Healthcare Group, joins the session toward the end with his own version of the same reflections. He'd had two first years too: one in modular manufacturing where his background was, and one in healthcare where he transitioned later.
His manufacturing first year mistake was the same as Greg's, in different clothes. He went to a Lean seminar, got excited, came back to his factory, and developed an all-day training program full of simulations tailored to the modular-home environment. Managers attended. They got excited too. They went back to their day jobs after the training and nothing changed. The underlying assumption -- that didactic education by itself would produce behavior change -- was wrong. The training was the easy part. The work of supporting people in actually changing how they operated was the part that didn't happen.
The corrective Michael applies now: condense the training, make it specific and just-in-time, and let learning-by-doing produce most of the change. The training is a support function for the practice, not a substitute for it.
His healthcare first year mistake was different. By that point he knew enough to engage the right stakeholders -- middle managers, senior leaders, frontline staff. He led a redesign of ER patient flow processes that produced real results. As long as he was actively running the project, the improvements held. When he was reassigned to the next project, the improvements began to decay.
The reason, in retrospect, was that he had set goals around improving processes but not around building the capacity of the team to keep improving after he left. Continuous improvement isn't a project that completes. It's a capability that has to be developed in the people who will keep doing the work after the consultant or the central CI team moves on. Michael's framing: the goals should include building the team's capability, not just achieving the immediate process improvements. The process improvements without the capability are temporary. The capability includes the process improvements and produces more after that.
His broader observation extends Mark's earlier framing. Healthcare organizations are heavy on the social side of socio-technical systems. The mechanistic approach -- "if I adjust this lever, the system will respond predictably" -- works less well than in manufacturing. People are not levers. The flexibility, adaptability, and patience that healthcare improvement requires is different from what manufacturing improvement requires. The methodology is the same. The application is more demanding.
Several themes show up in every reflection across the three practitioners.
Start small. Low-risk, low-cost improvements produce the feedback loop that builds the habit. Big ideas without small ideas underneath them don't sustain.
Engage the middle. The most common mistake in launching a continuous improvement program is treating it as a CEO-to-frontline initiative and skipping the middle managers whose buy-in determines whether anything sticks.
Build coaching capacity early. The work has to be developed in other people, not just done by you. The bottleneck in any continuous improvement program is how fast you can build a community of practice that doesn't depend on you.
Be honest about not knowing. The reflex to perform expertise is the enemy of learning. Practitioners who say "I don't know yet, let's figure this out" make faster progress than practitioners who pretend they have all the answers.
Treat the work as a practice. The framing matters. Implementation has an endpoint. Practice doesn't. The organizations that sustain continuous improvement are the ones whose leadership frames the work as ongoing rather than as a project to complete.
The mechanics of how to get started with continuous improvement aren't reducible to software, but the infrastructure does matter once the practice is underway.
The feedback loop Greg names as the engine of Kaizen depends on the organization being able to act on small ideas quickly. Without infrastructure for capturing those ideas, routing them to the people who can implement them, tracking them through completion, and showing the originator that something happened, the loop breaks. The platform makes that loop sustainable at scale.
The change management work that both Greg and Mark name as the missing piece in their first years depends on visibility. The middle managers who got skipped in Greg's first year didn't have visibility into what was happening in their departments. The platform makes the work visible -- which improvements are being submitted, which are being implemented, which are stuck, which are producing impact. That visibility is the raw material for the conversations that change management requires.
The capability-building work Michael names depends on tracking that's lightweight enough to use. Building team capability isn't a measurable outcome the way completing a project is, but the data the platform produces -- volume of ideas, completion rates, who is participating, which managers are responding -- is the proxy that lets coaches see whether the capability is developing.
None of this substitutes for the practice. The platform supports the practice; it doesn't replace it. The first-year lessons in this session are about the practice, not the technology. The technology fits where it actually fits, after the practice is already underway.
Mark Graban is a Senior Advisor to KaiNexus and an internationally recognized Lean consultant, author, and speaker. He is the author of Lean Hospitals and co-author of Healthcare Kaizen. He began his continuous improvement work as an industrial engineer at General Motors in 1995 and transitioned to healthcare in 2005.
Greg Jacobson, MD is co-founder and CEO of KaiNexus. A practicing emergency physician before founding the company, he began applying Kaizen principles in the emergency department at Vanderbilt in 2004 and founded KaiNexus to support the kind of management system he found missing in his early work.
Michael Lombard served as corporate director of operational excellence at Cornerstone Healthcare Group at the time of this recording. His background includes Lean work in modular manufacturing prior to his transition to healthcare.
Why frame continuous improvement as a practice rather than an implementation?
Because the word "implementation" implies a project with a start and an end, while continuous improvement has neither. Organizations that frame the work as something they're implementing tend to declare it complete after a year or two and then watch the program decay because nothing about the underlying management system has changed. Organizations that frame the work as a practice -- the way physicians practice medicine or lawyers practice law -- treat it as a discipline that requires ongoing development. The framing affects what gets measured, what gets sustained, and what gets abandoned.
What is the single most common mistake in launching a continuous improvement program?
Skipping the middle. Most programs are launched with senior leadership endorsement and frontline staff engagement, while the middle managers -- whose daily behavior determines whether anything sustains -- are left without the context, the expectations, or the conversation that would let them support the work. A few short conversations with middle managers at the beginning would prevent most of the failure modes that programs encounter six months in. The mistake is rarely about technique. It's about which conversations happen and which ones don't.
Why does starting with small ideas work better than starting with big ones?
Because the feedback loop matters more than the size of any individual idea. Small low-cost low-risk improvements can be acted on quickly, which means staff members see their ideas implemented within days or weeks. That immediate visible reward builds the habit of looking for improvement opportunities. When you ask for big ideas, the ideas come in slowly, the organization can't implement them quickly, and the feedback loop breaks. The team that generates many small ideas eventually finds the large ones embedded in them. The team that only asks for large ones never finds either.
How should an experienced practitioner treat someone just getting started?
As a coach, not a critic. The reflex to dismiss the newcomer who is making mistakes you remember making yourself makes the field worse. It treats expertise as a club rather than a discipline that exists to develop other practitioners. The discipline is to coach -- to share lessons in ways that help the newcomer learn rather than in ways that establish hierarchy. The field grows when experienced practitioners help develop the next generation. It shrinks when they don't.
What should a CI practitioner change about their role as they gain experience?
Move up the stack from doing to teaching to teaching-how-to-teach. The reflex of the experienced practitioner is to keep doing the work because they know how. The discipline is to develop others who can do the work, then to develop coaches who can develop others. Practitioners who never make this transition become bottlenecks. Practitioners who make it become builders of organizational capability that scales beyond what they can do alone.
What was the most important lesson from Mark's first year at GM?
Build relationships before you need them. The advice came from a supervisor who had absorbed W. Edwards Deming's training and applied it to his own leadership posture. The advice was to spend time with the UAW shop committee, have coffee with people, let them get to know who you were and what you were trying to do. That investment opened doors for the rest of Mark's time at the plant that wouldn't have opened any other way. Improvement work is fundamentally relational. The technical methodology rides on top of the relationships.
Download this free eBook to see how to get your employees more engaged in your culture of continuous improvement.
.svg)
Copyright © 2026
Privacy Policy