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.
This transcript has been edited for readability.
Mark Graban: Hi everybody. I'm Mark Graban, VP of Customer Success at KaiNexus, author of Lean Hospitals, and co-author of Healthcare Kaizen.
Greg Jacobson: And I'm Dr. Greg Jacobson, co-founder and chief product officer of KaiNexus. We'd both like to welcome you to today's webinar, Getting Started with Continuous Improvement: Lessons and Reflections. KaiNexus is a technology company. Our software helps organizations engage their frontline staff and organize their Lean and improvement work. It was born out of my work when I started as an attending physician at Vanderbilt and began implementing Masaaki Imai's principles in our emergency department. I saw the lack of a management system to get everyone on the same page, and the idea was born: could we provide that for organizations so they can focus on the improvement work? We know technology can help change behaviors, and we're seeing that.
Mark Graban: Our theme today is getting started with continuous improvement. A lot of people call it a journey -- a continuous improvement journey, a Lean journey. I'm reminded of the quote from the philosopher Lao Tzu: the journey of a thousand miles begins with one step. Those of you who saw the slides in advance know I'd prepared a slide with that quote. Here in Austin, Texas, where Greg and I are sitting, I was walking up South Congress to get a snack and passed a sign with that exact quote. All our continuous improvement journeys begin with that single step.
Mark Graban: For those of us who are a few dozen or a few hundred steps down this journey, it's important to think back to our first steps, because at some point we have to get started. We can't just study, think, and talk about continuous improvement forever. Getting started can be difficult, and at some point you just have to give it a try. We learn by doing. Even 20 years into my own journey, we're all hopefully continuing to improve how we do things, teach things, and talk about continuous improvement. It's important to reflect. We're likely not very good at this when we start, but we shouldn't let that stop us from giving it a good effort. Learn from others, ideally have coaches and mentors, and go.
Mark Graban: Why aren't people as good at this at first as they'll be later? Sometimes it's a lack of knowledge, and with Lean and continuous improvement, a little knowledge can be dangerous. We learn about a tool and think, "That's easy." Then we have missteps and realize it's not as easy as we thought. I hear organizations in their second or third year say, "We're just now realizing how difficult this can be." Sometimes it's a lack of experience, and I don't know how to solve that other than by doing things and gaining experience.
Mark Graban: Another pitfall is relying too much on asking what Lean says we should do, what that hospital system does, or what Toyota tells us. At some point we have to balance what we've learned from others with thinking things through ourselves. If we're going to copy anything, copy a process rather than the exact methods someone else used. Do we understand our problem and what's happening?
Greg Jacobson: What we're trying to do is help set up the first steps people take. At one end of the pendulum, you study forever and never do anything. At the other, you just start doing without thinking. The middle ground is best. We have three people here who have done this, and we'll share what worked and what didn't, so your middle ground doesn't have big stumbles -- or, since stumbles will inevitably happen, so they're small and don't stop your forward momentum.
Mark Graban: Learning about other people's mistakes, including ours, won't keep you from making any of your own. But hopefully we can avoid the major mistakes without being so scared of the little ones as we go.
Mark Graban: Part of my own reflection is the idea of being kind to people who are new to this -- being patient and being teachers and coaches. We shouldn't be too hard on people just starting out with Lean, Kaizen, continuous improvement, or Six Sigma. Think back to your own first year. Mistakes will be made. Some are good mistakes we can build on as learning opportunities. Some bad mistakes can really derail things, at a big-picture level or within a team. As more experienced people who are still learning, we should try to coach and help people improve rather than step back and criticize.
Mark Graban: Without beating myself up too much, I think about some of my own blogging. If I'm criticizing a practice, I try not to attack the person. It's usually not that someone is stupid or uncaring or foolish. They just don't have as much experience. I'm more patient with someone who says, "I'm new to this, and I'm trying to get better." What irritates me is someone who says, "I'm an expert," as if they have nothing more to learn. I've criticized practices on my blog that I think are silly, like companies that get overenthusiastic about 5S, tell everybody to put tape around the stapler on every desk, and remove family photos from desks because they aren't productive. I've written about an acronym I call L.A.M.E.: Lean As Misguidedly Executed. I'm trying to be kind in that acronym. People are misguided or mistaken, not idiots. But I need to be careful that when I share stories or give feedback, I do it kindly rather than in an "I'm better than you" way.
Greg Jacobson: For me, the translation is being a teaching physician at Vanderbilt, and now working with residents. Ironically, residents sometimes have a better mastery of the knowledge, because they're studying it in real time and spending massive amounts of time acquiring it. What a teaching physician brings is experience. When I teach, I frame it as, "In my experience, this has worked and this hasn't." I didn't start with innate knowledge. You pick up little tidbits along the way, and in medicine we call those pearls. So the idea here is to put together a few pearls that may not translate perfectly from a book -- sometimes you have to make the mistakes to learn -- and hopefully help others make smaller mistakes, or fewer of them.
Mark Graban: Greg's going to talk about how people progress in their careers and with different improvement methodologies. People in other fields talk about practicing law or practicing medicine. I think it's an interesting phrase.
Greg Jacobson: I love doing these webinars because preparing for them, we figure out what's fresh and new, what we're learning from our current work implementing -- there I go again -- practicing Lean. Mark brought this up, and I was intrigued. People joke about practicing law and medicine, as if you'll get good at it someday. So I did some quick internet searching on the origins. According to the Oxford English Dictionary, the word first appeared in English around 1421, meaning to pursue or be engaged in a particular occupation, professional skill, or art. By 1542 it had come to mean what we mean today: to perform an activity or exercise a skill repeatedly or regularly in order to acquire, improve, or maintain proficiency.
Greg Jacobson: I think we need to stop saying we're implementing Lean and start saying we're practicing Lean, because there really isn't a beginning or an end. It's a constant engagement with this body of knowledge, exactly like what people do in law, medicine, architecture, and other fields.
Mark Graban: We can think about that for organizations. What really makes me cringe is when people say, "Oh yeah, we implemented that two years ago." It shows a beginner's misunderstanding that Lean is just a project. Greg's point about acquiring, improving, and maintaining proficiency also applies to individuals with a certification. Occasionally you hear someone treat certification as an end: "I got certified. I'm an expert, and I know everything." It's healthier to see certification as a beginning, the same way your medical degree, Greg, is hopefully just the beginning of your ongoing improvement.
Greg Jacobson: And just because you're at the beginning doesn't mean you can't do it well or have real impact. I truly believe a first-year medical student brings value to the patient experience, just like a first-year resident. A 20-year attending will have a lot more knowledge and experience, and may bring a lot more baggage too. Being at the beginning shouldn't stop you from seeing immediate results from practicing Lean.
Mark Graban: Here's a progression I've reflected on for a continuous improvement professional. At first, you learn how to do. Early in my career, I learned how to use particular tools and methods, and you can get benefits from that: helping people improve ergonomics, improve safety, and prevent errors. At some point there's a natural progression where you learn how to teach. That's where we engage people in the workplace. We're not doing it to them; we're doing it with them, teaching people to use these methods themselves. Now we're teaching and coaching instead of doing. Further along, we learn how to teach others how to teach. In Six Sigma terms, a Green Belt might be learning to do, Black Belts learn to teach because they teach Green Belts, and a Master Black Belt teaches Black Belts how to teach. That's a very natural progression.
Greg Jacobson: When you're trying to pass along a pearl, it's best to narrow the focus. So I'll share one thing I could have done a lot better in my first year and one thing I think I nailed. There were probably a hundred things I could have done better and hopefully a couple dozen I did well, but I want you to take away one of each.
Greg Jacobson: Let's go back to 2004 and 2005. I'd read Masaaki Imai's book Kaizen, which the chairman of my emergency medicine department gave me. He said, "I want you to teach residents how to do this and implement a Kaizen program." I was all gung-ho. I thought it was brilliant. So I went right to the frontline staff, because Kaizen is about engaging frontline staff, and I taught them. As a side note, I learned that you don't need to teach years' worth of knowledge to frontline staff to get them engaged in improvement. They immediately got the concepts and started identifying opportunities for improvement.
Mark Graban: When you were challenged to teach this, did you go through a learn-to-do phase first, or were doing and teaching simultaneous?
Greg Jacobson: I did go through a learn-to-do phase, but over about three years, not just my first year. I initially gave almost a three-hour lecture series to frontline staff and residents. Over those three years it got compressed to about a 15-minute primer. I learned that in about 15 minutes, you can give people enough knowledge to identify really good opportunities for improvement. That doesn't mean they'll be able to problem-solve, but they'll be able to identify the kinds of things we're looking for.
Mark Graban: That's a really good lesson, and I've heard it from others. I think I've gotten better about giving people the right amount of training at the right time, when they can go apply it.
Greg Jacobson: My biggest mistake was that I completely left out everyone in between. In a group of 300 people, I went from the CEO straight to the frontline staff and skipped the middle managers and senior leaders. That created a situation where middle leadership had no idea what was expected of them or what was going on. I never told them, "The leader of this organization strategically wants us to start this type of behavior. It fits our mission, and this is the system we're putting in place. What do you think, Mark? Is this something you want to get behind? What are your concerns?" We're not talking about hundreds of people. A five- or 10-minute conversation with five or 10 key people to prepare them for what was about to happen would have been a huge benefit in my first year.
Mark Graban: That's a common organizational mistake: relying too much on a process improvement specialist to drive change, instead of having department managers and directors own and embrace it -- not throwing a solution at them or implementing it for them, but making sure they understand the problem being addressed.
Greg Jacobson: To me, it was a change management issue. I really failed at change management in that first year. Change management has to come from leadership, and in this case I was leading the effort. Leadership needs to explain the value, why it aligns with the strategic initiatives, and what's expected, and start that dialogue.
Greg Jacobson: Now something I think I did really well -- and, as with everything, it's better to be lucky than good. I was lucky to learn from Mr. Imai, who really focuses on low-cost, low-risk changes. When you teach people about non-value-added steps, and that no problem is too small, staff can be trained easily. Another thing Mr. Imai talks about really well is telling people specifically what you're looking for. Let frontline staff know: we're looking for opportunities for improvement, and here's what they look like. They aren't things where we need to spend a lot of money, implement a ton of technology, or build a new wing. Those things may need to happen. But we want frontline staff to focus on low-cost, low-risk changes to what makes their work frustrating or gets in the way of good patient care, or whatever their work is.
Mark Graban: You're not telling them the answers. You're telling them the kinds of things to look for. Not a million-dollar idea, but little annoyances, irritations, and patient complaints. Let's fix those.
Greg Jacobson: And that sets you up for success, because when people find low-cost, low-risk improvements, you can actually implement them, and there's positive reinforcement. I'm reading a book about habits right now, and this is a perfect example of how to build a habit in an organization: the immediate reward of, "We identified a problem, and now it's fixed." The person can see it and say, "This is brilliant. I don't have to worry about this anymore." So a little guidance, then baby steps and developing habits.
Greg Jacobson: So pearl number one is change management. Talk to all the leadership in the organization, one-on-one, for five or 10 minutes. We're not talking about hours. Pearl number two is to make it about small changes. And here's a fascinating footnote, Mark, which you and I have been really interested in. We don't have an exact percentage yet, but somewhere around 1 in 50 to 1 in 100 small opportunities for improvement ends up having a huge impact.
Mark Graban: The best way to find a big idea is to have lots of little ideas: identify lots of little problems and implement lots of little solutions, and you'll inevitably stumble across something big.
Greg Jacobson: Big impact, but easily done. That's the key. We're building a really large data set to figure out the exact percentage, but it looks like it's in that range, where the impact might be $50,000, $100,000, or even half a million dollars, when nobody set out to go after that initially.
Mark Graban: I've had two different first years in continuous improvement. The first was right out of college, as an industrial engineer at the GM Livonia engine plant in my hometown of Livonia, Michigan. I got all my woe-is-me horror stories out of my system when Greg and I were rehearsing -- practicing -- earlier in the week. It was a challenging environment in a lot of ways for a young, eager, idealistic person trying to help make improvements. But rather than just blaming the organization and the culture, I've thought about what I could have done better and differently.
Mark Graban: I was in the engineer mindset that it was my job to go do things: install new equipment to improve safety, take it on as a project. A lot of that was me-driven instead of team-driven. I was trying to help frontline employees and benefit the people and the organization, but I was still thinking, "I have to do the analysis. I have to research which equipment we need and make those decisions." I probably didn't get enough input from people. Some of that was the nature of the environment, which unfortunately didn't encourage getting input from team members.
Greg Jacobson: It's the difference between drilling a well for someone and teaching someone how to drill a well.
Mark Graban: At that stage, we were implementing a lot of tools. We had people who'd been hired from Toyota suppliers and other organizations who talked about management practices and culture, and I learned a lot from them, but the organization wasn't at that step yet. We had some really old-school leaders, and you try to follow Lean mindsets as best you can in that environment. For a lot of people, starting with tools is a natural first step before moving on to management practices, philosophy, and culture change.
Mark Graban: One lesson: we didn't track ideas visually. We had a suggestion box -- an officially endorsed company and UAW suggestion program that I even participated in as an engineer -- and ideas just went there to die. We've talked about that in other webinars. It drove home that if you're even going to pretend to ask for people's ideas, you need to do something with them. I got discouraged when I felt my ideas weren't listened to, and that was a great lesson. How do others feel today if we ask for their ideas and don't help them, don't listen, and don't move forward?
Mark Graban: Maybe other engineers will relate to this: I spent too much time playing with computer simulation software. As an industrial engineer, I was taught to look analytically at questions like how much inventory we should have, or the effect of improving uptime on different machines. You can spend a lot of time in that software looking for the so-called right answer, instead of experimenting with a PDSA mindset: set the inventory at a certain level, see what happens when we lower it, and adjust. There's some benefit to that learning, but I spent too much time at my computer, especially early in my first year. I had a tool I'd learned in college, GM had the software, and I thought I had to use it. I probably overdid it.
Mark Graban: Another lesson: I didn't build good relationships with the direct frontline supervisors, called team coordinators, which was a well-intended title, but they were really old-school foremen. I worked well with frontline staff, and my blind spot was writing off the supervisors: "Those people are never going to change, so let me stay out of their way."
Greg Jacobson: What I love about this point, Mark, is that it sounds a lot like my pearl. I wrote off the middle managers because I figured they'd just get it -- of course they'd want to improve the emergency department. You wrote them off for the exact opposite reason. But we both came to the same conclusion: develop those relationships. There will be bumps, and that means actually meeting people face to face and getting to know them.
Mark Graban: Another lesson that didn't become clear until a few years ago is why those old-school managers acted that way. It wasn't because they were bad people. They were a product of 30 years in that culture. My second plant manager had experience in the GM-Toyota joint venture. When I reconnected with him a few years ago, I asked why he'd been so patient with some of those managers and their bad behavior. He said, "You have to understand, they didn't have the benefit I had of learning a new way and being coached and mentored by the Toyota people." I get it now. I was young, impatient, and judgmental.
Mark Graban: Along those lines, I tried to learn not to get too emotional. I spent a lot of time on the shop floor -- the gemba -- and saw unsafe situations that had been reported to maintenance and weren't being worked on or prioritized. One time I saw something where it looked like someone could have been hurt really badly by one of these nagging issues. This was 1995, before we had computers and email. I left a really nasty, emotional-sounding voicemail, copied it to a whole bunch of people, and called out the maintenance manager for not getting things fixed when someone could have been hurt. That was not a good relationship-building move with the maintenance manager. There's being right, and there's being savvy and effective within the organization. I think I was right, but I felt I needed to make waves and draw attention to the situation, and that can backfire on you.
Mark Graban: Now some positive lessons. I got really good advice about building relationships. One of the so-called old-school supervisors had taken a lot of the Deming training to heart and had come around to a different way of operating. He told me right away to make sure I wasn't just doing my work but also building relationships. That was helpful advice for an engineer. You're not going to chitchat all day, but you have to get to know people, and they have to get to know you. That included the UAW shop committee. I was advised to sit down and have a cup of coffee with them and let them know I was trying to help, and that we could work together on things of mutual benefit to employees and, hopefully, the company.
Mark Graban: That helped create some cover where I could go against the grain of the existing culture, which normally didn't engage frontline staff. We had something called the jobs bank, where employees were paid to sit in the cafeteria instead of being laid off. It was part of the union agreement, and I thought it was a waste. There were guidelines in the contract allowing you to bring people from the jobs bank to help with improvement projects. Most engineers thought, "Why would I want to do that?" I did it, and I found people who were really keen to be involved in improvement work. They didn't want to sit rotting away in the cafeteria. Some were really excited to participate and work together. I'm glad I had that experience, in an environment where a lot of people wrote off those employees, who were also a product of their environment.
Mark Graban: I learned from the plant manager with Toyota experience that quality and cost improvement go together. When he was talking about our cost problem and our quality problem, I asked, "Which do we need to work on first?" I think he was being patient and coaching instead of judging what I didn't know. He explained that we have to do both, and that by improving quality we'll reduce cost. They go hand in hand and can't really be separated. That's a lesson I've seen in healthcare too.
Mark Graban: I naturally spent a lot of time at the gemba when I wasn't doing computer simulations. Thankfully, email wasn't a huge time sink back then. But that plant manager was also at the gemba a lot. The leader of 800 employees was out there talking, listening, building relationships, and setting a good example. He told me one day, "I probably know a lot of the answers here about changing the culture and the way we manage. But they don't know that I know." The employees didn't know him from any other manager or that he had a different, Lean management perspective. He had to get to know people, and he probably spent more time listening than talking, which set a great example.
Mark Graban: Let me talk briefly about my first year in healthcare. Here's a picture from 2005 of a medical laboratory team I worked with. The picture on the right shows some of my progression. It's from about my 10th year in continuous improvement: a team from a lab designing and experimenting with their future layout. Instead of me, the engineer, figuring out the layout, I taught them principles and ideas so they could figure out the best layout themselves.
Greg Jacobson: When I look at that picture, the biggest thing I see is that you have absolutely no gray hair.
Mark Graban: That's more a function of age. I won't blame healthcare for the gray hair the attendees can't see.
Mark Graban: When people make the transition from manufacturing to healthcare, some say, "I'm an expert. I know Lean." But it's okay to be honest about what you don't know. I've heard people reflect on their first year in healthcare: if they come in with an attitude of "I'm here to fix you," organizations and people are really good at resisting that, as opposed to, "Let's share your experiences and mine, and we'll figure this out together." I was lucky to partner with a number of clinicians and learn back and forth. I've seen that work really well in other healthcare organizations: a Lean person from industry paired with a nurse who has good continuous improvement instincts.
Mark Graban: At the same time, in training I relied too much on manufacturing history, which interested me. People in healthcare didn't care about it at all. That's one way to get three hours of training down to 10 minutes: cut the trivia and history. And all I had were factory examples. Factory examples have a time and a place, but you have to use them well and explain the context. Back in 2005, there just weren't many healthcare examples. Even within my first year, I started to have my own healthcare examples and could draw on colleagues' examples too, and now that healthcare has focused so much more on process improvement, there are many more.
Mark Graban: The other thing I struggled with in that first year in healthcare was balancing getting things done with bringing others along. As an outside consultant or even an internal change agent, there's pressure to get results, versus teaching people and getting them engaged. Sometimes you need to push back and say, "This will go a little slower, but people will learn more in the process."
Mark Graban: Now I'd like to introduce our special guest, a good friend of mine and of KaiNexus, Michael Lombard.
Michael Lombard: Thank you, Mark. I'm the corporate director of operational excellence for Cornerstone Healthcare Group, and I've been working in healthcare for about the past four and a half years. Like Mark, I've had two first years where I was the newcomer making a lot of mistakes and learning from them. I started in manufacturing, in modular and manufactured housing. We had an assembly line, so many Lean concepts from the automotive industry were very applicable, and I thought it was a natural fit.
Michael Lombard: One of my first mistakes: I went to a seminar where they taught me some basic Lean history and principles, and it made so much sense to me. I was naive enough to think that if we put all our managers through an educational program and exposed them to these concepts, they'd automatically start applying them in the factory. So I went back and developed an all-day training program full of simulations. I did some good things. The simulations were based on our modular home environment, not an automotive one, and I used examples from our factory, so I tailored it to the audience. But the underlying philosophy was that didactic education would change our culture, and that was very naive and misguided.
Mark Graban: People won't magically get it and be enthusiastic from book learning.
Michael Lombard: Right. And I was so disappointed, because coming out of that all-day session, our managers were really excited about our improvement efforts for the first time in years, and they were all on the same page. It was great in the moment. But as soon as they went back to their day-to-day work in the factory, nothing had really changed. That was my first pearl, as Greg calls them: didactic training doesn't lead to wholesale change in behaviors or in your operating system. As my career progressed, I started using education and training more strategically.
Mark Graban: Have you experimented with different types of learning -- lecture, discussion, hands-on simulations? Sometimes those are more effective.
Michael Lombard: I've done it all, pretty much. What I've learned is what Greg touched on earlier: condense it down, keep it quick and to the point, give people something specific to focus on to get started, and then let the learning by doing commence.
Mark Graban: And then supplement it as you go with just-in-time learning.
Michael Lombard: It's the same principle. It's funny how we as Lean practitioners -- and I'm making a blanket statement, because people more advanced than me don't do this as much -- can still fall into the trap of making our batches of education too large. Apply just-in-time to learning. That was my big lesson from my first year in manufacturing.
Michael Lombard: My other first year was in healthcare, about four and a half or five years ago. Through Mark's mentoring, I went to work for a pediatric hospital in Dallas. I did some things well, having learned from my previous mistakes. When we did a big redesign of our ER patient flow processes, we included all the right people. We didn't skip the middle managers or the senior leaders, and we engaged frontline clinical and nonclinical staff. The team was really engaged, came up with great ideas to improve the care we delivered in the ER, implemented them, and started seeing great results.
Michael Lombard: I was in the Black Belt role, using the DMAIC approach to deliver results. Just as Mark saw his role as an engineer as implementing improvements, I saw my role as the Black Belt as implementing improvements, and I was the owner. That works pretty well during the project, when you're engaged with the people in the ER and everyone's excited. But as soon as I was reassigned to another project, there was no continuation of the improvement effort. We hadn't started with the end in mind -- the end being continuous daily improvement, with everybody involved, always moving toward our target condition. When we started the project, we set goals for ourselves, but they were all about improving processes. None were about building our team's capacity.
Michael Lombard: Sometimes we get tunnel vision and just focus on producing results. We don't leave enough room to coach and mentor people, to give much of the improvement responsibility to the people doing the work, and to trust that they have the brains to pull it off and the ability to learn quickly, because they do. We forget that sometimes.
Mark Graban: Sometimes organizations measure process activity instead of end results: how many rapid improvement events did we do this year? Wait a minute -- how did we affect safety, quality, waiting times, and the measures that matter? I've heard a lot of people reflect that they were too focused on what they were doing instead of the results and reasons behind it, or assumed people understood those connections.
Michael Lombard: Exactly. One last lesson: as a Black Belt and project manager, I viewed things very mechanistically. I saw process improvement as levers and pulleys. If I tweak this and change that, we'll get the results, and I've done a good job. I didn't understand the social, human component. We thought that if we put a control plan in place with a dashboard of metrics, things would take care of themselves and continuous improvement would happen. That's just not the case in a dynamic social setting like a hospital.
Mark Graban: Even in a factory. Thinking back to my first year, one thing that made it bearable and got me to a second year was having good mentors and coaches. Many of them were informal. My direct manager was good about this, and others were really good about coaching me through different scenarios and keeping things moving in a positive direction. Unfortunately, a lot of people don't have that benefit in their organization.
Michael Lombard: I've found that one limiting factor in how quickly you can develop people is how quickly you can create a core group of coaches in your organization, and that's not easy. Some training might help. Some practice coaching might help. But you need a framework. We're currently using the Toyota Kata approach to develop coaches and build habits. There are many ways to do it, but you have to make it a goal when you go into the improvement effort, not try to do it on the back end after the project is over.
Mark Graban: Thank you, Michael. Michael is staying for Q&A with Greg and me. I'd also invite you to reply to the follow-up email with reflections on your own first year in continuous improvement. We'd love to hear them.
Mark Graban: The first question is from Muhammad: "I'm a certified Six Sigma Black Belt, but implementing Six Sigma isn't part of my job description. How can I practice what I've learned so I don't lose it?" I think this applies to any methodology. Even if your organization doesn't have a formal program, the methods, tools, and systems you've learned can still help with what you're trying to accomplish individually. Can you use Six Sigma's statistical methods, or Lean root cause analysis approaches, to do your own job better? Hopefully that benefits you and the organization, and demonstrates that the methodology could be helpful more broadly.
Michael Lombard: If that's your situation, you're in startup mode. You might be a lone wolf, or have a small coalition of people practicing continuous improvement techniques, and that's okay. You can start small and get a snowball effect going. Doing rapid cycles of experimentation and proving out your ideas is a pretty effective way to grow your coalition and build consensus for what you do.
Mark Graban: Matt asks: "Based on your experience in other industries, what are the top two unique challenges of getting started with continuous improvement in healthcare?" Greg, do you want to take a stab?
Greg Jacobson: I don't know if I have two, but the one that comes to mind is time. In a place that's constantly seeing patients -- take a physician, for example -- asking a physician to take a week off from their clinic and practice just isn't going to happen. One of the really successful strategies I've seen is, instead of a week-long event, a one- or two-hour session once a week for eight or 12 weeks. Blending in with people's schedules is a strategy that's somewhat unique to healthcare.
Mark Graban: And one aspect of the "we don't have time" challenge is that people let it become an excuse instead of one of the first problems to solve. If we say continuous improvement is important and we're going to engage everybody, and we put that statement on our website or in the lobby, then we need to work at it. We need to figure out how to make time for managers and frontline staff. We can't fall back on that excuse, or any number of others.
Michael Lombard: I've had meetings with clinicians -- say, a physician who comes in 30 minutes late to a 60-minute meeting because he just finished installing a pacemaker or some other critical procedure. In healthcare, you have to be very flexible and recognize there's a lot of variation related to the human factor. Patients don't always respond the way the physician expects, and clinicians don't always respond the way the improvement facilitator expects. Every organization is a sociotechnical system, but healthcare is very heavy on the social side. So you have to be flexible and adaptive. Don't go in with an extensive plan for exactly how your Kaizen event or meeting will go. Take a more agile approach.
Mark Graban: Deanna asks: "How do you work around the attitude of 'we don't have time for continuous improvement' and get away from focusing only on getting the freight out the door, while still working on quality along with quantity?"
Greg Jacobson: One way I've found really successful for engaging physicians, clinicians, nurses, or whoever is to make it personal. I used to coach people to stop and pause when they're frustrated at work, because there's often a process issue underneath that frustration. When you make it personal about their work -- and as we work with more and more organizations outside healthcare, I see the same thing everywhere -- people want to do their work well.
Mark Graban: And it matters when leaders recognize that and specifically carve out time for people. I think of an organization I visited where the chief of the transplant institute was talking to the department that schedules patients to even be considered for an organ transplant. Those people were busy all day long. There was a backlog of people waiting to get into the backlog. This world-renowned surgeon told the team, "We have a lot of work to do, and it's serious work that helps people. But at some point we choose to go home to our families at the end of the day. We make choices. We can also choose to spend 20 minutes a day working on process improvement, because that's how we'll fix problems and free up time to take care of more people in the future." I really admired him for taking that stand and saying there would be no repercussions for people who made that choice to invest today to make things better in the future, instead of being caught on the hamster wheel of being constantly too busy.
Greg Jacobson: That's a change management aspect, Mark. It works because it comes from the very top, saying this is a strategic goal. Between that and focusing on the issues that make people's days inefficient, you can really get people engaged: "I'm going to stop fighting fires for 15, 20, or 30 minutes a day so there are fewer fires in the future."
Mark Graban: We have three other really good questions we won't be able to do justice to, so we'll answer them individually and maybe turn them into blog posts. On behalf of the whole team at KaiNexus, and Greg and Michael, thank you for taking the time to join us today. Thank you, Michael, and thank you, Greg.
Michael Lombard: My pleasure. Thank you.
Download this free eBook to see how to get your employees more engaged in your culture of continuous improvement.
.svg)
Copyright © 2026
Privacy Policy