Most leaders running a continuous improvement program who feel like momentum is dying do not have a commitment problem. They have a flow problem. Ideas come in. Some get worked. Many do not. Deadlines slip. Reviewers go quiet. Six months in, participation curves bend the wrong way and nobody can quite explain why.
This webinar is built around a specific diagnostic claim: there are four bottlenecks, observable in any improvement system, that account for most of what makes programs stall. They are not methodology problems. They are management behavior problems made visible by the data the system collects. And they have specific signatures you can learn to recognize.
What makes this session useful is the level of detail. Greg Jacobson and Ryan Confer walk through each of the four bottlenecks with reference to the actual reporting views people use to spot them -- the horizontal status bars showing unassigned and overdue work, the dashboard tiles that surface awaiting-review items, and the divergence chart that compares submitted to completed improvements over time. The framing is operational: here is what each bottleneck looks like in the data, here is why it damages the culture, and here is the leadership behavior that removes it.
The fourth bottleneck -- divergence -- is the one most leaders have not heard named before, and the one that gets the deepest treatment in the session. It also gets the most interesting interpretive nuance, including a worked example of how something that looks like divergence at twelve months turns out to be normal cycle behavior at twenty-two months.
Dr. Greg Jacobson is CEO and co-founder of KaiNexus. He graduated from Washington University in St. Louis in 1997 with a BS in Biology, completed medical school at Baylor College of Medicine, and finished a residency in Emergency Medicine at Vanderbilt University Medical Center, where he stayed on as faculty. His observation of operational inefficiencies in the emergency department led him to co-author "Kaizen: A Method of Process Improvement in the Emergency Department," published in Academic Emergency Medicine, and ultimately to co-found KaiNexus.
Ryan Confer was then VP of Customer Experience at KaiNexus, where he helped customers deploy the platform to track and manage their improvement work. His background spans an early-stage technology investment fund, a non-profit commercialization foundation, an automotive design agency, and a clinical-stage biopharmaceutical company. He holds a BSBA in Finance and Legal Studies from Bloomsburg University of Pennsylvania and an MS in Technology Commercialization from the McCombs School of Business at the University of Texas at Austin.
Before either presenter touched the four bottlenecks themselves, Greg set the precondition that makes any of the diagnostic tools useful. None of this works without leadership committed to building an improvement culture -- communicating that commitment, holding people accountable to the behaviors that produce it, and modeling those behaviors visibly. That ranges from front-line supervisors to the CEO, and it is non-negotiable.
He paired the leadership precondition with a methodology precondition. The improvement methodology has to be disciplined, consistent, and simple. Time and again, the organizations that build durable improvement cultures are using methods that meet those three criteria. Complicated methodologies, inconsistent application, or sporadic discipline are themselves bottleneck-generators upstream of the four specific patterns the session covers.
With that as the floor, the four bottlenecks live in the layer above -- the operating layer where the work either flows or it does not.
The first bottleneck is the simplest to see and the most damaging when ignored. An idea or opportunity for improvement gets submitted. Nobody is assigned to own it. It sits in an unassigned state for days, then weeks, then a month, then longer.
Ryan walked through the reporting view that surfaces this pattern. In the example, a horizontal status bar across about six months of activity showed 242 submitted improvements, with a substantial gray block -- roughly 60 to 70 items -- in the unassigned state. The gray block is the bottleneck made visible.
The reason this damages the culture is not abstract. Front-line staff submit ideas as a test of whether the system is real. When their submission disappears into an unassigned state, the message they receive is unambiguous: the people in charge are not listening. Even if leadership is genuinely supportive in every other respect, leaving submissions unassigned trains employees to stop submitting.
The remedy Greg and Ryan recommended is to assign within one to two days of submission. Not implement -- assign. The assignment itself is the response. It says: someone has eyes on this, someone owns it, and the work has entered the system rather than sitting outside it. Coaching front-line supervisors and managers to treat fast assignment as part of their daily routine is one of the highest-leverage behavioral changes a CI leader can drive, because it directly governs whether the next wave of submissions arrives at all.
The second bottleneck is the one that generated the most active discussion in the session, and the one Greg explicitly flagged as the trickiest. Work has been assigned and given a due date. The due date passes. Nothing happens. The item sits overdue for weeks or months.
The signature looks similar in the reporting view -- a large color-coded segment showing overdue items in the same horizontal status bar -- but the cultural damage is different from unassigned. Unassigned trains employees that leaders are not listening. Overdue trains the entire organization that accountability is optional.
What makes overdue tricky is that the underlying causes are varied. Sometimes the due date was unrealistic. Sometimes the assignee does not have the time, access, or resources to complete the work. Sometimes the improvement has grown in scope beyond what was originally captured. Sometimes the assignee is new to improvement work and does not know how to get started.
Greg's advice on this came in two parts. The first was operational: organizations that protect time for improvement work see fewer overdue items than organizations that do not. The amount of protected time does not have to be large -- fifteen minutes a day, a couple of hours a week -- but it has to be real. If people are expected to participate in improvement work on top of an already-full workload, items will go overdue and stay overdue.
The second was about due-date hygiene. Early in someone's improvement journey, they tend to set due dates that are either far too short (24 to 48 hours for work that genuinely requires more) or far too long (four months for work that could be done in two weeks, which guarantees the work waits until the last week). With practice and coaching, people calibrate. The system gets better as the humans inside it learn what realistic looks like.
Ryan added the behavioral piece. Once an item is in the overdue state, the question is whether the assignee needs resources or coaching to get unstuck, or whether the issue is purely about consistent check-in. The job of the coach is to figure out which, not to assume it is one or the other. And both presenters were firm on the point that technology cannot do this work alone. The notifications and dashboard tiles surface the pattern. The face-to-face conversation closes it.
The worst possible response, Greg said, is to leave items overdue for months at a time. What that trains is an organization that ignores alerts and notifications altogether -- a problem that compounds rather than resolves, because eventually the notification system itself becomes background noise nobody acts on.
The third bottleneck shows up less often than the first two but is no less damaging when it happens. The assignee has completed the improvement. They have submitted the resolution. The reviewer -- usually a leader one level up -- has not acknowledged it. It sits in an awaiting-review state.
Ryan recommended a specific dashboard configuration for surfacing this pattern: three tiles, one each for unassigned, overdue, and awaiting-resolution-approval, filtered to the leader's scope. The third tile is the one most leaders forget to set up because they are focused on the inbound side of the system rather than the closing side.
The damage here is to the reinforcement loop. When a leader reviews a completed improvement, they have an opportunity to provide positive reinforcement -- to call out the work, share it with colleagues, frame it as a win for the team. That single act of acknowledgment closes the loop on the improvement from the assignee's perspective and dramatically increases the probability that they will engage in improvement work again. Skipping the review breaks the loop. The person who did the work never hears whether it landed. The signal they receive is that completing improvements does not matter any more than submitting ideas did.
Greg's framing was that this is where leaders show up. The original idea matters. The implementation matters. But the review and recognition at the end is what tells everyone watching that the system is real.
The fourth bottleneck is the one that requires the most interpretation, and the one most leaders have not heard named explicitly. Divergence is the gap between the number of opportunities being submitted and the number being completed over a given period.
Greg walked through a divergence chart showing a year of activity at a representative organization. Two lines: a blue line for submitted opportunities and a red line for completed opportunities. The area between them, with blue above red, is divergence -- the accumulating backlog of opportunities that have entered the system faster than the organization is finishing them.
There are two dimensions to read on this chart. The vertical axis tells you the size of the OI workload at any moment -- how many opportunities are open. The horizontal axis gives you a rough sense of how long it takes the average opportunity to move from submitted to completed. Both matter, and they tell you slightly different things.
Greg offered a benchmark on cycle time: average duration from submission to completion should sit around one quarter, or 90 days. Organizations whose average consistently exceeds 90 days tend not to have as healthy a culture as those that come in under. Organizations whose average is substantially shorter than 90 days tend to be doing genuine rapid-cycle, low-cost, low-risk improvements -- which is usually a good sign. Items that are still open at six, nine, or twelve months are no longer rapid-cycle improvements; they are projects, and they should be managed as projects rather than tracked alongside daily Kaizen work.
The interpretive nuance came from a second chart. The first chart showed apparent divergence across 2014. The second chart extended the timeline 22 months further. Divergence narrowed and disappeared. What looked like a structural problem in the twelve-month view turned out to be a function of cycle time -- the submitted items had been entering the system before the completion curve caught up, but they had been getting completed all along. The right interpretation in that case was less "this organization is in trouble" and more "this organization is biting off larger improvements than it should and would benefit from focusing on faster cycles."
That subtlety is what makes divergence the bottleneck that most rewards careful reading. The chart tells you something is happening. Interpreting what it is requires looking at cycle time, scope of work, and trend direction together. Greg's working coaching advice for an organization with sustained divergence would usually be to push toward smaller, faster-cycle improvements -- because the sustainability of the program improves when the average improvement closes within the quarter rather than dragging across multiple quarters.
Pulling back from the four bottlenecks individually, there is an architecture argument running through the session that is worth pulling out.
Most CI teams are understaffed and overstretched. They cannot personally participate in every improvement in every department. What they need is the ability to monitor patterns across the organization and direct their attention to where it is needed most. The bottleneck framework gives them a set of leading and lagging indicators that map directly onto where they should be coaching, where they should be intervening, and where they can leave well enough alone because the local team is running well without them.
A CI leader who can pull up a view of unassigned counts across departments knows immediately where assignment discipline has slipped. A CI leader who can pull up overdue counts knows where due-date hygiene or resource constraints are biting. A CI leader who can pull up awaiting-review counts knows which leaders need a nudge about closing the loop on their teams' work. And a CI leader who can pull up a divergence chart by department knows where workload is accumulating faster than the team is clearing it -- which lets them intervene before the program collapses, not after.
This is what Greg called "traffic control" in the session. The CI leader's role is not to do all the improvement work. It is to see the whole system, identify where flow is breaking down, and direct coaching attention to the places that most need it. Without visibility, the CI team gets pulled into wherever the loudest complaint is coming from, which is rarely the place that most needs help.
One of the most useful exchanges in the Q&A came from a question that surfaces in nearly every CI program at some point: we use a committee to prioritize and assign new ideas, and we are lucky if we assign anything within a month. How do we fix this?
Greg's answer was unequivocal: the committee model, where all ideas go to a central body that meets monthly or quarterly to vote ideas up or down, is what he called an electronic suggestion box. It is what KaiNexus considers the opposite of a best practice for sustained continuous improvement.
The problems with the committee model are structural. Response time is too slow to keep employees engaged -- by the time a decision comes back, the person who submitted the idea has forgotten the context. The committee becomes a bottleneck by design. The author of the idea has no ownership of the implementation, which removes most of the engagement value from participating in the first place. And the cultural signal it sends -- that ideas are something to be vetted by a central committee rather than acted on locally -- runs against everything that makes a Kaizen culture sustainable.
The alternative architecture Greg sketched is distributed but visible. The first gate for an idea is at the front-line supervisor or manager level. They assess whether the improvement is local or affects other processes, and they make the call on whether to move forward with implementation. The author of the idea, in the organizations Greg sees working well, is involved in implementing the improvement more than 50 percent of the time. Visibility for the CI team and senior leadership comes from being able to see all the work happening across the organization in one place, but the decision-making is local.
Ryan added a constructive option for organizations stuck with a committee model they cannot dismantle immediately. Embed check-ins into the review window. A week after submission, ask the author for additional information. Two weeks in, ask them to sketch out who else would need to be involved if the improvement moves forward. By the time the committee actually reviews the idea, the author has been engaged multiple times, and the review itself becomes a smaller step in a longer conversation rather than a verdict delivered to someone who had forgotten they submitted anything.
The argument across this session is that the four bottlenecks are management behavior problems made visible by data. The behaviors that remove the bottlenecks -- fast assignment, realistic due dates, timely review of completed work, attention to divergence as a leading indicator -- are not things software can perform on a leader's behalf. They are things the leader has to do.
What infrastructure does is make the patterns legible. A horizontal status bar that surfaces 60 to 70 unassigned items in one view is doing something a spreadsheet cannot. A dashboard tile that filters awaiting-review items down to a single leader's scope is making visible what would otherwise sit in dozens of separate inboxes. A divergence chart that compares submitted to completed over multiple quarters is showing a pattern no human running the program by memory could reliably hold in their head. And the ability to run any of these views at the organization level, the site level, the department level, or the individual level is what lets a small CI team operate as the "traffic control" function Greg described.
None of this changes the underlying argument. The leadership behaviors are the work. What the infrastructure does is remove the structural excuses -- the lost ideas, the invisible workloads, the unrecognized closures, the slow-building divergence nobody noticed until it had already done damage -- so that the behaviors have something to act on.
What are the four bottlenecks that stall continuous improvement programs? Unassigned ideas (submissions sitting without an owner), overdue work (assigned items past their due date), unreviewed submitted resolutions (completed improvements awaiting a reviewer's acknowledgment), and divergence (the gap between submission volume and completion volume over time). The first three are visible in standard status reporting. The fourth requires a chart comparing submitted to completed improvements across multiple quarters.
How quickly should a new idea be assigned after submission? Within one to two days. The assignment itself is the response front-line staff are looking for -- it tells them their submission has been seen and an owner exists. Leaving submissions unassigned for longer than that trains employees that the system is not real and predictably reduces future participation.
Why is "overdue" the trickiest bottleneck to address? Because the causes are varied. Sometimes the due date was unrealistic. Sometimes the assignee lacks protected time, access, or resources. Sometimes scope has grown beyond what the original submission captured. Sometimes the assignee is new to improvement work and does not know how to start. The remedy is not one fix but a combination of protected time for improvement work, due-date hygiene that improves with coaching, and face-to-face check-ins that surface the actual blocker.
What is divergence, and how do you read it? Divergence is the gap between submitted and completed opportunities over time. It has two dimensions worth reading. The vertical gap shows the size of the open workload at any moment. The horizontal gap gives a rough estimate of cycle time -- how long it takes the average opportunity to move from submitted to completed. A healthy benchmark for average cycle time is roughly one quarter, or 90 days. Items consistently running longer than that should usually be reclassified as projects.
What does it mean when divergence appears to grow and then disappears over a longer time horizon? It usually means the apparent divergence was a function of cycle time, not a structural problem. Submitted items entered the system before the completion curve caught up, but they were getting completed all along. The example in the session showed apparent divergence across twelve months that flattened entirely over a 22-month view. The coaching takeaway in that situation is usually to push toward smaller, faster-cycle improvements rather than to assume the program is broken.
How long should a typical improvement take from submission to completion? About a quarter, or 90 days, as a useful average. Some improvements close within 24 hours; some larger ones take longer. Organizations whose average consistently sits over 90 days tend to have weaker improvement cultures. Organizations whose average is substantially shorter tend to be doing genuine rapid-cycle, low-risk improvements -- which is usually a healthy signal.
Why is leaving items in overdue status for months particularly damaging? Because it trains the organization to ignore alerts and notifications. Once people learn that overdue means nothing, the notification system itself stops working, and the program loses one of its primary accountability tools. The damage compounds rather than self-corrects.
Why does reviewing completed improvements matter so much? Because it closes the loop on the work and provides the reinforcement that drives future participation. When a leader reviews a completed improvement, they can call it out, share it with colleagues, and frame it as a win. That moment of acknowledgment is what tells the assignee -- and everyone watching -- that completing improvements actually matters to leadership. Skipping the review breaks the loop and reduces the likelihood that the person will engage again.
What is wrong with using a committee to vet and assign new improvement ideas? The committee model is functionally an electronic suggestion box. It centralizes decision-making far from where the work happens, slows response times to weeks or months, removes ownership from the author of the idea, and signals that ideas are something to be evaluated rather than acted on. Organizations with sustained improvement cultures tend to push the first decision gate down to the front-line supervisor or manager level, with the original author involved in implementation more than half the time.
If we are stuck with a committee model for now, what can we do to make it less damaging? Embed check-ins with the author during the review window. Ask for additional information a week after submission. Ask the author to sketch out who else would need to be involved a week after that. By the time the committee reviews the idea, the author has been engaged multiple times and has stayed connected to the process. That partially substitutes for the immediate response that a distributed model would provide.
How much protected time do employees actually need to participate in improvement work? Less than most leaders assume. Fifteen minutes a day or a couple of hours a week is often enough -- as long as it is real. The problem is not the amount of time; it is whether the time exists at all. Programs that ask employees to do improvement work on top of an already-full workload tend to generate overdue items as a structural consequence.
What should a CI leader do first when they see signs of all four bottlenecks at once? Start with unassigned. It is the cheapest to fix, the most directly tied to future submission volume, and the one whose remedy depends almost entirely on a behavioral change at the supervisor and manager level. Once assignment discipline is in place, overdue and unreviewed work become more tractable, and divergence patterns become easier to read because the front end of the system is no longer adding noise. Fixing unassigned first does not solve the other three, but it usually makes them easier to solve.
.svg)
Copyright © 2026
Privacy Policy