The Quiet System: Why Your Lessons Learned Aren’t Sticking

Your team keeps solving the exact same problems project after project. What if the issue isn't careless execution, but a reactive system designed to hide failures rather than learn from them? 

In this episode:
• Discover how protective, reactive systems create "quiet" organizations where vital failure data gets buried instead of shared.
• Learn the three essential shifts high-performing organizations use to turn lessons learned into strategic, upstream inputs.
• Understand why the pendulum swing toward over-constrained, paperwork-heavy processes is just another system design failure.

Ready to stop the cycle of repeating mistakes? Download the strategic quality integration checklist via the Quality During Design newsletter, or book a free 20-minute clarity call at qualityduringdesign.com/talk to map out your next best move.

Transcript

Why Lessons Don't Stick

0:00

Welcome to the Quality During Design podcast. When we're in work, we are faced with challenges having to do with the project. Those challenges can be fun. The not fun challenges are having to rediscover the same problems over and over again. This could be a lesson learned from another project that just never translated to what we were working on. It could also be just the frustration of the same problem happening over and again with how we do our work. It's frustrating that the lessons that we learn never seem to stick or we have trouble carrying them forward. And it's a problem. It's a loss. It's not a failure because anybody's careless. It's a failure because the system that we're working in was built to react, not to prevent. Let's talk more about it after the brief introduction. Within reactive organizations, the intent is usually protection. We're protecting people. There's liability concerns, we're protecting the company. When there's an issue that pops up or a problem, the first reaction is to fix it. Stop the bleeding, fix the problem, redirect, make sure that things are protected. But then we don't take the next step. You can think of it as continuous improvement, root cause analysis, however you wanna think of it. Yes, there are projects that are started as continuous improvement in order to fix some systemic issues, but oftentimes they don't do enough or they don't go far enough, and it's difficult to combat some of these reactive systems that we've intentionally built, that are keeping us stuck. This sort of failure information- failure about our products, about our quality management system, about a manufacturing process- this is good information for us to know because we wanna learn from our failures. We don't wanna repeat them in the future. But the data gets hidden. It gets compartmentalized into a project. This is why you might have been working on a problem for a project for a couple months, only to later find out that Mike two cubicles down had a similar problem three years earlier and knew the root cause, and it was something that really could have saved you and your project two months. When reactive organizations are protective in nature, that dictates what gets documented in our lessons learned. And our organizations don't become safer or more streamlined or smarter. They just become quieter because people don't talk about it. And quiet systems don't learn and improve. The work to fix this is not fixing people, but making the system visible and then designing something better deliberately, iteratively, and with the humility to adjust when it breaks. So what does intentional front end investment actually look like? There are three shifts I see in high performing organizations. One is that they ensure failure mechanisms go somewhere useful. They're shared with other projects, other divisions, with the field technicians. There is communication along the whole product development cycle, including when it's in the field from concept through retirement or disposal. And those communications are encouraged by intentionally setting up communication lines and ways to share that information, ways to access that information when you need it. A second shift is from"who caused it?" Assigning blame to"what did we miss upstream and how do we prevent it in the next FMEA?", For example. This is more related to the root cause of the problem, the root cause of why we're not capturing these failure mechanisms, why we're not communicating it across the organization. What is the root cause of the system? The failure of our system that's not allowing us to learn from our failures and mistakes. And then the third shift is treating lessons learned as strategic inputs, not compliance Artifacts filed away after a project closes. There was a time I was consulting on a new product development project. I was acting quality engineer and we developed supplier quality plans for some critical components. I did a lessons learned on that project and communicated it with the team, and then a director said,"what are we doing to seed this within the rest of the organization?" That was the perfect question to ask because now we have lessons learned, which included some things that didn't work out well and things that did work out well. How are we going to incorporate this into the rest of the organization? And part of that, is understanding who is responsible for making sure that it happens? The overall question to keep asking when we're intentionally designing our systems is,"how does this help people make decisions in their work?" If we can't answer that, the structure probably isn't earning its place. It isn't providing the value or doing the things we need it to do."How does this help people make decisions in their work?" Before you go building a system for everything, there's a version of this that goes wrong in the other direction. If you find yourself unable to move because of too much paperwork, too many checklists too many approval hurdles to get through, and generally it's just too hard. Then the pendulum has swung from accidentally undefined to accidentally over constrained. Both are system design problems. Intentional systems are agile. We should be able to change them when we need to. We know that whatever system we're developing isn't perfect and we expect changes, so we allow those changes to happen and we build in a way to be able to make those changes is the mark of a mature quality culture is one, where learning compounds instead of resets. If you wanna know where your system is leaking, start with a strategic quality integration checklist. You can find it through my newsletter. And if you wanna talk through what this looks like in your organization specifically, visit Quality during Design dot com slash talk. We'll talk for 20 minutes. I won't pitch anything, but you'll get clarity on your next best move. This has been a production of Deeney Enterprises. Thanks for listening.