Watch the recording:
Related Content:
Listen to it:
This is the kind of session that doesn't fit neatly into a single topic. The format is open Q&A — submit a question, get a real answer, watch the conversation go where the questions take it. Linda Vicaro and Lynn Howell from the KaiNexus Lean Strategy team field questions across the full range of what CI leaders are actually wrestling with: getting leadership to care, engaging frontline employees, starting in a small company, scaling in a large one, and sustaining the practice once it's in place.
Both Linda and Lynn came to KaiNexus the same way most of the Lean Strategy team did — as customers first. Linda spent six years using KaiNexus to lead continuous improvement work in healthcare before joining the company. Lynn was part of the launch as a user at her healthcare organization, did consulting work afterward (during which she kept telling clients "you really need KaiNexus"), and ended up here when a position opened. That dual perspective — having done the work, having used the tools, having now seen what dozens of other organizations do — is what makes the answers in this session different from typical product-pitch Q&A.
What follows are the substantive threads from the session. The full video has the texture; this page captures the takeaways.
The opening question. How do you make the case for continuous improvement to leaders who aren't yet bought in?
Linda's first move: measure your impact. CI practitioners often preach data discipline to others while undermeasuring the impact of their own work. Without data, the case for continued investment becomes anecdotal, and anecdotes don't survive budget pressure.
Lynn's addition: know what your specific leaders want to know. Some leaders are persuaded by stories. Others want data. Most want both, but in different ratios. The exchange Linda and Lynn keep having with each other on this point is essentially: marry the two. Stories without data are charming and dismissable. Data without stories is unmemorable.
A practical pattern they both pointed to: find one executive for whom the concepts click, even partially, and make them your champion. You're not going to convince every senior leader simultaneously. You're going to convince one, build momentum from their advocacy, and let that pull the rest along.
Mark added context most CI leaders don't see. KaiNexus customer impact across the entire customer base now totals more than 1.7 million completed improvement items and over $7 billion in tracked financial impact. That's the cumulative answer to "does this work" — not from any single organization but from the aggregate evidence across thousands of teams.
A specific version of the value question came in: how do you talk to a leader who says "we already collect data" and sees no benefit in doing more?
Lynn's response cut to the structural issue. The data and the improvement work often start as separate efforts in organizations and only converge later. If you'd integrated them earlier, the recurring problems wouldn't keep recurring. Just acknowledging data isn't the point. Doing something with it is.
Linda surfaced the psychological layer underneath the resistance. Sometimes leaders are tracking data because the data looks good and they want it to keep looking good. Suggesting improvement implies the current results aren't as good as they could be — and accepting that can feel like accepting that you've been failing to improve something for years. Defensiveness shows up. The leader's reflex becomes "if it were possible, we'd have already fixed it."
The work, then, isn't only analytical. It's helping leaders see the gap without feeling personally indicted by it. Mark's framing: leaders need to feel safe working on a long-standing problem without shaming themselves, even when no one in the organization is punishing them. That psychological permission is often what's actually missing — not the data.
Two related questions. How do you reduce resistance, and what are the best practices for engagement?
Linda's framing: think about what's valuable for the people you're trying to engage. Most CI rollouts ask people to do "one more thing." For that one more thing to land, it has to feel like something that reduces all the other things — not adds to them. CI practitioners know this in theory. The people being asked to participate often don't see the connection in practice.
Lynn's diagnosis on resistance: usually some version of "we've seen this before and it didn't stick." The team has been through previous improvement efforts that fizzled. They've watched programs come and go. Their resistance isn't laziness or hostility — it's pattern recognition.
Her practical move during frontline training: get people to apply the concepts to something outside the work process. Their laundry. Their grocery shopping. Unloading the dishwasher. Once the concepts click in a familiar setting, the application to work feels less abstract. The bridge from concept to lived experience matters more than the depth of the concept.
Mark's General Motors story sat in the same territory. New plant manager arrives, Toyota-trained, saying all the right things. Frontline workers with 30+ years of experience had been told to check their brain at the door for most of their careers. They didn't suddenly believe the new leader was different just because the leader said so. People had developed habits of not participating, and undoing those habits took time, consistency, and visible follow-through.
Linda's answer: keep it simple. The pull when you have limited coaching capacity is to ask people for more — more documentation, more updates, more detail — to compensate for the time you can't spend with them directly. That impulse backfires. Heavy reporting becomes a turnoff that kills participation in exactly the teams where you can least afford to lose it.
Better: design a methodology that integrates well into people's work and is easy to do correctly the first time. Iterate from there once the initial habit is in place.
Lynn's complement: if you have limited CI resources, make more CI resources. Train people. Find champions in departments who can spread the message. The CI team isn't the only source of CI capability in the organization — it's just the most visible one. Mature programs get leverage by developing distributed champions rather than concentrating expertise in a small central team.
Both led naturally into a conversation about habits — what habits do you actually want frontline employees doing, what habits do you want their leaders doing, and how do those habits connect to one another. The mid-level leadership layer often gets overlooked in conversations that focus on executives and frontline workers, but it's where most habit cycles either reinforce or break down.
The flip-side question. How do you build CI culture when the organization is too big to move quickly?
Linda's answer: find your champions, run a pilot, build a use case, and let the success at one site create the gravitational pull for adoption elsewhere. You can't change everyone simultaneously. Trying to is how programs collapse under their own weight.
Lynn's important caution: don't stop after the pilot. The most common failure mode in large-organization CI rollouts is a successful pilot that creates resentment in the rest of the organization because nothing else changes. The pilot site has new tools, new visibility, new wins. Other sites notice. If the spread plan doesn't exist, the goodwill from the pilot turns into "they got it and we didn't" — which is worse than not running the pilot at all.
The mission language KaiNexus uses internally — spread continuous improvement — applies here. Not just within a site, but across the organization. If the long-term vision for spread isn't built into the pilot from day one, the pilot itself becomes a problem.
Mark prompted Linda for an explanation mid-session (after pulling the proverbial andon cord on himself for forgetting to ask earlier). Worth keeping because it explains what makes the team's perspective useful.
The Lean Strategy department at KaiNexus is composed of CI professionals who were customers before they were employees. Linda and Lynn both used KaiNexus elsewhere first. The team's work with current and prospective customers focuses on understanding each organization's specific approach to continuous improvement — how they design A3s, how they run PDSAs, what tools they're already using — and then bridging that methodology with what KaiNexus offers.
KaiNexus's configurability is a feature and a challenge in equal measure. Configurability means the platform can fit the customer's actual practice rather than forcing a generic template. It also means the configuration choices matter, because they determine whether the platform makes the practice easier or just adds another place to enter the same information. The Lean Strategy team's role is to help customers make those choices well.
Mark deviated from the question list to ask Linda and Lynn what stands out about working at KaiNexus, given that the company actively works to be a culture of continuous improvement.
Lynn's answer: she's never worked anywhere where giving and receiving feedback was so normalized — and so non-punitive. People openly ask "do you mind if I give you feedback on this?" and the response is genuinely welcomed. Often the person giving feedback says "I struggle with the same thing" — feedback as collaborative coaching rather than judgment.
Linda surfaced something most external observers wouldn't know. KaiNexus uses an electronic note-taker that joins all internal meetings. Recordings get reviewed with managers as a development tool — what could have gone better, what could be improved. When she joined, the practice felt frightening. After a few months, it became unremarkable, and the value became obvious. That kind of openness to examining your own work is the cultural marker most organizations claim to want and few actually build.
Mark's reflection on the moment he made a mistake during the session — forgetting to ask Linda about the Lean Strategy team — sat as a small live demonstration of the culture both panelists were describing. The mistake got named, the system fix was acknowledged ("I could have had a checklist"), and the session moved on without theatrics.
A pre-submitted question Linda had been thinking about. Her top recommendation: don't be the one driving the computer.
Adults don't learn how to use new technology by watching someone else use it. They learn by doing it themselves. The training space should have computers (or be remote with everyone at their own machine). Participants should follow along with their own hands on the technology, not watch a demo of the technology being used by the trainer.
Lynn's addition: prep the participants before the session. Don't show them everything for the first time in the meeting itself. People who are processing brand-new information can't simultaneously evaluate it and give feedback on it. Sending material in advance — even lightly — lets them arrive ready to engage rather than ready to absorb.
Linda's third move: send participants off with structured follow-up. Information on how to ask questions when they hit problems on their own. An assignment that prompts them to actually use what they learned in the days following the session. The people who get nothing after a training session generally don't apply what they learned, regardless of how good the training was.
Lynn walked through what the optimization review process looks like for current customers. It runs every one to two years per customer depending on what's happening in their organization. The deep dive includes the customer success manager, a solutions engineer, and Lynn — across users, activity reports, data templates, and boards.
The framing matters: it's a work session, not a presentation. Lynn's standard line to customers going through it is that she isn't going to talk at them for hours. The session is collaborative — what's working, what isn't, what could be simpler, what new practices KaiNexus has learned might fit the customer better than what they're currently doing. At the end, the team agrees on what success looks like and how to measure it. The customer success manager continues supporting that work after the session ends.
The optimization review is one of the structural mechanisms that keeps customer practice from drifting. Without it, customers configure their KaiNexus instance once, then live with that configuration through years of organizational change that should have prompted updates. The review forces the question: does what we built two years ago still serve us?
A question with depth. How do you bring lean and digital transformation together rather than running them as separate, sometimes conflicting initiatives?
Mark's framing led: digital transformation is not just digitizing the way you've always done it. A paper suggestion box that becomes an electronic suggestion box hasn't been transformed. The structural problems of suggestion boxes — locked submissions, far-off committees reviewing them weeks later, no feedback to the person with the idea — survive the digitization unchanged.
KaiNexus's origins were never electronic suggestion boxes. The platform started as electronic kaizen — rapid engagement with employees, identification of opportunities (not just suggestions of solutions), local collaborative work, and visible follow-through. That distinction is what digital transformation looks like when it's done well, regardless of the specific tool.
Lynn's complement: don't jump to a solution because the technology can do the one thing you wanted. Ask what's before the moment the technology helps, and what's after. Implementing an employee suggestion program isn't a complete process. It's one step. If the rest of the process isn't designed, the technology either fails or actively makes things worse. The example Lynn pointed to — electronic health record implementations across organizations — is the cautionary tale most healthcare CI leaders know directly.
Linda's frame: there's an inclination to replicate paper tools one-to-one in a digital setting. That replication usually loses what made the paper version work and gains none of what the digital tool can do that the paper version couldn't. The translation has to be deliberate.
Linda's answer connected directly to the habits theme. Sustainment is fundamentally about whether the practice has become habitual. A practice that depends on the coach being present won't sustain when the coach moves on. A practice built into the team's daily work as a habit will.
Lynn's complement on sustainment from a project perspective: don't just hit the goal and leave. Build the recovery plan into the project. What happens if performance drifts back? Who notices? What do they do? Sustainment isn't a hope. It's a system.
She also flagged the value of historical visibility. A previous employer of hers — still a KaiNexus customer — recently pulled up a project she had documented in 2018 because they were revisiting the same problem. The ability to see what was already tried, what worked, and what didn't is significant when people change roles and organizational memory walks out the door with them.
Mark's complement: standardization gets a bad name because people think it means carved in stone. It doesn't. A standard is the current best-known way of doing the work. Standards exist to be improved. The point of standardization is to give you a stable baseline from which improvement experiments are measurable. Without the baseline, you can't tell whether a change made things better or worse.
Lynn closed the thread by emphasizing the systemic version of sustainment: when do we review this practice, what does the review look like, how do we revisit it before it becomes a problem again. The discipline of scheduled review prevents the slow drift that kills CI programs nobody noticed were dying.
The closing question. Linda's answer: start with the customer. Who are they, what do they need, and what work can we start on that improves their experience? That's the first place to look, in any kind of organization, before any methodology decisions get made.
Lynn's complement: when you can't act on the customer directly, look at internal processes that affect the customer outcome. In sales and service, the question often becomes "what's stopping us from meeting customer goals" — which is process work, not customer-facing work, but it's customer-driven nonetheless.
Mark's reinforcement: Taiichi Ohno's framing, "start from need." Start with your most pressing needs. Look at processes, look at barriers, look at what's getting in the way. Don't start by implementing 5S and putting tape around everything on the sales team's desks. (Hence the Lean Office Gone Wrong video, linked above — which is the cartoon version of exactly this failure mode.)
Mark's closing reflection on the video is worth lifting. The video is funny because the failure mode is recognizable. But the temptation to be snarky about people who fall into that mode isn't always helpful. Sometimes people don't have a good coach, or any coach. The work of CI leadership includes being a kinder coach than the system the person is currently operating in — even when the failure mode is genuinely worth laughing at.
A few specific things the platform does that connect to what surfaced in this session.
KaiNexus tracks improvement work and impact in the same place — which means the data Linda and Lynn both pointed to as essential for making the case to leadership exists by default rather than requiring a separate effort to build. The story-and-data combination they recommend is what the platform produces.
The platform supports the habit loops that Linda described — cue, routine, reward, with the reward made visible because what people contributed actually shows up as completed work. The structural problem with suggestion boxes Mark described is exactly what KaiNexus closes.
The optimization review process Lynn walked through is built into the customer relationship. The review isn't an optional service — it's how the team keeps customer configurations from drifting away from current best practice as both the customer and KaiNexus evolve.
If your continuous improvement practice is generating activity but losing the thread on impact, sustainment, or spread, the gap is usually the infrastructure that ties it all together. That's the gap KaiNexus is built to close.
Linda Vicaro is Director of Lean Strategy at KaiNexus. She has nearly 20 years of experience in continuous improvement, primarily in healthcare, and holds a master's degree in communication. She used KaiNexus as a customer for six years before joining the company, and she has been with KaiNexus for two years. She's based in Pittsburgh, Pennsylvania.
Lynn Howell is Senior Lean Strategist at KaiNexus. Her background started as a respiratory therapist, where she experienced continuous improvement as a frontline staff member during her organization's CI rollout. She moved into management, then onto the CI team at her healthcare organization, where she also worked as a KaiNexus customer for six years. After consulting work across the US, she joined KaiNexus when a position opened. She's based in Southeastern Ohio.
How do you communicate the value of continuous improvement to leadership?
Start by measuring the impact of your improvement work. The case for CI becomes anecdotal without data, and anecdotes don't survive budget pressure. Then find out specifically what your leaders care about — some are persuaded by stories, others by data, most by both in different ratios. Find one executive who responds to the concepts and build them into a champion. Convincing every senior leader simultaneously usually fails; building momentum through one advocate usually works.
What do you do when a leader collects data but doesn't use it to improve?
The structural issue is that data and improvement work often start as separate efforts and only converge later. The conversation isn't usually about the data itself — it's about what we do with it. There's also often a psychological layer underneath: leaders may be tracking data because the data looks good, and accepting that improvement is possible can feel like accepting they've been failing for years. Helping them see the gap without feeling indicted by it is usually the actual work.
How do you reduce employee resistance to change in a lean transformation?
Recognize that the resistance is usually pattern recognition, not laziness or hostility. People have watched previous improvement programs come and go. The most effective moves are demonstrating that the new practice will reduce existing burden rather than add to it, applying the concepts to familiar non-work settings so they click before being applied to work, and building habits gradually rather than expecting instant cultural change. Decades of "check your brain at the door" don't unwind in a quarter.
How do you start lean in a small company with limited resources?
Keep the methodology simple. The reflex when coaching capacity is limited is to ask people for more documentation and more detail to compensate — that backfires. Design a methodology that integrates well into existing work and is easy to do correctly the first time. Then iterate. Train department-level champions who can spread the practice without depending on the central CI team for every coaching moment.
How do you build a continuous improvement culture in a large organization?
Find champions, run a pilot at one site, build a case study, and let the success create gravitational pull for adoption elsewhere. The critical caveat: build the spread plan into the pilot from day one. A successful pilot with no follow-through creates resentment at other sites and is worse than not piloting at all.
How do you sustain lean practices over time?
Build practices as habits rather than as effortful behaviors that depend on the coach being present. Build recovery plans into projects so drift gets caught early. Invest in historical documentation so institutional knowledge survives turnover. Schedule regular reviews of standards so they evolve as the work evolves. Sustainment is a system, not a hope.
Where should a sales or service organization start with continuous improvement?
Start with the customer — who they are and what they need. The first improvement work should be visibly tied to customer experience or customer outcome. When the work is internal, frame it as "what's stopping us from meeting customer goals" so the connection stays clear. Resist the temptation to start with methodology rollouts (5S projects, kaizen events) before the need is identified. Start from need, then choose the methodology that fits.
.svg)
Copyright © 2026
Privacy Policy