Most KaiNexus webinars feature a single presenter walking through a structured methodology. This one works differently. Mark Graban and KaiNexus CEO Greg Jacobson, MD, took questions submitted in advance by the audience and worked through them in conversation. The format produces something the structured presentations rarely do: practitioners with substantial experience thinking through real questions in real time, sometimes disagreeing on emphasis, sometimes building on each other's points, occasionally going off-topic in ways that turn out to be useful.
The questions range across the typical concerns of CI practitioners and leaders: the origin story of KaiNexus, the differences between implementing improvement in healthcare versus manufacturing, the apparent tension between Lean and technology, the advice for organizations introducing Lean into established cultures, the sustainability challenge that most improvement programs eventually face, and the practical mechanics of executive engagement. There are also a few questions that wandered into territory the planners didn't anticipate -- favorite dinosaurs, childhood dream jobs, and how to take notes in a Lean way.
This is the first of two parts. The conversation in Part 2, broadcast a few weeks later, picks up additional questions from the substantial backlog the planners couldn't get to in the first session.
Greg Jacobson, MD is co-founder and CEO of KaiNexus. He came to continuous improvement methodology in 2005 during his emergency medicine residency at Vanderbilt, working overnight shifts when the administration wasn't around and the operational chaos of running a 24/7/365 emergency department was visible without filter. Reading Masaaki Imai's Kaizen connected the operational problem to a methodology that might address it. The realization that the methodology needed technology infrastructure to scale across the specialists and shift workers who ran an ED led eventually to founding KaiNexus.
Mark Graban was VP of Improvement and Innovation Services at KaiNexus at the time of this webinar. He spent the first ten years of his career in manufacturing, including a stretch at General Motors and later in defense electronics, before moving into healthcare in 2005 when his wife took a job in Texas. The move into healthcare started as exploration -- what would the worst case be? He'd learn something along the way. Ten years later, he was still focused on healthcare CI and had become one of the most-cited authors in the field, with books including Lean Hospitals, Healthcare Kaizen, The Executive Guide to Healthcare Kaizen, Practicing Lean, Measures of Success, and The Mistakes That Make Us.
The origin story Greg tells starts with the operational reality of an emergency department at 2 a.m. The administration doesn't show up at 2 a.m. The full range of specialists who keep an ED running -- physicians, nurses, techs, phlebotomists, registration staff, transport, environmental services -- are all there, doing specialized work, often without the connective infrastructure to coordinate effectively across shifts. The frustrations stay with the people doing the work. The patterns visible at 2 a.m. don't reach the daytime leadership.
The introduction to continuous improvement methodology came through Imai's Kaizen and reading at the start of his residency. The diagnostic clicked. The problem wasn't that the people were inadequate. The problem was that the system had no way of capturing what they observed, no way of acting on what they proposed, and no way of connecting their work across the shifts and specialties that fragmented information naturally.
The hypothesis that drove the technology decision: web-based applications could change the communication patterns that fragmented information. The infrastructure could help people identify opportunities, surface them to leadership, track them through completion, and demonstrate that ideas led to changes. The hypothesis wasn't tested by writing a research paper. It was tested by building software.
Greg notes the gap between his expectations a decade earlier and where he ended up. If someone had told him in 2005 that he'd be CEO of a software company helping people across multiple industries, his words at the time: "you would have thought I was smoking crack." The journey from emergency physician to software CEO wasn't planned. It came from following the problem he was trying to solve until it became clear that solving it required founding a company.
Mark's transition came differently. He had spent ten years in manufacturing -- a defense electronics company, General Motors, and a job in Phoenix when his wife took a position that required moving to Texas. While exploring the Dallas-Fort Worth job market, he got a call from a recruiter at Johnson & Johnson. The job involved hospital consulting.
The framing he describes for taking the role: he didn't know whether healthcare would be a temporary detour or a career change. He figured he'd learn something along the way. Ten years later, he was still very much focused on healthcare. The detour had become the career.
The question Mark addresses next -- the differences between implementing improvement in healthcare versus non-healthcare environments -- draws on both halves of his career. The methodology and philosophy of Lean are highly transferable. The starting conditions and the cultural texture are different.
Healthcare has a built-in advantage. The mission orientation among the people doing the work is genuine. Doctors and nurses go into healthcare for reasons that go beyond it being a job. The sense of calling is real, and a Lean program can rally people around that mission in a way that's harder to do in manufacturing, where many people legitimately treat their job as a job rather than a vocation.
Healthcare also has a built-in disadvantage. The starting point in most hospitals is one where continuous improvement hasn't been a focus. Operations are often shaped by the assumption that smart, well-intentioned people can be put in a department and the system will sort itself out. The result is operational chaos that the smart people work heroically to compensate for. The chaos doesn't get addressed at the system level because no one with authority is paying attention to it.
The Lean work in healthcare often involves trying to create basic stability before improvement becomes possible. Calming down the chaos enough that the team has a fighting chance to actually improve their processes is a precondition for the methodology to work. In manufacturing, the operational discipline is often more established at the baseline, even if the specific process improvements are similar.
The question comes up frequently in CI conversations: is Lean opposed to technology? KaiNexus is a technology company, so the framing matters for what they're building.
Greg's answer: Lean isn't anti-technology. Lean is anti-throwing-technology-at-a-problem when the problem is actually rooted in a process issue. The distinction matters because the anti-technology stereotype comes from real failures -- organizations that tried to automate broken processes and made them worse, organizations that bought ERP systems hoping the software would solve the management problem they actually had, organizations that confused having tools with having a method.
The example Greg uses: when Japanese manufacturers visited US factories in the 1950s, the US factories were the most sophisticated in the world. When the same Japanese manufacturers visited the US again in the 1980s, after the Toyota Production System had matured, US factories looked almost identical to what they had been in the 1950s. Meanwhile, Japanese factories had developed sophisticated manufacturing technology that was deeply integrated with their continuous improvement practices. Lean wasn't anti-technology. Lean was anti-stagnation, and the Japanese had used technology as part of a broader system that kept improving.
Mark adds the historical context. The "Lean is anti-technology" idea traces partly to the 1980s and 90s, when many manufacturers relied on MRP and ERP systems to drive every detail of production. Toyota and other Lean organizations used different approaches -- kanban supermarkets, visual management, andon systems -- that emphasized visibility and human judgment rather than algorithmic central planning. The contrast got interpreted as Lean rejecting technology, when the actual position was more nuanced. Technology was part of the system. It just wasn't the master of the system.
The related principle Mark names: don't automate the waste. If a process is poorly designed, automating it locks in the poor design. The discipline is to improve the process first and then automate the improved process, not the reverse. Software that supports good processes is part of the management system. Software that papers over bad processes is part of the problem.
For KaiNexus specifically, the framing is that the platform supports people and processes. It doesn't replace either. Visibility, lateral spread of improvements, knowledge repositories, structured workflows -- these are infrastructure that makes good practices easier to do at scale. They don't substitute for the practices themselves.
Two questions in the submissions went in a different direction. The interlude is worth preserving because it captures something about the conversational quality of the session.
Greg's favorite dinosaur: his four-year-old daughter, who makes dinosaur-like sounds when she doesn't want to do something. Greg's dream job as a kid: medicine. He always knew he was going to be a doctor.
Mark's favorite dinosaur: a velociraptor. The framing he offers: people think of dinosaurs as slow and plodding, but velociraptors were fast and able to change direction quickly. The Lean version would presumably be a leaner-raptor-saurus. Mark's dream job as a kid: a baseball writer. A friend's father traveled with the Detroit Tigers and wrote about every game. Young Mark thought that sounded like the best possible job. He didn't become a baseball writer, but the love of writing came along to engineering work eventually.
The exchange doesn't have substantive content, but it tells you something about the conversation that the rest of the session is set within. This isn't a polished keynote. It's two people who know each other well thinking through questions together, with occasional detours into where they came from and what they liked when they were younger.
A KaiNexus customer submitted a question about reinvigorating continuous improvement in a context focused on business processes -- order entry, payment processing, similar transactional work. What pitfalls should they watch for?
Greg's answer starts with the framing that the approach is the same regardless of the process. Start with why -- why are we doing this? Then ask what frustrates them at work. The combination of clear purpose and felt frustration opens floodgates. When people understand that the goal is making their work easier and they're invited to name what's actually frustrating them, the ideas don't have to be solicited carefully. They flow.
Mark adds the customer dimension. The "why" should include not just internal pain but customer impact. Office processes serve customers -- internal customers in many cases, external customers in others. Asking how the process needs to perform better for customers, what frustrates customers, and how the team can deliver more value brings the customer voice into the improvement work.
The pitfall both emphasize: don't try to copy manufacturing Lean tools literally. Mark's example: a factory might have shared toolboxes that have been 5S'd, with tape outlines or foam outlines for each tool. The visual standardization solves a real factory problem. Going into an office and saying "everybody put tape around everything on your desk" doesn't solve a compelling problem. It irritates the people you're trying to engage. The methodology has to translate to the context. The specific tools have to be evaluated for whether they actually serve the office environment.
A question that surprised both presenters: what key points have you learned that you wouldn't find in the books?
Mark's framing matters more than his specific answer. There are excellent books on Lean -- many of them. The concern Mark raises isn't that books are inadequate; it's that some books contain claims that aren't accurate, and the inaccuracies get repeated. The example he uses: the claim that "Lean is about speed and Six Sigma is for quality." Mark doesn't think that's true. Lean has substantial contributions to quality work. Six Sigma has roles beyond quality. The clean dichotomy makes good copy and doesn't reflect the actual relationship between the methodologies.
Greg's answer goes a different direction. The work that most influenced him on CI wasn't in the CI literature at all. He recommends three books that don't mention Lean directly but explain the social and business psychology that makes Lean work:
Start with Why by Simon Sinek -- explains how to introduce CI concepts to organizations that haven't encountered them.
The Power of Habit by Charles Duhigg -- explains the discipline required to make CI behaviors stick.
Drive by Daniel Pink -- explains the intrinsic motivation that determines whether employees actually engage with improvement work.
Greg's framing: it's better to know two or three books really well than to know fifty books superficially. The problem-solving techniques themselves aren't rocket science. The hard part is the individual and organizational psychology that determines whether the techniques actually get used. Books that go directly at that psychology are often more useful than books that walk through the techniques in detail.
Mark adds the standard CI reading recommendation. Pick one current book like The Toyota Way or Toyota Kata, one foundational older book by Taiichi Ohno or Shigeo Shingo, and one Deming book (Out of the Crisis, The New Economics, or something by or about him). The combination produces a balanced perspective. Deming and the Toyota lineage overlap substantially around intrinsic motivation, respect for people, and long-term thinking -- territory that overlaps with Pink, Duhigg, and Sinek but with the operational specificity that CI practitioners need. And then Mark notes a book by Mark Graban -- Lean Hospitals in particular -- for healthcare-specific readers.
A question about how to introduce Lean into a company that has an established culture without continuous improvement.
Mark starts with the why -- understanding why the organization doesn't currently have a CI culture. The default explanation often blames employees for not speaking up or engaging. The actual cause is usually upstream. Leaders have discouraged speaking up. Leaders have discouraged taking action. Leaders have discouraged experimentation that might fail. The current culture isn't an accident. It's the result of consistent signals over time, even if no one designed those signals deliberately.
The second principle Mark names: don't talk about needing to change the entire culture. Understand the current culture and figure out what parts to build on versus what parts to change. Cultures are never all bad. Some elements support what CI needs. Some elements don't. The diagnostic work is identifying the difference and acting on it specifically.
Greg adds a related question: what if the issue is low morale rather than just absence of CI? The story Mark tells about General Motors twenty years ago illustrates the answer. The plant was in a low-morale state when a new plant manager came in. He didn't start with Lean methodology. He spent a lot of time on the shop floor building relationships and trust. He listened. He let people vent. He did some teaching, but the teaching wasn't the priority. The relationship was the priority.
The point Mark draws: there's a minimum amount of trust necessary for any CI methodology to work. Sometimes the first steps have nothing to do with Lean tools. They're about relationships, listening, and finding common ground that the work can be built on. Practitioners who jump straight to methodology without doing the relationship work often find the methodology doesn't take. The relationship work isn't a prelude to the real work. It is the real work.
A question that comes up in almost every CI discussion: how do you make a Lean program sustainable when so many programs start strong and then fade?
Greg's answer connects to the habit framework from The Power of Habit. The habit loop has three components: a cue, a routine, and a reward. The routine needs to produce a reward, or the next time the cue appears, the routine won't happen. The cycle is what makes habits durable.
For improvement work, the implication is to focus on small incremental changes that produce rewards on short timeframes. A two- or three-year improvement project doesn't produce a reward quickly enough to establish the habit. By the time the reward arrives, the business has changed enough that the project itself might be outdated. The discipline of small daily or weekly improvements builds the habit that compounds over time. The big visible innovations come from compounded small improvements, not from heroic large projects.
The other element Greg emphasizes: organizations have turnover. Even at 10% turnover annually, the workforce composition shifts substantially over five to ten years. New people need to be onboarded into the improvement culture. New leaders, in particular, can accelerate or reverse progress depending on whether they're aligned with the methodology. The work of sustaining isn't a one-time installation. It's continuous reinforcement, continuous coaching, continuous reminder of why the methodology matters.
Mark adds the diagnostic approach. Ask why specific changes didn't sustain. Address the causes that actually appear. And start small -- forget about sustaining "a Lean program" as an abstraction; figure out how to sustain a specific change, then a few changes, then a few more. The cumulative effect of many sustained changes is what most organizations actually mean by sustainability, even if they describe it as a single cultural state.
Greg closes with a basketball reference that's worth preserving. When the San Antonio Spurs added LaMarcus Aldridge to their team, they didn't just continue doing the same things. They relearned their process around the new player. The methodology adapted to the people available. The principle generalizes. Lean methodology isn't a fixed template. It's a set of principles that get implemented through specific people, and as the people change, the implementation has to change with them. Copying another organization's specific Lean program won't produce the same results, because the people are different. Adapting the principles to the people you actually have is the work that sustains.
A question about getting executives and middle managers to buy into Lean, often described as a "bottom-up" methodology that needs top-down support.
Mark's first point: Lean isn't only bottom-up. The framing comes from John Shook at the Lean Enterprise Institute, who points out from his Toyota experience that Lean is both top-down and bottom-up. It's not aimless empowerment where everyone does whatever they want. It's not command-and-control either. There are rules. There's structure. There's strategic direction set at the top that aligns with frontline problem-solving at the bottom.
Greg addresses the executive buy-in question through two channels. First, leadership needs an easy way to see the benefit of CI work. If there isn't constant visibility into ROI -- broadly defined, including financial returns, safety improvements, employee retention, customer satisfaction -- leaders won't focus on the methodology. The visibility is part of how their attention gets directed.
Second, leaders need to understand the leverage. A CEO or VP setting strategic direction can either try to row the boat themselves with a thousand passengers or they can articulate the direction clearly and let the thousand people row together. The leverage of broad participation is substantial. The question isn't whether to use leverage -- it's whether the strategic direction is clear enough that the broad participation rows in a coordinated direction rather than scattering.
Mark adds the balanced scorecard framing. CI executives often focus on safety, quality, delivery, cost, and engagement together rather than on ROI alone. The framing helps with executive engagement because it shows that the methodology produces results across multiple dimensions, not just financial ones. It also helps with the longer-term shift in leadership habits that mature Lean cultures require.
The deeper challenge Mark names: getting executives to embrace Lean philosophies as personal practices, not just as programs to deploy. One book Mark recommends -- The Lean Manager by Michael and Freddy Ballé, or chapters from Jeffrey Liker's The Toyota Way on leading with humility and taking a long-term focus -- describes the personal shifts that effective Lean leaders make. Executives in cultures of prophetic short-term focus often find these shifts uncomfortable. The work of changing personal leadership habits is often slower and harder than the work of teaching methodology.
The practical advice Mark closes with: executives should work problems themselves. They should do PDSA cycles. They should do root cause analysis. They should learn by doing rather than only by reading. The capability to coach others in the methodology comes from having practiced the methodology personally. Without that personal practice, the coaching tends to be theoretical and unconvincing.
A question that probably wasn't expected: how do you take notes during a lecture or webinar in a Lean way?
Greg's first answer draws on KaiNexus's internal practice. The sales team experimented with several approaches to capturing customer conversation notes and eventually settled on entering notes directly in the CRM rather than writing them down on paper and transcribing them later. The waste of transcription was visible. Eliminating it produced faster cycle times and better data quality.
Mark adds an experimental approach he's tried at conferences. At large events where everyone has a laptop or iPad and is taking similar notes on the same content, the duplication of effort is substantial. He's experimented with shared Google docs where attendees collaborate on a single set of notes rather than each producing their own. The approach has merit in theory. It also has counterarguments -- the act of personally writing notes might be part of how people learn and retain the material. There's some research suggesting that handwriting notes produces better retention than typing them, possibly because the speed difference forces the writer to summarize rather than transcribe.
The exchange illustrates something Greg makes explicit: Lean methodology can be applied to almost any process, but the answer isn't always obvious. Experimentation is required. What works for one person or team might not work for another. The methodology isn't prescriptive about specific solutions. It's prescriptive about the disciplined approach to finding solutions.
The bonus point at the end comes from Greg's grandfather. Spend two minutes at the end of every session reviewing and condensing your notes. Roughly 90% of notes are superfluous. The two minutes of review filters the 10% that's actually useful, and the act of reviewing reinforces what was learned. The approach saves time downstream by eliminating the need to reread voluminous notes that mostly aren't useful.
A cluster of questions that came in: organizations worried about being overwhelmed if they ask employees for ideas. What if the floodgates open and we can't keep up?
Mark's first point: the flood often comes from asking everyone for ideas at once rather than starting small and building capability. Starting with a department or a team, learning what works, coaching the people involved, and building capability before expanding produces a more manageable flow.
The second point is more important. The fear of too many ideas often masks an assumption about what processing ideas requires. The assumption is that a manager has to review every idea individually. If everyone in a 200-person department has two ideas, that's 400 ideas the manager has to evaluate. Of course that's overwhelming.
The alternative is to spread out the work of implementation. The person who identified the opportunity is often well-positioned to test the proposed solution. With light coaching and clear boundaries, the team can be implementing solutions in parallel rather than queuing them all for a single manager's review. The bottleneck dissolves when the assumption about who does the work dissolves.
Greg adds the prioritization framing. There's an initial spike in submissions when an organization first opens the floodgates. The spike then settles into a manageable steady state. The initial spike is easily handled by being honest with the people submitting ideas: "We heard you. We have this much bandwidth. Here's when we'll get to this." The prioritization isn't dismissal. It's transparency.
The research Ethan Burris presented at the KaiNexus user conference reinforces the point. Soliciting ideas and then not responding to them is worse than never asking. The dissatisfaction at an organization that asks and doesn't respond is greater than the dissatisfaction at an organization that never asks. The implication: if you're going to ask, you have to be ready to follow through, even if "following through" sometimes means "we're not getting to this one in the next month, here's why, here's when."
Mark's framing: there's a balance between asking what people want to change and asking what they can actually change. Both are legitimate questions. Both can produce action. The constraint is the relationship between the volume of asking and the capacity to respond. Calibrate the asking to match the capacity, or work to expand the capacity. Don't ask volume and then ignore the volume.
A question that comes up frequently for new prospects: how is KaiNexus different from an electronic suggestion box?
Greg's answer simplifies for clarity and then adds nuance. The electronic suggestion box model: someone submits an idea. The idea goes to a committee. The committee reviews ideas every 30 or 90 days. Most ideas get rejected. The submitter often doesn't hear anything for weeks. Implementation rates in traditional suggestion box systems are commonly 1 in 200, sometimes 1 in 500 or worse. The system isn't sustainable. People stop engaging.
The KaiNexus model is structurally different. The submitter has been coached in advance about what kinds of opportunities to identify. The leadership has been coached about responsiveness. Ideas go to direct managers rather than committees. Response times are 24 to 48 hours rather than weeks. The response often isn't a vote up or down -- it's a conversation that helps articulate the problem more clearly. The implementation rate across KaiNexus customers is 75% to 80% rather than 1 in 200.
The deeper difference is philosophical. The electronic suggestion box automates the traditional suggestion box. The traditional suggestion box has a Frederick Winslow Taylor philosophy underneath it -- workers submit ideas, management decides what to do with them. KaiNexus is built on the kaizen philosophy that's the opposite of Taylor's. The "k" in kaizen is the same letter at the back of the KaiNexus logo because the underlying philosophy is the operating premise, not just a label.
Mark adds the related point that KaiNexus also supports top-down project management work and the visibility of metrics across the organization. The platform isn't just an idea capture system. It's improvement management infrastructure that supports the full range of work an organization needs to manage -- ideas from the frontline, projects from strategic priorities, metrics that track whether the work is producing results. The combination is what makes the system useful for organizations practicing continuous improvement at scale.
The session ends with Greg and Mark reflecting on the format. Both note they didn't pre-prepare for the questions deliberately, so the responses are first-impression thinking rather than rehearsed answers. The volume of questions submitted exceeded what the session could cover, so some questions remained unanswered and were addressed through follow-up emails and blog posts after the session.
The format produced something Greg notes was new for them. The conversational quality, the willingness to disagree on emphasis, the occasional detour into childhood dream jobs and favorite dinosaurs -- all of it was less scripted than the typical presentation webinars. The audience response suggested the format worked. Part 2 was scheduled for a few weeks later to address more of the backlog.
The session itself was substantially about the platform's relationship to continuous improvement methodology. A few of the specific connections are worth pulling out.
The platform supports rapid response to ideas through direct routing to managers rather than committee bottlenecks. The 24-to-48-hour response standard that distinguishes the KaiNexus model from traditional suggestion box systems is supported by workflow infrastructure that notifies the right people at the right time.
The platform supports the visibility that prevents the futility factor from killing engagement. Submitters can see what happened to their ideas. Status updates flow back. Implementation gets acknowledged. The visibility addresses the "why bother, nothing will happen" pattern that traditional systems produce.
The platform supports the prioritization that handles the initial spike in submissions when a CI program opens up. Ideas can be queued, scheduled for later, or assigned to specific projects -- with the rationale visible to the submitter rather than disappearing into a black box.
The platform supports the balanced scorecard view that Mark and Greg both reference. Metrics across safety, quality, delivery, cost, and engagement can be tracked alongside the improvement work intended to influence them, supporting the broader-than-financial view of organizational performance that mature Lean programs require.
The platform supports the spread of improvements across departments and facilities -- the yokoten practice that distinguishes organizations that learn from their own work from organizations that re-solve the same problems in parallel.
The platform doesn't substitute for any of the underlying practices. The methodology, the leadership behaviors, the cultural conditions, and the personal commitment to continuous improvement all have to be developed independently. What the platform does is hold the infrastructure that lets those practices operate at scale rather than being constrained by manual processes that break down as participation grows.
What is "Ask Us Anything"?
A conversational webinar format where Mark Graban and KaiNexus CEO Greg Jacobson work through audience-submitted questions in real time, without pre-scripted answers. The format produces something the structured presentation webinars don't: practitioners thinking through real questions live, sometimes disagreeing on emphasis, sometimes building on each other's points. The session was the first in what became a recurring series.
Why did Greg Jacobson found KaiNexus?
To solve the operational problem he had encountered as an emergency medicine physician at Vanderbilt -- a 24/7/365 environment with substantial waste, fragmented communication across specialists and shifts, and no infrastructure for capturing and acting on the ideas that frontline practitioners had. The realization that the methodology needed technology infrastructure to scale across the kind of organization an ED actually is led to founding the company. The framing he uses in the session: he expected to be an ER doctor, not the CEO of a software company, but the problem he was trying to solve required founding a company to address it.
Is Lean opposed to technology?
No. Lean is opposed to throwing technology at problems that are actually rooted in process issues. The "Lean is anti-technology" stereotype comes from real failures -- automating broken processes, relying on ERP systems to do management work, confusing tools with methods. The Toyota Production System and other mature Lean organizations use technology extensively. The discipline is using technology in a way that supports good processes and engaged people, not as a substitute for either.
What's the difference between Lean in healthcare and Lean in manufacturing?
The methodology and philosophy transfer almost directly. The starting conditions and cultural texture differ. Healthcare has a mission orientation built in -- people go into healthcare for reasons beyond it being a job, and a Lean program can rally people around that mission. Healthcare also has a starting point with less operational discipline than mature manufacturing, so much of the Lean work involves creating basic stability before improvement becomes possible. Manufacturing tends to have more operational discipline at the baseline but less natural mission orientation among the workforce.
How do you introduce Lean into an established company that doesn't practice continuous improvement?
Start with why. Understand why the organization doesn't currently have a CI culture -- the cause is usually upstream of the employees and involves leader behavior patterns over time. Understand the current culture before trying to change it; cultures are never all bad, and identifying what to build on matters as much as identifying what to change. If morale is low, start with relationships and trust rather than methodology; there's a minimum amount of trust required for any CI methodology to work, and sometimes the first steps have nothing to do with Lean tools at all.
How do you sustain a Lean program?
Through small incremental changes that produce rewards on short timeframes, building the habit cycle that compounds over time. Through continuous coaching and reminders that account for organizational turnover. Through diagnostic attention to why specific changes didn't sustain, addressing those causes rather than treating sustainability as a single abstract challenge. Greg's framing draws on Charles Duhigg's The Power of Habit: cue, routine, reward. Mark's framing emphasizes starting small and figuring out how to sustain specific changes before trying to sustain "a Lean program" as a whole.
How do you get executives bought into Lean?
Make the benefits visible in language they care about -- ROI broadly defined, including financial returns, safety, quality, retention, and customer satisfaction. Help them see the leverage of broad participation rather than trying to solve all problems themselves. Get them practicing the methodology personally rather than only sponsoring it. The capability to coach others in CI comes from having practiced it. Mark also emphasizes the deeper shift: leaders in cultures of short-term focus need to develop longer-term and more humble habits, which is often slower and harder than learning methodology.
What books do you recommend?
Greg recommends Start with Why by Simon Sinek, The Power of Habit by Charles Duhigg, and Drive by Daniel Pink -- three books that don't mention Lean directly but explain the social and business psychology that determines whether CI methodology actually gets used. Mark recommends a balanced reading list: one current Lean book like The Toyota Way or Toyota Kata, one foundational older book by Taiichi Ohno or Shigeo Shingo, and one Deming book. And for healthcare specifically, Mark notes his own Lean Hospitals as the standard introduction.
How do you handle the fear of getting too many improvement ideas?
Start small enough to build capability before opening the floodgates. Spread the implementation work across the team rather than assuming every idea has to be evaluated by a manager. Be honest with submitters about capacity and prioritization rather than dismissing or ignoring ideas. The research Ethan Burris presented at the KaiNexus user conference makes the case directly: soliciting ideas and not responding is worse than never asking. If you ask, you have to follow through, even if following through sometimes means "we're not getting to this one in the next month, here's why."
How is KaiNexus different from an electronic suggestion box?
Structurally and philosophically. The electronic suggestion box automates the traditional model -- ideas go to a committee, reviewed monthly or quarterly, with implementation rates of 1 in 200 typical. KaiNexus operates on a different premise: ideas go to direct managers, get response within 24-48 hours, are tracked through implementation, and produce response rates of 75% to 80%. The "k" at the back of the KaiNexus logo refers to kaizen, which is the operating philosophy underneath -- not Taylor's management-decides-what-workers-suggest philosophy of the traditional suggestion box.
What's the role of small daily improvement versus big projects?
Both have a place. Big projects produce visible wins and address problems that small daily improvements can't reach. Small daily improvements build the habit cycle that compounds over time and addresses the volume of opportunities that big projects can't get to. The most effective CI programs balance both. Organizations that rely only on big projects miss the daily improvement that drives most of the cumulative impact. Organizations that rely only on small daily improvement miss the strategic moves that big projects require. The mix matters.
.svg)
Copyright © 2026
Privacy Policy