Matthew Cannistraro opened the session with a chart that anyone running a continuous improvement program for more than a year has seen some version of. Improvements submitted per month, from April 2013 through March 2014. The early months show a spike. By summer, the line has dropped. By fall, it's flatlined. The program, in his words, wasn't breathing.
J.C. Cannistraro launched their internal Kaizen challenge on Red Sox opening day 2013. Ideas came in immediately. Then the system ran out of gas. The problem wasn't that people had stopped having ideas. The problem was that the system for capturing those ideas — Google Sheets and pads of paper — created enough friction between having an idea and getting it documented that most ideas didn't survive the trip.
This webinar is the story of what they did next. It's also, more interestingly, the story of an operational distinction that turned out to do most of the work: separating adopted improvements from opportunities for improvement, and designing the system around flow efficiency rather than around documentation or approval. That distinction is the load-bearing idea in the session, and it applies well beyond construction.
What makes the Cannistraro story unusual is the candor. Matthew shared what worked, what didn't, and one experiment they explicitly will not repeat — tying improvement counts to bonus payouts, which produced more submissions but, in his framing, "poisoned the well" of the program's cultural health. The session is closer to a working retrospective than a polished case study, and the lessons are sharper because of it.
Matthew Cannistraro is an Operations Analyst in the Sheet Metal Group at J.C. Cannistraro, a Boston-area mechanical contracting firm that designs, fabricates, and installs systems for commercial buildings, with a specialty in hospitals and laboratories. He leads the development and deployment of a data-driven, Lean-informed approach to process improvement within the sheet metal group, focused on how technology, data collection, and frontline engagement can combine to create a sustainable improvement culture. He helped Cannistraro move from spreadsheet-based tracking to a system where hundreds of employees capture and implement improvements as part of their daily work. Cannistraro is a family business; the company's founding history goes back several generations.
Cannistraro had something many companies don't when they start a CI program: a learning culture already in place, fueled by the firm's increasing use of 3D modeling technology. Designers and fabricators were building everything in software before any material was cut, which meant the workforce was already engaging with complex digital tools every day. The company had also brought in a steady stream of young employees through co-op and internship programs, some of whom had moved into key leadership roles.
That combination — young employees, technology-driven workflows, co-op culture — produced people who were curious by default. They asked why. They learned for the sake of learning. Matthew's framing was that this prior learning culture was the substrate that made the eventual improvement culture possible. People who were already asking why had only one additional step to take: ask why, and then ask why not.
The improvement culture had to build on that foundation rather than replace it. The initial Kaizen challenge tried to layer a new system on top of curious employees and failed not because the employees weren't engaged but because the system created friction between curiosity and action. The redesign had to remove that friction.
The Google Sheets-and-paper version of CI tracking had a structural problem that wasn't visible until improvements stopped flowing. The delay between having an idea, documenting the idea, and sharing the idea was long enough to kill momentum.
A worker would notice something on a job site. They'd think about logging it later. Later would come and the moment would have passed, or the context would have faded, or the form would feel like extra work on top of the actual work. Multiply that across a few hundred employees and a few months, and the result was the flatlining chart Matthew opened with.
The principle that emerged from the failure is one Matthew kept returning to throughout the session: improvements occur at the gemba — the place where the work happens — so capture them there. Any delay between the origin of the idea and getting it into the system creates risk. Risk that the person forgets. Risk that they submit it inaccurately. Risk that documenting feels like extra work rather than part of the work. Risk that tracking improvements becomes a separate activity from making them, which is a structural problem disguised as a workflow problem.
The 5S deployment that followed gave the shop teams a shared understanding of what they were trying to improve, which surfaced more opportunities than the existing system could manage. The progression of how the shop tracked those opportunities is a small parable in its own right: pads of paper, then a shop foreman's Excel spreadsheet, then the search for software. The success of 5S didn't kill the spreadsheet — the volume of improvements did.
The most important operational insight in the session was the decision to split improvement work into two paths.
Adopted improvements are changes someone has already made to their own work. Low investment, potentially high return, no collaboration required, no approval needed. The person making the improvement is also the person implementing it. The system's job is to capture it quickly and make it visible to others who might benefit.
Opportunities for improvement are ideas where someone recognizes waste but can't fix it alone. The idea requires collaboration, approval, or work across departments. The originator can't implement the change in a vacuum. The system's job is to route the idea, build the team, and track the work to resolution.
At the time of the session, Cannistraro had logged 3,032 adopted improvements and 1,287 opportunities for improvement — adopted running at roughly 3x the rate of OFIs. The ratio is the visible artifact of what the split is actually doing.
The reason this matters isn't terminological. It's operational. Most CI programs treat all improvements the same way, routing every idea through the same workflow — submission, review, approval, assignment, implementation, validation. That workflow makes sense for the cross-departmental redesigns that require it. It's overkill for the technician who figured out a faster way to populate a 3D model using a custom mouse button mapping. Forcing that improvement through an approval pipeline introduces wait time the improvement didn't need.
The shape of the chart at the top of the session reflects this. Submitted and completed improvements track close together, with very little space between the lines, because most of the volume runs through the adopted-improvements path where there's no waiting in between.
The conceptual backbone Matthew used was flow efficiency — a Lean concept that compares value-adding work time to total elapsed time. The formula is simple: work divided by work plus wait. The leverage point isn't the work itself. It's the wait.
A process with five minutes of value-adding work and fifty-five minutes of waiting has a flow efficiency of about 8 percent. Reducing the waiting from fifty-five minutes to ten minutes — without changing the work itself — pushes flow efficiency to about 33 percent. Most Lean improvement work, when measured honestly, lives in the waiting. The same is true of improvement programs themselves.
Most CI programs are designed without flow efficiency in mind. An idea gets submitted. It sits in a queue. A committee reviews it. It sits some more. Someone gets assigned to implement. It sits again until they have time. By the time it's complete, weeks or months have passed. The work portion of the cycle might have been hours. The rest was waiting.
Cannistraro's two-path design is flow efficiency applied to the improvement system itself. For ideas that don't need waiting — the technician's mouse button mapping, the Outlook notification settings someone adjusts on their own machine, the way a foreman organizes fall protection on a job site — the system removes the waiting entirely. The improvement happens, gets logged, becomes visible to others, and is closed in essentially one step. For ideas that genuinely need collaboration, the OFI path provides the structure to coordinate it without forcing every simple change through the same workflow.
Matthew recommended Niklas Modig's book "This Is Lean" for anyone wanting to understand flow efficiency more deeply. The healthcare examples in that book translate the principle into clinical workflows in a way that's particularly portable for any service operation.
Roughly 80 percent of Cannistraro's improvements involve technology in some way. CAD and modeling shortcuts. Outlook notification settings. File handling. Data upload automation. iPad usage in the field. Safety organization documented on tablets at the job site.
This produced a reinforcing loop that Matthew thought was underrated as a success factor. Because daily work was already technology-driven, using a technology platform to capture improvements created a natural fit. Employees were already at their computers when they had an idea about their computers. Foremen already had iPads in the field for work that had to be done electronically, so logging an improvement from the field didn't require any additional device or workflow shift. The tool of technology was being used to improve the tool of technology, and the synergy was real.
The contrast came from the fabrication shops, which had less technology in their daily workflow. The shops, despite being where 5S had originally produced striking results, were now logging fewer improvements through the platform than the office. Matthew was honest about what this meant: when technology isn't already part of the workflow, a technology tool for improvement feels disconnected.
The response was to bring more digital visibility into the shop — TV screens showing what the team needs to build, replacing paperwork, with the eventual goal of running the improvement platform on those same screens. The intervention isn't to force a technology tool onto a non-technology workflow. It's to bring the workflow itself closer to the medium the improvement tool already uses, so the capture happens at the gemba rather than after the fact.
This is a non-obvious lesson with implications well beyond construction. CI software works best in environments where technology is already part of how people work. In environments where it isn't, the work isn't to drop the software in and hope. The work is to think about why digital tools haven't yet entered that workflow — and whether bringing them in for reasons unrelated to CI would make the CI capture work as a downstream effect.
Matthew called this the mantra of the company, and it showed up structurally in the system configuration. Cannistraro deliberately removed approval steps for most improvements. Employees are trusted to improve their own work without waiting for permission. The latitude carries real risk in some workflows — file naming conventions, for example, are not something anyone is allowed to change unilaterally — but for the vast majority of small changes, the default is action.
This trust increased participation and reduced the friction that typically kills improvement programs. It's also operationally consistent with the two-path design: if adopted improvements don't require collaboration, they shouldn't require approval either. The system trusts that employees acting on their own work, in their own context, are making changes that benefit the company. The cases where that trust breaks down become opportunities for improvement that route through the heavier workflow.
The principle scales further than the configuration suggests. Most CI programs have approval gates that exist because someone, at some point, was uncomfortable letting employees make changes without oversight. The cost of those gates is invisible because the improvements they discourage never enter the system in the first place. Cannistraro's discipline is to ask, for each gate, whether the protection it provides justifies the participation it deters.
A question came in about how standard work gets updated as improvements accumulate. Matthew's answer was honest about the gradient: some things are standard, some aren't, and the boundary itself is a working question.
Things like keyboard shortcuts and personal Outlook settings are not standard work. Employees can change them. They should change them. They should log the change so others can benefit. The improvement is local.
Things like file naming conventions and folder structures are standard work. Cannistraro's business depends on consistency across project teams that interact with the same files. Changing those requires the OFI path because the change isn't local — it affects everyone.
The boundary between the two isn't fixed. Matthew acknowledged that the answer to "how do you update standard work when improvements accumulate" is genuinely "it depends." Mark added a useful distinction during the conversation: he and others sometimes prefer "standardized work" over "standard work" because "standard" can suggest identical and inflexible in a way that triggers resistance, especially in healthcare. "Standardized" leaves room for the question of what genuinely needs to be consistent versus what tolerates variation without harm. The implicit framing is negotiable versus non-negotiable. Blood draws being done by someone wearing gloves is non-negotiable. The exact twelve words used to greet a patient is negotiable. Both can be present in the same standardized work without turning the worker into a robot.
This framing matters for CI program design because it answers a question most programs avoid. The question isn't whether to have standards. The question is what to standardize, what to leave to individual judgment, and where to put the boundary between the two — knowing that the boundary itself is something that gets re-examined as the work matures.
The most candid section of the session came in response to a question about financial rewards. Cannistraro had included improvement counts as a bonus goal for the year. Employees who logged a certain number of improvements over the course of the year would earn a percentage bump on their bonus.
The program produced improvements. It also produced submissions made for the sake of hitting the count. Matthew's framing was direct: "It sort of poisoned the well, and you can't separate the good from the bad. It convoluted the real health of our improvement culture." Cannistraro is not repeating the experiment next year.
The pattern this reflects is well-documented and worth keeping in mind for anyone considering similar incentives. Mark walked through the relevant frame from Dan Pink's "Drive" — extrinsic motivation reliably crowds out intrinsic motivation over time, hampers creativity (which is exactly what CI work requires), and creates secondary problems around perceived fairness and squabbling over reward sizes. Mark's earlier work with another organization had shown the same dynamic at smaller scale: improvement submissions spiked during contests and collapsed afterward, with employees explicitly telling them they were holding back ideas until the next contest period. Eventually the organization stopped running contests and had to re-engage people around the actual reasons to participate.
What makes the Cannistraro retrospective valuable isn't the conclusion that incentives don't work. It's that they tried it, observed the side effects, and named the side effects honestly enough to stop. Most CI programs that try the same experiment don't have the discipline to abandon it once the metrics look briefly better.
A question came in asking how Cannistraro prevents the program from stalling again. Matthew's answer had no silver bullet, which was the right answer. The actual response is multi-pronged:
Improvements get mentioned and acknowledged at every company-wide meeting. Managers are responsible for tracking the health of the improvement program within their departments. An internal Lean leader works one-on-one with managers to make sure their dashboards are configured to surface the data they actually need. Training is small-group and tailored to how each role uses the system, with one-on-one coaching for managers on dashboards and reports.
None of these on their own would keep the program healthy. Together, they create the constant attention the program needs. Matthew's framing was that there's no automated solution to a stalled improvement program. The program stays alive because people stay attentive to it. The systems and dashboards make attention easier. They don't substitute for it.
One question Matthew didn't have a fully satisfying answer to was how Cannistraro deliberately socializes improvements across the company. They use tagging in the platform, but tagging is optional — consistent with the don't-let-perfect-be-the-enemy-of-good principle — which means search is the primary mechanism people use to find improvements from other parts of the organization.
The search examples were small but instructive. Matthew had business cards accumulating in his office after conferences and wanted a way to digitize them. He searched the platform for "business card" and found that an employee had already discovered an app for scanning them. He adopted the app. Someone else had found a way to batch-process PDFs with a digital stamp, which influenced workflows across multiple departments once the search pattern surfaced it. The Outlook notification settings improvement — Matthew's own — had been borrowed from a coworker named Courtney and spread further from there.
The principle running through these examples is that the institutional body of knowledge becomes useful at a certain volume. With 3,000+ adopted improvements logged, the search function works because there's actually enough content for someone with a problem to find that someone else had it first. With fifty improvements logged, search returns nothing useful. The volume itself is what makes the body of knowledge functional, which is another argument for the design choices that maximize submission rate.
Cannistraro is now assembling a cross-departmental Lean team specifically to filter through adopted improvements and identify ones worth socializing more deliberately. The recognition is that organic discovery through search is a floor, not a ceiling, and that some improvements would spread faster with active curation.
The argument running through this session is that the operational design choices — capturing at the gemba, splitting adopted improvements from OFIs, removing approval steps where they don't add value, optimizing for flow efficiency — are what made the program work. The platform itself was the medium that made those design choices implementable, not the cause of the improvement culture.
That distinction matters. Matthew was explicit that buying software didn't produce the result. Redesigning how improvement fit into daily work, reducing friction, trusting employees, and using technology to support rather than control the culture is what produced the result.
Where the platform earned its keep was in the things that would have been structurally impossible without it. Capturing 3,000+ adopted improvements in a paper system isn't a friction problem — it's a physics problem. Search across that volume requires digital indexing. The dashboards that let department managers track their own program health require aggregation across the organization. The synergy between technology-mediated work and technology-mediated improvement capture — the 80 percent of improvements involving technology being logged in a technology tool — only emerges when the tool is already in the same medium as the work.
The shop-versus-office gap Matthew identified is the clearest evidence of what infrastructure does and doesn't do. The shops had real improvement potential and had previously produced strong results through 5S work. The platform's lower adoption in the shops wasn't a sign that the platform failed there — it was a sign that the workflow itself didn't yet include the technology that would have made capture natural. The response wasn't to push harder on the platform. It was to bring digital tools into the shop workflow for reasons aligned with the work, knowing that improvement capture would follow as a downstream effect.
What the platform does is remove the structural reasons that good improvement design fails to scale. It doesn't substitute for the design. Cannistraro's program would have stalled again, on different software, if they had kept treating all improvements the same way. The two-path distinction is the load-bearing idea. The platform is what made that distinction operationally real.
What's the difference between an adopted improvement and an opportunity for improvement? An adopted improvement is a change someone has already made to their own work. Low investment, potentially high return, no collaboration needed, no approval required. The person making the improvement is the person implementing it. An opportunity for improvement is an idea where someone recognizes waste but can't resolve it alone — it requires collaboration, approval, or work across departments. Splitting the two paths is what allowed Cannistraro to remove waiting from the simple changes while preserving structure for the complex ones. At the time of the webinar, they were logging adopted improvements at roughly 3x the rate of OFIs.
Why did the original CI program stall in 2013-2014? Because the system for capturing improvements — Google Sheets and pads of paper — created enough delay between having an idea and documenting it that most ideas didn't survive the trip. The Kaizen challenge launched on Red Sox opening day with strong initial enthusiasm. Within months, submissions flatlined. The problem wasn't engagement. The problem was friction between where the improvement happened (the gemba) and where it had to be recorded (somewhere else, later). Removing that delay was the central design problem the new system had to solve.
What is flow efficiency, and how does it apply to improvement work? Flow efficiency compares value-adding work time to total elapsed time. The formula is work divided by work plus wait. Most processes are dominated by the wait, not by the work, which means the highest-leverage improvements come from removing waiting rather than speeding up the work itself. Applied to improvement programs, this means designing the system so that simple ideas don't sit in a queue waiting for approval. The Cannistraro two-path design — adopted improvements with no waiting, OFIs with structured collaboration — is flow efficiency applied to the improvement system itself.
Why does Cannistraro remove approval steps for most improvements? Because approval gates discourage the participation they're meant to govern. The cost of an approval requirement is invisible because the improvements it deters never enter the system. For changes that affect only the worker making them — keyboard shortcuts, Outlook settings, personal workflow tweaks — approval adds no protection and discourages capture. The discipline is to ask, for each gate, whether the protection it provides justifies the participation it deters.
Why are 80 percent of Cannistraro's improvements technology-related? Because their daily work is already heavily technology-mediated. Designers work in 3D modeling software. Foremen carry iPads in the field. Coordinators populate models with materials before anything is fabricated. When employees notice friction or waste, it's usually friction with a tool they're already using, so the improvements are about the tools. The reinforcing effect is that using a technology platform to capture improvements about technology creates a natural fit — the same medium for both the work and the improvement of the work.
Why does the shop have fewer logged improvements than the office? Because the shop's workflow has less technology in it. Designers and coordinators are already at computers when they have improvement ideas, so logging is one step away. Shop workers aren't, so capture requires interrupting the work to go to a tablet or computer somewhere else — which reintroduces exactly the friction the design was meant to remove. Cannistraro's response is to bring digital visibility into the shop workflow (TV screens replacing paperwork, with the goal of eventually running the improvement platform on those same screens) rather than to push harder on the existing platform in a workflow that isn't yet structured to support it.
What does "improvements occur at the gemba — capture them there" mean operationally? It means the capture method has to be available where the work happens, not somewhere else. A worker noticing something on a job site should be able to log it from the job site, on a device already in their hand, without going back to an office or waiting until end of shift. Any delay between the moment of insight and the moment of capture introduces risk that the idea is forgotten, miscategorized, or simply never submitted. Cannistraro's foremen carrying iPads in the field is part of what made this operationally possible.
Why did the bonus-tied improvement count experiment backfire? Because tying improvement counts to bonus payouts produced submissions made for the sake of hitting the count, which contaminated the signal about the program's actual cultural health. Matthew's framing was that it "poisoned the well — you can't separate the good from the bad." The same pattern is documented in research on extrinsic motivation (Dan Pink's "Drive" is a useful reference). External rewards reliably crowd out intrinsic motivation, hamper creativity (which CI work requires), and create secondary problems around fairness disputes. Cannistraro is not repeating the experiment.
How do you keep an improvement program from running out of gas a second time? There's no silver bullet. Cannistraro uses a multi-pronged approach: improvements get acknowledged at every company-wide meeting; managers track the health of the program within their departments; an internal Lean leader works one-on-one with managers to configure dashboards that surface useful data; training is small-group and tailored to how each role uses the system. None of these individually keep the program healthy. Together, they sustain the constant attention the program needs.
How does Cannistraro update standard work when improvements accumulate? It depends on what kind of improvement it is. Local changes (keyboard shortcuts, personal Outlook settings) don't affect standard work and can be made unilaterally. Changes that affect shared standards (file naming conventions, folder structures, anything that touches other departments) route through the OFI path because the change isn't local. The boundary between local and shared is itself a working question that gets re-examined as the program matures. Mark added the useful frame that "standardized work" (rather than "standard work") leaves more room for distinguishing between what needs to be consistent and what tolerates variation without harm.
Did learning culture come before improvement culture? At Cannistraro, yes — and Matthew's framing was that this sequencing mattered. The company already had a learning culture in place before any CI program launched, fueled by young employees, co-op and internship programs, and heavy use of 3D modeling technology that required constant skill development. People were already curious by default and asking why. The CI program built on that substrate rather than trying to create it. The shift was from asking why to asking why and then asking why not.
What's the right way to think about training for an improvement platform? Small-group, role-specific, and ongoing rather than one-time. Cannistraro uses an internal Lean leader as the first line of support, who runs job-specific training tailored to how each role uses the system. New employees get training as part of onboarding. Managers get one-on-one coaching on dashboards and reports. The model treats software training the way most companies don't: as an ongoing practice that adjusts to how the platform itself evolves, not as a discrete event at deployment.
.svg)
Copyright © 2026
Privacy Policy