<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Justin Buzzard- Tired QA Guy on Medium]]></title>
        <description><![CDATA[Stories by Justin Buzzard- Tired QA Guy on Medium]]></description>
        <link>https://medium.com/@jdbuzzman79?source=rss-1c832fe420b7------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*n34CKso3Z9urdNvjljFRFg.jpeg</url>
            <title>Stories by Justin Buzzard- Tired QA Guy on Medium</title>
            <link>https://medium.com/@jdbuzzman79?source=rss-1c832fe420b7------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Fri, 22 May 2026 04:30:49 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@jdbuzzman79/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[What Auditors See That Everyone Else Misses]]></title>
            <link>https://medium.com/@jdbuzzman79/what-auditors-see-that-everyone-else-misses-1fd6ed1f2d9e?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/1fd6ed1f2d9e</guid>
            <category><![CDATA[culture]]></category>
            <category><![CDATA[process-improvement]]></category>
            <category><![CDATA[quality-assurance]]></category>
            <category><![CDATA[auditing]]></category>
            <category><![CDATA[business]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Thu, 21 May 2026 13:01:02 GMT</pubDate>
            <atom:updated>2026-05-21T13:01:02.618Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*jgbFfANNRUShNhZZGrG5QQ.jpeg" /></figure><p>There’s a skill that good auditors develop that has almost nothing to do with checklists, compliance standards, or regulatory requirements. It’s the ability to walk into a process they have never seen before and notice, within minutes, the gap between how the people running it describe it and how it actually works.</p><p>This skill is not mystical. It’s the product of a specific mental discipline that can be learned and applied by anyone who wants to see their own organization more clearly than daily familiarity usually allows.</p><p>Most people who work inside a process eventually stop seeing it. The brain is an efficiency engine. It takes familiar patterns and converts them to background, freeing attention for something else. After six months in a role, you are no longer observing your process. You’re navigating it from memory. The gap between the map and the territory widens invisibly.</p><p>An auditor walks in sees the process from a new, fresh angle.</p><p><strong>The Four Things Good Auditors Actually Look For</strong></p><p>Experienced auditors don’t start with a checklist. They start with questions that expose the system rather than verify its components.</p><p>The gap between documented and actual. Every organization has a version of its process that lives in procedures and training materials and a version that lives in the daily behavior of the people who run it. These two versions are never identical. The interesting question is not whether a gap exists but how large it is, in what direction, and why.</p><p>Sometimes the actual practice is better than the documented one. An operator has found a more reliable method and is using it quietly. The documentation is out of date. This is a documentation problem with a straightforward fix.</p><p>Sometimes the actual practice is worse. Steps are being skipped under time pressure, controls are being bypassed informally, the procedure is being followed in name while its intent is being violated in practice. This is a culture and accountability problem with a less straightforward fix.</p><p>A question that surfaces this gap quickly. <em>Walk me through what you actually do, including the parts that do not always go exactly as the procedure describes.</em></p><p>The places where people hesitate. In any process walkthrough, there are moments where the person being interviewed pauses slightly before answering. These hesitations are information. They mark the places where the answer is complicated, where the practice is inconsistent, where the person is deciding how much to share, or where they are genuinely uncertain whether what they do is correct.</p><p>A skilled auditor notices the hesitations and gently explores them. Not with accusation, but with curiosity. Hesitation is often the entrance to the most useful part of the conversation.</p><p>What happens when things go wrong. The nominal process, the one everyone describes when things are running smoothly, reveals relatively little about the system’s actual robustness. The deviation process, what actually happens when something unexpected occurs, reveals almost everything.</p><p><strong>Ask: </strong><em>What do you do when a step does not go as planned? What do you do when the input you receive is not what you expected? What do you do when the equipment or system fails?</em> The answers expose whether the process has been designed with exception handling in mind or whether exceptions are resolved informally through individual judgment with no documentation and no shared learning.</p><p>Before any formal finding is documented, a skilled auditor asks two open questions. <em>What part of this process do you think works particularly well</em>, and <em>what part of it concerns you most?</em></p><p>These questions produce remarkably honest answers. The <em>first</em> invites the person to bring their own best practices, which the auditor can then look for evidence of and potentially recommend as a model for other areas. The <em>second</em> invites the person to name their own risks, which is best. It provides more credibility because the process owner already knows it, sees it and hopefully actions them.</p><p><strong>The Self-Audit Habit</strong></p><p>The auditor’s perspective is most valuable when it is applied to your own work. This requires deliberately adopting an outsider’s eyes toward a process you have become invisible inside.</p><p>The tool I have used most reliably is a simple one. Once per quarter, pick one process you run or oversee and observe it as if you were seeing it for the first time. Not from memory. Watch it actually happen. Then ask the same four questions.</p><p><em>Where does the actual practice differ from the documented one, and why? Where do the people running it hesitate or seem uncertain? What happens when something goes wrong? What worries them about it?</em></p><p>The answers will surprise you, reliably. Processes you thought you understood have informal workarounds you didn’t know existed. Steps you thought were being followed are being interpreted loosely under time pressure. Controls you designed carefully are being bypassed for reasons that made sense to the person bypassing them.</p><p>Seeing this is not a failure. It’s the beginning of improvement. The process you cannot see clearly cannot be improved deliberately. The auditor’s discipline is the practice of seeing clearly.</p><p><strong>What This Changes Organizationally</strong></p><p>Organizations that build the auditor’s perspective into their culture at every level don’t need as many formal audits as the risk is lower. The seeing-clearly discipline becomes distributed rather than concentrated in a specialized function that visits periodically and leaves a report.</p><p>This is the ideal endpoint of a mature quality culture. Not fewer audits, but fewer surprises in the audits that do occur. The gap between how processes are described and how they actually run is narrow because the people running them are continuously examining it, not because a scheduled audit forced a temporary cleanup.</p><p>The auditor’s most lasting contribution is not the finding. It’s the habit of looking.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Process Improvement, #Business, #Quality, #Auditing</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=1fd6ed1f2d9e" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Correction/Corrective/Preventative Actions in Quality]]></title>
            <link>https://medium.com/@jdbuzzman79/correction-corrective-preventative-actions-in-quality-dd1a9f76c314?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/dd1a9f76c314</guid>
            <category><![CDATA[quality-assurance]]></category>
            <category><![CDATA[business]]></category>
            <category><![CDATA[design-systems]]></category>
            <category><![CDATA[leadership]]></category>
            <category><![CDATA[design-process]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Tue, 19 May 2026 02:05:54 GMT</pubDate>
            <atom:updated>2026-05-19T02:19:43.856Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3Ht5iCbKOOaOBIphbfVNZg.jpeg" /></figure><p>A recent LinkedIn discussion highlighted a common tension in the quality world. When is <em>just fix it</em> sufficient, and when does a deeper investigation become essential?</p><p>The exchange started with a strong statement roughly like the following.</p><p>Corrective action shall fix the fault (symptom). That’s its job. However, root cause investigation afterward can result in Preventive Action… if there is no analysis, there could be a problem no one sees.</p><p>A counter-view followed using a practical analogy.</p><p>When you have a flat tire on your car, you just change the tire (Corrective Action). You don’t trigger investigation why this happens. Some of the faults are just faults.</p><p>The discussion evolved. Points were raised about trusting experienced technicians, the difference between ISO 9001’s focus on quality risk versus safety, and the reality that quality practices vary significantly across industries and company sizes.</p><p>Quality is wide-ranging, with different sectors, client requirements, and regulatory environments. Companies adapt ISO principles to fit their context, and what works in one business may not work in another. There’s rarely a single wrong answer, just different approaches.</p><p><strong>The Core Question</strong></p><p>This debate isn’t really about being right or wrong. It’s about risk and context.</p><p>Corrective Action addresses the immediate symptom.</p><p>Preventive Action / Root Cause Investigation aims to stop recurrence.</p><p>In low-risk environments (e.g., general manufacturing of non-critical consumer goods), many faults can indeed be handled with simple corrective fixes.</p><p>Over-investigating everything would be wasteful and bureaucratic, but in safety-critical, high-consequence industries, aviation, aerospace, medical devices, automotive, pharmaceuticals, rail, etc., the stakes change dramatically and also have more in depth requirements to meet.</p><p><strong>Why the Flat Tire Analogy Doesn’t Always Hold</strong></p><p>If your car gets one flat tire, changing it is usually enough.</p><p>If you keep getting flat tires, only changing them without checking alignment, road conditions, tire quality, or driving habits is irresponsible. Eventually, you’ll face a blowout.</p><p>In aviation or other regulated industries, even simple recurring faults can signal deeper systemic issues. Supplier problems, inadequate training, scheduling pressure, poor documentation, or normalization of deviance. Many serious incidents and accidents have started exactly this way, as well-known minor issues that were repeatedly corrected but never prevented.</p><p><strong>Standards Provide Guidance, Not Rigid Rules</strong></p><p>ISO 9001 focuses on quality risks to the product and customer.</p><p>AS9100, EASA/FAA regulations, and Safety Management Systems (SMS) explicitly require risk-based thinking that includes safety of operations.</p><p>Good CAPA systems are not investigate everything. They use risk-based triggers. Repeat occurrences, safety impact, critical parts, audit findings, customer complaints, etc.</p><p>Relying solely on the technician or operator to suggest further investigation when needed sounds empowering but has limitations. Even highly skilled people are subject to cognitive biases, production pressure, fatigue, and organizational culture.</p><p>While I love and promote the idea of Quality at the Source, it’s not full proof at the operator level.</p><p><strong>A Balanced View</strong></p><p>Quality is not one-size-fits-all. Different sectors and company sizes require different approaches. A small company with stable processes may thrive with lighter systems. A complex aviation maintenance organization cannot.</p><p>However, dismissing the value of preventive actions and investigation as default practice risks swinging too far toward complacency. Organizations that systematically avoid asking why will find issues creeping into their system and processes over time, not those that apply intelligent, risk-based thinking. That&#39;s how you will lose clients/customers over time.</p><p><strong>Final Thoughts</strong></p><p>Corrective Action is essential.</p><p>In high-risk contexts, it’s rarely sufficient by itself.</p><p>Smart organizations blend both. Fix the problem quickly and have disciplined processes to decide when deeper analysis is warranted.</p><p>Experience and technician judgment matter greatly, but they work best when supported by good systems, not used as a replacement for them.</p><p>Quality and safety professionals should remain open to nuance. What works in one environment may not in another. The goal is not bureaucracy or over-analysis, just sustainable performance and risk reduction.</p><p>Have you seen organizations struggle with this balance? Do you lean more toward fix it fast or always investigate? I’d love to hear real-world experiences from different industries.</p><p>Quality is an amazing topic because it is so wide-ranging in our lives.</p><h3>#Quality #Business #Correctiveaction #Preventativeaction #Processes</h3><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=dd1a9f76c314" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Document Control Is Not About Documents. It’s About Trust]]></title>
            <link>https://medium.com/@jdbuzzman79/document-control-is-not-about-documents-its-about-trust-aaf1cb7c163a?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/aaf1cb7c163a</guid>
            <category><![CDATA[operations]]></category>
            <category><![CDATA[process-improvement]]></category>
            <category><![CDATA[business]]></category>
            <category><![CDATA[quality-assurance]]></category>
            <category><![CDATA[document-control]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Mon, 18 May 2026 13:01:01 GMT</pubDate>
            <atom:updated>2026-05-18T13:01:01.663Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*objmLZ0ECg_mBIDidr6JKA.jpeg" /></figure><p>Of all the quality system requirements that organizations approach with least enthusiasm, document control is near the top of the list. It sounds like filing. It sounds like the kind of administrative overhead that quality departments impose on organizations that would otherwise be getting work done. It sounds, frankly, like the opposite of anything that would make a meaningful difference in how well an organization performs.</p><p>This perception is understandable and wrong in a way that has real consequences.</p><p>Document control is not about managing files. It’s about ensuring that every person in an organization who needs to do a task correctly has access to the current, approved version of the instructions for doing it, and that no one is operating from outdated, unauthorized, or unofficial guidance without knowing it.</p><p>That’s not a filing problem. That is a trust and reliability problem. Organizations that solve it well perform differently from those that do not.</p><p><strong>What Happens Without It</strong></p><p>Consider what actually occurs in organizations without effective document control. Procedures exist in multiple versions simultaneously. The official one in the quality system, the one that got updated six months ago in someone’s local folder, the one that was printed and laminated at the workstation three years ago, and the one that lives in the head of the person who has been doing this the longest.</p><p>When a new person is trained, they’re trained by whichever of these versions their trainer uses. When a problem occurs, the investigation is complicated by the fact that different operators may have been following different procedures. When a regulatory audit occurs, the documentation doesn’t reflect the actual practice because the actual practice has evolved informally while the formal documentation stayed frozen.</p><p>Each of these consequences compound over time. The informal procedure diverges further from the formal one. The training inconsistency produces more process variation. The investigation is harder because the baseline is unclear. The audit finding is more significant because the gap between documented and actual is larger.</p><p>None of this is the result of bad intent. It’s the result of a system that wasn’t designed to maintain itself.</p><p><strong>What Effective Document Control Actually Requires</strong></p><p>The core requirements are simpler than most organizations make them.</p><p>Every document that describes how work is to be done needs a <em>unique identifier</em>, <em>a version number</em>, an <em>effective date</em>, an <em>owner</em>, and an <em>approval signature or electronic equivalent</em>. These <em>five</em> pieces of information answer the questions of <em>what is this</em>, <em>which version is it</em>, <em>when did it become official</em>, <em>who is responsible for it</em>, and <em>who authorized it</em>.</p><p>Every person who uses a document to do their work needs access to the current version of that document and a clear way to know they are looking at the current version. This sounds obvious. In practice, the path of least resistance is usually to print the document once, use the printed copy indefinitely, and never check whether a newer version exists. Effective document control makes this path disappear by making the current version easily accessible and making the use of obsolete versions obviously non-standard.</p><p>Every change to a document needs a process, a proposal, a review by the people who will use it, an approval by someone with authority to change the standard, and a communication to the people affected by the change. Without this process, changes happen informally and the formal documentation decays from the actual practice.</p><p><strong>The Trust Argument</strong></p><p>Here is why document control is fundamentally about trust rather than filing.</p><p>When a customer buys a product or receives a service, they’re trusting that the people who produced it followed a process that reliably produces what was promised. That trust is based on the assumption that the process is defined, followed, and maintained.</p><p>When an employee follows a procedure, they trust that the procedure they are following is current, correct, and approved. If they cannot be confident of that, they are either following a procedure that may be wrong or using their own judgment to fill the gap, which produces exactly the process variation that procedures are designed to prevent.</p><p>When a regulator audits a quality system, they’re trusting that the documented system reflects how the organization actually operates. If the documentation is unreliable, the audit produces a finding not because the operation is unsafe but because the documentation cannot be trusted to represent it accurately.</p><p>In each of these cases, document control is the system that makes trust possible. Not because it is a bureaucratic requirement. Because it answers the fundamental question that every process depends on how do we know the right thing is being done the right way?</p><p><strong>The Practical Starting Point</strong></p><p>Most organizations with document control problems don’t need a new document management software system. They need three things.</p><p>A complete inventory of what documents actually need to be controlled. Not every document in the organization. The ones that describe how critical work is done, how quality is verified, and how compliance is maintained. A well-maintained small set is worth far more than a comprehensive system that no one maintains. Just to note, what documents required control will vary from company to company and business sector per the client/customer requirements as well as regulatory requirements.</p><p>A simple, consistent naming and versioning convention that anyone can use and everyone understands. The convention doesn’t need to be elaborate. It needs to be universal. A document whose version status cannot be determined at a glance is already causing the problem document control exists to prevent.</p><p>A defined review cycle for every controlled document. Documents age. Processes change. Regulations update. A controlled document that has not been reviewed in three years is either current by coincidence or wrong by accumulation. The review cycle is the system’s immune response to decay.</p><p>Start there. The system that maintains itself reliably is simpler than most people build. The one that requires constant heroic maintenance will not be maintained.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Process Improvement, #Document Control, #Quality, #Business, #Operations</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=aaf1cb7c163a" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Process Improvement Has a Dirty Secret: Most Improvements Don’t Need a Project]]></title>
            <link>https://medium.com/@jdbuzzman79/process-improvement-has-a-dirty-secret-most-improvements-dont-need-a-project-6b6632d97d8b?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/6b6632d97d8b</guid>
            <category><![CDATA[process-improvement]]></category>
            <category><![CDATA[lean]]></category>
            <category><![CDATA[productivity]]></category>
            <category><![CDATA[quality-assurance]]></category>
            <category><![CDATA[business]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Sat, 16 May 2026 13:01:00 GMT</pubDate>
            <atom:updated>2026-05-16T13:01:00.633Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*SRq0ef1B7wsyk93kqEJFuA.jpeg" /></figure><p>The process improvement industry has, inadvertently, created the impression that improving a process is a complex, specialized, resource-intensive undertaking. You need a project sponsor, a charter, a project team, a methodology, a timeline and a tollgate review structure and a final report.</p><p>For some improvement problems, that investment is justified and necessary. For the majority of improvement opportunities in most organizations, it’s a barrier that prevents improvement from happening at all.</p><p>The dirty secret of process improvement is this. Most improvements are made by one person who looked at something that was not working, understood why, changed one thing, and confirmed that the change helped.</p><p>No project. No methodology. No tollgate or bottleneck of decision making. Just a person paying attention and doing something about what they noticed.</p><p><strong>Why We Complicate It</strong></p><p>The formalization of process improvement happened for real reasons. Large-scale improvements involving multiple functions, significant capital, regulatory requirements, or systemic root causes genuinely require structured approaches. DMAIC, Six Sigma, and formal kaizen events exist because informal approaches do not scale to the size and complexity of some problems.</p><p>The formalization that was appropriate for complex, large-scale improvement became the template for all improvement. Organizations that should be making dozens of small, fast improvements every month instead queue them as formal projects, wait for project capacity, staff a team, work through a methodology, and complete a report. By the time the improvement is implemented, the opportunity cost of the delay has often exceeded the value of the improvement itself.</p><p>The other consequence is that the people closest to work who have the most accurate picture of what’s wrong and often the most practical ideas about how to fix it, stop offering those ideas because the path from idea to action is too long, too formal, and too discouraging.</p><p><strong>The Two-Category Framework</strong></p><p>A useful way to think about improvement is to divide all potential improvements into two categories before anything else.</p><p><strong>Category one:</strong> Improvements that require authority, resources, or coordination that a single person or small team does not have. Cross-functional process changes, significant capital investment, policy modifications, regulatory changes. These genuinely require a formal approach. They need a project structure because they need the organizational structure that this provides.</p><p><strong>Category two:</strong> Improvements that are within the authority and resources of the people who identified them. A step that can be simplified, a form that can be redesigned, a sequence that can be reordered, a communication that can be automated. These don’t need a project. They need a person with the mandate to make them and the habit of doing so. Documenting an improvement for credit is nice and the improvement should be praised. Just don’t let paperwork bog you down.</p><p>Most organizations heavily underinvest in category two and use the formalization designed for category one as the default for both. The result is a backlog of small improvements waiting for project capacity that never quite arrives, accumulating as a drag on the people who see them clearly every day and cannot get them addressed.</p><p><strong>What Everyday Improvement Actually Looks Like</strong></p><p>Toyota’s production system produced insight that became the lean philosophy partly because it treated every worker as a potential improver of their own process. Not occasionally. Continuously. The expectation that every person, every day, would look for at least one small thing to improve and would have the authority and the mechanism to act on what they found was structural, not aspirational.</p><p>This did not require elaborate systems. It required two things. A genuine expectation that people would improve their work as part of doing their work, and a simple mechanism for capturing, implementing, and documenting small changes.</p><p>The mechanism can be as simple as a shared log where anyone can record a change they made, what problem it solved, and what the result was. Not a formal change control process for minor improvements. A visible record that the improvements are happening, what is driving them, and what they are producing.</p><p>The expectation requires something more important; leaders who ask about improvement not as a special topic but as a routine part of how they talk about work. Not what projects are in the improvement pipeline but <em>what did you change this week and what happened?</em></p><p><strong>The Question That Unlocks It</strong></p><p>The single most impactful thing a leader can do to build an improvement culture requires no budget and no methodology. It requires asking one question in every team meeting, consistently, over time.</p><p><em>What is one thing about how we work that you changed or want to change, and what do you expect the result to be?</em></p><p>Not a suggestion box. Not an ideas portal. A direct question, in a meeting, that requires a specific answer, receiving a substantive response from the leader, and produces a visible action or detailed reason for inaction.</p><p>That question, asked consistently, does three things. It signals that improvement is everyone’s job. It creates a low-friction path from observation to action, and it generates a continuous flow of small improvements that, accumulated over months, produce the kind of operational gains that large formal projects are supposed to produce but often do not.</p><p>Process improvement is not a department or a methodology. It’s a habit. The organizations that improve most reliably are the ones where that habit is so embedded in daily work that it no longer feels like improvement. It just feels like how things get done.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Process Improvement, #Lean, #Business, #Quality, #Productivity, #Operations</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=6b6632d97d8b" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[The Corrective Action Report Nobody Reads (And How to Write the One They Will)]]></title>
            <link>https://medium.com/@jdbuzzman79/the-corrective-action-report-nobody-reads-and-how-to-write-the-one-they-will-a378fb2faf01?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/a378fb2faf01</guid>
            <category><![CDATA[business-writing-skills]]></category>
            <category><![CDATA[professional-development]]></category>
            <category><![CDATA[corrective-action]]></category>
            <category><![CDATA[process-improvement]]></category>
            <category><![CDATA[business]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Thu, 14 May 2026 13:01:02 GMT</pubDate>
            <atom:updated>2026-05-14T13:01:02.582Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*0M6s7MUIE-t1SI2aLXGR8A.jpeg" /></figure><p>Every organization that takes quality seriously has some version of a corrective action process. A problem is identified, an investigation is conducted, a root cause is determined, an action is implemented, and the effectiveness is verified. The outputs of this process are documented in a corrective action report, or CAR, or corrective action request, or 8D report, or whatever the organization calls its formal response to a significant quality failure.</p><p>These documents are, in most organizations, among the least read and least useful pieces of writing produced. They’re written to satisfy compliance requirements and filed in a quality management system where they will be accessed again primarily during the next audit.</p><p>This isn’t because the information they contain is unimportant. The information is often critically important. It’s because the documents are written in a way that makes them functionally inaccessible to the people whose decisions they should inform.</p><p>Here’s what makes the difference.</p><p><strong>The Structural Problem</strong></p><p>Most corrective action reports are organized around the process of the investigation rather than the output of it. They walk through the timeline… <em>here is when the problem was reported</em>, <em>here is when the team was assembled</em>, <em>here is what each investigation step found</em>, <em>here is the root cause that was determined</em>, <em>here is the action that was implemented</em>.</p><p>This structure is satisfying to write and nearly useless to read quickly. A manager reviewing a corrective action report to understand whether the organization has addressed a significant quality failure doesn’t need the timeline of the investigation. They need to know, in order <em>what happened</em>, <em>why it happened</em>, <em>what was done</em>, and <em>how we know it worked</em>.</p><p>Those <em>four questions</em> are the reader’s questions. The investigation timeline is the writer’s story. The two are not the same, and writing the writer’s story when the reader needs their questions answered is the primary reason corrective action reports are not read.</p><p><strong>The Format That Works</strong></p><p>A corrective action report that will actually be read and understood by the people who need to understand it answers <em>four questions</em> in <em>four sections</em>, as concisely as the subject requires.</p><p><strong>What happened. </strong><em>One paragraph</em>. <strong>Describe the specific nonconformance or failure.</strong> <em>What was found</em>, <em>where</em>, <em>when</em>, and <em>what the impact was</em>. Include the scope. How many units, how many patients, how many customers, what the affected period was. This section should contain enough specificity that a reader who was not involved in the incident has an accurate picture of what occurred.</p><p><strong>Why it happened. </strong><em>One to three paragraphs</em>. <strong>State the root cause clearly and directly</strong>. Not the contributing factors, the immediate cause, and the systemic cause as separate categories that require the reader to synthesize. The root cause. The specific gap in the process, the system, the training, or the design that allowed this failure to occur. Supporting it with the evidence from the investigation is appropriate. Burying it in the supporting evidence is not.</p><p><strong>What was done.</strong> <em>One to two paragraphs</em>. <strong>Describe the corrective actions taken</strong>. The specific changes to the process, the system, the procedure, or the training. Include the timeline of implementation and the named owners. This section should be specific enough that someone could verify whether the action described was actually implemented.</p><p><strong>How we know it worked. </strong><em>One paragraph</em>. <strong>Describe the effectiveness verification</strong>. What was measured, what the baseline was, what the result was after the corrective action was implemented, and what ongoing monitoring is in place. This section is the one most frequently absent from corrective action reports, which is why the same problems so often recur.</p><p><strong>The Language That Undermines It</strong></p><p>Corrective action reports frequently contain a category of language that sounds thorough and communicates nothing. Awareness training will be conducted. Additional oversight will be implemented. Team members will be reminded of the importance of following the procedure.</p><p>These are not corrective actions. They are aspirations that cannot be verified, do not address root causes, and will produce no measurable improvement. They’re written when the root cause analysis was incomplete or when the actual corrective action required is politically inconvenient, and they’re recognized as such by any experienced auditor who reads them.</p><p>The test of a corrective action is simple. If the action described was fully implemented, would the root cause that produced the failure be eliminated or significantly reduced? If the honest answer is probably not, the corrective action is not finished.</p><p><strong>The Accountability It Requires</strong></p><p>Writing a corrective action report that actually answers the <em>four questions</em> requires something that the compliance-driven version does not, honest determination of root cause.</p><p>Root cause determination requires asking why at least <em>three</em> to<em> five </em>times before accepting an answer. It requires the intellectual courage to follow the investigation where it leads, even when it leads to a systemic gap in training, a design flaw, a management decision, or a process failure rather than individual error. Individual error is almost never the root cause. It’s almost always the trigger for a failure that was enabled by a systemic gap.</p><p>Organizations that are genuinely committed to improvement write corrective action reports that identify systemic gaps, implement changes that address them, and verify that the changes worked. Organizations that are primarily committed to compliance write corrective action reports that satisfy the form requirement and leave the system intact.</p><p>The difference is visible to anyone who reads them carefully. It’s also visible in the organization’s quality metrics over the subsequent year.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Leadership, #Process Improvement, #Business Writing, #Quality, #Professional Development, #Operations</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=a378fb2faf01" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[The Feedback Nobody Gives (That Everyone Needs)]]></title>
            <link>https://medium.com/@jdbuzzman79/the-feedback-nobody-gives-that-everyone-needs-5e6f81328e9d?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/5e6f81328e9d</guid>
            <category><![CDATA[leadership]]></category>
            <category><![CDATA[business]]></category>
            <category><![CDATA[careers]]></category>
            <category><![CDATA[professional-development]]></category>
            <category><![CDATA[management]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Mon, 11 May 2026 13:01:01 GMT</pubDate>
            <atom:updated>2026-05-11T13:01:01.698Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*1-FJlAHBs8Hk2IJORxmvVQ.jpeg" /></figure><p>There’s a specific category of feedback that most professionals rarely receive and almost no one reliably gives. The honest, specific, well-timed observation that tells someone exactly how their behavior or their work is landing, delivered in a way they can actually hear and act on.</p><p>Most professional feedback lives in one of two inadequate areas. The <em>first</em> is too vague to be useful. <em>Good work</em>, <em>nice presentation</em>, <em>you should communicate better</em>. These are assessments, not feedback. They tell the recipient that someone has formed a view but gives them nothing to work with in terms of what specifically to do more of or differently.</p><p>The<em> second </em>is too blunt to be received. <em>That meeting was a disaster</em>, your report is not ready to be sent, <em>I am not sure you are cut out for this kind of work.</em> These land with impact, but they activate defensiveness rather than reflection, which means they produce discomfort rather than change.</p><p>The narrow band of feedback that actually works, that changes behavior and improves performance and builds rather than damages the relationship, is more specific, timelier, and more skillfully delivered than most professional feedback ever gets.</p><p><strong>Why We Avoid Giving It</strong></p><p>Most people who could give genuinely useful feedback to a colleague or direct report do not. The reasons are understandable and consistent.</p><p>The<em> first</em> is discomfort with the other person’s potential reaction. Giving honest feedback means accepting that the other person might respond with defensiveness, hurt, or anger. Managing that possibility is tiring. The path of least resistance is to say something vague and move on.</p><p>The <em>second</em> is uncertainty about whether the feedback will be received as intended. The giver is not sure whether they will be seen as helpful or critical, supportive or undermining. This uncertainty, particularly in organizations where the culture around feedback is unclear, produces avoidance.</p><p>The <em>third</em> is the belief that it is not their place. In hierarchical organizations, feedback is understood to flow primarily downward. Giving feedback to a peer, or upward to someone senior, feels presumptuous. Many people withhold genuinely useful observations because they have not been explicitly invited to share them.</p><p>The <em>fourth</em>, and most honest, is simple selfishness. Giving good feedback takes effort, carries social risk, and produces benefit primarily for the recipient. The cost-benefit calculation, viewed narrowly, does not obviously favor doing it.</p><p><strong>What Changes When You Give It Well</strong></p><p>The professional who develops the skill of giving specific, timely, useful feedback to colleagues becomes progressively more valuable in any team context, in ways that are not immediately obvious.</p><p>They become a person others seek out for honest input before important communications, decisions, and presentations. This gives them visibility into a broader range of the organization’s work than their formal role would normally provide.</p><p>They build a reputation for being straight with people, which is different from and more valuable than a reputation for being nice. Colleagues who trust that you will tell them the truth bring you their real problems. That trust, accumulated over time, produces the kind of working relationships that make both parties significantly more effective.</p><p>They also tend to receive better feedback themselves. Feedback norms in teams are reciprocal. People who give it specifically and skillfully tend to create environments where others do the same, which means their own blind spots are more likely to be named while there’s still time to address them.</p><p><strong>The Delivery Framework That Actually Works</strong></p><p>Good feedback has four components, delivered in order.</p><p><strong>Specific situation.</strong> Not <em>when you give presentations</em> but <em>in the client review last Tuesday.</em> The specific context grounds the feedback in observable reality rather than general impression and prevents the recipient from dismissing it as a broad character judgment.</p><p><strong>Observed behavior.</strong> What you actually saw or heard, described without interpretation or judgment. Not <em>you seemed unprepared</em> but <em>you referenced slides three and seven by the wrong content twice and had to ask the client to give you a moment to find the right section.</em> The behavior is verifiable. The interpretation is arguable. Use the behavior.</p><p><strong>Impact. </strong>What the observed behavior produced. On the client, on the team, on the outcome. <em>The client asked twice whether we had reviewed the materials before the meeting</em> is a specific impact statement. “<em>It didn’t look professional</em> is a general impression. The impact statement shows the recipient why the feedback matters, which makes them more receptive to it.</p><p>One specific suggestion. Not a comprehensive development plan. The single most useful thing the person could do differently in the next similar situation. <em>Before the next client review, I would walk through the deck once specifically to make sure the sequence matches how you plan to present it</em> is specific enough to act on.</p><p>The complete delivery takes less time than most people expect. The details make it feel longer than they are. The reception, because the recipient can see exactly what was observed and exactly what to do about it, is markedly different from the vague or blunt alternatives.</p><p><strong>The Cultural Effect of Doing It Consistently</strong></p><p>Teams where specific, honest feedback is a regular practice rather than an occasional event develop a quality of professional honesty that grows over time. People in those teams improve faster, because the feedback loop between behavior and impact is short and reliable. They make fewer costly mistakes in public, because someone told them about the pattern in private before it became a public problem. They trust each other more, because they know that what they hear from colleagues is honest rather than managed.</p><p>Building that culture doesn’t require a formal feedback program or a management initiative. It requires a few people who have decided to give the feedback that matters when they have it, delivered with enough skill that it can be heard.</p><p>That decision is available to anyone. The skill required to act on it well is learnable. The return, for the person receiving it and for the team it is given in, is consistent and significant.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Leadership, #Management, #Business, #Career, #Quality, #Professional Development</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=5e6f81328e9d" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[The Difference Between a Manager and a Leader Is Not What You Think]]></title>
            <link>https://medium.com/@jdbuzzman79/the-difference-between-a-manager-and-a-leader-is-not-what-you-think-894e92f21e2c?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/894e92f21e2c</guid>
            <category><![CDATA[careers]]></category>
            <category><![CDATA[business]]></category>
            <category><![CDATA[management]]></category>
            <category><![CDATA[leadership]]></category>
            <category><![CDATA[professional-development]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Sat, 09 May 2026 13:01:01 GMT</pubDate>
            <atom:updated>2026-05-09T13:01:01.458Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3oHaSMRfIWHbq6qJcEDP5A.jpeg" /></figure><p>The management versus leadership debate has generated more business writing than almost any other topic, and most of it produces the same conclusion in different packaging. Management is transactional and operational, leadership is transformational and visionary. Managers maintain. Leaders change. Managers enforce. Leaders inspire.</p><p>This framing isn’t wrong. It’s incomplete in a way that causes real harm to the professionals who absorb and accept it.</p><p>The harm comes from implicit hierarchy. Leadership is positioned as the superior version of the activity, the thing you graduate into when you have outgrown mere management. This leads capable managers to devalue the skills that make them effective in their current role in favor of performing the behaviors associated with leadership. It leads developing leaders to abandon the management discipline they need in order to appear strategic and visionary.</p><p>The more useful framing is that management and leadership are two distinct sets of activities, both of which are necessary, neither of which substitutes for the other, and both of which require deliberate development.</p><p><strong>What Management Actually Is</strong></p><p>Management is the discipline of producing reliable outcomes through people, processes, and systems. It includes setting clear expectations and verifying they are understood. Planning work and allocating resources to it realistically. Monitoring progress and identifying variance from plan before it becomes a crisis. Removing the obstacles that prevent capable people from doing their jobs. Developing team members’ skills in the specific areas the work requires. Maintaining the process discipline and documentation that make performance consistent.</p><p>Done well, management is invisible. The work gets done. Quality is maintained. Commitments are met. Problems surface early enough to be addressed without drama. The team feels clear about what is expected, supported in meeting the expectation, and confident that variance from the plan will be handled constructively.</p><p>Done poorly, management is very visible. Missed commitments. Rework from unclear expectations. Problems that grew large because no one was watching. People who feel unsupported, unclear, or uncertain about what success looks like for them personally.</p><p>The quality of management on a team is probably the strongest single predictor of whether that team consistently meets its objectives, at every level of organizational complexity.</p><p><strong>What Leadership Actually Is</strong></p><p>Leadership is the discipline of direction and change. It involves understanding where the organization needs to go and making that direction compelling enough that people commit to it. Navigating the human and organizational complexity of significant change. Building alignment across people and groups with different interests and perspectives. Making decisions under genuine uncertainty and maintaining the team’s confidence through difficulty. Connecting the daily work to a purpose that sustains engagement through the inevitable difficult stretches.</p><p>Leadership operates on a longer time horizon than management. Its outputs are slower to materialize and harder to connect to specific actions. A management failure shows up in this quarter’s metrics. A leadership failure shows up in the organization’s over years.</p><p>Done well, leadership creates teams and organizations that are moving in the right direction with genuine commitment rather than compliance, that can navigate change without losing coherence, and that have a collective sense of purpose that sustains performance when the immediate rewards are insufficient motivation.</p><p>Done poorly, leadership produces meandering, change initiatives that collapse into exhaustion, and teams that execute competently toward goals that no longer matter or never quite made sense.</p><p><strong>Why Both Are Required</strong></p><p>The failure mode of strong management without leadership is a well-run operation moving reliably in the wrong direction. The team meets every target, maintains every process, and hits every quarterly number while the strategy that makes those numbers meaningful slowly becomes irrelevant. Efficiency in the service of a failing strategy accelerates failure.</p><p>The failure mode of strong leadership without management is an inspiring vision executed chaotically. The strategy is correct. The direction is compelling. The team is motivated, and commitments are missed because no one was tracking them, quality drops because the process discipline that maintains it has been dismissed as bureaucracy, and talented people leave because the inspiring vision has not been accompanied clarity that allows them to be effective on a daily basis.</p><p>The most effective organizations at every scale have both, which requires that the people in positions of organizational responsibility develop both. Not one or the other. Not the one they are naturally inclined toward. Both.</p><p><strong>The Development Challenge</strong></p><p>Most people have a natural preference. The detail-oriented, process-minded professional is often drawn to management activities because they produce visible, measurable results in predictable timeframes. The vision-oriented, relationship-focused professional is often drawn to leadership activities because they produce the kind of change and inspiration that motivated them to pursue organizational responsibility in the first place.</p><p>The development challenge for each type is to develop genuine competence in the activity they are not naturally drawn to, not just sufficient familiarity with it.</p><p>For the strong manager, this means developing the tolerance for ambiguity that effective leadership requires, the ability to communicate direction in ways that produce commitment rather than compliance, and the patience for the longer feedback loops that organizational change produces.</p><p>For the strong leader, this means developing the discipline to define expectations specifically enough to be verified, to track progress closely enough to catch variance before it becomes a crisis, and to build the process rigor that makes the organization’s performance consistent rather than episodic.</p><p>Neither development path is comfortable. Each requires sustained effort of relative weakness. Both are available to anyone with honesty to see what needs more investment and the discipline to make it.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Leadership, #Management, #Business, #Career, #Quality, #Professional Development</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=894e92f21e2c" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[The Quiet Loss Nobody Talks About at Work]]></title>
            <link>https://medium.com/@jdbuzzman79/the-quiet-loss-nobody-talks-about-at-work-13c37a28b0eb?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/13c37a28b0eb</guid>
            <category><![CDATA[leadership]]></category>
            <category><![CDATA[business]]></category>
            <category><![CDATA[layoffs]]></category>
            <category><![CDATA[professional-development]]></category>
            <category><![CDATA[career-development]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Fri, 08 May 2026 13:01:03 GMT</pubDate>
            <atom:updated>2026-05-08T13:01:03.115Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*k2QsLGMXtMwcrdR67MF0PQ.jpeg" /></figure><p>There’s a quiet loss that doesn’t get talked about enough in the workplace.<br>It’s not just losing a job. It’s losing the people who knew you. The ones who saw you build something from nothing. Who remembered the late nights, the changes you made to improve things, the wins nobody announced in a meeting. The colleagues who could vouch for your value without you having to explain it. Then leadership changes. New faces arrive, and suddenly, your track record lives only in your own memory.</p><p>To those above you now, you’re just a line item, and possibly a more expensive one than someone they can bring in fresh.</p><p>It’s a reality that rarely gets named out loud. Companies don’t always let people go because of poor performance. Sometimes they let you go because the people who understood your performance are gone, and it’s simply cheaper to start over. That’s a painful thing to sit with.</p><p>It’s one of the hardest professional experiences to process, realizing that institutional knowledge and loyalty don’t always protect you. That your contributions can be quietly erased when the people who witnessed them move on.</p><p>You built something real. You showed up, adapted to the workload and changes, and invested yourself in work that mattered.</p><p>Organizations have short memories, especially when the faces at the top rotate out.</p><p>If you’re navigating this right now, you’re not imagining it, and your value didn’t disappear. It just needs a new place to be seen.</p><p>More importantly, remember this. You’re not defined by a role or a job title. A career chapter closing does not close the story. The next room you walk into will have people who have yet to see what you’re capable of, and that’s not a setback. That’s an opportunity.</p><p>Your track record belongs to you. Carry it forward.</p><p>#CareerTransition #WorkplaceReality #Leadership #Layoffs #ProfessionalGrowth</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=13c37a28b0eb" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Checklists Are for People Who Don’t Know What They Were Doing?]]></title>
            <link>https://medium.com/@jdbuzzman79/checklists-are-for-people-who-dont-know-what-they-were-doing-9868073d7f19?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/9868073d7f19</guid>
            <category><![CDATA[professional-development]]></category>
            <category><![CDATA[quality-assurance]]></category>
            <category><![CDATA[risk-management]]></category>
            <category><![CDATA[checklist]]></category>
            <category><![CDATA[safety]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Mon, 04 May 2026 13:01:03 GMT</pubDate>
            <atom:updated>2026-05-04T13:01:03.551Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ZozT3_WAoXebEEB_aukvog.jpeg" /></figure><p>If you were truly an expert at something, you don’t need a list to tell you what to do, right? You know what you’re doing. The checklist is a crutch for the inexperienced.</p><p>I read Atul Gawande’s research on surgical checklists and you can find it online if you wish to review it. The study documented introduced a 19-item checklist to operating rooms in hospitals across eight countries, ranging from a major hospital in London to a rural facility in Tanzania. The result, across all eight sites, was a 36 percent reduction in major complications and a 47 percent reduction in deaths.</p><p>The surgeons in those operating rooms were not inexperienced. They were the people society entrusted with the highest-stakes technical work human beings perform on each other. A 19-item list that took less than two minutes to complete was saving lives that their expertise alone was not.</p><p>That alone is a reason to rethink you position on checklists.</p><p><strong>What Gawande Actually Found</strong></p><p>The research did not find that surgeons were incompetent without checklists. It found something more specific and more interesting; that expert performance under complexity and time pressure is vulnerable to specific categories of failure that expertise alone cannot prevent.</p><p>The failures the checklist was designed to address were not technical errors. They were coordination failures. The wrong patient, wrong site, or the wrong procedure. They were communication failures such as the team didn’t know each other’s names, the anesthesiologist did not know about the patient’s drug allergy, the surgeon didn’t know the blood bank had been notified. They were memory failures under pressure. A step was skipped not because no one knew it was required but because attention was divided and the step didn’t surface in the moment it was needed.</p><p>These are not the failures of people who don’t know what they’re doing. They are the failures of complex systems operating at the limits of human capacity. The checklist doesn’t replace expertise.</p><p><strong>The Underlying Principle</strong></p><p>There are two categories of professional failure that require two very different responses.</p><p><strong>Failures of knowledge and skill: </strong>Situations where the person didn’t know the right thing to do or couldn’t do it competently. These are addressed by training, education, and deliberate practice. A checklist does nothing for them.</p><p><strong>Failures of execution: </strong>Situations where the person knew exactly what to do and did not do it, or did it in the wrong order, or forgot a step under pressure. These are addressed by external support structures that do not depend on memory and attention remaining perfect under conditions where memory and attention are reliably imperfect. Checklists are designed for this second category.</p><p>Aviation is another high-risk industry and understood this decades before medicine did. The pre-flight checklist is not used because pilots don’t know how to fly the plane. It is used because the consequences of a missed step are catastrophic and irreversible, and the risk of human memory failing under routine operational conditions is well established. Every takeoff follows the same checklist regardless of how many hours the pilot has logged.</p><p><strong>Where This Applies Outside Aviation and Medicine</strong></p><p>The cases where checklists save lives are the most dramatic illustrations of the principle. The principle extends to any situation where the combination of high stakes, procedural complexity, and human cognitive limits under pressure creates meaningful risk of execution failure.</p><p>The financial auditor running a year-end close. The IT team deploying a production update. The construction crew completing a pre-pour inspection. The quality rep performing an inspection. The clinical trial coordinator enrolling a study participant. In each of these contexts, a missed step has real consequences. In each of them, the professional performing the work is expert. In each of them, expertise alone is not sufficient to prevent execution failure reliably across thousands of repetitions.</p><p>The question for any high-stakes procedural context is not whether a checklist would be useful. The question is what the cost of execution failures has been, what proportion of those failures involved missed or incorrectly sequenced steps, and whether the investment in a well-designed checklist is proportionate to the cost of not having one.</p><p><strong>What Makes a Checklist Work</strong></p><p>The design matters. Gawande’s surgical checklist wasn’t a comprehensive list of everything that should have happened in a surgery. It was a targeted list of the specific steps that were most commonly missed and most consequential when they were.</p><p>A checklist too long to be used consistently will not be used consistently. A checklist that includes obvious steps the expert will resent verifying loses the expert’s engagement with the steps that actually matter. A checklist that was designed by someone who doesn’t do the work will miss the potential or actual failure that practitioners know about and include steps that don’t address real risk.</p><p>The professionals most qualified to design a checklist for a given process are the ones who run it regularly and have seen where it fails. Involving them in the design is not a courtesy. It’s the difference between a checklist that gets used and one that gets ignored.</p><p>No one should think checklists are for people who don’t know what they are doing. They are simply for people who understand that knowing what to do is not the same as reliably doing it under every condition the real world provides, and who care enough about outcomes to use every available tool to close the gap.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Leadership, #Safety, #Business, #Risk Management, #Quality, #Checklists, #Professional Development</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=9868073d7f19" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Why the Best Organizations Treat Near-Misses Like Gold]]></title>
            <link>https://medium.com/@jdbuzzman79/why-the-best-organizations-treat-near-misses-like-gold-dd115e4d312b?source=rss-1c832fe420b7------2</link>
            <guid isPermaLink="false">https://medium.com/p/dd115e4d312b</guid>
            <category><![CDATA[leadership]]></category>
            <category><![CDATA[culture]]></category>
            <category><![CDATA[safety]]></category>
            <category><![CDATA[risk-management]]></category>
            <category><![CDATA[quality-assurance]]></category>
            <dc:creator><![CDATA[Justin Buzzard- Tired QA Guy]]></dc:creator>
            <pubDate>Sat, 02 May 2026 13:01:01 GMT</pubDate>
            <atom:updated>2026-05-02T13:01:01.891Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*kEbJOqotGmtm2fCgrLzcCw.jpeg" /></figure><p>A near miss is an event that came close to producing a failure or incident but didn’t. The wrong medication was drawn up and caught before it was administered. The shipment was packed incorrectly, and an error was found before it left the facility. The code was deployed with a critical bug that a monitoring alert caught before any customer was affected. The financial report had an error that the second reviewer identified before it was sent.</p><p>In most organizations, the near miss is treated as good news and largely forgotten. Nothing bad happened. Someone is relieved. Life goes on.</p><p>In the organizations that have the best long-term safety and quality records across every industry, the near miss is treated as something closer to the most valuable quality event that occurred that week.</p><p>The reasoning is not complicated, but the implications are significant.</p><p><strong>Why Near-Misses Are More Valuable Than Failures</strong></p><p>When a failure occurs, two things happen simultaneously. The system reveals a gap, which is useful information, and the cost of that revelation, in harm to customers, in rework, in regulatory consequence, in relationship damage, is already being paid.</p><p>When a near miss occurs, the same information is revealed. A gap in the system’s defenses allowed the failure to almost occur, but the cost hasn’t been paid. The information is free. The defect was caught, the error was found, the patient was protected, and the organization has been handed a specific, real-world signal of where its system is vulnerable, at no cost beyond the attention required to investigate it.</p><p>This is the gold. A failure that reveals its cause without producing its consequence.</p><p>Organizations that investigate near misses with the same rigor they apply to actual failures accumulate a form of organizational learning that is unavailable to those that only learn from the failures themselves. They learn what their system’s vulnerabilities are before those vulnerabilities produce harm.</p><p><strong>Why Near-Misses Are Underreported</strong></p><p>The near miss is the most underreported event in most quality and safety systems, and the reasons are revealing.</p><p>The most <em>immediate reason</em> is relief. Something bad almost happened and didn’t. The emotional response is gratitude that the outcome was not worse, not curiosity about the chain of events that allowed it to almost occur. Relief is a powerful deactivator of investigative instinct.</p><p>The <em>second reason</em> is fear. In organizations where failures produce blame, near misses carry a version of the same risk. Reporting a near miss is voluntary disclosure of a process gap, a system failure, or a moment of human error that could have been worse. In cultures where the messenger of bad news is associated with the bad news, reporting near-misses feels like unnecessary exposure.</p><p>The<em> third reason</em> is effort. Investigating a near miss properly takes time. In organizations already stretched for capacity, the event that didn’t cause harm is easy to deprioritize in favor of the work that is already generating visible urgency.</p><p>Each of these reasons is understandable. Each of them, allowed to operate without a deliberate counter-effort, produces an organization that is blind to its own vulnerabilities until those vulnerabilities produce a failure that cannot be ignored.</p><p><strong>What a Near Miss Culture Looks Like</strong></p><p>The organizations that treat near misses as gold have made several specific choices that create the conditions for honest reporting and genuine learning.</p><p>They have separated reporting from accountability. Near miss reporting systems that are anonymous, or that explicitly separate the act of reporting from any personnel consequence for the reporter, produce significantly higher reporting rates than those that do not. The goal of near miss investigation is system improvement, not individual accountability. When those two goals are conflated in the reporting structure, system improvement loses.</p><p>They have made reporting easy. The near miss that requires a lengthy formal report to document is a near miss that will not be documented. A simple reporting mechanism, a short form, a verbal report to a designated person, a standing agenda item in team meetings, produces more reports than a comprehensive system that is too burdensome to use consistently.</p><p>They have demonstrated that reports lead to action. The most powerful driver of near miss reporting is visible evidence that previous reports were investigated and produced changes. When people can see that the near miss they reported last month resulted in a process change that prevents recurrence, they report the next near miss with confidence that doing so was worth it.</p><p>They’ve created a shared vocabulary. Teams that talk openly about near misses in meetings, where leadership shares examples of near misses they personally encountered and what was learned, normalize the behavior. The near miss stops being a near-scandal and becomes professional information.</p><p><strong>The Investigation That Matters</strong></p><p>When a near miss is reported, the investigation should ask the same questions that a failure investigation would ask, with the same rigor.</p><p>What was the specific near-miss? What happened, in the sequence it happened, up to the point where the failure was prevented?</p><p>What prevented the failure? The catch mechanism, whether it was a person, a system check, a second review, or a unexpected circumstance, is as important as the failure mechanism. Understanding what saved the situation tells you where your actual defenses are.</p><p>Why did the near miss get as far as it did? The same root cause analysis tools that apply to actual failures apply here. A near miss that progressed through three steps before being caught tells you that three steps of your process didn’t stop it.</p><p>What systemic change would make recurrence less likely? Not retraining the individual who almost made the error. Redesigning the process so the error is less likely to occur or more likely to be caught earlier.</p><p>The organizations that ask these questions consistently, about near-misses as well as failures, know their vulnerabilities before those vulnerabilities cause harm. That knowledge is worth considerably more than the cost of investigating events that ended well.</p><p>Also follow my weekly newsletter on Quality, Business &amp; Life on Substack. Subscribe at <a href="https://substack.com/@jdbuzzard">https://substack.com/@jdbuzzard</a> &amp; LinkedIn where I post near daily <a href="https://www.linkedin.com/in/justinbuzzard/">https://www.linkedin.com/in/justinbuzzard/</a></p><p>All my social media links and website (<a href="https://justin.buzzard.com">https://justin.buzzard.com</a>) can be found at my Linktr.ee: <a href="https://linktr.ee/admin">https://linktr.ee/admin</a></p><p>#Leadership, #Safety, #Business, #Risk Management, #Quality, #Quality Culture, #Operations</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=dd115e4d312b" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>