KaiNexus CEO and co-founder Greg Jacobson joins host Mark Graban for the thirtieth episode of the Ask Us Anything series, the recurring session built around questions from webinar attendees. This episode does something the others mostly don't: it puts the methodology on display in real time. A chat setting was broken at the start, a person walked in past a "webinar in progress" sign, and the hosts used each glitch as a live demonstration of containment, short-term countermeasures, and long-term root cause work. The submitted questions follow the same spirit, common mistakes when implementing a Lean tool, how a leader builds a culture that learns from mistakes rather than hiding them, and the chicken-and-egg question of whether culture has to change before you can implement Lean.
Here is what the episode covers and the thinking behind each answer.
Early on, an attendee flagged through a back channel that nobody could use the webinar chat. Mark narrated the response as a problem-solving exercise. Someone pulled the andon cord, the problem was identified and acknowledged, and Greg applied a short-term countermeasure by adjusting the settings to contain it. Then came the long-term countermeasure: go back to the Zoom setup, find the default that should have been on, and add the check to the recurring webinar checklist. Mark, the senior advisor at a software company, made the point that he still prefers a paper checklist he can hold, even though KaiNexus could build the same recurring checklist in its own platform. It's a small illustration of a recurring theme in the series: the right technology is the one optimized for the job, and sometimes for a personal checklist that's paper.
The same pattern repeated twice more. A person opened the door 45 seconds before the start despite a "webinar in progress" sign, and Mark caught himself in the instinct to blame, "didn't you see the sign?" He turned it into a countermeasure instead: the person obviously didn't want to interrupt, so the sign placement is the problem, not the person. Tape it directly over the door handle so you physically cannot open the door without touching it. And on the recurring risk of forgetting to hit record, Mark described two countermeasures, a note placed on the trackpad he has to touch, and the better long-term fix of setting Zoom to record automatically and editing out the pre-show. Telling people to "be careful" or "see the sign" is an ineffective strategy. Designing the mistake out is the move.
A reader named Kathy asked about the most common mistakes in implementing kanban and how to mitigate them. Mark generalized the question, because the same answer applies whether you swap in kanban, 5S, or any Lean method. He named three mistakes.
First, starting with the tool. Saying "we are going to implement this tool" instead of framing it as "what problem are we solving" is the fastest way to a tool that has no impact or that people abandon. It feels like implementation for its own sake. Second, being too rigid. People sometimes insist on doing a tool the exact way another company does it or the way they were taught. A starting point is fine, but adapt and adjust based on your own learning and needs. Third, not engaging enough people. He pointed back to the A3 process: engage people early in understanding the need, the current condition, and the performance gaps, then engage them in deciding which countermeasures to use. When a small group decides to implement something and then asks "how do we gain buy-in," it's already too late. Gain buy-in early and often.
Greg added three of his own, which he framed as general change-management principles, with the honest caveat that he and Mark are not perfect at any of this and constantly have to self-correct. Start with why, which is another way of asking what problem or opportunity you're addressing. Don't let better be the enemy of good; sometimes you just have to start and let it evolve. And make it easy. If you teach something new as a 15-step process with subtasks and conditional branches, it won't stick. Make it as easy as possible and build from there. He added a fourth, make it obvious, illustrated by keeping his dry-eye drops on the desk where the visible cue triggers the routine.
Both hosts circled the scientific-problem-solving frame and its limits. The Lean mindset reframes "we're going to implement the solution that will work" as "we have a hypothesis that this countermeasure will produce the results we predicted without major side effects," and you stay open to learning something unanticipated. But Mark flagged a real tension. Iterating your way to good has a place, and so does doing a little research first, because there's existing knowledge to build experiments on. You don't want to research a problem to death, and you don't want to be reckless either. In many organizations you get one chance, so the skill is finding the middle ground, enough research to be grounded, enough courage to try something not guaranteed to work. High-trust cultures make this easier, because people trust that others are doing their best.
Greg's medical analogy made the point land. If a patient came in saying "I want to be on blood pressure medication" or "I want glasses," a good physician doesn't just hand over the countermeasure. They run the history, the exam, the differential, they understand whether there's even a problem and what it is, before prescribing. And dosing is itself a PDSA process: you start with a small dose, adjust based on results, pair it with diet and exercise. You don't start with the maximum dose, which argues against rolling a tool out organization-wide as a big bang. Start somewhere small, get the early lessons learned where the stakes are lower, refine, then spread the refined practice while accepting it's still not perfect.
A reader asked how Greg, as CEO, thinks about creating a culture of learning from mistakes. He started by pushing back on a piece of startup lore, the romanticized "mistakes are wonderful, I'll only invest in a founder who's failed a few times" line. His honest take: mistakes suck, nobody wants to make one. What separates a mistake that becomes negative from one that becomes positive is your thinking about it, which is why growth mindset is a KaiNexus value. A fixed mindset reads a mistake as "I'm an awful person, I'm sloppy." A growth mindset reads it as "I learned something, how do we do this differently next time?"
His example was a penetration test. KaiNexus had just scored 5 out of 5, but the year before, the social-engineering portion of the test succeeded, the testers got in. When Greg told the story to his family, his daughter asked whether the employee who got fooled had been fired. The answer was no, of course not, everyone learned from it. He made the point that if you punish that person, two things happen: they feel even worse, and you build a hiding culture where nobody surfaces the next problem. Highlighting it as a learning opportunity does the opposite.
Mark added the balance. Celebrating mistakes makes sense only when there's a connection to learning, so you don't repeat the same mistake over and over. Erring too far toward punishing mistakes drives problems underground, which means you can't improve and may keep repeating the same error because nobody dares name it. By definition, a mistake wasn't intended; if it were intentional, you'd call it sabotage, which is a different matter. The healthy posture is to expect mistakes will happen and prepare for how you'll react when they do.
Greg's answer to how a leader builds this was leading by example. He told a story against himself: four to six weeks earlier he had treated someone poorly in a meeting, recognized it in the moment, stopped, and apologized directly. He was proud of that, because a version of himself five years earlier would have brushed it off. Mark named what that demonstrates, growth, and added the principle underneath it: own your role in something even when systemic factors are involved. A different person might deflect, "they're too sensitive," and blame the other party. The healthier move is to acknowledge there may have been other contributing factors while still saying "here's what I did, I can reflect and grow." When senior leaders visibly do this, it sets the tone, people like us do things like this. And if people think less of you for apologizing authentically, they're probably not people you want to lead. The caveat both noted: anything taken to its extreme inverts. Apologizing every five minutes is its own problem. Done authentically and appropriately, it builds the culture.
A reader named Charles posed it as a near-statement: is there anything more important than a cultural transformation from top management down to the shop floor before implementing Lean and Lean tools? Mark read the genuinely interesting part as the chicken-and-egg problem. Culture change is not a light switch; it's a journey. The culture changes because people are inspired enough to want to change, learn enough to start trying things, and have the air cover and psychological safety to attempt them. Greg's reframe: there's nothing more important than being a runner before you run a marathon, and what do runners do? They run. You behave your way into the culture.
The resolution both landed on is that it goes hand in hand, with one firm conclusion. You cannot sustainably do Lean on the shop floor if the leadership of that plant doesn't understand what's about to happen, because they will stop it. The andon cord is the perfect example. Plants have installed andon equipment only to waste the money, because in a culture without a help response, pulling the cord gets you yelled at for stopping the line. In the Toyota culture, pulling the cord triggers a leader asking how to help. So some elements of culture do need to be in place before a tool will work, and you can anticipate the culture gaps that would get in the way. But culture change is also a result of doing Lean things, engaging people in structured PDSA improvement. You don't need a perfect Lean culture to start. You do need enough leeway to let people try things that don't work, because if the PDSA cycles aren't actually cycles, if it's a straight path of "here's what we implemented," you're just wrapping new language around the same old improvement attempts.
Mark closed the segment with the dropped-part example that ties the whole episode together. A worker on an assembly line drops a part. The help culture says a team leader responds, gets the dropped part out of the way (a tripping hazard), hands over a new one, and the line recovers, or stops briefly to put quality and safety first. Without that help culture, the worker feels pressured, "I can't get in trouble, I'll just use it anyway," and now a defect flows downstream, maybe all the way to the customer. That's the damage a culture that pressures people into hiding mistakes actually does. The long-term countermeasure might be gloves, or redesigning the part to be easier to grip, because you don't want to react to the same problem all day. At some point you move to root cause.
A reader named Clint asked how KaiNexus knows the impact its customers are having, beyond counting customers or users. Greg shared two milestones. Customers had logged over five billion dollars of impact in the system, tracked across many currencies since 30 to 40 percent of customers are international, and not estimated but literally logged by customers based on their improvement work. And the system had crossed one million completed items in September, where items include opportunities for improvement, A3s, projects, charts, and tasks, because the platform is configurable enough that every organization uses different templates.
Mark drew out the harder question underneath: how much of the benefit comes from the methodology, the leadership, or the technology, given they're intertwined? Greg's honest answer is that you can't fully separate them. Nobody is forced to use KaiNexus, so there's always a question of what the organization would have done without it. What's compelling is the inflection point visible when an organization imports its baseline data and then starts using the platform, and the way CI professionals light up describing it. The technology does nothing without the methodology and the leadership behaviors. Greg also flagged a newer capability, tracking impact like CO2 emissions and water use for mining and manufacturing customers focused on environmental impact. Impact is no longer just cost savings; it's safety, satisfaction, and environmental and resource improvements too.
Mark added the three ways a system like this adds value, framed not as a salesperson but as what customers report. Better tracking of improvements that otherwise never get tabulated or roll up. Better collaboration as improvements are worked on, bringing in people who would be hard to involve otherwise, which produces more effective improvement. And the spread factor, logging and sharing what one team solved so other parts of the organization can see problems, solve problems, and reuse what's been done.
Ask Us Anything is a recurring series of short sessions answering questions from KaiNexus webinar attendees. It is hosted by Mark Graban, VP of Improvement and Innovation Services at KaiNexus, with Greg Jacobson, the company's CEO and co-founder, and occasional guest hosts from the KaiNexus team.
See every episode in the series on the Ask Us Anything main page. Earlier episodes are also available on the KaiNexus YouTube channel and in the KaiNexus podcast archive.
See KaiNexus in action and see how KaiNexus helps organizations capture ideas, coach improvement, and connect daily work to strategy.
.svg)
Copyright © 2026
Privacy Policy