Watch the webinar here:
A3 thinking is one of the most widely taught problem-solving methodologies in continuous improvement work, and one of the most frequently misapplied. The methodology shows up in books, certifications, and workshops as a clean seven-step process printed on a single sheet of 11x17 paper. The reality of using A3 thinking effectively is messier. Teams skip the deep root cause analysis. Leaders rush to solutions. Countermeasures fail to sustain. The same problems return six months later in slightly different form.
Jess Orr's two-part webinar series with KaiNexus is one of the most practical treatments of A3 thinking available, and this second installment is where the depth lives. Part 1 covered the basics of the methodology. This session takes the substantial audience questions generated by part 1 and works through them with the directness that comes from someone who has been doing this work for a decade and is still learning.
Jess is founder of Yokoten Learning and at the time of this session was a continuous improvement practitioner at WestRock. She earned the Toyota Business Practices certification during her years at Toyota, holds two Six Sigma Black Belt certifications, and has a bachelor's degree in mechanical engineering from Virginia Tech. Yokoten is a Japanese term referring to the spread of knowledge across an organization -- the lateral transfer of learning that distinguishes mature improvement cultures from those that rediscover the same lessons in every department.
The session is hosted by Clint Corley, Enterprise Account Executive at KaiNexus.
The single most useful framing Jess offers in this session is the problem complexity spectrum. The question that surfaced repeatedly in audience feedback was when to use A3 versus other problem-solving approaches. The complexity spectrum gives a usable answer.
On the low-complexity end of the spectrum sit problems where the solution is generally known or readily knowable. The improvement is low cost, low effort, and low risk. Sustainment is relatively straightforward. The right tool is often PDCA or simply Just Do It. Examples: organizing a workspace where tools are hard to find (5S is the answer), reducing setup time on a machine where SMED is the proven approach, replicating hygiene practices from one hospital to another similar one, implementing min-max inventory management (Kanban handles this well). For these problems, an A3 isn't wrong, but it's overkill. The methodology adds friction without adding value when the root cause is already understood.
On the high-complexity end sit problems where the solution is genuinely unknown, the effort required is substantial or long-term or both, the data is voluminous or difficult to analyze, the root causes involve multi-factor interactions, and previous A3s have failed to solve the problem. The right tools at this end are more sophisticated: DMAIC for complex measurement-and-analysis projects, DFSS (Design for Six Sigma) for designing robust new processes from scratch, design of experiments for multi-variable interaction problems, agile methodologies for iterative development work. Examples: developing a new model vehicle (a multi-year process with too much complexity for a single A3), optimizing a hospital schedule with highly variable patient workload, selecting new digital equipment across five or six options through a structured selection matrix, analyzing chemical reactions in pharmaceutical applications, building a predictive regression model. A3 can be used at this end, but typically requires significant supporting documentation, and a parent-child A3 structure where a strategic A3 holds the overall framing and child A3s address specific sub-problems beneath it.
In the middle sits A3's natural territory. Problems where the solution is unknown but knowable through structured analysis. Problems that need long-term sustainable countermeasures, not just quick fixes. Problems that benefit from team-based root cause analysis and iterative countermeasure testing. Examples Jess offers: a high rate of errors in a billing invoice process where the source of errors is unclear, advanced setup time reduction work beyond the initial SMED low-hanging fruit, elderly patient falls at a hospital where the target is zero but the path there isn't obvious, dropped customer satisfaction scores at a call center, high temporary employee turnover rates, increasing average SAT scores for high school students.
Her estimate, drawn from a decade of practice across multiple industries: about 75% of the problems most CI practitioners encounter fall into this middle territory where A3 is the right tool. When in doubt, use A3 -- and adjust the approach if the problem reveals itself to be at one of the extremes.
Jess walks briefly through the standard A3 process to establish shared vocabulary before going deeper. The seven steps:
Define the problem with appropriate scope. Go to the gemba to understand where and how the problem actually occurs. Identify the current condition and set the target, both quantified. Analyze for root causes. Experiment with countermeasures. Evaluate results against the target. Sustain the gains through structured follow-up. The optional seventh step she adds: reflect on the process to capture what went well and what should be improved next time.
The proportion of effort matters as much as the steps themselves. Jess spends roughly 60% of her A3 effort on steps one through three -- the problem definition, current condition, and root cause analysis. The remaining 40% goes to the last four steps. The investment in upfront analysis pays back substantially in the speed and accuracy of countermeasure work that follows.
The 60/40 distribution is unusual in how most teams actually work with A3. Most teams flip this -- spending 20% on problem definition and 80% on countermeasure development and implementation -- and produce countermeasures that don't address root causes. Going slow at the beginning to go fast at the end is the discipline that distinguishes effective A3 work from improvement theater.
The audience submitted many questions about what to do when leadership isn't supportive of a problem worth solving. Jess's earlier framing was that you should move on to a different problem. The framing she has matured into is more useful.
The first move when leadership isn't engaged: clarify alignment with key business objectives. If leadership's performance ratings include defect reduction, an A3 on a top defect will land. If the work doesn't have a clear line of sight to what leaders are accountable for, the engagement gap is structural, not attitudinal. Make the connection explicit.
The second move: pre-discuss one-on-one with each leader. This is not a meeting where the leader gets informed of the plan. It's a two-way conversation where you explain the thinking and listen to their concerns. The investment in these conversations seems obvious in retrospect, but is consistently skipped in practice. Most leadership resistance Jess has encountered was the predictable result of leaders being asked to support an initiative they hadn't been adequately briefed on or consulted about.
The third move: when resistance persists despite alignment and pre-discussion, treat the resistance itself as a problem worth diagnosing with five-whys. Most resistance is fear-based. The fear may be of looking bad, of additional workload, of priority conflict with other commitments, of skepticism that the work will produce results. Each of these has a different appropriate response.
The common resistance patterns Jess identifies:
Lack of understanding around the problem. Hallway chatter creates uncertainty about what the actual problem is and what's being proposed. The response is communication and sharing so everyone has the same picture.
Lack of priority. Sometimes the leader is right that this isn't the right problem to work on right now. Don't be afraid to pivot. It's far better to redirect at the beginning than to discover during the sustainment phase that you were solving the wrong problem.
Lack of bandwidth. Leaders often assume an improvement initiative will require substantial time from them. The reframe: "if we reduced these defects by 75%, would that make your life better?" Most leaders nod. Then make clear that their role is to support and remove obstacles, not to do the daily work themselves.
Skepticism from prior failures. "We tried to solve this a year ago and it didn't work." The response: ask them to suspend disbelief, judge the process by results, and remember that the methodology is different now even if the problem is the same.
Once leadership is aligned, the next engagement challenge is the project team itself. Jess introduces a technique she draws from Simon Sinek's work: start with why.
The example she walks through is concrete enough to be operational. She was assigned to a plant that needed productivity improvement to sustain its business. In the first team meeting, she asked the question directly: "Why am I here?"
The answer: "To improve our productivity."
Her response: "No, that's not right. Why do you come to work every day?"
The answer: "To make money."
"Why do you want to make money?"
"To take care of our families."
The reframe she offered the team: "We are here today together so that we can ensure security to ourselves, our jobs, and our families."
The light bulbs came on in the room. The team could rally behind that why in a way they couldn't rally behind a productivity metric. The metric became the measurable expression of something more fundamental that the team actually cared about. The work shifted from being something they were assigned to being something they had reason to do.
The principle generalizes. Find the why that resonates with the specific team in front of you. Make it bigger than the metric. The metric matters operationally, but motivation requires connecting the work to something the team has independent reason to care about.
The deeper work of team engagement is building an environment where people feel safe enough to contribute honestly. Jess names several practices:
Establish ground rules early. What's discussed in the room stays in the room until the team decides to share it externally. Get to know team members beyond their roles. Be transparent about your own motives -- people will detect a hidden agenda even if it's not stated, and the detection itself destroys trust.
Solicit and act on team member feedback. The framing Jess uses with her teams: "Honestly, when it comes to your process, I don't know anything. I'm hoping you guys are going to teach me. I really see you as the process experts, and I'm going to be leaning on you pretty hard as we go through this." The framing is true. It's also the kind of statement that gives the team room to contribute without having to fight for it.
Use one-on-one conversations when team members are visibly disengaged. One of Jess's examples: a supervisor who sat at the back of meetings glaring at her. She had a one-on-one with him later and asked what was going on. It turned out he was worried that the existence of the improvement project implied criticism of his work as the supervisor. Once she reassured him that the project was meant to amplify what he'd been doing rather than to indict it, his entire posture toward the project changed. He became one of its strongest advocates.
Implement team ideas over your own, even when your idea seems better. This is the hardest discipline Jess names, and the one she had to learn through repeated experience. As the engineer in the room, she often had ideas she thought were higher-benefit than the ideas team members proposed. The lesson she learned the hard way: it's far better to implement a lower-benefit idea that's the team's than to implement a higher-benefit idea that's yours. The team will own and sustain their idea. Your idea will quietly erode after you move on, regardless of how good it was technically.
The honest version of this principle Jess offers: 95% of the time, when she eventually let the team's idea win against her engineering preference, the team's idea turned out to be better than hers anyway. The team knew the process better than she did. They were 100% right, and she was 100% wrong, and the result was both better outcomes and better team ownership.
A specific framing Jess offers for the countermeasure experimentation phase: give the team permission to fail. As countermeasures are designed and tested, there's natural anxiety about what happens if they don't work. The reassurance: this is an iterative process. PDCA cycles assume that some countermeasures won't work. The discovery that a countermeasure didn't produce the expected result is information, not failure. If the team isn't failing sometimes, they aren't really trying, and they aren't really learning.
The principle connects to the broader culture of psychological safety the team needs to do effective A3 work. Teams that are punished for failed countermeasures will only propose conservative ones, which limits the methodology's ability to produce breakthrough improvements.
Many of the audience questions concerned the pressure -- from customers, from leadership, from operational stakeholders -- to produce solutions quickly. The discipline of slow thinking that A3 requires can feel impossibly out of step with the immediate demands of the operation.
Jess's reframe: ask whether the goal is to solve the problem quickly once or to solve it permanently the first time. Most stakeholders, when asked directly, prefer the permanent solution. The pressure to be fast is often less about actually wanting speed than about wanting to know that action is being taken.
The practical adaptation: implement a short-term countermeasure to stop the bleeding while the long-term countermeasure is developed through proper A3 process. If a quality defect is reaching customers, deploy 100% sort immediately. The 100% sort isn't the real countermeasure -- it's a temporary fix that protects the customer while the team does the root cause analysis that will produce the durable solution. Stakeholders can see that something is being done, which usually satisfies the urgency, while the team retains the discipline to find the real root cause.
The other practical move: use the A3 storyboard to communicate progress to stakeholders during the analysis phase. Often what stakeholders want most is visibility into the work being done, not an immediate solution. The storyboard provides that visibility and buys the team the time needed to do the analysis properly.
The framework Jess invokes here is fast thinking versus slow thinking, drawn from Daniel Kahneman's work. Fast thinking -- the heuristic, pattern-matching, jump-to-conclusions mode -- is what evolution gave humans for survival situations. It works well when being chased by a saber-toothed tiger. It works badly when the problem is a chronic workplace issue with multiple contributing factors. A3 deliberately engages slow thinking, which is the rational, structured, deliberate mode that produces durable solutions.
The audience submitted substantial questions about the five-whys methodology, particularly around how to know when to stop. Jess offers a clear distinction: symptomatic root causes are intermediate causes that explain part of the problem but aren't themselves actionable in a way that prevents recurrence. True root causes are the underlying drivers that, when addressed, actually prevent the problem from recurring.
The discipline: keep asking why until further asking doesn't logically make sense, then you've found the true root cause. The number five in "five whys" is not magic. Sometimes it takes three whys. Sometimes seven. The point is to dig past the symptom level.
The example she works through with the team is concrete enough to internalize. The problem: coffee at a large coffee shop is too bitter. The fishbone diagram identifies several potential root causes across the 6M categories. One of them: the coffee grinder isn't grinding adequately.
The five-why trail from that initial cause: Why isn't the grinder grinding adequately? Because the beans are too large and tough. Why are the beans too large and tough? Because of climate changes where the beans were grown.
At that point, asking "why were there climate changes" stops being productive. The countermeasure has to address the actionable layer. Possible countermeasure: a holding area where bean moisture content can be regulated to compensate for the variable raw input.
A second example from her own work: long cycle time for purchase order approvals. Why long cycle time? Many layers of approvals. The intuitive countermeasure at this point would be to remove approval layers. Jess pushes further. Why are there many layers? Because there's a lack of confidence in the accuracy of POs. Why a lack of confidence? Because of a high error rate. Why a high error rate? Because the input to POs wasn't standardized.
The real countermeasure isn't removing approval layers. It's standardizing PO input so that the error rate drops, which restores confidence, which allows the approval layers to be reduced safely. Removing approval layers without addressing the error rate would have produced a faster but more error-prone process.
The third example: a healthcare team investigating a wrong-medication error. The five-why trail eventually lands on the fact that the prescription was handwritten and difficult to read. The countermeasure: require typed orders. The 5-why discipline transformed what could have been a generic "improve attention to medication" countermeasure into a specific operational change that addresses the root cause.
The other critical discipline Jess names: ask why, not who. She rejected a supplier's five-why analysis that landed on "the operators were not trained adequately" because that root cause stops short. The question to ask is why the operators weren't trained adequately the first time, and how to ensure adequate training the second time. The supplier was being asked to identify a person to blame. The methodology requires identifying a system to fix.
The structure Jess uses for root cause identification is the fishbone diagram, with categories that vary by domain. For manufacturing processes: Manpower, Method, Machine, Material, Measurement, Mother Nature -- the 6 M's. For transactional or administrative processes: People, Process, Procedure, Policy -- the 4 P's. The categories matter because they prevent the team from getting stuck on the first one or two plausible causes and missing categories where the real driver lives.
The discipline: each category should have at least two or three potential root causes brainstormed. The "at least two or three" prevents groupthink that takes the team down a single path without exploring alternatives. Some of the potential causes will turn out to be irrelevant. That's fine. The point of the exercise is exploration, not conviction.
The team-based brainstorming structure she uses for both root cause identification and countermeasure generation:
Put the identified root causes (or the problem statement) on a flip chart visible to the team. Each team member brainstorms solutions silently for about ten minutes, writing one idea per Post-it note. Collect the notes on the wall. Read each one aloud and combine duplicates so there's only one Post-it per distinct idea. Group the ideas into logical categories (affinitize them) with the team. Use a selection method -- nominal group technique, multi-voting, or similar -- to identify the top potential solutions. Apply a benefit-effort matrix to the finalists.
The benefit-effort matrix is the final filter. Effort on the x-axis (low/medium/high), benefit on the y-axis (low/medium/high). The green zone is high benefit with low or medium effort. The yellow zone is moderate territory worth considering. The red zone is low benefit with high effort. Pick three to five countermeasures from the green and yellow zones, no more. Too many simultaneous countermeasures disperses team energy and makes it impossible to attribute results to specific changes.
The anonymity in the silent-brainstorming phase matters operationally. Many people, particularly those who aren't comfortable speaking up in groups or who are concerned about how their ideas will be received by leadership, will contribute more in writing than in conversation. The silent brainstorming surfaces ideas that would otherwise stay hidden. The subsequent group discussion attributes the ideas back to their authors in a way that gives credit while preserving the safe-to-contribute structure of the initial generation.
A useful conceptual distinction Jess introduces during the countermeasure brainstorming discussion: there are two kinds of change worth considering. Kaizen is the small incremental change -- the steady improvement that compounds over time. Kaikaku is the radical breakthrough change -- the rethinking of how the process works fundamentally.
Most CI training emphasizes kaizen, and rightly so, because most improvement gains come from sustained small changes. But kaikaku has its place. When brainstorming countermeasures, the discipline is to consider both. Don't shut down a radical idea because it's not incremental. Don't dismiss an incremental idea because it's not radical. Both kinds of change have potential for impact. Different problems call for different kinds.
Resistance to change is predictable enough that Jess offers a distribution that maps to how teams typically respond. The bottom 10% are high resisters who will be against the change regardless of its merit. The top 10% are gung-ho about the change and excited to do it -- ideally these include project team members. The middle 80% are the skeptical majority who aren't against the change but aren't sold on it either. They'll evaluate the results and make a judgment.
The distribution matters because it shapes the change management strategy. The bottom 10% will probably never be converted by argument alone, but some of them can be moved over time by evidence. Jess has had high resisters become some of her strongest advocates after seeing the work succeed. The 80% middle ground is the actual target of change management work -- this is where most communication and evidence and reassurance lands. The top 10% need protection from being overwhelmed by the resistance of the other groups; they're the energy source for the work and need to be sustained.
The other principle: the distribution is dynamic. People move between categories as evidence accumulates and as their concerns get addressed. The 80% middle group is where most movement happens. A successful change can shift them into the top 10%. An unsuccessful one can shift them into the bottom 10%. Treating the response distribution as fixed misses the point of change management.
The Japanese term Jess uses extensively is nemawashi, which she learned at Toyota and uses constantly. The literal meaning is the gardening practice of tending the roots of a plant carefully before transplanting it. The roots are exposed, examined, prepared, and protected so the plant can take root in its new location.
In change management, nemawashi is the work of preparing everyone affected by a change before the change is formally implemented. The discipline is the two-way pre-discussion: explaining the proposed change, listening to feedback, incorporating relevant feedback into the change before it's deployed, and surfacing the underlying concerns that would otherwise become resistance after the fact.
The most useful operational principle Jess offers about nemawashi: when you encounter resistance, treat it as information about a fear that hasn't been addressed. The antidote to most fear-based resistance is knowledge. Explain the change in enough depth that people understand why it's being made and what it will and won't do. Inclusion: make people feel like they're part of the change rather than subjects of it. Adaptation: reassure them that the change isn't permanent if the results show it should be adjusted. Ongoing support: don't deploy the change and walk away. Stay engaged through the implementation period.
For more structured change management work, Jess references the ADKAR model: Awareness, Desire, Knowledge, Ability, Reinforcement. The model provides a sequence for thinking through what each affected person needs at each phase of the change.
Awareness: do they know the change is happening and what it is? Desire: do they understand how the change benefits them and the organization? Knowledge: have they been trained on the new way of working? Ability: have they had the opportunity to practice the new way and develop the skill, with verification that they actually understood the training? Reinforcement: are resources and support in place to sustain the change over time?
The verification step in the Ability phase is the one most often skipped. Verbal or written training is delivered, but no one confirms that the training was actually understood and can be applied. Jess uses a coaching analogy: a coach explains a play to the players, then watches them practice it. The watching is part of the coaching. Without it, the training is incomplete.
The hardest part of any improvement project is sustaining the gains after the project ends. Jess prefers the word "ownership" over "accountability" because accountability can carry a negative connotation -- the sense that someone will be blamed when something goes wrong. Ownership flips the framing. If you own something, by default you're accountable for it. The accountability is implied by the ownership rather than being a separate threat.
The operational principles for sustainment:
One owner per action item. Multiple owners almost always produce shared deferral -- each owner assumes the others are handling it, and none of them actually do.
Communicate the what and why thoroughly, but let the owner determine the how and when. The work belongs to the owner. The negotiation about timing and method can be a two-way conversation, but the ownership of execution is theirs.
Follow up on a predetermined frequency. Weekly check-ins, monthly reviews -- whatever the appropriate cadence is, make it consistent rather than ad-hoc.
Lead by example. If you have ownership items on the sustainment plan -- and as the project leader, you usually do -- demonstrate the ownership you're asking others to provide.
Make progress visible. Control charts are useful here because they distinguish actual movement in the metric from random fluctuation. Without visible progress, the sustainment work feels like it's happening in a void.
Start with asking why when gaps occur between target and actual. Don't start with judgment. The gap may reveal information about the process that's valuable. Maybe one of the countermeasures wasn't as robust as expected. Maybe the owner needs more support. Maybe the metric itself wasn't quite right. Asking before judging produces better information and better relationships.
The artifact Jess uses to hold the sustainment work is a control plan. The structure: what we're measuring (typically leading metrics that indicate whether the countermeasure is being practiced rather than just lagging metrics that show the eventual result), the trigger for action (often a specific deviation from target that triggers reactivation of the team), who's responsible, and the schedule for deployment and follow-up. The control plan doesn't need to look exactly like the template Jess showed in the session. It needs to include those components in whatever form fits the organization.
The closing principle Jess offers is the one that matters most for practitioners trying to apply A3 thinking for the first time: progress over perfection.
Her first A3 wasn't perfect. Her most recent A3 wasn't perfect. The standard isn't whether you produce a textbook A3 on your first attempt. The standard is whether you used a structured process to engage a team in solving a problem more effectively than you would have without the structure. The answer to that question is almost always yes, even for early attempts where the methodology is being learned through use.
The discipline of reflection -- the optional seventh step Jess adds to the standard process -- captures the learning each time so the next A3 can be slightly better. After every A3 she does, she writes down what went well and what should be improved next time. Every A3 produces items in the "needs to be improved" column. That's expected. The learning compounds across projects, and the practitioner who's done a dozen A3s with disciplined reflection is operationally different from the practitioner who's done a dozen A3s without it.
Jess's session is methodology-focused rather than platform-focused. She presents A3 thinking as a discipline that exists independently of any particular tooling. The platform integration is implicit rather than explicit.
That said, the methodology benefits from infrastructure that supports several specific practices.
A3 storyboarding throughout the project keeps stakeholders informed and patient. The platform can hold the storyboard as a living document, with updates visible to anyone who needs them, rather than as a static document that requires email distribution every time it changes.
Control plans for sustainment benefit from a system that holds the metrics, the trigger conditions, the responsible owners, and the schedule for follow-up. The platform's structured workflow and reporting features are designed for exactly this kind of sustained tracking.
The lateral spread of learning across the organization -- the yokoten that gives Jess's consulting practice its name -- depends on visibility of completed improvements across the organization. When an A3 produces a successful countermeasure in one area, the platform can make that improvement discoverable to other areas that could benefit. Without a shared system, lateral spread depends on people happening to mention their work to the right colleagues, which rarely scales.
The platform doesn't substitute for the methodology. The discipline of slow thinking, the structured root cause analysis, the change management work, the sustainment ownership -- these are practitioner disciplines that no system can perform on its own. What the system can do is hold the artifacts of the work in a place where they remain visible, accessible, and connected to the broader organizational improvement portfolio.
Jess Orr is founder of Yokoten Learning and a continuous improvement practitioner with more than ten years of experience across multiple industries, including automotive at Toyota where she earned the Toyota Business Practices certification. She holds two Six Sigma Black Belt certifications and a bachelor's degree in mechanical engineering from Virginia Tech. At the time of this webinar, she was working at WestRock in continuous improvement. She applies her passion for people and processes to help colleagues make sustainable, high-impact improvements. She is available for coaching through her website at yokotenlearning.com and can be reached on LinkedIn.
When should I use A3 versus PDCA or DMAIC?
The choice depends on problem complexity. Low-complexity problems where the solution is generally known or readily knowable -- 5S applications, setup time reductions where SMED is the proven approach, Kanban implementations, replicating proven best practices -- are usually handled best with PDCA or just-do-it execution. High-complexity problems where the solution is unknown and significant analysis is required -- new product development, multi-variable interaction issues, statistical optimization, regression modeling -- often need DMAIC, design of experiments, or other more sophisticated methodologies. A3 sits in the middle territory, which covers roughly 75% of the problems most CI practitioners encounter: chronic problems where the solution isn't yet known, the analysis is complex enough to require structured thinking but not voluminous enough to require dedicated statistical tooling, and the work benefits from team-based root cause analysis and iterative countermeasure testing.
What percentage of A3 effort should go to problem definition and root cause analysis?
Jess spends roughly 60% of her A3 effort on the first three steps -- defining the problem, understanding the current condition, and analyzing root causes. The remaining 40% goes to countermeasure work, evaluation, and sustainment. Most teams flip this distribution, which produces countermeasures that don't address root causes. The discipline of going slow at the beginning to go fast at the end is the single most important habit for effective A3 work.
How do you decide when to stop asking "why" in a five-why analysis?
When further asking doesn't logically make sense, you've found the true root cause. The five in "five whys" isn't magic. Sometimes the true root cause emerges at three whys, sometimes at seven. The discipline is distinguishing symptomatic root causes (intermediate causes that explain part of the problem but aren't actionable in a way that prevents recurrence) from true root causes (the underlying drivers that, when addressed, actually prevent the problem from recurring). A useful test: when you reach a cause, ask what the countermeasure would be. If the countermeasure addresses something that would actually prevent the problem from happening again, you've found the true root cause. If the countermeasure would just treat the next symptom, keep asking.
Why is "ask why, not who" important in root cause analysis?
Because the methodology is meant to find systemic causes that can be addressed by improving the process, not to find individuals to blame. When a five-why analysis lands on "the operators were not trained adequately," the analysis isn't complete. The next question is why the operators weren't trained adequately and how to ensure they will be trained adequately going forward. Asking why focuses attention on systems. Asking who focuses attention on people. Systems can be improved. People can be blamed. The two produce very different organizational responses, and only one of them produces durable improvement.
How do you handle leadership resistance to an A3 project?
Start by clarifying alignment with key business objectives -- if the work doesn't connect to what leaders are accountable for, the gap is structural and needs to be addressed first. Pre-discuss one-on-one with each leader in two-way conversations before the project starts, not after. When resistance persists despite alignment and pre-discussion, treat the resistance itself as a problem worth diagnosing with five-whys. Most resistance is fear-based -- fear of bandwidth, of priority conflict, of looking bad, of skepticism from prior failures. Each fear has a different appropriate response, and identifying which one is operating lets you address it specifically.
What is nemawashi and why does it matter?
The Japanese term for the gardening practice of carefully preparing the roots of a plant before transplanting it. In change management, nemawashi is the work of preparing everyone affected by a change before the change is formally implemented -- pre-discussing the change in two-way conversations, listening for and addressing fears, and incorporating relevant feedback before deployment. Most change management failures Jess has seen would have been prevented by adequate nemawashi. The investment in pre-discussion seems like overhead and is consistently skipped, which produces resistance that could have been prevented at far lower cost than the resistance ends up costing to manage after the fact.
Why does Jess prefer "ownership" over "accountability"?
Because accountability carries a negative connotation in many organizations -- the implication that someone will be blamed when something goes wrong. Ownership flips the framing. If you own something, by default you're accountable for it. The accountability is implied rather than being a separate threat. The shift in language matters operationally because it changes how owners relate to their work. Owners who feel ownership tend to take initiative on their items. People assigned accountability tend to do the minimum required to avoid blame.
Why implement a team's lower-benefit idea over your own higher-benefit idea?
Because the team will own and sustain their idea. Your idea will quietly erode after you move on, regardless of how good it was technically. The lesson Jess learned through repeated experience: better to implement a team-owned countermeasure that sustains than a project-leader-owned countermeasure that decays back to the pre-project state within six months. The honest version of this principle: 95% of the time, when she eventually let the team's idea win against her engineering preference, the team's idea actually turned out to be better than hers anyway. The team knew the process better than she did, and the methodology rewards that knowledge when project leaders get out of the way.
What is the benefit-effort matrix and how is it used?
A simple two-by-two grid for evaluating potential countermeasures. Effort on the x-axis (low, medium, high), benefit on the y-axis (low, medium, high). The green zone is high benefit with low or medium effort. The yellow zone is moderate territory worth considering. The red zone is low benefit with high effort. Pick three to five countermeasures from the green and yellow zones, no more than that. Too many simultaneous countermeasures disperses team energy and makes it impossible to attribute results to specific changes. The matrix is most useful as a structured discussion tool with the team rather than as an individual analytical exercise -- the conversation about where each idea falls is where the alignment happens.
What's the difference between fast thinking and slow thinking in problem-solving?
The distinction comes from Daniel Kahneman's work. Fast thinking is the heuristic, pattern-matching, jump-to-conclusions mode of cognition. It works well in survival situations where speed matters more than accuracy. Slow thinking is the rational, structured, deliberate mode that engages working memory and attention. It works well for complex problems where accuracy matters more than speed. A3 deliberately engages slow thinking, which is why the methodology can feel slow and frustrating to teams accustomed to fast-thinking problem-solving. The discipline of slowing down to engage slow thinking is what produces solutions that actually work, rather than solutions that feel right initially but don't address root causes.
What is a control plan and what should it include?
A structured artifact for holding the sustainment work after an A3 project completes its initial implementation. It should include what's being measured (typically leading metrics that indicate whether the countermeasure is being practiced rather than just lagging metrics that show eventual result), the trigger for action (a specific deviation from target that triggers reactivation of the team), who's responsible for monitoring and acting, and the schedule for deployment and follow-up. The specific format matters less than including those components. Without a control plan, sustainment depends on people remembering to monitor the metrics, which rarely scales beyond the immediate aftermath of the project.
.svg)
Copyright © 2026
Privacy Policy