View or download the slides:
Watch the recording of the webinar (and the bonus Q&A)
Listen to the recording via our podcast (and additional Q&A):
Woodfin is a Virginia-based company with 66 to 70 departments spanning heating oil delivery, convenience stores, residential services -- plumbing, electrical, HVAC, IEQ -- commercial HVAC and electrical work, metal fabrication, and a graphics and wrap shop. Getting a CI initiative to work across one industry is difficult. Getting it to work across all of those simultaneously, with cultures developed over 30 years, is something else.
Evan Graczyk and Bob Bell have been doing it. This session is their account of how Woodfin built an idea-driven organization, what worked, what didn't, what they've had to unlearn, and what they're still figuring out.
In 2018, Woodfin's key executives and owners attended a small business event where Dr. Alan Robinson spoke. Robinson is the author of The Idea-Driven Organization, and the idea that resonated most with the Woodfin leadership team was simple: small problems are the foundation of continuous improvement culture.
That framing mattered for Woodfin specifically because of its diversity. A single-methodology program aimed at a single type of problem in a single type of environment wasn't going to work across heating oil, convenience stores, residential plumbing, commercial construction, and metal fabrication. But everybody, in every one of those environments, has small problems. Everybody sees things that don't work. The small problem frame was broad enough to apply everywhere.
They started with four pilot teams in spring 2018 -- accounting, plumbing, and manufacturing -- specifically chosen to span different types of work. Evan came on as CI director in 2019 with a first priority of building structure: a framework, a manual, clear expectations, and feedback loops. Not a rigid prescription but, as he puts it, "baby bumpers on the bowling alley" -- enough structure to keep people in the right direction while leaving room for teams to find their own style.
Three rules became the foundation: participate, be respectful, and try to find the best answer. The vision was always a win-win-win: if a solution isn't good for the customer, the company, and the employee, you need to think harder.
The core argument for small problems over large projects isn't just simplicity. It's participation.
People working in the field every day see things management will never see. Those things are hurting productivity. Traditional improvement programs -- Six Sigma black belt projects, dedicated improvement teams -- capture some of that, but they capture it at the top of the organization and miss most of what's actually happening at the bottom. Alan Robinson's research suggests that in organizations running both a formal improvement program and an idea system, roughly 80% of the actual improvement comes through the idea system. Not the projects. The small ideas.
Bob adds a framing he uses early in every training: problems are good to bring up. That sounds obvious until you've worked somewhere that punishes surfacing problems. Setting the norm explicitly -- if we refuse to acknowledge our problems, we can't fix them -- changes what people are willing to bring forward. Some of Woodfin's teams put up tape on their boards saying "Problem Board" rather than idea board, specifically to normalize the concept. Bankers who came in were impressed that teams were acknowledging their problems openly and working on them.
The practical advantages of small problems compound quickly. They're usually solvable without a large capital investment. They're often process or training issues. They can be tested quickly. And once solved, they're replicable -- if one department figures out a better way to handle something, five other departments can potentially implement the same solution without repeating all the root cause analysis work.
Robinson's "100-headed brain" concept is central to Woodfin's approach. The idea is this: any individual has a certain set of problems they can recognize and a certain set of solutions they can generate, and those two sets don't always overlap. What defines an idea in their system is a problem plus a solution -- either is insufficient on its own.
When you add more people, something important happens. The set of recognized problems gets much larger. The set of available solutions gets much larger. People with non-traditional knowledge bases and different life experiences can see things specialists miss and generate solutions specialists wouldn't think of. The collaborative improvement meeting -- not as a committee deciding what management should do, but as a group solving problems together -- dramatically expands what any individual team member can contribute.
This is also why everyone participates. It's not that every person needs to be a black belt. Some people are better at recognizing problems. Some are better at research. Some are better at solution design. All of those skills are needed, and nobody is excluded from contributing just because they can't do every part of the process.
Teams spend roughly an hour to an hour and a half per week -- 30 to 45 minutes for the meeting plus about an hour of what they diplomatically do not call homework -- on improvement work. It's additive to daily work, not a replacement for it.
Two examples from Woodfin's experience illustrate what small problems actually look like in practice.
The first: technicians driving around Virginia couldn't find addresses because the GPS function in their operating platform wasn't working. This was an ongoing frustration that people had complained about and stepped over. When it came to the idea board, the IT director identified a one-minute fix: turn on GPS permissions on the technicians' phones so they could use their phones' native navigation instead. Simple. Fast. Immediately useful to everyone experiencing the problem.
The second is messier and more instructive. The plumbing team kept losing their sewer machines -- the large drain-clearing equipment -- and when they found them, they were often broken. The root cause analysis that followed didn't produce one fix. It produced several. The large machine was only needed about 20% of the time, and it was hard on backs. They switched to smaller machines that could ride on trucks and be handled solo. The machines had no serialization, so there was no way to track them. They added tags and set up a tracking system in Slack. They also established replacement parts inventory and a maintenance schedule so the machines would stay in working condition. What looked like a "we can't find the machines" problem turned out to be a tracking problem, a maintenance problem, a specification problem, and an ergonomics problem. Roughly 20 hours per week of wasted time during busy spring seasons, recovered.
Bob's favorite example comes from Alan Robinson's training materials: a bartender who noticed he was losing bar time every time he had to lug glass bottles and aluminum cans down stairs to a basement recycling area. He realized he was directly below the bar. He proposed drilling holes in the floor and running chutes down for the recycling. His manager listened rather than immediately dismissing it. They refined the idea together. Not only did it save significant time and increase bar sales, it eliminated a legitimate safety hazard. The example isn't about the chutes. It's about what happened when someone felt safe proposing something that sounded odd and a manager had the discipline to hear it out.
The most valuable part of the session is probably this section, because Evan and Bob describe a significant failure honestly and explain what they learned from it.
The EMC Construction team -- field crews working on job sites involving plumbing, sheet metal, and related trades -- was given the same idea network structure as everyone else. It didn't work.
The standard structure assumed weekly meetings, a relatively stable set of recurring problems, and enough time between problems and solutions to go through a defined process. Construction doesn't work that way. Problems on a job site change daily. They need rapid responses -- same day, sometimes same hour -- so the crew can keep moving. A process designed for office-based teams with stable weekly rhythms imposed in a construction context was just the wrong tool.
Before Evan joined, the executive team had attended a Shingo Institute company tour in Utah and come back with an important observation: there is no single correct method for improvement. Different organizations, different environments, different problems require different approaches. You can go beyond any single methodology and create what your situation actually needs.
Applied to construction: Woodfin redesigned the process from scratch, with construction crews involved in the design from the beginning. The weekly meeting became a brief daily structure. Clear expectations were set -- not that every person had to find an opportunity every day, but that the intent and participation were what mattered. The managers were included in the redesign rather than just informed of the results.
A project manager who had been part of the first failed rollout and hadn't understood what they were trying to do became, after being properly trained and included, a genuine champion of the program. As Evan puts it: that one moment illustrated why getting managers involved early and actually training them -- not just informing them -- is essential.
Evan and Bob return to this several times, so it's worth treating as its own topic.
Managers play a more significant role in idea-driven improvement than most organizations expect -- both as enablers and as potential blockers. Woodfin has businesses with cultures developed over 30 years, where managers were often brought up with a directive, do-as-I-say style. Moving to a model where teams solve their own problems and managers serve as mentors rather than heroes requires a real shift in how managers understand their role and their value.
Two failure modes keep recurring. The first is managers who don't see the value in small improvements within their area -- the "was it really worth my time?" reaction to a solution that saved someone else three minutes. The ongoing work here is making impact visible at multiple levels: not just to a department but to the organization as a whole, so that a manager can see their team's improvements as part of a larger network effect.
The second is managers who see their identity as being the person who rescues the team from problems. When teams start solving problems themselves, that can feel threatening. The response isn't to dismiss or lecture those managers but to work through what being genuinely helpful looks like in this new context -- a conversation that takes time and requires some patience.
Clear expectations from the start help with both. If managers know what the program is actually trying to accomplish before it launches, they can decide to be advocates rather than obstacles. That's easier to build into the design than to fix after the fact.
It happens. Alan Robinson prepared Woodfin for it, and it's worth preparing for.
After four or more years, some of Woodfin's early teams have reached the point where the obvious, accessible problems have been solved. This is a natural progression, not a failure. What they've built in response includes a few things.
A replicable ideas bank in KaiNexus, where implemented improvements from any team across the organization are visible to every other team. If another team has already solved a problem you're facing, you don't have to reinvent the solution from scratch -- you can reach out to them and apply what they learned.
Encouragement to observe other teams' idea meetings. Seeing how a different department works, hearing what problems they're solving, often surfaces problems in your own area you hadn't recognized.
And an upcoming initiative they call the "idea activator" -- the next wave of problem identification training from Robinson, specifically designed for teams past the initial low-hanging-fruit stage.
The well, as Evan puts it, may run dry periodically. But the rain comes back. Major changes -- new software rollouts, operational shifts, COVID-era protocol changes -- consistently generate new problems to work on. The teams that maintained the habit of surfacing problems through those disruptions were better positioned to generate ideas on the other side of them.
Woodfin didn't start with a strict ROI model. Bob, who is from a finance background, is candid about this: the early focus was on participation and productivity, not financial calculation. How many improvements were completed? How long since a team's last completed improvement? Were action items being finished?
What they've built out more recently, with a significant investment of effort to get historical data into KaiNexus, is a reporting structure that gives managers a clearer view of team performance -- including where teams may need additional support, not just where they're succeeding. They're careful about framing: the team at the bottom of a performance report isn't necessarily failing. Something is going on in that team that warrants a conversation.
They've also introduced a recognition program where contributions to the idea network earn reward points redeemable for branded items. It's not primarily about the items -- it's about creating a mechanism that keeps leadership attention on the improvements people are making, surfacing successes that can then be recognized through additional channels.
Bob's observation on team size: comparing a 13-person team's raw output to a 3-person team's output doesn't mean anything useful. When they compare teams, they normalize by active team member. The goal is to keep people motivated and show that their work matters -- not to generate a competition that excludes or discourages people.
Woodfin is explicit about the platform's role in their program. With 66 to 70 departments across multiple business units and geographies, the problem without a shared system is fragmentation: teams solving problems in isolation, with no mechanism for learning to spread.
KaiNexus became what Evan calls the unifier -- the single place where all improvement work across all departments lives, where replicable ideas are visible across the whole organization, where tracking happens at scale without manual coordination overhead, and where management reporting is possible without requiring someone to chase down data from 70 different places.
The construction redesign was done in close partnership with the KaiNexus team, which had to adjust how the platform was configured to support the daily rather than weekly cadence. That collaborative process itself -- a CI team working with software support to solve a process design problem -- is a small example of the same principles the program is built on.
Evan Graczyk is the Continuous Improvement Manager at Woodfin. He holds a BS in Industrial Engineering from Clemson University and a Lean Six Sigma Green Belt certification from Clemson. Prior to Woodfin he worked as a Lean Process Engineer at Schaeffler Group and a Lean Manufacturing Engineer at BorgWarner.
Bob Bell leads Financial Planning and Analysis at Woodfin. He holds a BBA in Marketing from the University of Georgia, a PBC in Information Technology from the University of Richmond, and an MBA from the UVA Darden School of Business. He earned his Six Sigma Green Belt while at Circuit City, with a background spanning retail operations and finance, IT, inventory management, and financial planning.
What is an idea-driven organization?
An idea-driven organization is one where improvement comes primarily from the people doing the work -- frontline employees who see everyday problems and are empowered to identify and solve them -- rather than exclusively from dedicated improvement specialists or top-down projects. Based on Alan Robinson's research, organizations that build functioning idea systems typically see roughly 80% of their real improvement coming through those systems, not through formal Six Sigma or Black Belt projects.
Why focus on small improvements rather than large projects?
Small improvements offer three practical advantages. First, everyone can participate -- you don't need a certification to notice a problem in your own work. Second, they're usually solvable quickly with little or no capital investment. Third, they're replicable -- a solution that works in one department can often be adopted by five others without requiring each to repeat the full root cause analysis. The aggregate effect of many small improvements, implemented consistently, typically exceeds what occasional large projects can achieve.
What is the "100-headed brain" concept?
Any individual can recognize a limited set of problems and generate a limited set of solutions, and those two sets don't always overlap. When a team works together on improvement, the combined set of recognized problems and available solutions becomes dramatically larger. People with different backgrounds, roles, and knowledge bases see things specialists miss and generate solutions specialists wouldn't think of. Getting everyone involved -- not just the people who are "good at CI" -- is what makes the collective problem-solving capability of an organization actually work.
What happened when Woodfin's standard approach didn't work for construction crews?
The weekly meeting structure, designed for office-based teams with stable recurring problems, didn't translate to job sites where problems change daily and responses are needed the same day. Woodfin redesigned the process from scratch -- with construction crews involved in the design from the beginning -- shifting to a brief daily structure, clarifying expectations, and ensuring managers were trained and included rather than just informed. The construction team became one of the stronger examples of successful adaptation in the program.
What role do managers play in idea-driven improvement?
A critical one, in both directions. Managers who understand and support the program become its most effective advocates at the team level. Managers who were trained in a directive style can unintentionally block it -- either by not seeing the value in small improvements or by feeling threatened when teams solve problems without them. Getting managers involved in program design from the start, training them explicitly, and helping them understand what their role looks like in a coaching culture rather than a fixing culture is among the most important investments the program makes.
How do you handle teams that run out of ideas?
It happens, especially in teams that have been active for several years. The practical responses include a replicable ideas bank where solutions from any team are visible to every other team, encouraging team members to observe other departments' meetings to spark new observations, and advancing to a second level of problem identification training for teams past the initial phase. Environmental changes -- new software, operational shifts, policy changes -- consistently generate new problems and can restart momentum.
.svg)
Copyright © 2026
Privacy Policy